AI agent identity risk is outpacing API governance controls

At a glance

What this is: This is Salt’s argument that AI agents are expanding the attack surface through API and MCP access, with visibility and governance failing to keep pace.

Why it matters: For IAM, NHI, and security teams, the issue is that autonomous or semi-autonomous agent behaviour can turn existing API trust models into a control gap across identity, privilege, and monitoring.

👉 Read Salt's analysis of AI agent API risk and MCP exposure

Context

AI agent identity risk is emerging at the point where software that makes decisions also starts using production APIs. In practice, the governance problem is no longer just about authenticating a workload or protecting a secret. It is about understanding what the agent can decide, what it can call, and whether those permissions change faster than security teams can review them.

Salt frames this as the next phase of the API visibility problem, with MCP acting as the connective layer between agents, LLMs, and downstream services. That framing is directionally right for identity teams: once an agent can trigger business actions, the identity question becomes whether access is bounded, observable, and revocable at the speed of execution, not the speed of policy review.

The article’s starting point is typical rather than unusual. Most enterprises have already learned that API exposure becomes a governance issue long before it becomes a breach issue, and AI agents compress that timeline further.

Key questions

Q: How should security teams govern AI agents that call APIs instead of using a UI?

A: Security teams should govern AI agents by treating each callable action as a scoped entitlement, not as a general application login. The key control is to limit which APIs, data sources, and write actions the agent can chain together in one session. That keeps machine-paced behaviour inside a reviewable boundary instead of relying on human-style session assumptions.

Q: Why do AI agents complicate least-privilege access models?

A: Because agents often use shared or long-lived NHIs, move quickly, and cross platform boundaries that human-centric review processes do not cover well. Least privilege still applies, but it has to be enforced at the identity, resource, and execution layers together. Otherwise the agent keeps more reach than the task requires.

Q: What breaks when AI agent access is inherited directly from the user who triggered the workflow?

A: Direct inheritance collapses two different subjects into one security decision. The human may be authorised for the workflow, but the agent may reach systems the human never needed to touch directly. That creates privilege inflation, weakens accountability, and makes incident review harder because the access path no longer reflects the real executor.

Q: Who is accountable when an AI agent takes an unsafe action?

A: Accountability should sit with the business owner of the agent, the team that provisioned the access, and the control owners responsible for monitoring and revocation. If no one can answer who approved the identity, the scope, and the oversight model, the governance framework is not complete enough for production.

Technical breakdown

MCP as the identity layer between agents and APIs

Model Context Protocol, or MCP, is the transport and coordination layer that lets an AI agent discover tools, call services, and exchange context with downstream systems. From an identity perspective, MCP matters because it turns a model output into an executable action path. That creates a chain of trust across the agent, the broker, and the API it reaches. If the agent can choose tools dynamically and call them at runtime, then the security boundary is no longer the model alone. It is the full identity path from prompt to permissioned action.

Practical implication: Map every MCP-connected agent to the API identities it can reach, and treat that path as a governed access surface.

Why over-permissive roles turn agents into high-blast-radius identities

An AI agent becomes dangerous when its identity inherits broad API permissions without task scoping. The risk is not only unauthorized data access. It is also business-action abuse, such as workflow triggering, transaction creation, or cross-system movement through delegated permissions. In NHI terms, this is standing privilege applied to a runtime actor that can act faster and more variably than a human. The result is blast radius expansion: one compromised or misdirected agent can exercise all the access of the role it was handed.

Practical implication: Constrain agent permissions to task-specific scopes and separate read, write, and action rights wherever possible.

Why visibility and detection must be runtime, not retrospective

Traditional logs often show that an API was called, but not whether the call matched the agent’s intended purpose. That is insufficient when the agent can chain decisions, access multiple tools, and call downstream services without a human in the loop. Runtime context matters: who the agent is, what it was allowed to do, what it actually did, and whether the call sequence matched policy. Without that context, teams can detect that something happened but not whether it was legitimate, misconfigured, or malicious.

Practical implication: Instrument agent activity with runtime context, not only API logs, so investigation can distinguish normal delegation from abuse.

Threat narrative

Attacker objective: The objective is to hijack an agent’s delegated access so it can be used to exfiltrate data or trigger harmful business actions.

