Most AI risk assessments ask what a model might say; an agent also needs to be assessed for what it can do, with whose credentials, and how fast it can be stopped. This template sets out a policy and a scoring method for assessing every AI agent before it receives production access, and again when it changes. It scores agency (autonomy, tools, permissions and reach) alongside impact, maps findings to the OWASP Top 10 for Agentic Applications, and ties the result to approval gates and required controls. It is written for security, risk and AI governance teams, and for the executives who sign off agent deployments. Adapt roles, thresholds and scales to your organisation, and have it reviewed by your legal, risk and compliance teams before adoption.
How to use this template
- Replace text in square brackets, such as [Organisation], [AI governance body] and [X days], with your own terms and values.
- "Must" is a mandatory requirement; "should" is recommended practice where a documented exception may be justified.
- Section 4 contains the assessment method. Use the scoring tables as a worksheet: one completed copy per agent, stored with the agent's registry entry.
- Use it alongside your general AI risk process (for example one based on the NIST AI RMF or ISO/IEC 42001) and your data protection impact assessment. This template covers the agent-specific part; it does not replace either. See the AI Risk Assessment Guide and the DPIA Template.
- Calibrate the scales on two or three existing agents before mandating it, so scores mean the same thing across teams.
1. Purpose
This policy requires that every AI agent at [Organisation] is risk assessed before it is given access to production systems or data, that the assessment considers the agent's autonomy, tools, permissions and identity as well as the impact of its actions, and that the resulting risk tier determines the controls and approvals the agent needs. The aim is to bound agent risk before deployment, consistent with [Organisation]'s risk appetite, rather than discover it in an incident.
2. Scope
This policy applies to:
- AI agents built internally on any framework or platform, including low-code and no-code agent builders.
- Third-party agents and AI features that act on [Organisation] systems or data through OAuth grants, API keys, connectors or MCP servers.
- AI coding agents and assistants with access to source code, pipelines or cloud environments.
- Multi-agent systems, where the assessment covers each agent and the interactions between them.
An "AI agent" is software that uses an AI model to decide on and take actions, such as calling tools or APIs, towards a goal, with or without human approval of each step. Chat assistants with no tools and no write access are out of scope and are covered by [AI acceptable use policy].
3. Roles and responsibilities
- Agent owner: a named employee accountable for the agent. Completes the assessment, implements required controls, and requests reassessment on change.
- [Security team]: reviews and challenges the assessment, confirms the scores, sets required controls and runs pre-deployment testing for Tier 3 and Tier 4 agents.
- [IAM team]: confirms the agent's identity, credentials and permissions as recorded.
- [Data protection officer]: decides whether a DPIA is required and reviews agents processing personal data.
- [Risk function]: owns the scoring scales and the link to the enterprise risk register.
- [AI governance body]: approves Tier 4 agents and all exceptions, and sets risk appetite for agents.
4. Policy statements
4.1 When an assessment is required
- An assessment must be completed and approved before an agent receives any production credential, tool or data access.
- A reassessment must be completed when the agent's model, system instructions, tools, MCP servers, data sources, permissions, autonomy level or user population changes materially, and at least [every 12 months for Tier 1 and 2 / every 6 months for Tier 3 and 4].
- A reassessment must follow any security incident or near miss involving the agent.
4.2 Required information
The owner must record, before scoring:
- Purpose, business process and the principal the agent acts for (itself, a user, or both).
- Every tool, API, MCP server, plugin and other agent it can call, with the permissions each grants.
- Its identity and credentials: identity type, credential type, lifetime, where stored, and who can revoke them.
- Data it can read, write or send, with classification, and whether it processes personal data.
- Memory: whether it persists context between sessions, and whether memory is shared across users or tenants.
- Untrusted inputs it consumes, for example email, web pages, documents, tickets or other agents' output.
- Actions it can take without human approval, and the human checkpoints that exist.
- How it is stopped and how its credentials are revoked, with the expected time to do so.
4.3 Scoring agency
Score each factor from 1 (low) to 4 (high). The agency score is the highest single factor score, not the average, because one high factor is enough to create serious exposure.
| Factor | 1 | 2 | 3 | 4 |
|---|---|---|---|---|
| Autonomy | Suggests only; human executes | Acts with approval for every action | Acts alone on routine actions; approval for high-impact | Acts alone, including high-impact actions |
| Tool reach | Read-only, internal, one system | Writes to one non-production or low-risk system | Writes to production systems or sends external communications | Executes code, moves money, changes access, or provisions infrastructure |
| Permissions and credentials | Short-lived, task-scoped, own identity | Own identity, scoped, longer-lived | Broad scopes or delegated user access across systems | Admin, wildcard, shared or static long-lived credentials |
| Untrusted input exposure | Only trusted internal input | Internal documents from many authors | External content such as email, web or customer tickets | External content plus other agents' output, unfiltered |
| Supply chain | Only internally built, pinned components | Approved third-party tools, pinned | Third-party MCP servers or plugins, not pinned | Dynamically discovered tools or agents |
| Persistence and propagation | No memory, single agent | Per-user memory | Shared memory or outputs consumed by other agents | Shared memory and multi-agent chains with downstream execution |
4.4 Scoring impact
Score the worst credible outcome if the agent is hijacked, misused or malfunctions, from 1 to 4, across confidentiality, integrity, availability, financial, safety, legal and regulatory, and people affected. The impact score is the highest of these.
| Score | Impact description |
|---|---|
| 1 | Minor, contained, reversible within a working day; no personal or restricted data |
| 2 | Limited, reversible; internal data or a small number of individuals affected |
| 3 | Significant: personal or confidential data exposed, production disruption, financial loss above [threshold], or a notifiable event possible |
| 4 | Severe or irreversible: large-scale data loss or exposure, safety impact, major financial loss, regulatory breach, or loss of control of systems |
4.5 Risk tier and what it requires
Inherent risk = agency score multiplied by impact score (1 to 16). The tier sets mandatory controls and approval. Residual risk is scored again after controls, and must be within [Organisation]'s appetite before go-live.
| Tier | Inherent score | Minimum controls | Approver |
|---|---|---|---|
| Tier 1 | 1 to 3 | Registration, own identity, logging | Agent owner |
| Tier 2 | 4 to 6 | Tier 1, scoped credentials, approved tools only, quarterly access review | Owner and [Security team] |
| Tier 3 | 8 to 9 | Tier 2, short-lived credentials, policy enforcement outside the model, approval for high-impact actions, pre-deployment testing, tested kill switch | [Security team] and business risk owner |
| Tier 4 | 12 to 16 | Tier 3, independent security testing, sandboxed execution, monitoring with alerting, staged rollout, reassessment every 6 months | [AI governance body] |
4.6 Threat coverage
- For Tier 2 and above, the assessment must record for each entry in the OWASP Top 10 for Agentic Applications (ASI01 Agent Goal Hijack to ASI10 Rogue Agents) whether it applies, the controls in place and any gap.
- Where the agent uses credentials, the assessment must also consider the OWASP Non-Human Identities Top 10, in particular overprivileged, long-lived and reused credentials.
- Controls that rely only on instructions in the system prompt must not be counted as reducing residual risk.
| ASI entry | Assessment question | Evidence expected |
|---|---|---|
| ASI01 Agent Goal Hijack | Can untrusted content change what the agent does? | Input handling design, injection test results |
| ASI02 Tool Misuse and Exploitation | Can any permitted tool cause harm if misused? | Per-tool scopes, rate limits, egress rules |
| ASI03 Identity and Privilege Abuse | Does the agent hold more access than the task, or inherit a user's full access? | Identity record, credential lifetime, access review |
| ASI04 Agentic Supply Chain Vulnerabilities | Are all tools, MCP servers and components approved and pinned? | Approved list, AI-BOM, version pins |
| ASI05 Unexpected Code Execution (RCE) | Can the agent run code, and where? | Sandbox configuration |
| ASI06 Memory and Context Poisoning | Can one user or source write memory others rely on? | Memory segmentation, provenance, expiry |
| ASI07 Insecure Inter-Agent Communication | Are other agents authenticated and messages protected? | Authentication method, message signing |
| ASI08 Cascading Failures | What limits a bad output spreading downstream? | Circuit breakers, quotas, approval gates |
| ASI09 Human-Agent Trust Exploitation | Do approvers see the real action and parameters? | Approval screen design |
| ASI10 Rogue Agents | How fast can the agent be stopped and its credentials revoked? | Kill switch drill record and time |
4.7 Decision and record
- The outcome must be one of: approved; approved with conditions and dates; rejected; or reduce scope and resubmit.
- The completed assessment, scores, evidence and approval must be stored with the agent's registry entry and retained for [period].
- Tier 3 and Tier 4 residual risks must be entered in the [enterprise risk register] with an owner.
5. Exceptions
An agent may go live without a required control only with an exception requested by the agent owner, risk assessed by [Security team], approved by [AI governance body] for Tier 3 and Tier 4 agents, recorded with compensating controls and an expiry no later than [90 days], and reviewed before expiry. No exception may remove the requirements for a unique agent identity, logging, or the ability to stop the agent.
6. Compliance and monitoring
- [Security team] must compare the agent registry with discovered agents, OAuth grants and API keys at least [monthly]; any agent without a current assessment must be suspended or assessed within [X days].
- Monitoring must confirm that agents operate within their assessed tools and permissions; use of an unassessed tool or permission triggers reassessment.
- Measures reported to [AI governance body] each quarter: percentage of production agents with a current assessment; number of Tier 3 and Tier 4 agents; overdue reassessments; open exceptions and their age; agents found in use without an assessment; and measured time to stop and revoke for Tier 3 and Tier 4 agents.
- Internal audit may review a sample of assessments for completeness and accuracy of scores.
7. Review and approval
This policy is owned by [policy owner] and approved by [AI governance body]. It must be reviewed at least annually, and sooner after a significant agent incident, a change in regulation applying to [Organisation], or a revision of the frameworks it references.
| Version | Date | Author | Approved by | Change |
|---|---|---|---|---|
| [1.0] | [date] | [name] | [name, role] | Initial version |
Implementation guidance
- Start from the inventory. Assessment depends on knowing which agents exist. Build or reuse an agent register first. See the AI Register and AI Inventory Template and the Shadow AI Discovery Guide.
- Pilot on existing agents. Score two or three agents already in use, including one you consider high risk, and adjust the scale descriptions until reviewers agree within one point.
- Reduce agency before adding controls. The fastest way to lower a score is to remove tools, narrow permissions or add an approval step. This follows OWASP's least agency principle and the Singapore IMDA Model AI Governance Framework for Agentic AI, whose first dimension is assessing and bounding risks upfront by limiting autonomy and access to tools and data.
- Connect to identity controls. The permissions and credentials factor is usually the cheapest to fix: unique identity, short-lived credentials, scoped access. See the Agentic AI Identity Guide.
- Test before approving Tier 3 and 4. Use threat modelling and adversarial tests against the ASI entries that apply. See the AI Agent Threat Modelling Guide and the AI Agent Security Testing Checklist.
- Roll out in stages. Deploy Tier 4 agents to a pilot group with monitoring and approval on all write actions, then relax approvals only where evidence supports it. Keep the ability to return to the previous configuration.
- Automate the triggers. Link reassessment to change events in the agent platform: new tool, new scope, new model version.
| Template section | NIST AI RMF function | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 |
|---|---|---|---|
| 3 Roles, 7 Review | Govern | GV.RM-02 | RA-3 |
| 4.2 Required information | Map | ID.RA-04 | RA-3, AC-2 |
| 4.3 to 4.5 Scoring and tiers | Measure | ID.RA-05 | RA-3 |
| 4.6 Threat coverage, 4.7 Decision | Manage | ID.RA-06, PR.AA-05 | AC-6, CM-7 |
| 6 Compliance and monitoring | Manage | DE.CM-09, GV.SC-07 | CA-7, SI-4 |
This mapping is NHI Mgmt Group's own reading of where each section fits. ISO/IEC 42001:2023 organisations can use the completed assessments as evidence for their AI management system's risk assessment and treatment process. For the controls that follow from a high tier, use the Agentic AI Security Policy Template and the OWASP Top 10 for Agentic Applications Guide.
This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: AI Risk Assessment Guide · Agentic AI Security Guide · AI Agent Autonomy Levels Framework · Vendor Security Assessment Template