API authorization is the #1 risk of the agentic era

Every few months a new report restates the same uncomfortable fact in a new way. APIs are where the software is, so APIs are where the attacks are. Salt Security's telemetry puts the average organization at 258 API attacks per day, up from 121 a year earlier. Akamai finds that 84% of security professionals dealt with an API security incident. Analysts size the API security market near $1.2 billion in 2026 and growing around 28% a year, which is what a market looks like when the problem is outrunning the tooling.

What almost none of these numbers change is the shape of the problem. Strip away the noise and the same root cause sits under most serious API breaches: a missing authorization check. Someone asked for an object that was not theirs, or called a function above their role, and the server handed it over. The agentic era did not create this problem. It is about to multiply it.

The root cause was never injection. It is authorization.

If you learned application security on web apps, your instincts point at injection: SQL, command, cross-site scripting. Those still matter. But on APIs they are not what breaks. The flaw that breaks APIs is authorization, and it comes in two shapes.

BOLA, broken object level authorization, is a failure to check that the user asking for an object owns that specific object. An API exposes data by identifier, /orders/124, /patients/89, /documents/abc, and the endpoint authenticates you but never confirms the record is yours. Change the number, and you walk the table. If you know it as IDOR, it is the same bug; OWASP renamed it BOLA for APIs. BFLA, broken function level authorization, is a failure to check that you are allowed to perform an action at all: a standard user calls an admin-only route with an ordinary token, and the server executes it because it only checked that you were logged in, not which role you hold.

These are not edge cases. BOLA has topped the OWASP API Security Top 10 in both the 2019 and 2023 editions, BFLA sits at number five, and industry analysis attributes on the order of 40% of API attacks to BOLA alone. The pattern is remarkably consistent across sectors. In 2025 a vulnerability chain in ZITADEL's admin API (CVE-2025-27507) let low-privilege users reach sensitive configuration through insufficient authorization checks; the Spoutible breach exposed users' data because object-level checks were missing. A joint advisory from CISA, the NSA, and Australia's ACSC named IDOR/BOLA as a class organizations must address. From automotive to fintech to healthcare SaaS, the same missing check keeps opening the same door.

There is a reason this specific flaw is so durable: it is not a bug in a library you can patch. It is a decision the application failed to make, on every object, on every request. Which is exactly why it resists the tools built to find library bugs.

The agentic era pours gasoline on it

Here is what is new, and why 2026 is the inflection point rather than just another year of BOLA. Until recently, the callers of your API were browsers and mobile apps driven by humans, plus a handful of server integrations you set up deliberately. That is changing fast. Two-thirds of organizations report their API count grew by more than 50% in the past year, and a large share of that growth is non-human: AI agents, copilots, and autonomous workflows that call APIs on a person's behalf.

An agent is not a feature. It is an identity with credentials and real permissions, acting without a human watching each step. And the plumbing connecting agents to your systems was not built with authorization in mind.

MCP authenticates. It does not authorize.

The Model Context Protocol, introduced by Anthropic in late 2024 and broadly adopted by 2026, is how agents call tools and reach data. It was designed for capability, not control: as security researchers and the NSA's 2026 guidance on MCP both note, the protocol shipped without a real access-control model, no standard way to express who may do what, under which conditions. OAuth 2.1 handles authentication, proving an agent is who it claims to be, but it does not answer the harder questions: who authorized this agent, and what is it allowed to do on behalf of which human? An agent that holds a valid token looks, to your API, exactly like a legitimate user. If your API decides access by "is this token valid" rather than "should this identity reach this object," an agent inherits every BOLA and BFLA gap you already had, at machine speed.

You cannot see what you cannot test

The visibility gap makes it worse. Salt Security's 1H 2026 research found that nearly half of organizations, 48.9%, are effectively blind to non-human traffic, unable to monitor what their own agents are doing, and that 92% lack the security maturity the agentic environment demands. IBM's 2026 Cost of a Data Breach report closes the loop on cost: the average breach reached $4.99 million, AI-enabled breaches ran about $6 million, and among organizations that suffered an AI-related breach, 92% lacked proper AI access controls. Access controls. The same gap, priced.

The failure mode writes itself. A prompt injection or a compromised agent does not need a novel exploit. It needs an over-permissioned identity and an API that never checks object ownership. Then the agent, doing what it was told, reads records that were never yours, across tenants, at the speed of a loop.

Why almost nothing actually tests authorization

If authorization is the number-one risk, you would expect it to be the most-tested thing in your pipeline. It is close to the least. To understand why, look at what each category of tool is actually built to do.

