Does completing a governance checklist prove an AI agent is safe?

No. A separate reviewer must inspect the evidence and run production-equivalent negative-path, attribution, revocation, and successor-continuation tests.

Should every unattended AI agent have its own identity?

Yes. Use a named, single-purpose, revocable service identity so access and authorship remain attributable.

HHandover

Private browser assessment

AI agent governance checklist

Q: What belongs in an AI agent governance checklist?

Record ownership, purpose, risk, identity, least-privilege access, approval gates, evidence, negative tests, revocation, incident response, and offboarding.

Review identity, access, approval, evidence, verification, and offboarding controls before an agent reaches production.

Local to this tabExportable evidence record

Readiness signal

Not ready

13 required controls are still unresolved.

0complete13required blockers

Resolve next

RequiredA named business owner and technical owner are recorded.
SupportingPurpose, users, environment, and prohibited uses are explicit.
RequiredRisk is tiered by data, autonomy, reversibility, and impact.
RequiredThe agent has one named, single-purpose identity.

Preview assessment Markdown

# AI agent governance assessment: Unnamed AI agent

## Assessment summary
- Status: Not ready
- Controls marked complete: 0/18 (0%)
- Required controls unresolved: 13
- Generated: 2026-08-05

This is a self-assessment record, not proof of compliance or safety. A separate
reviewer must inspect the cited evidence and test the controls.

## Agent profile
- Agent: Unnamed AI agent
- Purpose: Not recorded
- Owner: Not recorded
- Environment: experimental
- Risk tier: 2
- Notes: None

## Inventory
- [ ] A named business owner and technical owner are recorded.
  Evidence expected: Inventory record with accountable people and review date.
- [ ] Purpose, users, environment, and prohibited uses are explicit.
  Evidence expected: Approved use-case statement and exclusions.
- [ ] Risk is tiered by data, autonomy, reversibility, and impact.
  Evidence expected: Risk decision with supporting reasoning.

## Identity and access
- [ ] The agent has one named, single-purpose identity.
  Evidence expected: Identity record that is distinct from human and shared tokens.
- [ ] Read, write, publish, delete, and admin scopes are separated.
  Evidence expected: Resource-level access matrix and denied-scope test.
- [ ] Search applies the same authorization rules as direct reads.
  Evidence expected: Negative test proving denied metadata is undiscoverable.
- [ ] Credentials stay outside prompts, URLs, source, and shared files.
  Evidence expected: Secret-store reference and rotation owner.

## Actions and approval
- [ ] Allowed tools, data inputs, outputs, budgets, and rate limits are bounded.
  Evidence expected: Tool matrix with enforced limits and expected failures.
- [ ] Consequential actions require attributable, scoped approval.
  Evidence expected: Approval record tied to action, resource, evidence, and expiry.
- [ ] Destructive or external actions have a tested stop and rollback path.
  Evidence expected: Recorded stop test and recovery result.

## Evidence and review
- [ ] Every material change names the authenticated human or agent.
  Evidence expected: Immutable history derived from the accepted credential.
- [ ] Objective, state, decisions, evidence, constraints, and next action persist.
  Evidence expected: Versioned continuation record with original artifacts.
- [ ] Human review is anchored to the exact artifact and revision.
  Evidence expected: Open, resolved, and superseded findings remain attributable.

## Verification
- [ ] Out-of-scope search, read, write, and publish attempts are denied.
  Evidence expected: Production-equivalent negative-path test results.
- [ ] A separately authenticated successor can verify and continue the work.
  Evidence expected: Read-back, evidence reproduction, and successor revision.
- [ ] Credential revocation stops API, CLI, and MCP access immediately.
  Evidence expected: Post-revocation failure across every active interface.

## Lifecycle
- [ ] An incident owner can identify the last trusted state and contain the agent.
  Evidence expected: Incident runbook with contact, containment, and recovery revision.
- [ ] Offboarding disables identity, schedules, secrets, and access before deletion.
  Evidence expected: Retirement checklist and retained ownership transfer.

## Unresolved controls
- Required: A named business owner and technical owner are recorded.
- Supporting: Purpose, users, environment, and prohibited uses are explicit.
- Required: Risk is tiered by data, autonomy, reversibility, and impact.
- Required: The agent has one named, single-purpose identity.
- Required: Read, write, publish, delete, and admin scopes are separated.
- Required: Search applies the same authorization rules as direct reads.
- Required: Credentials stay outside prompts, URLs, source, and shared files.
- Supporting: Allowed tools, data inputs, outputs, budgets, and rate limits are bounded.
- Required: Consequential actions require attributable, scoped approval.
- Required: Destructive or external actions have a tested stop and rollback path.
- Required: Every material change names the authenticated human or agent.
- Supporting: Objective, state, decisions, evidence, constraints, and next action persist.
- Supporting: Human review is anchored to the exact artifact and revision.
- Required: Out-of-scope search, read, write, and publish attempts are denied.
- Supporting: A separately authenticated successor can verify and continue the work.
- Required: Credential revocation stops API, CLI, and MCP access immediately.
- Required: An incident owner can identify the last trusted state and contain the agent.
- Required: Offboarding disables identity, schedules, secrets, and access before deletion.

## Reviewer verification
- [ ] Inspect evidence for every control marked complete.
- [ ] Run denied search, read, write, and publish tests.
- [ ] Verify attribution from the authenticated identity.
- [ ] Revoke the credential and confirm access stops.
- [ ] Use a separate identity to retrieve and continue one record.
- [ ] Record approval, conditions, owner, and next review date.

Canonical framework:
https://handover.sh/guides/ai-agent-governance-framework

Evidence, not a badge

A completed checklist is the start of review

Every marked control needs inspectable evidence. A separate identity should test denied paths, attribution, revocation, and successor continuation before approving production use.

Direct answer

What belongs in an AI agent governance checklist?

An AI agent governance checklist should record a named owner, purpose, risk tier, distinct identity, least-privilege access, consequential-action approvals, immutable evidence, negative-path tests, revocation, incident response, and offboarding. Controls should be verified at the model host, MCP server, API, data, and publishing boundaries the agent actually uses.

Shared review

Give unresolved controls an owner

Continue the assessment as a versioned handover so people and agents can attach evidence, comment on exact files, and record the final decision.

Inspect a reviewed handover