# AI Agent Security Checklists and Permissions Register

The controls that decide whether an agent has earned more autonomy and whether you can stop it. Autonomy expansion criteria, a multi-agent trust hierarchy, a non-human identity register, scope-drift monitoring, and logged kill-switch propagation tests.

**Who this is for:** The security owner for agentic systems whose autonomy is growing.

Source playbook: https://aigovernance.com/playbook/ai-agent-security-controls

---

## Autonomy expansion approval criteria

_What must be true before an agent's scope grows, and who signs off at each tier._

### Template

| Autonomy tier | Minimum operating history | Max error rate over that window | Additional evidence | Sign-off required |
|---|---|---|---|---|
| Tier 1: read + draft | none (launch) | n/a | sign-off checklist | Business + Risk |
| Tier 2: reversible writes | <e.g. 60 days, 5,000 actions> | <e.g. < 1% blocked-gate rate, 0 Sev-1> | monitoring clean; red-team clean | + Security |
| Tier 3: irreversible external actions with confirmation | <e.g. 90 days at Tier 2> | <threshold> | tabletop of a bad action; kill-switch test | + Legal + exec sponsor |
| Tier 4: irreversible external actions autonomous | case by case | <threshold> | dedicated security assessment | full committee |

### Worked example

> support-copilot request: Tier 1 to Tier 2 (allow KB article edits).

| Criterion | Value | Meets threshold? |
|---|---|---|
| Operating history | 74 days, 11,200 actions | Yes (>= 60 days / 5,000 actions) |
| Blocked-gate rate | 0.4% | Yes (< 1%) |
| Sev-1 incidents | 0 | Yes |
| Sev-2 incidents | 1 (F-1, fixed) | acceptable; 30 days clean since |
| Red-team | v1.6.1 cleared | Yes |
| Sign-off | Head of Support, CRO, Head of Security | complete 2026-09-15 |

Outcome: approved; KB edits enabled behind human confirmation.

### Acceptance criteria

- Expansion criteria are defined before any agent asks for more autonomy.
- Each tier has quantitative thresholds (history, error rate), not just a review.
- Higher tiers require additional sign-off, and Tier 4 requires a dedicated security assessment.

---

## Multi-agent trust hierarchy

_For systems where agents interact: whose instructions win, and what happens on conflict._

### Template

> One page plus a diagram. For any deployment with more than one agent.

- **Agents in the system:** each with its role and autonomy tier
- **Instruction precedence:** the order in which instruction sources are trusted (human operator > orchestrator > peer agent > tool output > retrieved content)
- **Delegation rules:** which agent may instruct which, and what it may not delegate (an agent cannot grant another agent more authority than it holds)
- **Conflict resolution:** what happens when two agents receive or issue conflicting directives (halt and escalate, defer to higher tier, operator decides)
- **Untrusted input rule:** content from tools, retrieval, or external sources is never treated as an instruction
- **Logging:** every cross-agent instruction is logged with both identities

### Worked example

- **Agents:** orchestrator (Tier 2), research sub-agent (Tier 1, read only), drafting sub-agent (Tier 1).
- **Precedence:** human operator > orchestrator > sub-agent output > tool output > web content.
- **Delegation:** the orchestrator may task sub-agents within its own scope; sub-agents cannot spawn further agents; no sub-agent can perform a write.
- **Conflict:** if the research and drafting sub-agents return contradictory facts, the orchestrator halts the task and surfaces both to the operator rather than picking one.
- **Untrusted input:** text fetched from the web is passed to sub-agents as data with an explicit "not instructions" wrapper.
- **Logging:** orchestrator-to-sub-agent tasks logged with both service identities.

### Acceptance criteria

- Instruction precedence is written down and puts human and orchestrator above peer agents and any input content.
- An agent cannot delegate authority it does not have.
- Conflicts halt and escalate rather than resolving silently.

---

## Non-human identity register

_Every agent, sub-agent, and spawned process has its own identity with an expiry and a re-certification date._

### Template

| Identity | Belongs to | Parent identity | Scopes | Created | Expires | Re-certification due | Owner |
|---|---|---|---|---|---|---|---|
| <id> | <agent / sub-agent / job> | <parent or none> | <scopes> | YYYY-MM-DD | YYYY-MM-DD | YYYY-MM-DD | <name> |

