Most AI agents reach production after a model review and a privacy check, but nobody has formally assessed what the agent can do on its own, with whose credentials, and how fast it can be stopped. This template sets a policy and a repeatable assessment record for AI agents at [Organisation]. It scores autonomy, tools and permissions, the agent's identity and credentials, data access, human oversight, kill switch readiness and logging, then ties the score to required controls and approval levels. It is for security, IAM and AI governance teams and the executives who sign off agent risk. It complements a DPIA and a model-level AI risk assessment.
How to use this template
- Replace text in square brackets, such as [Organisation], [AI governance body] and [X days], with your own terms and thresholds. Bracketed values are illustrative.
- "Must" is mandatory; "should" is recommended practice where a documented exception may be justified.
- Section 4 contains the policy statements and the assessment record. Copy the tables in 4.2 and 4.3 into your GRC tool or agent registry as the assessment form.
- Assess per agent, not per model: the same model with different tools and credentials carries very different risk.
- Use it with the Agentic AI Security Policy Template, which sets the baseline rules, and the DPIA Template where personal data is processed.
1. Purpose
This policy requires that every AI agent at [Organisation] is risk assessed before it receives access to production systems or data, and again when it changes. The assessment establishes how much the agent can do without a human, what it can reach, which identity and credentials it uses, and whether [Organisation] can observe, override and stop it. The outcome is a risk tier that determines mandatory controls, approval authority and review frequency, so that agent autonomy stays within the risk appetite set by [AI governance body].
2. Scope
This policy applies to any software that uses an AI model to decide on and take actions, such as calling tools, APIs or other agents, on behalf of [Organisation], its staff or its customers. This includes:
- Agents built internally on any framework or cloud agent service.
- Agents built by staff on low-code or no-code agent platforms.
- AI coding agents and assistants that can run commands, edit repositories or call cloud APIs.
- Third-party agents and AI features that hold OAuth grants, API keys or accounts in [Organisation] systems.
- Tools, plugins and MCP servers that agents use, assessed as part of the agent.
Chat assistants that only return text to a person and cannot call tools are out of scope, but must be reassessed under this policy as soon as tool access is added.
3. Roles and responsibilities
| Role | Responsibility in the assessment |
|---|---|
| [AI governance body] | Sets risk appetite for agents, approves Tier 3 agents and exceptions, receives quarterly reporting. |
| [Chief Information Security Officer] | Owns this policy and the scoring method; approves Tier 2 agents. |
| Agent owner | A named employee accountable for the agent. Completes the assessment record, justifies every tool and permission, accepts residual risk up to their delegated authority. |
| [IAM team] | Confirms the agent identity, credential type, scopes and expiry recorded in the assessment; issues credentials only after approval. |
| [Security architecture] | Reviews tool gateway, sandbox, egress and kill switch design; validates the score. |
| [Data protection officer] | Decides whether a DPIA is required and reviews personal data access. |
| [Security operations] | Confirms logs reach the SIEM and that the kill switch runbook has been tested. |
4. Policy statements
4.1 When an assessment is required
- An assessment must be completed and approved before an agent receives production credentials or access to production data.
- The assessment must be repeated when the agent's model, system instructions, tools, permissions, data sources, autonomy level or principal changes, and at least every [12 months for Tier 1, 6 months for Tier 2, 3 months for Tier 3].
- Agents discovered without an assessment must be suspended or have credentials restricted within [X days] until assessed.
- Pilots that touch production data or hold real credentials are in scope; a pilot label does not reduce the tier.
4.2 Assessment record
The agent owner must complete every field. "Unknown" is a valid answer but scores as the highest level for that dimension.
| Field | What to record |
|---|---|
| Agent ID and name | [Registry ID], [agent name], version, platform or framework, model and model provider. |
| Purpose and principal | The business task in one sentence; whether the agent acts as itself, for a user, or both; intended users. |
| Owner | [Name], [role], [backup owner]. |
| Autonomy level | A0 to A4 from table 4.3, with the actions that run without human approval listed. |
| Tools and permissions | Every tool, API, MCP server and plugin, with the operations allowed (read, write, delete, execute, send) and the target environment. |
| Identity and credentials | The agent's own identity (service principal, workload identity, OAuth client); credential type (federated short-lived token, OAuth delegated token, static API key, password); scopes; lifetime; storage location; rotation date. Any use of a person's credentials must be recorded here. |
| Data access | Data sources, classification ([Public / Internal / Confidential / Restricted]), personal or special category data, volume the agent can read or export per run. |
| Untrusted input | Whether the agent reads email, web pages, tickets, documents, form submissions or other agents' output that an outsider can influence. |
| Human oversight | Which actions require approval, who approves, how the approval is enforced (platform, gateway or target system), and how the reviewer sees what will happen. |
| Kill switch | How to halt execution, revoke every credential and block tool access; who can trigger it; target time; date last tested. |
| Logging | What is logged (prompts, tool calls with parameters, approvals, credential use, outputs), where, retention period, and whether each action can be attributed to the agent and its principal. |
| Third parties | Model provider, agent platform, tool and MCP server publishers; contract and data residency status. |
| Score, tier and residual risk | Dimension scores, total, tier, open actions, accepted risks and approver. |
4.3 Scoring
Each dimension must be scored 0 to 4 against the descriptions below. The tier is set by the total and by override rules in 4.4.
| Dimension | 0 to 1 (lower risk) | 2 | 3 to 4 (higher risk) |
|---|---|---|---|
| Autonomy | A0 suggests only, or A1 acts after approval of every step | A2 acts alone on reversible, low-impact actions; approval for the rest | A3 acts alone on most actions with after-the-fact review, or A4 fully autonomous, long-running or self-scheduling |
| Tools and permissions | Read-only, single system, non-production | Write to one production system, no delete or external send | Delete, execute code, change access, move money, send external messages, or admin and wildcard scopes |
| Identity and credentials | Own identity, federated tokens under 1 hour, task-scoped | Own identity with static secret in an approved vault, expiry within [90 days] | Shared or human credentials, non-expiring keys, secrets in config files or code, unknown |
| Data access | Public or internal data only | Confidential data, limited volume | Restricted or personal data at scale, or bulk export possible |
| Untrusted input | None: only curated internal sources | Internal content that staff can edit | Content from the internet, customers, inbound email or other agents |
| Human oversight | Platform-enforced approval for every high-impact action | Approval enforced for some actions; others by prompt instruction | No enforced approval, or approval only requested in the system prompt |
| Kill switch and logging | Tested kill switch, credentials revoked in [15 minutes], full tool-call logs in SIEM | Manual stop documented, partial logs | No tested stop, no list of the agent's credentials, logs not attributable |
4.4 Tiers and mandatory controls
- Tier 1 (total [0 to 9]): approval by the agent owner and [IAM team]; baseline controls from the Agentic AI Security Policy.
- Tier 2 (total [10 to 17]): approval by the [CISO]; enforced approval for high-impact actions, own identity with short-lived or vaulted credentials, tool allowlist, logs in SIEM, tested kill switch.
- Tier 3 (total [18 or more]): approval by [AI governance body]; all Tier 2 controls plus sandboxed execution, restricted egress, red team or security test before go-live, and monitoring with alerting on anomalous tool use.
- Override rules: any agent scoring 4 on identity and credentials, or 3 or more on both untrusted input and tools, is Tier 3 regardless of total. Untrusted input combined with delete, execute or external send permissions must not go live without enforced human approval for those actions.
- Controls that restrict agent behaviour must be enforced by the platform, a tool gateway or the target system. Instructions in prompts do not count as a control in this assessment.
- An agent acting for a user must never exceed that user's access, and logs must show both the agent and the user.
5. Exceptions
- The agent owner must request exceptions in [GRC tool], stating the control not met, compensating controls and an end date within [90 days].
- Tier 1 and Tier 2 exceptions are approved by the [CISO]; Tier 3 exceptions and any use of human or shared credentials by [AI governance body].
- No exception may be granted for an agent with no kill switch or no attributable logging.
- Expired exceptions trigger credential restriction until the control is in place or the exception is renewed.
6. Compliance and monitoring
- [IAM team] must reconcile the agent registry against identities, OAuth grants and API keys issued to agents at least [monthly]; credentials with no current assessment are reported to the owner and [CISO].
- [Security operations] must monitor agent tool calls for use outside the assessed tools, environments or volumes and treat deviations as security events.
- Kill switch tests for Tier 2 and Tier 3 agents must be run at least [every 6 months] and the result recorded in the assessment.
- The following metrics must be reported [quarterly] to [AI governance body]:
- Percentage of production agents with a current, approved assessment.
- Number of agents using human, shared or non-expiring credentials.
- Percentage of Tier 2 and Tier 3 agents with a successful kill switch test in the period, and median time to revoke all credentials.
- Number of high-impact actions taken without enforced approval.
- Open exceptions and overdue reassessments.
- Non-compliance may lead to suspension of the agent and is handled under [disciplinary or supplier management procedure].
7. Review and approval
| Item | Value |
|---|---|
| Policy owner | [Chief Information Security Officer] |
| Approved by | [AI governance body], [date] |
| Version | [1.0] |
| Review cycle | At least annually, and after any significant agent incident, new regulation or change to the OWASP or NIST frameworks referenced |
| Related documents | [Agentic AI Security Policy], [Information Security Policy], [DPIA procedure], [Third-Party Risk Policy], [Incident Response Plan] |
Implementation guidance
Rolling it out
- Inventory first: list every agent you can find, including low-code and coding agents, with its credentials. The Shadow AI Discovery Guide covers discovery methods.
- Pilot the scoring: score five agents of different types with their owners and adjust the thresholds in 4.3 and 4.4 until the tiers match the judgement of your security architects.
- Assess existing agents by exposure: start with agents that read untrusted input or hold write, delete or admin permissions.
- Gate credential issuance: make an approved assessment a precondition in the IAM workflow that issues agent identities and secrets, so the policy enforces itself.
- Test the stop: for every Tier 2 and 3 agent, run the kill switch once in a non-production environment and record time to halt and revoke. See the AI Agent Kill Switch and Containment Guide.
- Roll back safely: if an assessment blocks a business-critical agent, reduce its autonomy level (for example A3 to A1 with approval of each step) rather than granting a blanket exception.
What the dimensions are catching
- Credentials found, not issued: in the PocketOS incident a coding agent found an account-scoped API token in an unrelated file and used it to delete a production volume and its volume-level backups in one call. The identity and tools dimensions both score 4 for that pattern.
- Default and harvested machine credentials: the JADEPUFFER agentic ransomware case shows an attacker's agent chaining exposed AI provider keys, cloud credentials and default service credentials. Your agents' secrets are part of the attack surface.
- Regulators expect it in risk analysis: after Spain's first AI agent data breach notification, the AEPD called for AI-driven attacks to be included in risk analysis and for stronger protection of accounts, API keys and tokens.
- Prompt-only guardrails: OWASP LLM06 Excessive Agency and the OWASP Agentic Top 10 (ASI02 Tool Misuse, ASI03 Identity and Privilege Abuse) both treat excessive functionality, permissions and autonomy as the root cause; the scoring therefore ignores controls that live only in the prompt. See the OWASP Top 10 for Agentic Applications Guide.
Framework mapping
| Template section | NIST AI RMF 1.0 | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 |
|---|---|---|---|
| 4.1 Assessment triggers, 4.4 tiers | MAP 1.1, MAP 4.1 | GV.RM-02, ID.RA-04 | RA-3 |
| Identity and credentials | GOVERN 3.2 | PR.AA-05 | AC-2, IA-9 |
| Tools, permissions, data access | MEASURE 2.7 | PR.AA-05 | AC-6 |
| Human oversight | MAP 3.5 | GV.RM-02 | AC-6 |
| Kill switch and decommissioning | MANAGE 2.4, GOVERN 1.7 | ID.RA-04 | IR-4 |
| Logging and monitoring | MANAGE 4.1 | DE.CM-09 | AU-2, AU-12, AC-6(9), CA-7 |
| Third parties | MAP 4.1 | GV.OC-03 | SR-3 |
NIST AI 600-1, the Generative AI Profile, lists Human-AI Configuration, Information Security and Value Chain and Component Integration among its twelve risks, which line up with the oversight, credentials and third-party dimensions here. For the wider model-level process see the AI Risk Assessment Guide and the NIST AI RMF Guide; for threat analysis of a single agent, the AI Agent Threat Modelling Guide.
Small and large organisations
- Small teams: keep the record in a spreadsheet, merge the CISO and IAM roles, and focus on three questions per agent: whose credentials, what can it delete or send, and how do we stop it.
- Large enterprises: embed the record in the agent registry and the identity issuance workflow, delegate Tier 1 approval to platform teams, and report tier distribution by business unit.
Standards and references
- OWASP GenAI Security Project: Top 10 for Agentic Applications for 2026
- OWASP: Top 10 for LLM Applications 2025 (LLM06 Excessive Agency)
- NIST: AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0)
- NIST: AI 600-1, Generative Artificial Intelligence Profile
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls
This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: Agentic AI Security Policy Template · Top 10 AI Agent Security Risks for CISOs · Human-in-the-Loop for AI Agents Guide · Identity Governance for AI Agents Guide · Vendor Security Assessment Template