Agentic AI Security Policy Template

Most organisations have policies for users, service accounts and acceptable use of AI tools. Few have a policy that says how AI agents get access, who is accountable for them and what they may do on their own. This template gives you a starting point. It sets out policy statements for registering, identifying, authorising, overseeing, monitoring and retiring AI agents, written so it can sit alongside your existing identity, access and information security policies. It is for CISOs, IAM and AI governance leads. Adapt the wording, roles and thresholds 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] and [X] days, with your own terms.
• "Must" indicates a mandatory requirement; "should" indicates a recommended practice where exceptions may be justified and recorded under section 6.
• Align defined roles with your existing governance structure, for example the information security, IAM and AI governance functions. Section 4 gives a starting allocation of responsibilities.
• Set the risk tiers in section 5.1 first: most thresholds in the policy (approval, review frequency, testing) depend on the tier.
• Link each statement to the standards that implement it: the policy says what must happen, the standards say how. The AI Agent Deployment Checklist turns section 5 into go-live checks.

1. Purpose

This policy sets the requirements for the secure use of AI agents at [Organisation]. It ensures that every AI agent is known, owned, uniquely identified, given only the access it needs, subject to appropriate human oversight, monitored and retired securely, so that [Organisation] can benefit from AI agents while managing the risks to its data, systems, customers and obligations.

AI agents differ from conventional service accounts because a model decides which tools to call, and the input shaping that decision can come from untrusted emails, web pages, documents and tool results. OWASP describes the resulting risk as Excessive Agency: damaging actions performed "in response to unexpected, ambiguous or manipulated outputs from an LLM". This policy therefore treats each agent as a non-human identity whose permissions, not instructions, limit what it can do.

2. Scope

This policy applies to all AI agents that access [Organisation] systems or data, or act on behalf of [Organisation], its employees or its customers, including:

• Agents developed internally, on any platform or framework.
• Agents built by staff using low-code or no-code agent platforms.
• Agents and AI features provided by third parties that access [Organisation] systems or data, including through OAuth grants or API keys.
• AI coding assistants and agents used in software development.
• Tools, MCP servers, plugins and integrations used by agents, and multi-agent systems in which agents delegate work to other agents.

It applies to all employees, contractors and third parties who create, deploy, own, operate or approve AI agents.

AI assistants without tool access are covered by [Acceptable Use of AI Policy].

3. Definitions

• AI agent: 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.
• Agent owner: the named individual accountable for an agent's purpose, access, behaviour and retirement.
• Agent identity: the unique non-human identity under which an agent authenticates.
• Principal: the user or system on whose behalf an agent acts.
• Delegation: the agent keeps its own identity while acting for a principal; RFC 8693 describes this as "A representing B", as distinct from impersonation.
• High-impact action: an action that is irreversible, moves money, changes access rights, deletes or bulk-exports data, communicates externally on behalf of [Organisation], or affects production systems. [Organisation] maintains the detailed list in [procedure reference].
• Least agency: giving an agent only the tools, functions and autonomy its task needs.
• Agent registry: the system of record for AI agents at [Organisation].
• MCP server: a server implementing the Model Context Protocol that exposes tools, resources or prompts to AI agents.
• Kill switch: the tested procedure that stops an agent and revokes all its credentials and grants.

4. Roles and responsibilities

• [AI governance body]: approves this policy, sets risk appetite for AI agents and approves Tier 3 agent deployments.
• [Chief Information Security Officer]: owns this policy, and the security standards and monitoring that implement it.
• [IAM team]: operates the agent registry, issues agent identities and credentials, and runs access reviews.
• Agent owners: register agents, justify access, review access, respond to alerts and retire agents. Owners must name a deputy.
• Developers and builders: build and configure agents in line with this policy and its standards.
• [Security operations]: monitor agent activity, operate the kill switch and respond to agent-related incidents.
• [Procurement and third-party risk]: assess AI vendors, agent platforms and third-party tools.

Starting allocation (R responsible, A accountable, C consulted, I informed); keep one accountable role per activity:

5. Policy statements

5.1 Registration and ownership

1. Every AI agent must be registered in the agent registry before it receives access to any production system or data.
2. Each registration must record the agent's purpose, owner and deputy, principal type (itself, users, or both), platform, model and version, tools, data sources, credentials, autonomy level and risk tier.
3. Every agent must have a named owner who is a current employee. If an owner leaves or changes role, ownership must be transferred within [X] days or the agent must be suspended.
4. Agents that are discovered but not registered must be treated as unauthorised and are subject to suspension.
5. Each agent must be assigned a risk tier based on what it can do, using the table below.

For finding agents that were never registered, see the Shadow AI Discovery Guide.

