BOLA is the core identity risk in autonomous AI agent systems

At a glance

What this is: This is an analysis of how broken object level authorization becomes the dominant control failure in autonomous AI agent environments.

Why it matters: It matters because IAM, PAM, and governance teams must treat agent actions as object-level access events, not just authenticated API traffic.

👉 Read Salt's analysis of BOLA risk in autonomous AI agent systems

Context

Broken object level authorization is an access-control failure where an authenticated actor can reach objects it was never meant to touch. In agentic AI environments, that failure becomes more dangerous because the actor is not a person clicking through one record at a time, but a system capable of making rapid object requests across many APIs and MCP servers.

The identity governance problem is not just whether the agent is authenticated. It is whether the backend authorization model can distinguish intended use from machine-scale abuse, especially when the same agent can touch thousands of objects across dozens of systems. Traditional API gateways and WAFs were built for request filtering, not for governing the intent behind autonomous actions.

Salt frames this as an Agentic AI Action Layer problem, but the deeper issue is broader: once AI agents can act through APIs, object-level authorization becomes part of NHI governance, IAM design, and runtime monitoring at the same time.

Key questions

Q: How should security teams manage permissions for AI agents?

A: Security teams should regularly assess and update the permissions granted to AI agents to ensure they align with their intended scope. Implementing a governance framework that details access levels and usage policies is crucial to mitigate risks. Moreover, continuous monitoring can detect irregular permissions that may increase exposure.

Q: Why do AI agents make BOLA more dangerous than in traditional applications?

A: Because an autonomous agent can issue many valid requests in rapid succession, turning a single authorization gap into large-scale exposure. Traditional controls may see each call as legitimate, but they miss the abnormal object pattern created by machine-speed traversal across many records.

Q: What do security teams get wrong about agentic AI security tools?

A: The most common mistake is treating agentic AI security as an extension of an existing category such as NHI, endpoint, or DSPM. That view misses the fact that agents operate across multiple deployment patterns and require both posture controls and runtime response. A narrow tool can be useful, but it is not comprehensive governance.

Q: Who should own governance when humans and AI agents share access paths?

A: Ownership should sit with the identity, security, and platform teams jointly, because the control problem spans human delegation, machine credentials, and runtime auditability. If each team manages only its own layer, no one can reconstruct the full action chain or revoke access cleanly when the workflow changes.

Technical breakdown

Why BOLA becomes a machine-scale control failure in agentic AI

Broken object level authorization, or BOLA, occurs when an API verifies the caller but not the caller's right to a specific object. In a human workflow, that flaw is often exploited one record at a time. In an agentic workflow, a single autonomous system can enumerate object IDs, repeat requests at speed, and turn one authorization gap into bulk exposure. The important shift is not just volume, but context. The backend sees valid API calls; the security team sees nothing unusual unless it understands the object pattern behind them.

Practical implication: object-level authorization must be tested against high-volume, multi-object access patterns rather than single-request checks.

How MCP servers expand the attack surface for AI agents

Model Context Protocol servers let agents connect to tools and data sources so they can do work instead of merely generating text. That utility creates a new control surface because each MCP connection can expose APIs, local data, or workflow actions outside central security review. When those endpoints lack strong authorization logic, they become shadow interfaces with inconsistent access enforcement. The risk is not MCP itself. The risk is that every new connection can multiply the number of object paths an agent can reach without corresponding governance.

Practical implication: inventory every MCP-connected service and subject each one to the same authorization review as production APIs.

Why excessive agency turns valid API traffic into abuse

Excessive agency means an AI system can take too many actions with too much scope once it is already authenticated. That matters because the dangerous pattern is not broken login, but legitimate access applied at the wrong scale. An autonomous agent can iterate through object identifiers, call the same endpoint repeatedly, and exfiltrate data or trigger transactions while every request appears individually valid. This is why behavioral baselining becomes necessary: the control problem is no longer only who can call the API, but what sequence of object access is normal for that actor.

Practical implication: baseline agent behaviour and alert on abnormal object fan-out, repetitive lookups, and unexpected workflow breadth.

Threat narrative

Attacker objective: The attacker wants to use legitimate agent access to access or export data at scale without triggering conventional API controls.

1. Entry occurs when an attacker compromises or abuses an AI agent or another authenticated machine identity that can reach backend APIs and MCP-connected tools.
2. Escalation happens when that identity uses valid access to enumerate object identifiers, repeat calls at machine speed, or exploit weak object-level checks to expand reach across records and systems.
3. Impact follows when the agent, acting through apparently legitimate API traffic, exfiltrates data or performs unauthorized actions across a large object set.

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

