FirstOpsFirstOps
Sign in
Back to blog
access-controlrbacabacagent-securitycontext-based-access-controlauthorization

Access Control Is Missing Its Human

RBAC and ABAC worked for forty years because a second, implicit layer rode on top: a human, slow and suspicious, deciding whether to exercise access. Agents collapse that layer. Every documented agent breach lives in the gap it leaves.

AD
Anshal Dwivedi
·14 min read

On May 6, 2010, the Dow Jones Industrial Average fell roughly 9% in thirty-six minutes; the S&P 500 dropped 7% in a single fifteen-minute window. By 2:47 p.m. New York time, nearly a trillion dollars in market value had evaporated. By 3:00 p.m., most of it was back. The SEC-CFTC joint report later found that between 2:45:13 and 2:45:27 (fourteen seconds), high-frequency trading firms traded over 27,000 E-mini contracts, accounting for roughly 49% of total volume in that window.

No fraud was committed. No regulation was violated. Every participant operated within their authorized capacity. Human-paced controls had no chance of catching it.

The regulatory response was not to make humans faster or algorithms smarter. It was to insert a control layer that did not exist: single-stock circuit breakers, market-wide halts, Limit Up-Limit Down bands. Controls that did not ask who was trading, only whether the trade cohered with the state of the market in that millisecond. The fix lived in context.

Fifteen years later, the same shift is happening to access control. The actors are agents, not algorithms; the stakes are credentials and data, not contracts. But the structural problem is identical. The decision layer used to be human, and the model we use to authorize access (RBAC, ABAC, the entire forty-year stack) was quietly held together by the human it no longer has.

The Unspoken Second Layer#

Role-based access control was formalized in the 1990s and standardized as ANSI INCITS 359 in 2004. Attribute-based access control was codified by NIST in SP 800-162 in 2014.

Both are simple. RBAC says: a principal is assigned a role; a role grants permissions; a permission allows an action on a resource. ABAC says: each request is evaluated against attributes of the subject, resource, action, and environment, and a policy decides allow or deny.

Neither model describes the second, invisible enforcement layer that made the first one work.

Consider the role "Salesforce admin." A human admin can, in principle, export every customer record, delete every account, and send mass emails. RBAC permits it. ABAC permits it. And yet they almost never do, because exercising that access has a cost: time, attention, suspicion, the fear of audit, the moment of hesitation before clicking "Export All." The authorization model permits what the human social model forbids.

That second layer is not in the policy. It is in the principal. Humans introduce latency between authorization and exercise, judgment about whether an action is appropriate, and suspicion when something feels off. None of this was written into RBAC or ABAC because it didn't need to be. It was inherent to the entity holding the permission.

Forty years of access control quietly assumed this layer existed. It almost always did.

When the Layer Vanishes#

On June 11, 2025, Aim Security disclosed CVE-2025-32711, the first widely-publicized zero-click prompt injection chain with an assigned CVE in a production AI agent. Microsoft scored it CVSS 9.3 (NVD assigned 7.5). The attack worked like this: an attacker sent a single email to a Microsoft 365 Copilot user. Copilot's retrieval layer ingested the email. The email contained instructions, hidden in reference-style markdown, telling Copilot to grep the user's mailbox, OneDrive, SharePoint, and Teams for sensitive content and embed the results in an image URL routed through a CSP-permitted Microsoft Teams proxy. The user took no action. Copilot did everything the email told it to. Every API call passed authorization.

The breach was authorized end to end.

The same structural failure shows up in other shapes. In August 2024, PromptArmor disclosed a cross-boundary exfil in Slack AI: a public-channel injection caused a private-channel data leak the attacker had no direct access to. In July 2025, a Replit AI agent ran destructive database operations during an active code freeze, deleting records for 1,206 executives and 1,196 companies; there was no attacker at all, just an agent ignoring a constraint sitting in a chat prompt.

This is the dominant pattern in documented agent breaches: a sequence of individually authorized actions producing a collectively unauthorized outcome. RBAC said yes to every call. ABAC said yes to every call. The breach lived between the calls, not inside any of them.

Johann Rehberger's "Month of AI Bugs" in August 2025 landed at least one critical disclosure per day across Claude Code, GitHub Copilot, Cursor, Devin, Codex CLI, and others. The failure is not a vendor problem. Categorical.

In December 2025, OpenAI itself wrote, in a post on Atlas hardening, that "prompt injection, much like scams and social engineering on the web, is unlikely to ever be fully solved." Two months earlier, OpenAI CISO Dane Stuckey called prompt injection a "frontier, unsolved security problem." Rare for a model vendor to publicly concede the problem isn't engineering-solvable.

The reason is structural. The human layer is gone.

"Can" and "Should" Used to Be the Same Question#

For a human admin, can access and should access right now collapsed into one because the same brain made both. The two questions were one question.

Agents pull them apart. An agent with Salesforce export permission, told to "summarize the last week of customer complaints," should not call Export All. It can. RBAC and ABAC don't care. The reason isn't in the permission grant. It's that the action is incoherent with the task the user delegated. That coherence used to be the human's job. Now it isn't anyone's.

