AI agent security starts with one shift in thinking: treat every AI agent as an identity with its own permissions, owner and audit trail, not as a feature hidden inside an app. Most large organisations already run agents that can read data and take actions, yet few govern them as carefully as they govern people. The quickest way to close that gap is a permissions checklist: give each agent an identity, grant only the access it needs, allow-list its tools, protect its credentials, keep humans in the loop for high-risk actions, log everything, build a kill switch and review access on a schedule.
This guide is for CISOs, CIOs, CTOs and platform owners who need to bring agents under control without stopping the teams that build and use them.
AI agents are already at work, and controls are lagging
Two 2026 vendor surveys show how far adoption has run ahead of governance:
- Okta, “AI Agents at Work 2026”: in a survey of 292 executives and 492 knowledge workers across seven countries, fielded in March 2026, 92% of executives said autonomous AI agents were already in widespread or moderate use in their organisation. Only 34% of organisations applied the same security controls to their agents as to their human workforce, even though 96% of executives said they were confident in their identity and access management for non-human identities. 58% of executives reported an AI-related security issue or close call in the previous 12 months.
- Wiz, “AI Threat Readiness Survey Report 2026”: in a survey of 100 senior IT and security decision-makers, only 17% of organisations said they maintain a comprehensive inventory of their models, agents and pipelines, and more than half had discovered unauthorised AI workloads inside their perimeter over the past year. 70% ranked access to sensitive data as a top agentic security concern.
The pattern is familiar from shadow IT: confidence at the top, sprawl underneath. The difference is that agents do not just store data. They act on it.
Why agents need their own permissions model
An AI agent is software that uses a large language model to plan and carry out tasks, usually by calling tools: reading a mailbox, querying a database, updating a CRM record, running code or raising a payment request. Three properties make agents riskier than traditional automation:
- They take instructions from content. An agent can be steered by text hidden in an email, web page or document it reads. This is prompt injection, which OWASP ranks first (LLM01) in its Top 10 for LLM Applications 2025.
- They often hold broad access. OWASP’s LLM06:2025 Excessive Agency describes the damage that follows when an agent has excessive functionality, excessive permissions or excessive autonomy.
- They are hard to see. Agents are created by developers, business teams and SaaS vendors, often using a person’s own credentials, so they rarely appear in an identity inventory.
In December 2025 the OWASP GenAI Security Project published a dedicated Top 10 for Agentic Applications. Several of its entries map directly onto permissions, including ASI01 Agent Goal Hijack, ASI02 Tool Misuse and Exploitation, ASI03 Identity and Privilege Abuse, ASI04 Agentic Supply Chain Vulnerabilities and ASI10 Rogue Agents. You cannot stop every attack on the model itself, but a good permissions model limits how much damage a manipulated or misbehaving agent can do.
The AI agent permissions checklist
Use the eight controls below as a review template for every agent in production or pilot. If an agent fails more than one or two, pause its expansion until the gaps are closed.
1. Give every agent its own identity and a named owner
- Register each agent in your identity provider as a distinct non-human identity, not a shared service account or a borrowed employee login.
- Record a business owner, a technical owner, the agent’s purpose, the data it touches and the systems it can change.
- State whether the agent acts on its own authority or on behalf of a specific user, and make that visible in the logs.
- Build the inventory before anything else. If you cannot list your agents, you cannot secure them.
2. Grant least privilege, scoped to the task
- Start from zero access and add only what the use case needs. Read-only by default, write access by exception.
- Scope access to specific folders, mailboxes, projects or record types rather than whole systems.
- Where an agent acts for a user, run its actions under that user’s permissions with minimal scope, so it can never do more than the person could.
- Enforce authorisation in the downstream system, not in the prompt. A system prompt that says “never delete records” is guidance, not a control.
- Prefer short-lived, time-bound access over standing privileges.
3. Allow-list tools and MCP servers
- Keep an approved list of tools, plugins and Model Context Protocol (MCP) servers that agents may connect to, and block everything else by default.
- Prefer narrow, purpose-built tools (“create a draft reply”) over open-ended ones such as a shell, unrestricted web requests or arbitrary code execution.
- Assess third-party MCP servers and plugins as you would any software supplier: who maintains them, what they can reach and how updates are controlled.
- Pin versions, and re-review whenever a tool’s description, scopes or owner changes.
4. Handle credentials properly
- Never place API keys, passwords or tokens in prompts, system prompts, agent memory or code repositories.
- Store secrets in a vault and issue short-lived, narrowly scoped tokens at run time.
- Give the agent its own credentials rather than reusing a person’s, so you can revoke the agent without locking out a colleague.
- Rotate credentials on a schedule and immediately after any suspected compromise.
5. Require human approval for high-risk actions
Not every action needs a person to click “approve”. Tier actions by impact and reversibility:
| Risk tier | Example actions | Suggested control |
|---|---|---|
| Low | Summarising a document, drafting a reply for a person to send, searching an approved knowledge base | Autonomous, logged |
| Medium | Updating a CRM record, creating a ticket, scheduling a meeting | Autonomous within limits, with rate limits and sampled review |
| High | Sending external email, changing access rights, deleting data, deploying code | Human approval before execution |
| Critical | Moving money, changing supplier bank details, bulk exports of personal data | Human approval plus a second check, or not permitted for agents at all |
Make the approval screen show exactly what the agent will do and why, so reviewers are not simply rubber-stamping requests.
6. Log every action and decision
- Log the prompt or trigger, the tools called, the data accessed, the action taken and the identity it acted under.
- Send agent logs to your SIEM alongside human activity so analysts can follow an incident end to end.
- Alert on unusual behaviour: new tools, unusual volumes, access outside normal hours or attempts to reach blocked systems.
7. Build a kill switch
- Be able to disable any single agent, revoke its tokens and stop queued actions within minutes.
- Know who is authorised to pull the switch, and test it as part of incident response exercises.
- Add “AI agent acting outside its intended scope” to your incident categories and runbooks.
8. Review access periodically
- Include agents in your regular access reviews, with the owner re-certifying each permission.
- Remove agents that have no owner, no recent activity or no current business purpose.
- Re-review after model upgrades, new tool connections or changes to the data an agent can reach.
- Red team high-impact agents before launch and after major changes.
Where to start this quarter
- Weeks 1 to 2: build a first inventory of agents from your identity provider, OAuth grants, developer platforms and SaaS admin consoles, and assign an owner to each.
- Weeks 3 to 4: score each agent against the eight controls above and fix the highest-risk gaps, usually shared credentials and broad write access.
- Weeks 5 to 8: publish a tool and MCP allow-list, introduce approval tiers and route agent logs into security monitoring.
- Weeks 9 to 12: run a kill switch drill, complete the first access review and agree the standard every new agent must meet before launch.
For a structured approach to setting policy, AccuroAI’s AI agent governance framework is a useful companion to this checklist. If your engineers and security team need to put these controls into practice, our Securing AI Agents programme covers agent threat modelling, permissions design and guardrails in hands-on labs. Leadership teams deciding how much autonomy to allow can start with AI Risk & Strategy for Leaders, and security teams wanting a broader curriculum can explore the AI Security Academy.
Frequently asked questions
What is AI agent security?
AI agent security is the set of controls that limit what AI agents can access and do, and that let you see and stop what they are doing. It covers identity, permissions, tool access, credentials, human oversight, logging and incident response, alongside defences against attacks such as prompt injection.
How is an AI agent different from a service account?
A service account runs fixed, predictable code. An agent decides what to do at run time based on instructions and content it reads, which means it can be manipulated into actions nobody planned. That is why agents need tighter scoping, approval steps for high-risk actions and closer monitoring than a typical service account.
What is an MCP server, and why does it need an allow-list?
The Model Context Protocol (MCP) is a common way to connect AI agents to tools and data sources. Each MCP server an agent connects to extends what the agent can reach and do. An allow-list ensures agents only use servers your organisation has reviewed, which reduces supply chain and data exposure risk.
Which OWASP lists cover AI agents?
The OWASP Top 10 for LLM Applications 2025 covers risks such as prompt injection (LLM01) and excessive agency (LLM06). The OWASP Top 10 for Agentic Applications, published in December 2025, focuses on agents specifically, including goal hijack, tool misuse, identity and privilege abuse, supply chain vulnerabilities and rogue agents.
Do we need to stop building agents until this is in place?
Usually not. Keep low-risk, read-only agents running while you build the inventory, and pause expansion of agents that hold write access, use shared credentials or touch sensitive data until they meet your minimum controls.
Secure your agents before they scale
Product Innovation Academy runs corporate AI security training for enterprises worldwide, with AI Security & Governance programmes delivered in partnership with AccuroAI. We can tailor a workshop around your agent platforms, identity stack and risk appetite. Request a proposal to get started.
Sources
- Okta, “AI Agents at Work 2026: Securing the agentic enterprise”, 27 May 2026. okta.com
- Wiz, “AI Threat Readiness Survey Report 2026”. wiz.io
- OWASP GenAI Security Project, “LLM01:2025 Prompt Injection”. genai.owasp.org
- OWASP GenAI Security Project, “LLM06:2025 Excessive Agency”. genai.owasp.org
- OWASP GenAI Security Project, “OWASP Top 10 for Agentic Applications for 2026”, 9 December 2025. genai.owasp.org