# Agent authority review

Fill this in for one agent or one delegation chain. The fields are the ones the article argues every autonomous action should carry.

**Agent / system reviewed:** ____________________

## Task identity

| Field | Value |
| --- | --- |
| Original human principal |  |
| Agent identity |  |
| Purpose |  |
| Capabilities |  |
| Restrictions |  |
| Spending limits |  |
| Expiration |  |
| Delegation depth |  |

**Do privileges only move down the delegation chain?** ____________________

## Memory provenance

| Memory item | Where did it come from? | Who created it? | How trustworthy was the source? | When was it created? | Independently verified? | Can it influence actions? |
| --- | --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |  |
|  |  |  |  |  |  |  |
|  |  |  |  |  |  |  |
|  |  |  |  |  |  |  |

## Context provenance

| Context source | Trust | Can provide information | Can change objective | Can authorize actions |
| --- | --- | --- | --- | --- |
|  |  |  |  |  |
|  |  |  |  |  |
|  |  |  |  |  |
|  |  |  |  |  |

## Agent Bill of Materials

| Component | Identifier | Software version | Cryptographic hash |
| --- | --- | --- | --- |
| Model |  |  |  |
| Runtime |  |  |  |
| Tools |  |  |  |
| MCP servers |  |  |  |
| Policies |  |  |  |
| Memory stores |  |  |  |
| Container |  |  |  |
| Connectors |  |  |  |

## Behavioral signals to monitor

| Signal | Baseline | Alert threshold | Response |
| --- | --- | --- | --- |
| Documents read |  |  |  |
| HR record queries |  |  |  |
| Contact with a domain never used before |  |  |  |
| Sub-agents spawned |  |  |  |
| Modification of its own configuration |  |  |  |
| API usage |  |  |  |

**Isolate agent procedure (disable network, revoke capabilities, freeze memory writes, stop jobs, preserve evidence):** ____________________

## Policy envelope

Write the standing authority as one sentence, following the article's example: my travel agent can purchase domestic airfare under $1,500 through approved vendors until Friday.

| Element | Value |
| --- | --- |
| Agent |  |
| Action permitted |  |
| Scope or limit |  |
| Approved channels or vendors |  |
| Expires |  |
| Escalation path outside the envelope |  |

**Policy statement:** ____________________

**Approved by / date:** ____________________

## Verification

Record what was tested, not only what was designed.

| Test | Method | Result / date | Exception and owner |
| --- | --- | --- | --- |
| Expiration: the agent cannot act after its authority lapses |  |  |  |
| Revocation: capabilities removed mid-task stop taking effect within the agreed time |  |  |  |
| Delegation: a sub-agent cannot obtain more than its parent holds |  |  |  |
| Goal hijack: planted instructions in a document, message, or web page do not change the objective |  |  |  |
| Memory: an unverified memory item cannot alone authorize an action |  |  |  |
| Spending: the limit is enforced by the broker or provider, not only by the agent's own reasoning |  |  |  |
| Escalation: an action outside the envelope reaches a named human, and the request is logged |  |  |  |

## Operating record

**Who approves changes to the envelope, and where the change history is kept:** ____________________

**Incident owner if the agent acts outside its authority, and what is preserved first:** ____________________

**Review cadence / triggers (new tool, new data source, new delegation, provider or model change, incident):** ____________________

## Common failure modes

- The envelope is written once and widened informally through new tools.
- Delegation depth is set but never tested, so a sub-agent inherits everything.
- Memory items written by the agent are trusted as much as instructions from the principal.
- Behavioral baselines are never recorded, so drift cannot be seen.

This review covers one agent's authority and provenance. It does not cover the deployment environment; use the deployment checklist for that.