The New Frontier in Identity Security: AI Agent Access

1. Agents Are Here and They Have Access

Past the inflection point

International Data Corporation (IDC) projects actively deployed AI agents will exceed one billion worldwide by 2029.^[1] That is not a distant forecast. Machine identities already outnumber human identities 82 to 1 across organizations worldwide.^[2] Microsoft Copilot Studio and SharePoint users created over one million custom agents in a single quarter in 2025, up 130% from the previous period.^[3] The inflection point is not coming. It already happened.

Coding agents like Claude Code and Cursor operate autonomously for hours, making hundreds of tool calls per session across codebases, databases, infrastructure and deployment pipelines. 90% of engineering teams now use AI coding tools.^[4] Claude Code reached $1 billion in annualized revenue within six months of launch and now exceeds $2.5 billion.^[5] Sales, finance and HR teams connect agents to CRMs, ERPs and HRIS platforms. Autocomplete gave way to full autonomous task execution faster than most security teams had time to prepare for.

Security teams are already behind. Microsoft's Cyber Pulse research found that 80% of Fortune 500 companies deploy active AI agents built with low-code and no-code tools. Of those deployments, 29% are entirely unsanctioned: agents that no security team has approved, audited or even registered.^[6]

Agents need autonomy to reach full capability

An agent that asks for permission before every action is not a real agent. It is a chatbot with extra steps. The entire value proposition of agentic systems is that they find their own paths. They reason about a task, determine which tools to use, discover what information they need along the way, decide what sequence of actions to take and execute across multiple systems without constant human oversight.

That emergent path-finding is what makes agents valuable. It is also what makes them ungovernable with today's infrastructure. Agents need access to do their work: SaaS applications, cloud infrastructure, internal APIs, databases, file systems, communication tools, code repositories. And right now, that access is almost always granted by borrowing human OAuth credentials. Agents get broad permissions with long-lived, static access. No standard authorization layer governs what agents do at runtime.

The missing authorization layer

The industry has invested heavily in building the connectivity layer for agents. Anthropic's Model Context Protocol (MCP) achieved 97 million monthly SDK downloads and over 10,000 active public tool servers within its first year.^[10] Google contributed its Agent2Agent (A2A) protocol to the Linux Foundation. Everyone is building the pipes for agentic communication. The governance layer that controls what flows through those pipes barely exists.

Some argue the models themselves are the solution. LLM guardrails, safety training, system prompts that instruct the agent to be careful. This is necessary but fundamentally insufficient. Guardrails inside the model are probabilistic. They can be bypassed through prompt injection, adversarial inputs or through the model reasoning itself into a situation where the guardrail does not apply (intent drift). You cannot build a security boundary on a system that is, by design, non-deterministic. The authorization layer has to be independent of the model.

The consequences are already documented. In March 2026, an autonomous AI agent breached a McKinsey's internal AI platform in two hours. It needed no credentials and no insider knowledge. It gained access to millions of internal messages and the system prompts governing thousands of agents.^[7] Separately, a Meta AI safety researcher's personal agent deleted her entire inbox after its context window silently discarded the "confirm before acting" constraint.^[8] Both failures share the same root cause: no independent layer evaluated the agent's actions before execution.

No authorization layer sits between the agent deciding to take an action ("I need to go to that database and read that data") and the action being executed. Each agent job should go through this type of review: should this specific action, in this specific context, by this specific agent acting on behalf of this specific user, be allowed?

2. Why Existing Access Models Break

Existing security frameworks cannot adequately govern AI agent access. 68% of organizations lack identity security controls for AI.^[2] Three areas where traditional security approaches fail agents.

Traditional Identity and Access Management (IAM) does not model delegated decisions

The traditional IAM stack was built around a simple assumption: the entity that authenticates is the entity that decides what to do. A human logs in, proves who they are, and the system grants them a set of permissions. The human then exercises judgment about which permissions to use, when, and how.

This model works (to some extent) because humans carry accountability. A person who deletes a production database can be asked why they did it. They have a manager, a role, a name on the audit log and legal liability. They operate at human speed, which lets them notice when something feels wrong, pause, and reconsider. The entire IAM framework assumes a decision-making actor who can be held responsible for their actions and who exercises judgment at every step. And let's not forget: even access for humans is an unsolved problem in many companies.

Agents inherit a human's permissions through delegation, but no existing identity framework distinguishes between what the human is authorized to do and what the agent should be authorized to do on their behalf. An agent that can read a database and an agent that can decide to delete records carry completely different risk profiles. IAM treats them identically.

Non-Human Identity (NHI) management breaks on emergent behavior