### Worked example

| Identity | Belongs to | Parent | Scopes | Created | Expires | Re-cert due | Owner |
|---|---|---|---|---|---|---|---|
| svc-orchestrator-prod | orchestrator | none | task queue; sub-agent spawn | 2026-06-01 | 2027-06-01 | 2026-12-01 | Platform |
| svc-research-prod | research sub-agent | svc-orchestrator-prod | web fetch; kb:read | 2026-06-01 | 2027-06-01 | 2026-12-01 | Platform |
| tmp-run-8841 | spawned run | svc-orchestrator-prod | inherits research scope; 1h TTL | 2026-09-05 | 2026-09-05 | n/a | auto |

### Acceptance criteria

- Every agent, sub-agent, and spawned process resolves to a distinct identity.
- Each identity has an expiry and a re-certification date, treated like a service account.
- Spawned short-lived identities inherit no more scope than their parent and carry a TTL.

---

## Credential and permission scope-drift monitoring

_Alert when an agent's effective permissions grow beyond its task definition, not only when it hits a hard limit._

### Template

| Signal | Definition | Alert threshold | Response |
|---|---|---|---|
| New scope granted | Any permission added to an agent identity | any change | review against task definition within 24h |
| Scope broader than task definition | Effective permissions exceed the documented task spec | any delta | open a finding; revoke or update the spec |
| Unused broad scope | A granted scope not exercised in <N> days | 30 days | remove at next review |
| Cross-resource access | Agent accessed a resource outside its declared targets | any | block and investigate |
| Spawned identity scope | A child identity requested more than the parent holds | any | deny; alert |

### Worked example

| Signal | This period | Threshold | Action |
|---|---|---|---|
| New scope granted | svc-research-prod gained "kb:write" | any change | Reviewed: not in task spec (research is read-only). Revoked 2026-09-06; traced to a mis-scoped Terraform change. |
| Unused broad scope | orchestrator "admin:read" unused 45 days | 30 days | scheduled for removal |
| Cross-resource access | none | any | - |

### Acceptance criteria

- Monitoring compares effective permissions to a documented task definition, not just a hard-coded ceiling.
- Any scope increase triggers a review within a set time.
- Findings are remediated by revoking scope or updating and re-approving the task definition.

---

## Kill-switch propagation test log

_Evidence that stopping the top-level agent actually stops every sub-agent and spawned process._

### Template

| Test date | Scope | Sub-agents / processes expected | Reached by kill switch | Gaps found | Fix | Re-test date |
|---|---|---|---|---|---|---|
| YYYY-MM-DD | <deployment> | <count / list> | <count> | <what did not stop> | | YYYY-MM-DD |

### Worked example

| Test date | Scope | Expected | Reached | Gaps | Fix | Re-test |
|---|---|---|---|---|---|---|
| 2026-08-30 | orchestrator + 2 sub-agents + spawned runs | 1 orchestrator, 2 sub-agents, up to 5 runs | orchestrator + 2 sub-agents; 3 of 5 runs | 2 in-flight runs on a worker node finished their current tool call before stopping (up to 20s) | add a hard interrupt check between tool calls | 2026-09-20 |
| 2026-09-20 | same | same | all, within 3s | none | - | 2026-12-20 |

### Acceptance criteria

- The kill switch is tested against the real deployment topology, including spawned processes.
- Every gap (something that did not stop, or stopped slowly) has a fix and a re-test.
- The test is repeated on a cadence and after topology changes.

---

## Governance controls this kit produces evidence for

- **AGT-017**: The expansion criteria table is the agentic autonomy expansion criteria and sign-off log.
- **AGT-004**: The trust hierarchy document is the multi-agent trust hierarchy with conflict-resolution rules.
- **AGT-009**: The kill-switch test log is the kill-switch propagation testing evidence.
- **AGT-011**: The scope-drift monitoring is the agent permission and OAuth scope-drift detection.
- **AGT-022**: The NHI register and test logs are the written attestation of which agentic governance controls are actually enforced.