BOLA exposes why the legitimate request is no longer trustworthy

At a glance

What this is: This is an analysis of BOLA and the collapse of perimeter-based API security, showing how legitimate-looking requests can still drive large-scale data exposure.

Why it matters: It matters because IAM, PAM, and NHI teams increasingly have to govern object-level access decisions across APIs, microservices, and AI-driven request chains, not just authenticate the caller.

By the numbers:

• Broken Object Level Authorization remains ranked as the #1 risk in the OWASP API Security Top 10.

👉 Read Upstream Security's analysis of BOLA and the legitimate request problem

Context

BOLA is an object-level access control failure, not a classic injection problem. The caller is authenticated, the request is syntactically valid, and the endpoint often looks normal, but the application fails to verify whether that caller is allowed to touch the specific object being requested.

For identity practitioners, the issue sits at the intersection of API authorisation, workload identity, and runtime governance. As machine-to-machine integrations and AI agents drive more API activity, perimeter checks that focus on payload shape or source reputation miss the real control point, which is whether the object request is authorised in context.

Key questions

Q: How should security teams prevent BOLA in modern API environments?

A: Security teams should enforce object-level authorisation inside the application, not at the edge. Every request must be checked against the authenticated subject, the target object, and the transaction context. That approach is essential when valid tokens, clean syntax, and normal endpoints can still be abused to enumerate records or expose data.

Q: Why do valid API requests still create breach risk?

A: Valid API requests still create breach risk because authentication proves the caller is known, not that the caller is entitled to the specific object. If the application accepts an identifier or booking code as proof of access, attackers can modify that value and harvest data without tripping traditional perimeter controls.

Q: What do security teams get wrong about API perimeter controls?

A: They assume syntax inspection and request reputation are enough. In BOLA, the payload can be clean, the endpoint can be correct, and the token can be valid while the access decision is still wrong. The real control gap is the missing relationship check between identity and object.

Q: Who is accountable when policy-based access controls fail?

A: Accountability sits with the identity, security, and business owners who define policy, approve exceptions, and accept residual risk. If access decisions are not tied to clear ownership and evidence, failures become hard to explain during audit, incident response, or regulatory review. Governance only works when someone owns the policy outcome.

Technical breakdown

Why stateless API controls miss BOLA

Stateless tools inspect each request as if it were independent. That works for obvious payload abuse, but it fails when the attack uses a valid endpoint, a valid token, and a normal-looking object identifier. BOLA succeeds because the security stack sees syntax, while the application decision depends on context: who the caller is, which object is being requested, and whether that specific relationship is permitted. Without stateful correlation across requests and objects, the system cannot distinguish normal navigation from systematic enumeration.

Practical implication: teams need object-aware authorisation checks that sit inside the application decision path, not just inline traffic inspection.

How business logic becomes the real attack surface

Modern APIs often encode business meaning in identifiers, booking codes, account numbers, or session references. When those values are treated as proof of entitlement, the application turns business context into an access control weakness. The article’s airline example shows the danger clearly: a reservation code functioned as the access gate, and the payload exposed far more data than the user needed. That is not a network perimeter problem. It is a failure to bind the request to the authenticated subject and the expected business transaction.

Practical implication: map every sensitive API to the business object it protects and require explicit subject-to-object validation for each path.

Why AI agents and MCP servers widen the blast radius

When APIs are chained by autonomous agents or MCP-driven workflows, one weak object-level control can be exercised at machine speed across many endpoints. The risk is no longer a single bad request. It becomes high-velocity enumeration, cross-object scraping, and automated abuse that looks legitimate at the packet level. That changes the governance problem for NHI and agentic AI programmes. The identity subject may be a workload, token, or agent, but the exploitable condition is still the same: permission to ask is being mistaken for permission to access.

Practical implication: extend authorisation telemetry and anomaly detection to service identities, agent workflows, and object access patterns, not just human sessions.

Threat narrative

Attacker objective: The attacker aims to harvest sensitive records by abusing object-level access decisions that trust valid requests too much.

1. Entry occurs through a valid API endpoint and authentication token, which allows the attacker to appear legitimate to inline security controls.
2. Escalation happens when the attacker changes object identifiers or enumerates reservation codes, turning a single authorised-style request into broad unauthorised access.
3. Impact follows when the application returns overly rich records, enabling large-scale exposure of passenger PII, itinerary data, and government identifiers.

Breaches seen in the wild

• Microsoft SAS Key Breach — Overly permissive Azure SAS token exposes 38TB of Microsoft internal data including secrets and credentials.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

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 is an object-authorisation failure, not a perimeter failure. The article is right to frame the problem as legitimate traffic that breaks business context. Traditional controls can verify syntax, source, and token validity while still missing the one decision that matters: whether the caller may access that specific object. Practitioners should treat BOLA as evidence that access control has moved inside the application decision path, where network controls cannot see it.

