AI Agent Permissions: How to Audit What Your Agents Can Actually Do

Ask any engineering team what permissions their various AI agents have, and you're likely to get a shrug and a "probably have whatever the service account does?"

That might have been acceptable a few years ago when the "agent" in question was really just a cron job with three API calls and a set of instructions. Not so much anymore. Modern AI agents can plan, call out to tools, spin up sub agents, and make judgments about what systems or tools to use based on a prompt.

Gartner estimates that by 2026, 40% of enterprise applications will have some form of task-based AI agents compared to less than 5% the previous year. And most of those agents are likely running on production credentials that have not had their access reviewed since launch.

This article is a working guide to auditing agent access based on practical experience across multiple companies in the space. If you work in a CTO office, VP of Engineering role, or similar capacity where you need to know, understand, and communicate to auditors or executives what your agents can and cannot do, it's designed for you.

Why AI agent permissions are a different problem than user permissions

Traditional access control assumes a few things that don't hold for agents:

• A human is behind every action, so intent can be inferred from who's logged in.
• Access patterns are relatively static, a person's job function doesn't change hour to hour.
• A single identity performs a single action at a time.

Agents violate all three. An agent acts on behalf of a human subject but is not the human subject. The agent's decisions are the result of a prompt or plan formed at run-time, so what the agent decides to do can vary between two runs that are otherwise identical.

A single "agent identity" can spawn sub-agents or make tool-calls that delegate to other functions, each of which may inherit some subset of the privileges of their parent, potentially without any intention that this inheritance occur.

The research conducted by the Cloud Security Alliance on the agent governance gap highlights the issue of agents that act on the behalf of users, possess delegated credentials, make real-time authorization decisions, and can generate sub-agents with specific permissions; however, there is no specific identity model that covers these requirements. NIST came to the same conclusion after reviewing its own SP 800-53 control catalog, as the access-control, identification, audit, and supply-chain-risk families of controls found there do not adequately address the need to distinguish between an AI agent and a human operator, limit the agent's permissions based on the task's context, or identify an agent in a way that would meet forensic accountability needs.

Because of this, NIST's Center for AI Standards and Innovation announced the initiation of the AI Agent Standards Initiative in February 2026. Getting ahead of this shift is part of why a clear AI governance strategy matters as much as the technical audit itself.

---

What "AI agent permissions" actually cover

Before you can audit anything, you need a shared definition of what's in scope. Agent permissions aren't one thing, they're a stack:

• Identity, how the agent authenticates (OAuth app, service account, API key, workload identity) and whether that identity is distinguishable from a human's.
• Tool/function access, which functions, APIs, or plugins the agent is allowed to invoke, and under what parameters.
• Data scope, which records, tables, documents, or file paths the agent can read or write, independent of which tools it holds.
• Action authority, whether a given tool call executes automatically or requires human approval (read vs. write, reversible vs. irreversible, low-value vs. high-value).
• Delegation boundaries, what a sub-agent or spawned process inherits from its parent, and whether that inheritance is scoped down or copied wholesale.
• Session and credential lifetime, how long a token or grant is valid, and whether it's re-issued per task or left standing.

Most permission reviews only dig into layer 2, the tool list. This is like conducting a security audit of a building by checking which doors exist and completely ignoring who has keys, how long the keys are valid for, and who is actually walking through the doors.

---

The audit framework: five passes

Run these as five distinct passes, not one big review. Each one surfaces different problems, and combining them tends to produce a report nobody acts on.

Pass 1, Inventory: what agents exist and what identity do they run as

You cannot audit what you haven't listed. Build (or pull, if you already track it) a registry with, at minimum:

• Agent name and owning team
• Identity type and where credentials live (secrets manager, env var, vault)
• Every tool/API/connector it's wired to
• Whether it can spawn sub-agents, and what those inherit
• Last time its permissions were reviewed

This is a basic check, which many companies overlook. That's why "shadow AI" (AI agents created by an organization, connected to production systems, and not formally documented somewhere) is likely to be one of the critical enterprise AI risks in 2026 security audits. Teams with mature DevOps consulting practices tend to catch this gap far earlier, since credential and access tracking is already part of their pipeline discipline.

The inability to provide such a list in less than a day is the finding here.

Pass 2, Least privilege: does each permission map to a task the agent actually performs

For every tool and dataset in scope, ask: what task requires this? If the answer is either "it might come up" or "we gave it broad access so that we wouldn't have to constantly update it," tag it as a concern.

This pattern is, by far, the most common vulnerability class in the frameworks converging upon agent security this year: Google's SAIF 2.0 Agent Risk Map, Anthropic's guidance on building zero-trust patterns for agents, and Microsoft Entra's Agent ID all recommend limiting scope to the minimum set of tools required for a given task, and considering every write-capable agent as an inherently high-risk identity by default. This is especially true for teams doing generative AI development, where agents are often wired into production systems faster than their permissions are reviewed.

