> For the complete documentation index, see [llms.txt](https://docs.bluerock.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bluerock.io/policy-configuration/policy-life-cycle.md). # Policy Life cycle The complete lifecycle of a policy is as follows: | Stage | Component | Description | | ----------------------------------- | ------------------------- | --------------------------------------------------- | | Policy Authoring | JSON Format / TREX Tool | Generating the Policy template/modifying the Policy | | Generating Signed Policy Blob | Key Pairs / TREX Tool | Policy integrity protected | | Publishing the Policy Blob | Cloud Storage (AWS / GCP) | Policy uploaded | | Download, Validate and Apply Policy | BlueRock Control Plane | Verification of Policy Signature and Policy syntax | | Enforcement | BlueRock Control Plane | Rules are evaluated at Program Run-time | | Observability | BlueRock Control Plane | Source Events and Violations are logged | ### Policy Source Configuration The BlueRock Control Plane service fetches and loads the configuration using the URL specified in the configuration source file: `s3://us-east-2@bru-config-bucket/config.yaml` The BlueRock Control Plane configuration file defines the following parameters: • Policy storage bucket name\ • Policy file name\ • Policy signature file name\ • Public key file used for signature verification\ • Storage bucket region\ • Event format used for telemetry export (for example OTEL)\ • Event endpoint URL used for sending observability events If the signature validation fails, the policy will not be loaded. Example configuration: ```yaml event_format: OTEL event_url: http://OTEL_IP:4318 ucpcm: policy_url: s3:/// policy: policy.json policy_sig: policy.json.sig public_key: s3:///pol_pubkey.pem transport: transport_type: s3 auth_method: default region: us-east-2 ``` *** ### When a Policy Is Applied Policies are applied at runtime by the BlueRock Control plane service. The service periodically checks the configured cloud policy location for updates and loads the latest valid policy. Policy application occurs in the following situations: 1. When the BlueRock Control plane service starts or restarts. 2. When a newer policy version is detected in the configured cloud storage location during periodic checks. #### Policy Loading Workflow 1. The BlueRock Control plane service reads the `config.yaml` configuration file. 2. It connects to the configured policy storage location (for example an S3 bucket). 3. The service checks whether a newer policy version is available. 4. If a new version is detected, the policy package is downloaded. 5. The policy signature is verified using the configured public key. 6. If verification succeeds, the policy configuration is validated. 7. The validated policy is applied to the BlueRock sensors (App Sensors and Kernel Sensors) for runtime enforcement. 8. Sensors generate MCP events and evaluate them against the configured policy rules during MCP client–server interactions. 9. Violations are exported through OpenTelemetry (OTEL) using OTLP streams to external observability systems such as AWS CloudWatch or Google LogExplorer. If signature verification or policy validation fails, the policy is rejected and the system continues using the previously active or default built-in policy. *** ### Enforcement Modes Policies support two enforcement modes: | Mode | Behavior | | ------------------------- | ------------------------------------------ | | observe (remediate:false) | Log violations but allow program execution | | enforce (remediate:true) | Block program execution and log violation | *** ## Policy Generation and Signing using TREX tool *** ## Validation Overview After uploading the policy artifacts and restarting the BlueRock Control plane service, validation should confirm that the policy was successfully retrieved, verified, and applied by the BlueRock runtime. Validation includes the following checks: 1. Confirm BlueRock Control plane service is running 2. Confirm policy download and signature verification in runtime logs 3. Confirm policy lifecycle events in CloudWatch (OTEL telemetry) 4. Trigger rule condition 5. Confirm runtime activity after policy execution *** ## 1. Confirm BlueRock Control plane Service Is Running Verify that the BlueRock Control plane service is running on the instance. ```shellscript sudo systemctl status uc-docker.service ``` Example output: ```shellscript ● uc-docker.service - Manage the Ultracontrol Docker Service Loaded: loaded (/etc/systemd/system/uc-docker.service; disabled; preset: disabled) Active: active (running) since Wed 2026-03-04 12:43:28 UTC Main PID: 3714 (uc-docker.sh) Tasks: 2 Memory: 2.4M CPU: 4.843s CGroup: /system.slice/uc-docker.service ├─3714 /usr/bin/bash /opt/bluerock/bin/uc-docker.sh start └─4055 sleep 5 Mar 04 12:43:28 ip-172-31-22-98.us-east-2.compute.internal systemd[1]: Started uc-docker.service - Manage the Ultracontrol Docker Service. Mar 04 12:43:28 ip-172-31-22-98.us-east-2.compute.internal uc-docker.sh[3714]: starting uc container with ultracontrol:latest image Mar 04 12:43:28 ip-172-31-22-98.us-east-2.compute.internal uc-docker.sh[3714]: uc container started successfully.This confirms that the BlueRock Control Plane service is active and running. ``` This confirms that the BlueRock Control Plane service is active and running. *** ## 2. Confirm Policy Download and Signature Verification in Runtime Logs Check the BlueRock Control Plane service logs to confirm that the policy has been downloaded and applied. ```shellscript /opt/bluerock/bin/uc-docker.sh logs ``` Example output: ```shellscript 2026-03-04T12:43:28.302213+00:00 ip-172-31-22-98 kernel: brs_policy: Cleared brs_configuring_task (was PID 3644) 2026-03-04T12:43:29.308937+00:00 ip-172-31-22-98 bluerockd.sh: Starting bluerockd.sh 2026-03-04T12:43:29.322074+00:00 ip-172-31-22-98 bluerockd.sh: Bluerockd starting 2026-03-04T12:43:34.573057+00:00 ip-172-31-22-98 kernel-sensor.sh: starting kernel-sensor.sh 2026-03-04T12:43:34.585662+00:00 ip-172-31-22-98 kernel-sensor.sh: launching kernel-sensor 2026-03-04T12:43:34.593384+00:00 ip-172-31-22-98 kernel: brs_policy: Updated brs_configuring_task to point to PID 3851 2026-03-04T12:43:34.732971+00:00 ip-172-31-22-98 kernel: BR config: Loaded a policy of 2248 bytes ``` The log entry below confirms that the BlueRock runtime successfully loaded the generated policy: ``` BR config: Loaded a policy of 2248 bytes ``` *** ## 3. Confirm Policy Lifecycle Events in CloudWatch (OTEL Telemetry) BlueRock emits OpenTelemetry (OTEL) telemetry events during the policy lifecycle process. These events provide visibility into policy retrieval, validation, and application during runtime startup. To verify these events: 1. Open the **AWS CloudWatch Console** 2. Navigate to: ```shellscript Logs → Log groups ``` 3. Open the BlueRock telemetry log group: ```shellscript bluerock-premium-1-TelemetryLogGroup ``` 4. Select the latest log stream: ```shellscript bluerock-premium-1-TelemetryLogStream ``` 5. Locate the policy lifecycle events generated during service startup. These events are emitted by the **BlueRock Control Plane - Policy Control Manager (PCM)** component running on the deployed EC2 instance. *** ## Example OTEL Policy Lifecycle Events #### Policy Download Attempt ```json { "body": { "action": "policy_download_attempt", "delay": 300, "error": null, "startup_state": "WarmStartup" }, "severity_text": "INFO", "attributes": { "domain": "pcm", "event_name": "policy_lifecycle", "hostid": "bluerocknode1-ip-10-0-1-54" }, "scope": { "name": "uc-pcm" }, "resource": { "service.name": "bluerock" } } ``` *** #### Policy Download Started ```json { "body": { "action": "policy_download_started", "startup_state": "WarmStartup" }, "severity_text": "INFO", "attributes": { "event_name": "policy_lifecycle" } } ``` *** #### Policy Download Completed ```json { "body": { "action": "policy_download_completed", "error": null, "startup_state": "WarmStartup" }, "severity_text": "INFO", "attributes": { "event_name": "policy_lifecycle" } } ``` *** #### Policy Download Success ```json { "body": { "action": "policy_download_success", "delay": 300, "error": null, "startup_state": "WarmStartup" }, "severity_text": "INFO", "attributes": { "event_name": "policy_lifecycle" } } ``` *** This sequence confirms that the BlueRock Control Plane successfully downloaded, validated, and applied the configured runtime policy. *** ## **4. Confirm Runtime Policy Is Loaded** Check the UltraControl runtime logs to confirm that the policy has been successfully loaded. Example command: ```shellscript /opt/bluerock/bin/uc-docker.sh logs ``` Example output: ```shellscript 2026-03-04T12:43:34.593384+00:00 ip-172-31-22-98 kernel: brs_policy: Updated brs_configuring_task to point to PID 3851 2026-03-04T12:43:34.732971+00:00 ip-172-31-22-98 kernel: BR config: Loaded a policy of 2248 bytes ``` This confirms that the runtime policy engine has successfully loaded the configured policy. ## 5. Trigger Rule Condition Run commands that generate runtime activity to trigger policy evaluation and produce event logs for any policy violations (WARN or ERROR). Example command: ```shellscript curl http://example.com ``` This command generates a network request event, allowing the runtime policy engine to evaluate activity on the host. *** ## **6. Verify Policy Evaluation in Logs** Re-check the runtime logs to confirm that the rule evaluation and any violations are recorded. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.bluerock.io/policy-configuration/policy-life-cycle.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.