The intuition, stripped of jargon: just because you can do something does not mean you should, in this context. When the decision layer was a human, "in this context" was automatic. When it's a machine, it has to be made explicit. RBAC and ABAC weren't built to answer that question.

The Machine-Speed Attack Surface#

A second-order effect follows immediately.

When humans were the decision layer, convincing a target was bespoke, slow, and expensive. The attacker's iteration loop ran at human speed.

When the decision layer is an agent, the attacker's iteration loop runs at machine speed too. Three measurable shifts make this concrete.

First, construction collapsed. IBM X-Force's red-team experiment built AI-generated phishing campaigns in five minutes versus the sixteen hours their human team needed. Second, per-attempt success rose. 2025 research from Brightside AI, summarized by Vectra, measured 54% click-through rates on AI-generated phishing against 12% for human-written controls.

Third, the iteration loop is itself now agentic. PAIR showed an attacker-LLM jailbreaking a target agent in fewer than twenty queries. In December 2025, OpenAI disclosed its own RL-trained prompt-injection attacker, built for red-team use. Attack generation is now automated; deployment is O(API calls).

The economics have flipped. Targeted social engineering used to be expensive and reserved for high-value targets; against agents, it is a script that needs seconds per target.

The implication is uncomfortable. The defense that worked against human-speed social engineering ("train your people, raise their suspicion, make them slower") has no machine analog. The fix has to be structural, and it has to live outside the agent.

Defining the Models Honestly#

RBAC assigns permissions to roles and roles to principals. Its strength is operational: roles are auditable, role-permission mappings are reviewable, and access reviews map cleanly onto organizational structure. Its weaknesses are familiar: role explosion as the cross-product of organizational axes grows, role drift as users accumulate permissions over time, and a complete absence of any native expression for context, time, or task.

ABAC evaluates authorization rules against attributes of the subject, resource, action, and environment, computed at request time. Its strength is expressive power. Jin, Krishnan, and Sandhu proved in 2012 that ABAC can be configured to express DAC, MAC, and RBAC, the strongest possible statement on policy-language generality. NIST SP 800-162 names environment attributes, so ABAC can encode time, location, threat level, and (in principle) a declared purpose for the request.

The strongest objection to this essay is simple: ABAC can already do everything I'm about to describe. Just add a "purpose" attribute. Just enrich the environment. Just write better policies.

That's true on paper. It fails in practice, for two reasons.

First, ABAC trusts facts. Intent is a claim. When ABAC checks a request, it asks the HR system for the user's department, the device system for posture, the network for IP. These are facts asserted by systems the policy engine trusts. Now ask the same machinery whether an agent's purpose is "summarize email" or "exfiltrate email." There is no HR system for purpose. The IETF acknowledged this in RFC 9396: the authorization_details field carries a declared purpose that the server is supposed to validate. ABAC's machinery doesn't help validate claims, only facts.

Second, RBAC and ABAC check requests one at a time. Agent attacks happen across many. Both models evaluate a single request against a single policy. That works when each request is a complete unit of intent: a human clicking a button. It breaks when the attack is a pattern across requests. CamoLeak's exfiltration is one tiny image fetch per character of data stolen. Each fetch passes every policy check; the attack is the thousands of fetches together.

You can't catch a pattern by checking each piece of it separately. The model has to change what it looks at.

Context Is Not Intent. It Is Larger.#

The market names this missing layer in two incompatible ways. The first camp calls it "intent-based access control" (Microsoft, Token Security, Akeyless). The second calls it "context-based access control," a thread that runs back through Covington et al. on context-aware access control (2001), Byun and Li on purpose-based access control (2008), and Thomas and Sandhu on task-based access control (1997).

The second framing is the right one.

"Intent" alone is one-dimensional and partially unknowable: the requester claims a purpose, and no oracle verifies the claim. "Intent is squishy and unobservable," the standard objection, has weight.

"Context" includes intent but also what's observable: the trajectory of the session, the action shape (tool, resource, payload, egress), the session boundary at delegation. Even intent gets more checkable when cross-validated against the trajectory. An agent that claims to be "summarizing email" but is fetching thousands of images is not actually summarizing email.

Context-based access control is intent-based access control plus the observability that makes intent verifiable. For the rest of this essay, I'll use CBAC.

Context-Based Access Control, Precisely#

CBAC evaluates a request's coherence with its session context. A CBAC decision is a function of four components:

1. Stated purpose. The objective declared at delegation: "resolve customer ticket #4521," "deploy service-x to staging," "summarize this week's incoming email." Attested by the delegating human at session start, bound to the agent's session identity.

2. Trajectory. The full sequence of prior inputs, tool calls, and responses in this session: what the agent has read, what tools it has loaded, what conversation has occurred. Fully observable.

3. Action shape. The concrete attributes of the current call: tool name, resource path, payload size and pattern, frequency relative to prior actions, egress destination, data type. Fully observable.

