Implementation Kit
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.
1. Autonomy expansion approval criteria
SpreadsheetWhat 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.
2. Multi-agent trust hierarchy
DocumentFor 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.
3. Non-human identity register
SpreadsheetEvery 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.
4. Credential and permission scope-drift monitoring
SpreadsheetAlert 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.
5. Kill-switch propagation test log
SpreadsheetEvidence 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
Completing the artifacts above gives you a head start on the evidence requirements for these controls.
The expansion criteria table is the agentic autonomy expansion criteria and sign-off log.
The trust hierarchy document is the multi-agent trust hierarchy with conflict-resolution rules.
The kill-switch test log is the kill-switch propagation testing evidence.
The scope-drift monitoring is the agent permission and OAuth scope-drift detection.
The NHI register and test logs are the written attestation of which agentic governance controls are actually enforced.
This kit backs one playbook. Read the full guidance for the reasoning behind each artifact.
Decide what to implement next
Assess your governance gaps, then create an action plan with owners and target dates. Build and export without an account; sign in when you want to save your plan.
Start the AI governance assessment →