BOLA has become the most important authorization problem in agentic AI because it scales abuse through legitimate access. The article's central point is not that AI agents create a new vulnerability class, but that they industrialise an old one. When one authenticated system can traverse thousands of objects across multiple APIs, the control failure is no longer accidental overreach on one record. Practitioners should treat object-level authorization as the primary governance boundary for agentic runtime behaviour.

Shadow MCP connections create a governance gap that traditional API security was never built to close. Model Context Protocol servers extend agent reach into data and tools, but they also bypass the normal discipline of central review when teams spin them up quickly. That means the enterprise can accumulate hidden object paths even when the main API estate looks controlled. The practitioner conclusion is that visibility and authorization scope must be tied together, not managed as separate problems.

Excessive agency is the named concept security teams should use when discussing this risk. It describes the condition where an authenticated agent can execute too many object requests with too little contextual restriction. That is more precise than saying the agent is simply autonomous, because the failure is about runtime scope, not just decision-making. The governance implication is clear: object fan-out, not login success, becomes the signal of danger.

Human-era access models assume a caller's intent can be inferred from a small number of bounded requests. That assumption fails when the caller is an agent that can chain actions, repeat queries, and expand scope without a human approval gate between each step. The implication is that identity governance must move from static entitlement thinking to runtime object control across APIs, MCP servers, and delegated workflow paths.

The API is now the control plane for agentic identity. In this model, the strength of IAM is measured by whether the backend can evaluate object rights in real time, not by whether the front door authenticated correctly. That means teams should stop treating agent identity as adjacent to API security and start treating API authorization as the operational expression of agent governance.

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 report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• For a broader threat model, see OWASP Agentic AI Top 10 for the control patterns that fail when agents misuse tools and object access.

What this signals

Excessive agency is becoming the practical warning signal for agentic environments: when one identity can fan out across too many objects, the issue is no longer authentication but runtime scope. With 80% of organisations already reporting agent behaviour beyond intended scope, governance teams should expect more pressure to prove object-level controls before production rollout.

Agentic AI programmes should now be reviewed as API governance programmes with identity implications, not as isolated AI projects. The next maturity step is to connect API inventory, behavioural monitoring, and entitlement review so that security teams can see when a trusted agent starts behaving like a bulk data path.

Teams aligning to OWASP guidance should map agent-facing workflows against OWASP Agentic AI Top 10 and cross-check runtime controls with the NIST AI Risk Management Framework. That combination helps separate acceptable tool use from object-level abuse.

For practitioners

• Inventory agent-facing APIs and MCP servers Build a live register of every API and MCP-connected data source that agents can reach, including shadow endpoints created outside central review. Prioritise systems that can touch regulated data or high-volume record sets.
• Enforce object-level authorization tests Validate that each endpoint checks object ownership or scope, not just session validity. Test for ID enumeration, repeated object traversal, and cross-record access that a single authenticated agent could execute at machine speed.
• Baseline agent behaviour for abnormal fan-out Set behavioural thresholds for object breadth, request repetition, and workflow chaining. Alert when an agent accesses objects it has not touched before, or when one session spreads across far more records than normal.
• Tie governance to API lifecycle reviews Require security review for every new agent workflow, MCP server, and delegated API path before production use. Reassess authorisation whenever an agent gets access to new object types or new backend systems.

Key takeaways

• Autonomous AI agents expose a BOLA problem that is fundamentally about object-level authorization, not login failure.
• Machine-speed request patterns can turn one weak API check into broad data exposure across many systems.
• Security teams should govern agent identity through API inventory, object-level controls, and behavioural monitoring together.

Key terms

• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
• Agentic AI Action Layer: The API and protocol layer through which an AI agent performs real work, such as reading records, updating systems, or triggering transactions. It is where identity, authorization, and workflow execution meet, so security failures here become operational failures rather than model issues.
• Excessive agency: A condition where an AI system is given more operational authority than its task requires. The risk is not just poor output. It is that mistakes, manipulation, or compromise can produce destructive actions at machine speed across the systems the agent can reach.

What's in the full article

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

• Concrete examples of how BOLA appears in agent-facing APIs and MCP-connected workflows.
• The article's description of the 1-to-many risk pattern across object requests and backend systems.
• The operational framing Salt uses for continuous API inventory and runtime governance.
• The full explanation of how intent analysis is positioned against abnormal agent behaviour.

👉 Salt's full post covers the API action layer, shadow MCP exposure, and the object-level controls behind agentic governance.

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.