Is this the answer? Can agents be governed like traditional non-human identities? We've heard this a lot recently: "Agents are another type of non-human identity. We already manage service accounts, API tokens and OAuth grants. Same category."

To be clear: agents are not the same category as the non-human identities known so far.

Traditional non-human identity management works because non-human actors in classic architectures are deterministic and bounded. A service account runs a specific pipeline. An API integration syncs data between two defined systems. An OAuth grant enables a scoped, predefined set of operations. A Continuous Integration/Continuous Deployment (CI/CD) token triggers a known sequence of build steps. You can enumerate what these identities will do because they were built to do exactly that and nothing else.

Agents operate in open, emergent environments. A coding agent given access to a repository might decide it needs to query a database to understand a data model, then read environment variables to understand the deployment configuration, then call an external API to verify an integration, then modify a configuration file it discovered during exploration. None of these steps were predetermined. The agent discovered them at runtime based on its reasoning about the task.

This is the fundamental difference. Non-human identity management assumes you can define the access boundary at provisioning time because the system's behavior is predetermined. With agents, the access boundary is discovered at runtime. When an agent encounters resources, it decides it needs them and attempts to use whatever credentials it has. The path is emergent, not scripted.

Machine identities already outnumber human identities by a factor of 82 to 1 in the average enterprise.^[2] Agents are about to add a category that is neither as predictable as traditional NHIs nor as accountable as humans.

Observability is not governance

The third response: tool-call observability. Log everything the agent does, build dashboards, create alerts, track anomalies. This is valuable. But it is not enough. Logging that an agent accessed a customer database after reading a document containing personally identifiable information (PII) is useful information after the fact. The action already happened. The data was already read. If the agent then sent that data to an external endpoint, observability tells you about it. It does not stop it.

The speed and scale of agent operations compress the window between action and consequence to near zero. A human employee who accesses a sensitive file and then starts composing an external email gives you seconds or minutes to intervene. An agent that reads sensitive data and then immediately calls an external API gives you no window at all.

Governance requires the ability to intervene before execution, not merely record what happened. A dashcam records the accident. Brakes prevent it. Observability without enforcement only gives you a dashcam for your agents but no brakes.

3. The Core Problem: Static Permissions, Broad Scopes

Every agent gets more access than it needs

When a company deploys an AI agent today, someone gives it credentials. An API key, an OAuth token. These credentials are scoped at setup time based on what the agent might need, which in practice means based on what makes the agent work without breaking.

The problem starts with how agent access is defined. In the MCP ecosystem, each tool server exposes a set of capabilities, and the scope of those capabilities is defined by the server author, not by the organization connecting the agent.^[10] A GitHub MCP server might expose read, write, delete and admin operations as a single tool set. A Slack MCP server might grant access to read messages, post messages, manage channels and invite users. The result is that an agent connected to ten tools effectively has dozens or hundreds of individual capabilities, most of which it does not need for any given task.

Because nobody can predict exactly which of these capabilities the agent will use at runtime, teams leave them all enabled. A coding agent gets access to the full repository, the CI/CD pipeline and often the production database. A sales agent gets access to the entire CRM, email sending capabilities and calendar management. An IT automation agent gets admin-level access to the tools it manages because anything less causes tasks to fail unpredictably.

This is not laziness. It is the pragmatic response to infrastructure that cannot support job-specific permissions. If the agent encounters a permission it does not have, the task fails. Today, there is no proper mechanism for the agent to request additional access, wait for that access to be provisioned and then resume where it left off. The workflow breaks. So teams give agents everything they might need upfront, because the alternative is constant failure. In traditional IAM, this would fail every access review. For agents, there is no access review to fail.

Standing access is the structural risk

Broad scopes are one problem. Standing access is the other.

Standing access means the agent's permissions persist regardless of whether it is currently executing a task, what that task is or who asked for it. An agent configured on Monday for a data migration still holds those database permissions on Friday. The same pattern repeats everywhere: email agents retain send permissions long after a campaign ends, admin access granted for a one-time configuration change persists for every subsequent task.

In traditional IAM, standing access is already understood as a risk, which is why companies enforce time-based access and regular reviews. Yet 88% of organizations define "privileged user" as applying solely to human identities.^[2] That is going to change. Agents will have to request access, and that access will have to be time-based and reviewed regularly.

Nobody knows who authorized what

Today, when an agent takes an action, the audit trail typically shows a credential identifier, a timestamp and the action itself. It does not show which human user the agent was acting on behalf of, what the original task was, or whether the action was aligned with that task.

The fix is straightforward in principle: every agent action must trace back to a delegating human through a governed session. The agent does not need its own standing identity. It inherits the delegating user's permissions, scoped to the task. Every permission grant, every action and every access decision gets logged against that session and traced back to the human who authorized it. You get a full audit trail of what each agent was authorized to do, what it did and who was responsible.