A scanner or DAST tool fires payloads at inputs and matches responses against signatures. That model is blind to authorization for one structural reason: authorization is relative. There is nothing wrong with the response to GET /orders/124 in isolation; it is a valid 200 with a valid order. Whether it is a vulnerability depends entirely on who asked. A scanner sees one request, one response, one identity, and cannot express the only question that matters: should this caller reach this object? A WAF has the same blind spot from the other direction, inspecting one session at a time with no model of what a different session should be allowed to see.

The surprise is that the autonomous pentesting wave does not close the gap either. The leading platforms, NodeZero, Pentera, RidgeBot, are excellent at what they were built for: internal network validation, Active Directory, credential reuse, lateral movement. That is infrastructure. It is not the business-logic authorization layer of your API, where BOLA and BFLA live, one object and one role at a time. Crowdsourced PTaaS brings human judgment, but on a time-boxed, sampled engagement that rarely walks every object on every endpoint across every role pairing. The category consensus that settled in 2026 is honest about the split: autonomous systems own breadth and continuous coverage; humans own judgment and sign-off. Neither half, on its own, systematically tests API authorization.

This is not a knock on any one tool. It is a category gap. The most common way into your data is the least covered surface in your program, and the agentic era is widening it faster than the coverage is catching up.

What testing authorization actually requires

The method is conceptually simple and mechanically brutal, which is why it gets skipped. You cannot test authorization with one identity, because authorization is defined by the relationship between identities. So you start with several: at minimum two peer accounts (to catch BOLA between equals) and a low-privilege and high-privilege pair (to catch BFLA between levels). In the agentic era you add the identities that now matter, an agent or service token, and treat it as a first-class caller, not an afterthought.

Then, for every operation the API exposes:

• Cross-account (BOLA): take every request that references an object, in the path, a query parameter, or the body, and replay it with another identity's session, substituting object and tenant identifiers. If identity B receives identity A's object, that is a confirmed BOLA.
• Cross-privilege (BFLA): take every privileged function and call it with a low-privilege token, including HTTP method swaps and routes the UI never renders. If the action executes, that is a confirmed BFLA.

Done honestly, that is dozens or hundreds of operations, times multiple parameters, times several identity pairings. By hand it is enormous and repetitive, so in practice it gets sampled, and sampling is how the one endpoint that leaks slips through. This is the exact shape an agentic API penetration test is built for. You hand it your OpenAPI spec and one token per identity, human and agent; it enumerates every operation and replays one identity's requests as another across the whole surface. Because it is an agentic pentester that reasons about roles rather than a scanner matching signatures, it does not stop at "this looks off." It confirms the cross-account access happened and returns the exact request and response that prove it, rated with a CVSS v3.1 vector.

We keep returning to authorization because we keep finding it. When we analyzed a smart-lock platform under its responsible-disclosure program, using our own account on our own property, the resident app showed us the two access codes we managed. The API behind it, asked about our own property, returned the property's entire code table, including the master PIN the app never shows a resident. Authentication was solid; every request carried a valid token. The failure was authorization: the server never asked whether this resident should see those codes. It is now public as CISA advisory ICSA-26-237-01 / CVE-2026-75960. One valid login, every door in the building. That is what an authorization gap looks like when you actually test for it.

What to do now

• Inventory your identities, including the non-human ones. Agents, service accounts, and copilots are callers with permissions. If you cannot list them, you cannot reason about what they may reach.
• Separate agent tokens from human tokens so a policy engine can apply different scope, rate limits, and audit to non-human traffic. You cannot govern what you cannot distinguish.
• Make authorization a test, not an assumption. For every object-scoped and privileged endpoint, verify ownership and role server-side, and prove it by replaying one identity as another.
• Test continuously, not annually. Your API surface changes on every deploy, and so do its authorization boundaries. A once-a-year snapshot cannot keep up with a surface that grows 50% in a year.

The agentic era is a genuine step change in what calls your API and how fast. It does not, however, change the flaw that will actually breach you. That flaw is the same one that has topped the list since 2019, and the same one your tooling was never built to see. The organizations that come through this well will be the ones that stopped treating authorization as an assumption and started treating it as something you prove, on every operation, for every identity, human and machine alike.

References

• OWASP API Security Top 10: API1:2023 Broken Object Level Authorization
• Salt Security: State of AI and API Security, 1H 2026 (Navigating the Agentic Era)
• IBM: 2026 Cost of a Data Breach Report
• NSA: Model Context Protocol (MCP) Security Design Considerations
• CISA advisory ICSA-26-237-01 / CVE-2026-75960
• CWE-639: Authorization Bypass Through User-Controlled Key