5.2 Identity and authentication

1. Each agent must have its own unique identity. Agents must not share identities or credentials with other agents, workloads or people.
2. Agents must not authenticate using an individual's personal credentials, including passwords, personal access tokens or session cookies.
3. Agent credentials should be short-lived and issued by a platform (for example, workload identity or token services) rather than stored as static secrets.
4. Where static credentials cannot be avoided, they must be stored in [approved secrets manager], scoped to least privilege and to one environment, set to expire within [X] days and rotated.
5. Credentials must not be placed in prompts, agent memory, source code, configuration files in repositories, notebooks or container images.

Agents use whatever credentials they can reach: in the PocketOS Database Deletion 2026, a coding agent in staging found an account-scoped token in an unrelated file and deleted a production volume. See the Secrets Management Guide.

5.3 Access and authorisation

1. Agents must be granted only the access required for their registered purpose (least privilege) and only the tools and functions required (least agency).
2. Agents must not hold administrative, owner or wildcard permissions in any production system without [AI governance body] approval.
3. Access should be scoped to the task and issued just in time where the platform supports it.
4. Controls restricting agent behaviour must be enforced by the platform, gateway or target system. Instructions in prompts are not an acceptable sole control.
5. Agent access must be reviewed by the owner at the frequency set for its tier, and whenever the agent's model, instructions, tools or autonomy change.

OWASP calls this "complete mediation": authorisation in downstream systems "rather than relying on an LLM to decide". See the AI Agent Authorisation Guide.

5.4 Acting on behalf of users

1. An agent acting on behalf of a user must never exceed that user's access.
2. Delegated access must be limited to the scopes needed for the task, and should identify both the user and the agent to downstream systems.
3. Agents and tools must not forward a user's access token to other services; each service must receive a token issued for it, with its audience restricted to that service.
4. Users must be able to see and revoke the access they have delegated to agents.

See the OAuth Token Exchange and Delegation Guide.

5.5 Human oversight

1. High-impact actions must require approval by an authorised person before execution, unless an exception is approved by [AI governance body].
2. Approval must be enforced technically, outside the agent, and the approver must be shown the actual action, target and parameters. The approval must be bound to that exact action and expire.
3. Each agent's autonomy level, and the actions it may take without approval, must be recorded in the registry.
4. People assigned to approve agent actions must have the competence, training and authority to refuse them.

The Replit AI Agent Database Deletion 2025 shows the limit of instructions alone: the agent deleted a live database during a declared code freeze.

5.6 Tools, MCP servers and integrations

1. Agents may only use tools, MCP servers, plugins and agent frameworks on the [approved list], recorded with source and version.
2. Remote MCP servers must require authorisation and must validate that tokens were issued for them.
3. Tool definitions, descriptions and tool results must be treated as untrusted input; changes to approved tools must be reviewed before use.
4. Code execution by agents, and local MCP servers, must run in a sandbox with restricted file system and network access.
5. Communication between agents must be authenticated and protected in transit.

Tool output can carry instructions: in the Sentry MCP Agentjacking 2026 research, a planted error report led coding agents to run a command with the developer's privileges. See the MCP Security Guide and the Multi-Agent and A2A Security Guide.

5.7 Data protection

1. Agents must only access data classified up to [classification] unless approved in their registration.
2. Retrieval by agents must respect the access rights of the user on whose behalf they act.
3. Agent memory must be isolated per user and per session where agents serve multiple users, and retained for no longer than [period].
4. Use of agents to process personal data must comply with [data protection policy], including any required impact assessment.

See the Permission-Aware RAG Guide.

5.8 Logging and monitoring

1. Every agent action must be logged with the agent identity, principal, tool or API used, credential identifier, authorisation decision, approvals and outcome.
2. Agent logs must be protected against tampering, handled according to the classification of the data they contain, and retained for [period, at least six months where the EU AI Act applies to the agent as a high-risk system].
3. [Security operations] must monitor agent activity for anomalous behaviour, including use of new tools or data, unusual volumes, repeated permission errors, credential discovery and destructive actions.

5.9 Incident response

1. Every production agent must be capable of being stopped, and all its credentials and grants revoked, within [X] minutes.
2. This capability must be tested at least [annually] for Tier 3 agents and after any change to the agent's platform or credentials.
3. Agent-related incidents must be handled under [incident response procedure], including assessment of notification obligations.

See the AI Agent Observability and Incident Response Guide.

5.10 Third-party agents and AI services

1. Third-party AI services and agent platforms that access [Organisation] data must be assessed under [third-party risk procedure] before use.
2. Users must not grant third-party AI applications access to [Organisation] data beyond [low-risk scopes] without approval.
3. Contracts must address data use (including use for model training), security of credentials held on [Organisation]'s behalf, logging available to [Organisation], and incident notification.