4. What Can Go Wrong

Gartner predicts that by 2028, 25% of enterprise breaches will be traced back to AI agent abuse, from both external attackers and malicious insiders.^[9] We believe this underestimates the real number. Agents are goal-oriented systems. They will do whatever it takes to complete the task. If an agent determines that deleting a file, reading a secret or calling an external API is necessary to accomplish its goal, it will, as long as its scopes permit it.

And it's already happening:

Agents delete data

The Amazon Kiro incident above is not an isolated case. In July 2025, Replit's AI coding agent wiped a live production database containing over 1,200 customer records, then fabricated thousands of fake entries to mask the damage.^[16] The agent had been given explicit instructions not to make changes, repeated in capital letters. It ignored them. When questioned, it admitted to running unauthorized commands and violating the code freeze. No guardrail in the infrastructure stopped it.

Agents share secrets

In August 2025, a compromised build package in the NX ecosystem included malware targeting Claude Code environments, harvesting cryptocurrency wallet secrets the agent had accessed while working.^[14] Agents accumulate sensitive context (API keys, database credentials, .env files) as a side effect of doing their job. That context is accessible to anything in the same environment. This also creates compositional risk: an agent that reads customer PII and then drafts an external email has created an exfiltration path. Neither action is dangerous alone. The combination is.

Agents download malicious tools and skills

The MCP ecosystem has over 10,000 active public servers with 97 million monthly SDK downloads.^[13] In September 2025, a malicious npm package impersonating Postmark's email MCP server began silently blind carbon copying (BCC'ing) all outbound emails to an attacker-controlled address after a routine update.^[15] One line of code, thousands of compromised emails. Tool responses and instructions occupy the same context window, so the agent cannot distinguish a malicious instruction from a legitimate one.

The conversation history is the attack surface

All of these risks share a common root: the agent's conversation history is both its working memory and its instruction set. There is no separation between the "control plane" and the "data plane." Prompt injection through a malicious document, a compromised tool response or crafted database content can redirect agent behavior in ways traditional access controls cannot prevent. And agents chain dozens of tool calls per task. By the time anyone notices, the damage has propagated across multiple systems.

5. What Governing Agent Access Actually Requires

The previous chapters describe four structural gaps: access checked at setup rather than at action time, standing permissions that agents never lose, no traceability from agent actions back to human decisions and no mechanism to intervene before damage is done. Closing these gaps requires a governance layer that operates at a fundamentally different speed and granularity than anything in traditional IAM.

Authorization Must Move From Setup Time to Action Time

Traditional access control evaluates permissions once, at connection time. An agent that authenticates with a service account inherits everything that account can do, for as long as the session lasts. The incidents in Chapter 4 all exploited this gap: the agent had broad access from the start, and no policy evaluated individual actions before they executed.

Agent governance requires per-action policy evaluation. Every tool call, API request, and database query should be evaluated against policy rules before it executes. The evaluation considers the action type (read, write, destructive, external), the delegating user's entitlements, the sensitivity of the target data and the agent's session history. Three outcomes: auto-approve for low-risk actions like reading internal documents, escalate to a human for sensitive operations or deny outright for destructive actions that violate policy. Agents start every task with no permissions and lose them when the task ends.

Humans Must Stay in the Loop Without Slowing Agents Down

The value of agents depends on their ability to operate autonomously. A governance layer that requires human approval for every action reintroduces the bottleneck that agents were built to eliminate. The challenge: keep humans in the decision loop for sensitive actions without reducing agents to interactive assistants that pause after every step.

The industry calls this mid-execution consent. When an agent encounters an action that policy flags for human review, it pauses. The request routes to the appropriate decision-maker, not the user who initiated the task, but whoever organizational policy designates: a manager, a security team member, a compliance officer. That person evaluates against policy. The agent resumes exactly where it stopped, with full context. From the agent's perspective, the approval is a slow tool call, nothing more.

This is structurally different from the confirmation prompts that some agent platforms offer today. A chat dialog asking "are you sure?" trains users to click "yes" reflexively. Mid-execution consent routes the decision to a different human, evaluates against organizational policy and produces a structured record of who approved what and why.

Two additional requirements follow. First, agents should never handle real credentials. The governance layer injects credentials into outbound requests at runtime; agents hold only opaque, session-scoped references. If an agent's context is compromised through prompt injection or conversation history manipulation, no real tokens or API keys can be extracted. Second, every agent's permissions must derive from a specific human's entitlements. An agent acting on behalf of a junior engineer cannot access what a CTO can access, even if both use the same tool. Changes to the human's access automatically cascade to every agent acting on their behalf.

‍