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:

event_format: OTEL
event_url: http://OTEL_IP:4318
ucpcm:
  policy_url: s3://<policybucket>/
  policy: policy.json
  policy_sig: policy.json.sig
  public_key: s3://<policybucket>/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.

sudo systemctl status uc-docker.service

Example output:

● 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.

/opt/bluerock/bin/uc-docker.sh logs

Example output:

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:

Logs → Log groups

1. Open the BlueRock telemetry log group:

bluerock-premium-1-TelemetryLogGroup

1. Select the latest log stream:

bluerock-premium-1-TelemetryLogStream

1. 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

{
  "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

{
  "body": {
    "action": "policy_download_started",
    "startup_state": "WarmStartup"
  },
  "severity_text": "INFO",
  "attributes": {
    "event_name": "policy_lifecycle"
  }
}

---

Policy Download Completed

{
  "body": {
    "action": "policy_download_completed",
    "error": null,
    "startup_state": "WarmStartup"
  },
  "severity_text": "INFO",
  "attributes": {
    "event_name": "policy_lifecycle"
  }
}

---

Policy Download Success

{
  "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:

/opt/bluerock/bin/uc-docker.sh logs

Example output:

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:

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.