# Agent observation and containment review

Run this in one sitting for a single agent deployment. Every item comes from the article; the blanks record what you found, not what you intend.

**Deployment reviewed / owner:** ____________________

**Date of review:** ____________________

## Relays and transitive egress

- [ ] Every internal service the sandbox can reach is listed below (package mirrors, caches, artifact stores, wikis, anything else).
- [ ] For each service, both questions were answered by a test from inside the sandbox, not from documentation.
- [ ] Every service with two yes answers has a control applied or has been removed from the sandbox's reach.
- [ ] From inside the sandbox, an attempt was made to reach an outside host through each reachable service, and the result is recorded per service.

| Reachable internal service | Agent can write there? | Can reach the internet for the agent? | Relay? | Control applied or removed | Tested on |
| --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |

## Telemetry the runtime emits

- [ ] Every tool call, with its arguments
- [ ] Every denied action, with the reason
- [ ] Every network destination attempted, not only those allowed
- [ ] Every credential requested
- [ ] Step count and elapsed time per task
- [ ] Every write to shared infrastructure
- [ ] Telemetry is shipped off the host before the agent finishes
- [ ] The store is append-only for the agent's identity
- [ ] From inside the sandbox, an attempt to alter or delete the agent's own log failed and was itself recorded

**Where telemetry lands / who owns the store:** ____________________

## Who watches it

- [ ] Alerts come from the identity provider (unusual API calls, new roles, token issuance), not only from the runtime.
- [ ] Alerts come from the network layer (denied egress, unexpected destinations, port sweeps), not only from the runtime.
- [ ] Writes by agents to shared services are correlated across agents and runs, not reviewed one at a time.
- [ ] Alerts separate task-boundary crossings (a destination, credential, or write the task never called for) from ordinary sandbox noise.
- [ ] A named person receives each class of alert.

| Alert source | Signal watched | Who receives it | Confirmed on |
| --- | --- | --- | --- |
| Identity provider |  |  |  |
| Network layer |  |  |  |
| Agent runtime |  |  |  |
| Shared services |  |  |  |
|  |  |  |  |

## Independence of prevention, detection, and mitigation

Write down the three controls for each objective, then check whether any two share a component or an administrator.

| Objective | Prevention control | Detection control | Mitigation control | Shared component or admin? |
| --- | --- | --- | --- | --- |
| Agent reaches an unapproved host |  |  |  |  |
| Agent writes to shared infrastructure |  |  |  |  |
| Agent uses a credential outside its task |  |  |  |  |
| Agent escalates privilege inside its sandbox |  |  |  |  |
|  |  |  |  |  |

- [ ] No single configuration, gateway, or administrator account carries all three controls for any objective.

## Identity and path

- [ ] Every credential the agent or its services hold is listed below with its target service.
- [ ] For each, the answer to "reachable from where the holder runs?" comes from a test, not from a diagram.
- [ ] Where a target was reachable from anywhere, a network rule now requires a path as well as the credential.
- [ ] Crossings between networks, clusters, and regions are denied by default and allowed only where named.
- [ ] From a sandbox in one zone, an attempt to reach a control plane in another zone failed and was recorded.

| Credential held | Target service | Reachable from the holder's zone? | Rule that decides the path | Tested on |
| --- | --- | --- | --- | --- |
|  |  |  |  |  |
|  |  |  |  |  |
|  |  |  |  |  |
|  |  |  |  |  |

## Decoys

- [ ] Decoy credentials or lookalike resources are placed where a harvester would look (environment variables, configuration files, shared stores).
- [ ] Any touch of a decoy alerts a named person.
- [ ] The alert was tested by touching a decoy on purpose, and the time to a human seeing it is recorded.

**Decoys placed / alert owner / last test:** ____________________

## Duration breaker

- [ ] A normal task budget is defined in steps, tokens, or minutes.
- [ ] Exceeding the budget pauses the agent automatically and notifies a person.
- [ ] The threshold was tuned on real runs, and the count of false-alarm pauses is recorded.

**Budget / pause action / false alarms this period:** ____________________

## The 30-minute rule and the kill switch

- [ ] Any security alert involving the agent that cannot be ruled a false positive within 30 minutes results in a pause.
- [ ] The firm's cyber incident plan names who can pause and who can pull the kill switch, how long observation runs before action, and who makes the call to move forward.
- [ ] The people who can pause are named below, and each has confirmed they can do it from a phone.
- [ ] A kill-switch drill has been run, with the time from decision to full stop measured, including credential revocation.

**Who can pause:** ____________________

**Last drill date / time to full stop:** ____________________

## Tool-call review

- [ ] Second-model or human review of elevated tool calls is enabled on the platform.
- [ ] It was tested with a scripted action that should be blocked, such as a write to a shared store or a call to an unapproved host.
- [ ] The test result is recorded, and the action was in fact blocked or escalated.

**Scripted action used / result / date:** ____________________

## Public credential exposure and vendors

- [ ] A scheduled search runs for the firm's tokens and keys in public repositories, datasets, paste sites, and shared artifact stores.
- [ ] Anything found has been rotated, and the rotation is recorded.
- [ ] For platforms that publish their exposed-credential response (GitHub, AWS, Google Cloud, Microsoft Entra), the published behavior is recorded before asking.
- [ ] Each vendor that holds firm data has been asked how it would detect a valid token used quietly by a process that is not its owner.

**Search cadence / last run / findings:** ____________________

| Vendor holding firm data | Asked on | How it would detect a leaked token in automated use | Follow-up |
| --- | --- | --- | --- |
|  |  |  |  |
|  |  |  |  |
|  |  |  |  |
|  |  |  |  |

## Sign-off

**Reviewed by / date:** ____________________

**Next review date / change triggers (new tool, new credential, new reachable service, new model):** ____________________

This review covers observation and containment for a deployment that already exists. It does not decide whether the deployment should exist; use the OpenClaw deployment checklist and the agent authority review for that.