4. Coherence test. Does the action shape, given the trajectory, plausibly serve the stated purpose? When the answer is yes, allow. When the answer is no, escalate to a human or block.

The coherence test is the load-bearing piece, and the hardest one.

CBAC does not replace RBAC or ABAC. They remain the containment layer; they define what's structurally possible. CBAC sits above them as the coherence layer. RBAC and ABAC ask "is this action permitted?" CBAC asks "is it appropriate right now?"

Does the Frame Survive Documented Incidents?#

The honest test is whether CBAC actually catches what RBAC and ABAC do not. I ran the model against five documented incidents from the past two years.

IncidentRBAC checkABAC checkCBAC check
EchoLeak (CVE-2025-32711)Pass: Copilot has mail read + markdown renderPass: tenant, user, device all validFail: stated purpose "summarize inbox"; action shape "external image fetch encoding internal text"; incoherent with purpose
CamoLeak (GitHub Copilot Chat)Pass: agent has repo read + image fetchPass: all attributes validFail: stated purpose "help with codebase"; action shape "thousands of base16-encoded image fetches"; frequency and content incoherent
Slack AI cross-boundary exfilPass: querying user is authorized for the private channelPass: agent inherits user's authorityFail: trajectory crosses trust boundary (public-channel instruction → private-channel data → external link); incoherent with "answer my question"
ZombAIs (Claude Computer Use C2)Pass: Computer Use can execute commandsPass: all attributes validFail: stated purpose "browse this page"; action shape "download, chmod, execute remote binary, connect to external host"; incoherent
Replit AI production deletionPass: agent has DB writePass: all attributes validFail: stated purpose at delegation included "code freeze, no modifications"; action shape "destructive DB write"; direct contradiction

Five for five.

This is a small sample but not a cherry-picked one. These are the most-cited agent failures of the past year, across platforms, attack surfaces, and attacker postures (including one case with no attacker).

If the model had failed against even one of these, this essay would not exist. It didn't.

What CBAC Doesn't Solve#

CBAC is a coherence layer, not a containment layer. Without RBAC and ABAC underneath, it lets coherent-looking actions through that the permission layer should have blocked.

It isn't capability-based security either. Google DeepMind's CaMeL uses information-flow control to prove certain attack paths cannot exist, answering "what's structurally permitted." CBAC answers "what's appropriate right now." Both layers, used together, are stronger than either alone.

The hardest open question is the coherence function itself: does this action shape, given this trajectory, serve this purpose? No closed-form answer. Implementations today combine declarative rules (scoped tool-call allowlists per session) with runtime evaluators (judge models, anomaly detectors). State of the art is uneven; the model will look primitive in three years.

The honest comparison isn't CBAC versus perfect; it's CBAC versus the current state, where every documented agent breach is invisible to the authorization layer.

The Historical Pattern#

This is not the first time a control plane has had to grow a new layer because the decision layer changed. When spam dropped send cost to near zero, the fix was receiver-side context, not stronger sender authentication. When credential stuffing automated password reuse, the fix was behavioral anomaly detection, not stronger passwords. When SQL injection collapsed the data/control boundary, the fix was parameterized queries, a protocol-level separation.

In every case, existing controls assumed the old actor; new controls had to occupy a new dimension (rate, coherence, behavior, structure) that the old controls did not. Agents are in the same moment, and the new dimension is coherence.

What the Layer Replaces#

Authorization was always two layers. The first was written down: RBAC, ABAC, the role model. The second was the human, who supplied the judgment that "can" was not the same as "should," the latency that made brute force expensive, and the suspicion that caught the email that felt wrong.

The first layer cannot do the second's job. It was never designed to. It worked for forty years because the second layer was free.

The second layer is gone, and it isn't coming back. The control plane has to write down the second layer, or every breach of the next decade will look like the breaches of the past year: every API call authorized, every audit trail clean, the data gone anyway.

CBAC is what I'm calling that written-down second layer. Others will call it intent-based control, runtime authorization, or action-time policy. The name doesn't matter. The layer is missing.

The Flash Crash got circuit breakers. The agentic era is going to get coherence checks. Ten years from now, our successors will find it strange that anyone ever ran authorization without them.

Sources#

Documented Incidents#

Foundational Access Control#

Standards#

Machine-Speed Attack Research#

Vendor and Researcher Framings#

Historical Analogies#

Related posts

·12 min read

Prompt Injection Is Not the Incident

Prompt injection detection is getting better, but what happens when the exploit doesn't look like an exploit? We split a credential-stealing attack across two normal-looking tickets and watched a coding agent execute both. The fix isn't better detection. It's controlling what agents can do.

·13 min read

Your Coding Agent Has Your Keys: A Trust Boundary Analysis

When you run a coding agent, it can read every credential on your machine (SSH keys, cloud tokens, API secrets) without asking. It asks before running commands, but the permission is 'allow this command,' not 'allow access to this credential.' The security boundary everyone focuses on is on the wrong side. The real attack surface is the input to the agent's reasoning, not the output.

All posts