A helpful way to think about this: if a prompt injection succeeded right now, what's the worst thing this agent could do with its current permission set?

If the answer is "export the customer database" or "issue unbounded refunds," it's not the prompt that's the vulnerability, it's the permission set.

Pass 3, Blast radius: map what a compromised or misdirected agent could actually reach

This pass is about consequence, not intent. Trace each agent's access outward:

• Which systems does it touch directly?
• Which systems could it reach indirectly through a tool it calls (e.g., an agent with "send email" access can trigger downstream automations it was never meant to control)?
• Are there irreversible actions (deletes, payments, external sends) reachable without a human checkpoint?

The OWASP Top 10 for Agentic Applications, 2026 names privilege abuse and tool misuse as a high-risk category since the blast radius, and not the likelihood, defines the impact of a security incident. The limited permission scope determines the potential damage even if the model misbehaves.

Pass 4, Delegation and inheritance: check what sub-agents actually get

If any of your agents can spawn sub-agents, or delegate tasks to other agents, confirm that delegation is scoped or copied.

The common mistake: a parent agent with broad access spawns a sub-agent for a narrow task, but the sub-agent inherits the parent's full permission set "for simplicity." This is a recurring blind spot in AI agent builder workflows, where sub-agent creation is often abstracted away from the team that owns permission review.

Now you have an unaudited agent often with no logs, holding permissions it doesn't need, for the ten minutes it exists.

Pass 5, Audit trail: can you reconstruct what an agent did, after the fact

Permissions that don't get logged are permissions that can't be proven to be enforced, or not enforced. For every agent with write-permissions, answer: what did it do, when, on behalf of whom, and was that within the scope of its permissions?

That is now what regulators and auditors are asking for: the "runtime truth" of what an agent did within a connected system, not the permission configuration snapshot, but what actually happened. This is a core piece of any serious digital transformation initiative that involves AI agents touching production data.

NIST IR 8596, the draft Cybersecurity Framework profile for AI it's proposing, was designed to give organizations a way to bake agent-centric accountability practices into an existing CSF 2.0 program, instead of starting from scratch.

---

Common over-permissioning patterns worth checking first

If you only have time for a partial audit, start here, these show up constantly:

• The "just use the admin key" shortcut. Fastest way to unblock a prototype, and the permission scope almost never gets revisited once the agent goes to production.
• Standing credentials instead of per-task grants. A token that's valid indefinitely is a liability that sits there whether the agent is running or not.
• Tool access granted at the connector level, not the action level. "Has Gmail access" often really means send, read, delete, and manage filters, when the task only needed "read subject lines." This is often a side effect of rushed AI integration work, where connectors are wired up broadly to save time upfront.
• No distinction between read and write scopes. An agent that only needs to summarize data frequently ends up with write access because it was easier to provision once.
• Sub-agents with copy-pasted permissions. Covered above, and worth checking twice, this is where privilege creep hides best because nobody thinks of a sub-agent as a separate identity.
• No expiration on approval grants. A human approves a one-time exception, and the elevated scope quietly becomes permanent because nothing forces it to roll back.

---

Turning the audit into a standing process

A one-time audit shows you where you are today, but it does not prevent problems later. These three practices can help you keep your security strong:

1. Review permissions when you deploy changes, not just on a schedule. Whenever an agent's tools, prompt, or AI model changes, check its permissions again. Don't wait for a quarterly review because the permissions may already be outdated.
2. Treat AI agents as separate identities in your IAM system. Don't manage an agent like a human user or a normal service account. AI agents need their own identity, limited access, and clear activity logs because they can act much faster than humans.
3. Always check the possible damage before giving an agent more access. Ask, "What could happen if someone tricks this agent into misusing this access?" If the answer is "it could cause serious damage," add a human approval step for that action instead of giving the agent more overall access.

---

Where this fits in a broader AI governance program

Permissions that don't get logged are permissions that can't be proven to be enforced, or not enforced. For every agent with write-permissions, answer: what did it do, when, on behalf of whom, and was that within the scope of its permissions?

That is now what regulators and auditors are asking for: the "runtime truth" of what an agent did within a connected system, not the permission configuration snapshot, but what actually happened.

NIST IR 8596, the draft Cybersecurity Framework profile for AI it's proposing, was designed to give organizations a way to bake agent-centric accountability practices into an existing CSF 2.0 program, instead of starting from scratch.

---

Conclusion

AI agent permissions should not be treated as a one-time security task. As agents change, gain new tools, and access more data, their permissions can quickly become too broad.

A strong permission strategy starts with knowing what each agent can access, giving it only the permissions it needs, limiting its blast radius, and keeping clear audit logs. Regular reviews and human approval for high-risk actions can further reduce the damage caused by mistakes or attacks.

The goal is simple: give AI systems enough access to complete their tasks, but never more than they need. This approach helps teams build safer, more controlled, and more trustworthy AI systems.