AI agents usually reach production through a demo that worked, not a security review that passed, and they arrive holding a developer's token, broad tool access and no way to switch them off. This template is a pre-production checklist for any AI agent that will act on real systems or data: in-house agents, agents built on low-code platforms, coding agents and vendor agents connected to your tenant. It turns the joint Five Eyes guidance on careful adoption of agentic AI, the OWASP Top 10 for Agentic Applications and the MCP security best practices into checks with pass criteria and evidence. It is written for platform, security and IAM teams who approve agents for go-live, and for the agent owners who must evidence each check.
How to use this template
- Replace text in square brackets, such as [Organisation], [AI security team] and [30 days], with your own teams and values.
- Copy each checklist table into your tracker and add Result (Pass, Fail, N/A) and Evidence columns. A check passes only when evidence is recorded: a configuration export, a registry entry, a test report or a screenshot with a date.
- Set the agent's risk tier first (section 1). Checks marked T2+ apply to Tier 2 and Tier 3 agents; checks marked T3 apply to Tier 3 only; all other checks apply to every agent.
- Run the checklist before first production use and again on any material change: a new tool or MCP server, broader permissions, a new data source, a model change or a move to a higher tier.
- For the design behind these checks read the Agentic AI Identity Guide; for ongoing governance after go-live, the Identity Governance for AI Agents Guide.
1. Purpose, scope and risk tier
This checklist ensures that no AI agent operates on [Organisation]'s systems or data until it has its own identity, an accountable owner, the minimum permissions its task needs, enforced human approval for high-impact actions, attributable logging, a tested way to stop it and a recorded go-live decision. It applies to any software that uses a model to decide which tools to call or actions to take, whatever platform it runs on. Chat assistants that only answer questions and cannot call tools are out of scope and handled under [AI Acceptable Use Policy].
The joint guidance from CISA, the NSA and the Australian, Canadian, New Zealand and UK cyber agencies puts it plainly: "Privileges assigned to agents directly determine the level of risk they can introduce." Tier agents by what they can do, not by how capable the model is:
| Tier | Definition | Approval required |
|---|---|---|
| Tier 1 | Reads internal data within one user's existing permissions; no write actions; no external communication | Agent owner and [AI security team] reviewer |
| Tier 2 | Creates or changes records, files, tickets or code in internal systems, or reads data beyond one user's permissions | Tier 1 plus data owner of each system written to |
| Tier 3 | Sends external communications, moves money, changes access, deploys to production, deletes data, or acts autonomously without a user present | Tier 2 plus [CISO or delegate] and business risk owner |
2. Identity and credentials
| ID | Check | Evidence |
|---|---|---|
| ID-1 | The agent runs under its own identity (for example a Microsoft Entra Agent ID agent identity, a dedicated service principal, IAM role or service account), never a person's account or a shared team credential | Identity object ID and creation record |
| ID-2 | One identity per agent and per environment; development and production identities are separate | Identity list per environment |
| ID-3 | Credentials are short-lived and issued at run time (workload identity federation, managed identity, OAuth client credentials with short token lifetimes); no static API keys where the platform supports an alternative | Credential type and token lifetime setting |
| ID-4 | Any remaining secret is stored in [secrets manager], has an owner and a rotation date, and does not appear in prompts, code, configuration files or agent memory | Vault path; secret scan result for the agent repository |
| ID-5 | When the agent acts for a user, delegation is explicit (on-behalf-of or token exchange) and downstream logs show both the agent and the user | Sample log entry showing both identities |
| ID-6 | MCP servers accept only tokens issued for them; the MCP specification states servers "MUST NOT accept any tokens that were not explicitly issued for the MCP server", so token passthrough is absent | Audience validation configuration or test |
| ID-7 (T3) | Administrators of the agent platform use phishing-resistant MFA and separate admin accounts | Conditional access or IdP policy export |
A coding agent that wiped a production database used a token with far more authority than its task needed: see the PocketOS database deletion. For credential patterns, see the NHI Authentication Guide.
3. Ownership and registry
| ID | Check | Evidence |
|---|---|---|
| OR-1 | The agent is recorded in [agent registry] with name, purpose, tier, platform, model and version, identity, tools, data sources and environments | Registry entry |
| OR-2 | A named human owner and a deputy are accountable for the agent; on some platforms the creator is recorded as sponsor by default, so confirm the right person holds the role | Owner and deputy in the registry and on the identity object |
| OR-3 | A review date and an end date (or review trigger) are set; the agent is disabled if the owner leaves without a handover | Lifecycle fields in the registry; leaver process link |
| OR-4 | Access is denied to any agent or key that is not in the registry, as the joint Five Eyes guidance recommends | Policy or gateway rule that enforces registration |
| OR-5 | Third-party components (models, plug-ins, MCP servers, libraries) are recorded with source and version in a trusted component registry | Component list with versions |
Agents found outside the registry are handled as shadow AI; see the Shadow AI Discovery Guide.
4. Tool permissions
| ID | Check | Evidence |
|---|---|---|
| TP-1 | The agent has only the tools its task needs; the OWASP AI Agent Security Cheat Sheet advises "Grant agents the minimum tools required for their specific task." Unknown tools are denied by default | Tool allow list in configuration |
| TP-2 | Each tool's credential is scoped to the operations used (read-only where possible); no wildcard or omnibus scopes such as *, all or admin:* | Granted scopes and roles per tool |
| TP-3 | Tools and MCP servers come from an approved list with pinned versions; new or changed tool descriptions are reviewed before use | Approved list; version pins |
| TP-4 | Local MCP servers and code execution run in a sandbox with restricted file system and network access; the client shows the exact command before a server is added | Sandbox configuration; client setting |
| TP-5 | Outbound network access is limited to an allow list; requests to private ranges and the cloud metadata address 169.254.169.254 are blocked | Egress policy |
| TP-6 (T2+) | Authorisation for each tool call is enforced outside the model, by the tool, gateway or policy engine, not by instructions in the prompt | Policy rule or gateway configuration |
| TP-7 (T2+) | Rate, volume and spend limits apply per tool and per agent | Limit settings |
See the AI Agent Tool and Plugin Security Guide and the MCP Security Guide. A one-character token and default master keys exposed AI gateway credentials in the LiteLLM MCP auth bypass.
5. Data access
| ID | Check | Evidence |
|---|---|---|
| DA-1 | Every data source the agent can read is listed with its classification, and the data owner has approved access at that classification | Data source list with approvals |
| DA-2 | Retrieval respects the requesting user's existing permissions; the agent does not expose data a user could not open directly | Permission-aware retrieval test result |
| DA-3 | Memory is isolated between users and sessions, with retention and size limits; nothing is stored that the user could not see | Memory configuration |
| DA-4 | Sensitive data is minimised in prompts and context, and redacted from logs where not needed for investigation | Redaction rules |
| DA-5 | The model provider's data handling terms (training use, retention, region) are approved for the data classification in scope | Contract or service terms reference |
See the Permission-Aware RAG Guide and the AI Agent Memory Security Guide.
6. Guardrails and human approval
| ID | Check | Evidence |
|---|---|---|
| GH-1 | All external content (emails, web pages, documents, tickets, API responses, form submissions) is treated as untrusted input that cannot change the agent's goal or permissions | Design review note |
| GH-2 | Agent outputs are validated against a schema or allow list before they are executed or sent onwards | Validation code or configuration |
| GH-3 (T2+) | A list of high-impact actions exists for this agent (payments, external email, deletion, access changes, production deployment) and each requires human approval enforced by the system | Action list; approval workflow configuration |
| GH-4 (T2+) | Approvals are bound to the specific action and parameters, expire, and cannot be granted by the agent itself; critical actions require step-up authentication of the approver | Approval record sample |
| GH-5 (T3) | The agent fails safe: when uncertain or when a guardrail triggers, it stops and escalates rather than retrying another route | Test case result |
| GH-6 | Input and output guardrails (prompt injection detection, sensitive data filters) are configured and their blocks are logged | Guardrail policy export |
Guardrails reduce risk but do not replace least privilege: a poisoned web form turned a CRM agent into a data exfiltration tool in ForcedLeak. See the AI Guardrails and AI Firewalls Guide.
7. Logging and monitoring
| ID | Check | Evidence |
|---|---|---|
| LM-1 | Every run logs the agent identity, the user or trigger it acted for, prompts and inputs, tool calls with parameters, outputs, approvals and errors, with a correlation ID across systems | Sample run trace |
| LM-2 | Logs are sent to [SIEM] within [5 minutes] and retained for [12 months]; the agent cannot alter or delete its own logs | Log pipeline and retention settings |
| LM-3 | Alerts exist for: tool calls outside the allow list, access-denied spikes, unusual data volumes, a read of sensitive data followed by an external send, guardrail blocks, repeated approval requests and spend thresholds | Alert rule list |
| LM-4 | Credential use by the agent identity from unexpected networks or at unexpected times raises an identity alert | Identity threat detection rule |
| LM-5 | Alerts route to a named team with an agent-specific runbook | Runbook link |
See the AI Agent Observability and Incident Response Guide.
8. Testing and red teaming
| ID | Check | Evidence |
|---|---|---|
| TR-1 | A threat model covers goal hijack, tool misuse, identity and privilege abuse, supply chain, memory poisoning and cascading failures (OWASP ASI01 to ASI10) | Threat model document |
| TR-2 | Indirect prompt injection tests run through every content channel the agent reads, and the agent does not leak data or take unapproved actions | Test report |
| TR-3 | Permission tests confirm the agent cannot reach tools, data or environments outside its approved scope, including production from development | Negative test results |
| TR-4 | Approval bypass tests confirm high-impact actions cannot run without approval | Test results |
| TR-5 (T2+) | Red teaming by people independent of the build team; critical and high findings fixed or formally accepted before go-live | Red team report; finding tracker |
| TR-6 (T3) | A pilot runs in shadow or supervised mode for [14 days] with human review of every action before autonomy is increased | Pilot review record |
See the Red Teaming AI Agents for Identity Abuse guide and the AI Agent Threat Modelling Guide.
9. Kill switch and rollback
| ID | Check | Evidence |
|---|---|---|
| KR-1 | A documented kill switch disables the agent and revokes or disables its identity, tokens and tool credentials in one procedure | Runbook |
| KR-2 | The kill switch has been tested in pre-production and completes within [15 minutes]; the time is recorded | Test record with timings |
| KR-3 | Agent configuration, prompts, tool lists and model versions are under version control so the last known-good version can be restored | Repository and release tags |
| KR-4 (T2+) | Changes the agent makes can be reversed: backups exist and are out of the agent's reach, and destructive operations are soft-delete where the platform allows | Backup and recovery test |
| KR-5 (T3) | Automatic restriction triggers reduce the agent's permissions or pause it when monitored thresholds are breached | Trigger configuration |
A coding agent deleted live data during a code freeze in the Replit database deletion: backups beyond the agent's reach and a fast stop decide how bad such an event becomes.
10. Go-live sign-off
| ID | Check | Evidence |
|---|---|---|
| GL-1 | All applicable checks in sections 2 to 9 pass, or each failure has an approved exception with an owner and expiry under [Security Exceptions Procedure] | Completed checklist |
| GL-2 | The approvers for the agent's tier (section 1) have signed off, and no approver is the agent owner or builder | Signed approval record |
| GL-3 | The agent's tier, permissions and approved scope are recorded in the registry and match production configuration | Registry and configuration comparison |
| GL-4 | Users are told they are working with an AI agent and how to report a problem | User notice |
| GL-5 | The first access review date is set, no later than [90 days] after go-live | Calendar entry or review campaign |
11. Framework mapping
| Checklist area | OWASP Agentic Top 10 | Five Eyes agentic AI risk category | UK AI Cyber Security Code principle |
|---|---|---|---|
| 2 Identity, 4 Tool permissions | ASI03 Identity and Privilege Abuse; ASI02 Tool Misuse and Exploitation | Privilege; design and configuration | 6 Secure your infrastructure |
| 3 Ownership and registry | ASI04 Agentic Supply Chain Vulnerabilities; ASI10 Rogue Agents | Structural; accountability | 5 Identify, track and protect your assets; 7 Secure your supply chain |
| 5 Data access | ASI06 Memory and Context Poisoning | Design and configuration | 8 Document your data, models and prompts |
| 6 Guardrails and approval | ASI01 Agent Goal Hijack; ASI09 Human-Agent Trust Exploitation | Behaviour | 4 Enable human responsibility for AI systems |
| 7 Logging and monitoring | ASI10 Rogue Agents | Accountability | 12 Monitor your system's behaviour |
| 8 Testing | ASI01 to ASI10 | All | 9 Conduct appropriate testing and evaluation |
| 9 Kill switch and rollback | ASI08 Cascading Failures | Structural | 11 Maintain regular security updates, patches and mitigations |
Organisations using the NIST AI RMF can file the completed checklist as evidence under the Manage function, with the tiering in section 1 under Map. See also the OWASP Agentic Applications Top 10 guide.
Implementation guidance
- Start with the agents already live: run sections 2, 3 and 9 against every agent in production now. Identity, ownership and a working kill switch are the checks most often missing and the quickest to fix.
- Build the checks into the platform: make registration, a dedicated identity and a tool allow list prerequisites in the agent platform or deployment pipeline, so a non-compliant agent cannot be deployed rather than being caught later.
- Pilot before autonomy: deploy Tier 2 and Tier 3 agents first in supervised mode, review every action, then widen autonomy one step at a time. Watch access-denied errors and guardrail blocks during the pilot to tune permissions down, not up.
- Keep rollback simple: for any failure in production, disable the agent with the kill switch first, restore the last known-good version, then investigate.
- Re-run on change: treat a new tool, MCP server, data source or model as a new deployment for the affected sections.
Small teams can run this checklist in a spreadsheet and combine reviewer roles, but should not drop sections 2, 6 and 9. Large organisations with many agent platforms should automate the evidence collection and link the registry to the identity provider so that disabling an owner's account triggers an agent review. Common failure patterns: agents running on the builder's personal token; approval enforced by a line in the system prompt rather than by the system; tool results from MCP servers treated as trusted instructions (a fake error report hijacked coding agents in the Sentry MCP agentjacking case); kill switches that stop the agent but leave its tokens valid; and logs that show the agent's actions but not which user it acted for. Track these measures each month:
- Registry coverage: production agents in the registry with an owner (target: all).
- Dedicated identity: agents running on their own identity with short-lived credentials.
- Approval coverage: high-impact actions with enforced human approval (target: all Tier 3 actions).
- Kill switch time: median tested time to disable an agent and revoke its credentials.
- Exceptions: open go-live exceptions past their expiry date (target: zero).
Standards and references
- ASD's ACSC, CISA, NSA, Canadian Centre for Cyber Security, NCSC-NZ and NCSC-UK: Careful adoption of agentic AI services
- OWASP GenAI Security Project: OWASP Top 10 for Agentic Applications for 2026
- OWASP: AI Agent Security Cheat Sheet
- Model Context Protocol: Security Best Practices
- NSA, CISA, FBI and partners: Deploying AI Systems Securely
- DSIT: Code of Practice for the Cyber Security of AI
- NIST: AI Risk Management Framework
- Microsoft Learn: What is Microsoft Entra Agent ID?
This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: Identity Governance for AI Agents Guide · AI Agent Tool and Plugin Security Guide · MCP Security Guide · Agentic AI Identity Guide · Agentic AI Security Policy Template