1. Entry occurs when an AI agent receives access to APIs or MCP-connected tools with more privilege than the task requires.
2. Escalation follows when a poisoned prompt, unmonitored callback, or over-permissive role drives the agent to access data or trigger actions outside its intended scope.
3. Impact appears when the agent leaks information, initiates fraudulent transactions, or moves through connected systems at machine speed without human review.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agent identity is becoming an API governance problem before it becomes a model governance problem. Salt’s framing points to a structural shift: the attack surface now sits in the execution path between agent reasoning and downstream action. That means the governance question is no longer limited to whether the model is safe. It is whether the agent identity can be trusted to call tools, invoke APIs, and move data without expanding its own privilege boundary. Practitioners should treat agent identity as a first-class control surface, not an AI side issue.

Least privilege is no longer definable only at provisioning time when the actor can choose actions at runtime. The access model was designed for identities whose purpose was known before execution began. That assumption fails when an AI agent can select tools, chain calls, and alter its action path mid-session. The implication is not just tighter policy. It is a rethink of how entitlement, intent, and approval are expressed for actors that do not follow a fixed script.

Model Context Protocol introduces an identity translation layer that can hide risk if it is treated as plumbing. MCP is not just a connector; it becomes part of the trust chain that determines what an agent can see and do. When that layer is opaque, security teams lose the ability to distinguish authorised delegation from uncontrolled capability expansion. The practitioner conclusion is straightforward: if MCP is in the path, governance must extend to the path.

We should expect the identity security market to converge around agent visibility, tool governance, and runtime enforcement. The article reflects a broader market reality that API security alone is no longer enough when software can initiate actions independently. This does not eliminate NHI controls; it extends them into a more dynamic operating model. Teams that still separate API security, NHI governance, and AI oversight will struggle to answer who acted, under what authority, and at what point that authority widened.

AI agent governance will fail if organisations keep measuring access as a static state instead of a changing behaviour. The key shift is from entitlement snapshots to behavioural review of action sequences, tool calls, and data exposure. That is especially important where agents touch financial workflows or customer data. Security leaders should now think in terms of identity blast radius, not just policy compliance.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface.
• A separate finding from the same research shows that only 44% of organisations have implemented policies to govern AI agents, despite 92% saying that governance is critical to enterprise security.
• For a broader NHI context, see The State of Non-Human Identity Security for visibility and confidence data across third-party connections and credential rotation gaps.

What this signals

Agent identity governance is moving faster than most IAM operating models. With 80% of organisations already seeing AI agents act beyond intended scope, the programme risk is no longer theoretical. Teams need to decide whether agent access is managed as a one-time provisioning event or as a continuously changing behavioural problem.

Model Context Protocol will force a closer link between API security and identity security. If agents are the actor and MCP is the transport, then governance has to cover both. That means tightening ownership, logging, and approval paths around every agent-to-service delegation point.

Identity blast radius is the right concept for this category. One agent with broad delegated access can span data, workflow, and transaction systems in a way that human-centered IAM controls were never designed to absorb. Practitioners should measure blast radius by reachable systems, permitted actions, and recoverability after misuse.

For practitioners

• Inventory every agent-facing API path Map which AI agents, MCP servers, and downstream services are connected, then classify each path by data sensitivity, action capability, and ownership. If you cannot show who controls the path, you do not yet have governance over it.
• Separate read access from action authority Do not let an agent that needs context also inherit write or transaction privileges by default. Create distinct scopes for retrieval, decision support, and business execution so a single identity cannot silently cross those boundaries.
• Log runtime context, not just API calls Capture the agent identity, prompt or task context, tool invoked, target system, and outcome. Plain request logs are not enough to reconstruct whether the call was legitimate, misdirected, or injected.
• Apply human-style review only where it still fits Use approval gates for high-risk actions, but do not assume the same review cadence works for an agent that can act in seconds. Rework governance so the control matches the speed and variability of the actor.

Key takeaways

• AI agents create an identity and API governance problem because they can make decisions and execute actions through connected services.
• The biggest risk is not the model alone, but the permissioned path from agent to downstream systems when visibility and scope controls are weak.
• Practitioners should govern agent identities as runtime actors with bounded authority, separate action scopes, and runtime telemetry.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

Salt's full article covers the operational detail this post intentionally leaves for the source:

• The article spells out Salt's view of how AI agents, LLMs, and MCP connect to production APIs in practice.
• It outlines the visibility, governance, context, and detection capabilities the vendor says are required for secure deployment.
• It describes the security problem from the vendor's API-centric perspective, including how it interprets agent misuse and downstream exposure.
• It provides the vendor's own framing for why AI agent traffic will expand and how that changes the attack surface.

👉 Salt's full article covers the API visibility gap, governance model, and detection angle in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.