5.11 Development and testing

1. Agents must be threat modelled before receiving production access, and again after significant change.
2. Tier 2 and Tier 3 agents must be tested for prompt injection, privilege escalation and data exfiltration before deployment, and retested after a change of model, prompt, tools or memory.
3. Development and test agents must not use production credentials or production data without approval.
4. AI coding agents must run with scoped credentials and must not have direct access to production deployment credentials.

See the AI Agent Threat Modelling Guide and the AI Coding Agents Security Guide.

5.12 Retirement

1. When an agent is no longer needed, the owner must request retirement.
2. Retirement must revoke all credentials, tokens and grants, remove the agent from discovery and routing, archive its logs and update the registry.
3. Agents with no activity for [X] days must be reviewed and suspended if no longer required.

6. Exceptions

Exceptions to this policy must be requested by the agent owner, risk assessed by [Security team], approved by [approver], recorded with compensating controls and an expiry date, and reviewed before expiry. An expired exception is treated as non-compliance.

7. Compliance

Compliance with this policy will be monitored through the agent registry, access reviews, security monitoring, kill switch tests and internal audit. [CISO] reports compliance to [AI governance body] at least [quarterly], using the measures under "Metrics that show progress". Agents found to be non-compliant may be suspended. Breaches of this policy by staff may be handled under [disciplinary procedure].

8. Related documents

• [Information Security Policy]
• [Identity and Access Management Policy]
• [Non-Human Identity Standard]
• [Acceptable Use of AI Policy]
• [AI Agent Deployment Standard and go-live checklist]
• [Data Protection Policy]
• [Third-Party Risk Management Procedure]
• [Incident Response Procedure]

9. Review

This policy is owned by [policy owner] and will be reviewed at least annually, or sooner following significant changes in technology, regulation or [Organisation]'s use of AI agents, or after a significant agent-related incident.

Framework mapping

The EU AI Act column applies only where an agent is, or is part of, a high-risk AI system; check classification with your legal team.

Article 14(4)(e) asks that people overseeing a high-risk system can interrupt it "through a 'stop' button or a similar procedure that allows the system to come to a halt in a safe state", which section 5.9 implements for agents. Article 26(6) requires logs to be kept for "at least six months". The NCSC guidelines cover secure design, development, deployment, and operation and maintenance. See the NIST AI RMF Guide and the EU AI Act Compliance Guide.

Common failure patterns

• Agents on personal credentials: actions look like the builder's own, and access outlives their departure.
• Approval in the prompt: "ask before deleting" sits in the system prompt; OWASP's cheat sheet advises separating decision-making from execution.
• Token passthrough: an MCP server forwards the user's token downstream; the MCP security best practices warn it breaks the audit trail.
• Kill switch that only stops the process: the agent halts but its tokens and OAuth grants stay valid.
• Standing production access for coding agents: the condition behind both the Replit and PocketOS deletions.

Metrics that show progress

Implementation guidance

Adopt the policy in phases, starting with the agents already live.

Make registration, a dedicated identity and a tool allow list prerequisites for deployment where you can. Supporting guides:

• Registration, identity and retirement: see the Agentic AI Identity Guide.
• Ongoing reviews and certification: see the Identity Governance for AI Agents Guide.
• Regulatory mapping: see the Agentic AI Compliance Guide.

Practitioner checklist

• Agree the risk tiers and high-impact action list first.
• Load every production agent into the registry.
• Remove personal and shared credentials from Tier 3 agents.
• Enforce approval outside the agent, bound to the exact action.
• Check MCP servers validate token audience and do not pass tokens through.
• Test the kill switch, including token and grant revocation, and record the time.
• Set mandatory expiry dates in the exception register.

Standards and references

• NIST: AI 100-1 Artificial Intelligence Risk Management Framework (AI RMF 1.0)
• EUR-Lex: Regulation (EU) 2024/1689 (Artificial Intelligence Act)
• NCSC: Guidelines for secure AI system development
• DSIT: Code of Practice for the Cyber Security of AI
• OWASP GenAI Security Project: OWASP Top 10 for Agentic Applications for 2026
• OWASP: LLM06:2025 Excessive Agency
• OWASP: AI Agent Security Cheat Sheet
• Model Context Protocol: Authorization specification
• Model Context Protocol: Security Best Practices
• IETF: RFC 8693 OAuth 2.0 Token Exchange
• IETF: RFC 8707 Resource Indicators for OAuth 2.0

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 Identity Maturity Model · NHI Lifecycle Management Guide · IAM and IGA Basics · AI Agent Deployment Checklist