Dynamic perimeter language becomes misleading once machine identities start driving API behaviour. AI agents, service accounts, and backend integrations do not attack by malformed input alone. They can generate high-volume, perfectly formatted requests that exploit object relationships at runtime. That makes object-level authorisation a core NHI governance issue as well as an API security issue. Teams should stop treating API authorisation as a front-door problem and start governing the identities that can traverse the data model.

Blind trust in valid reservation codes is the same failure mode as blind trust in standing machine access. The airline example shows a business token being mistaken for proof of entitlement. That assumption was designed for a world where object references were not sufficient on their own. It fails when access can be enumerated, replayed, or automated at scale. The implication is that entitlement models must be bound to context, not just to a reusable identifier.

Runtime context is now the decisive control plane for API abuse detection. The article’s strongest point is that packet inspection alone cannot distinguish normal use from systematic harvesting. That makes behavioural baselines, object-scoped telemetry, and historical access patterns more important than signature logic. For identity programmes, this is the point where API governance, NHI visibility, and runtime monitoring converge into the same control problem.

Named concept: legitimate request illusion. This is the condition where a request is fully authenticated and structurally correct but still unauthorised at the object layer. The illusion matters because it causes teams to trust the transport and ignore the entitlement relationship. The practitioner conclusion is clear: if the authorisation check happens too far from the object, the request will look legitimate right up to the moment it leaks data.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
• 48% of companies cannot track and audit the data their AI agents access, leaving them with a compliance and investigation blind spot, according to AI Agents: The New Attack Surface report.
• For the adjacent control problem, see OWASP Agentic AI Top 10 for runtime abuse patterns that extend beyond the API perimeter.

What this signals

Legitimate request illusion: organisations are now dealing with traffic that is authenticated, syntactically correct, and still abusive at the object layer. That shifts the governance burden from perimeter filtering to identity-to-object binding, especially where service accounts and AI agents can generate high-volume requests that look normal in isolation.

With 80% of organisations already reporting AI agents acting beyond intended scope, the broader lesson is that runtime context has become the control plane. Teams that still depend on request-level inspection will keep missing abuse that only appears when identity, object, and transaction history are analysed together.

For practitioners

• Bind object access to authenticated subject context Require the application to verify that the caller is entitled to the specific record, booking, or resource requested, rather than trusting an identifier alone. This is the control that stops object enumeration from becoming data exposure.
• Instrument object-level access telemetry Log which identity accessed which object, at what rate, and through which transaction path, then alert on cross-object scraping and high-velocity enumeration. Use those signals to separate normal workflows from abuse patterns.
• Test for BOLA with business-context abuse cases Add negative tests that swap object IDs, replay booking codes, and vary session context across endpoints so security reviews prove the authorisation decision, not just the endpoint format. Use the same tests for service accounts and agent-driven workflows.
• Constrain machine identities to object-scoped permissions Limit service accounts, backend integrations, and AI-driven workflows to the smallest object set they need, then review whether any reusable credential can pivot across unrelated records. Narrow scope reduces the blast radius when a request path is abused.

Key takeaways

• BOLA shows that authenticated traffic can still be unauthorised when the application fails to validate the object relationship.
• The scale of the problem is large enough that AI agents and machine identities can turn a single access-control flaw into automated data harvesting.
• The practical fix is object-scoped authorisation with runtime telemetry, not heavier dependence on network perimeter tooling.

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.
• Legitimate Request Illusion: The condition where a request appears fully valid to network or gateway controls, yet is still unauthorized at the business object layer. The illusion is dangerous because it shifts attention away from the identity-to-object relationship that actually governs access.
• Object-Scoped Authorisation: An access control model that binds permissions to specific records, resources, or business objects rather than to the endpoint alone. It requires the application to verify the subject, the object, and the transaction context before data is returned or modified.
• Runtime Behavioural Evidence: Observed security evidence collected while software is executing, such as process activity, network traffic, and file access. In agent governance, this evidence is more trustworthy than static inspection because it proves how a skill behaved under real permissions and real execution conditions.

What's in the full article

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

• Endpoint-by-endpoint breakdown of how the airline reservation flaw exposed data.
• Examples of why stateless WAF and gateway controls missed the abuse pattern.
• Discussion of runtime behavioural analysis for detecting object enumeration.
• The article's own framing of AI agents and MCP servers in the perimeter debate.

👉 Upstream Security's full article covers the airline reservation flaw, object enumeration, and runtime detection context.

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 building or maturing an identity security programme, it is worth exploring.