The identity half of agent security has gotten crowded, and that is good news. An agent can now prove it is a known workload with SPIFFE, prove a human authorized its action with x401, and prove it is a legitimate bot with web-bot-auth. Each answers a version of who is this?

None of them answers the question that actually decides whether an agent should be allowed to do the thing it is about to do: **may this agent, acting for this user, take this action on this resource, right now?** That is authorization, it is a different problem than authentication, and it is the half most agent systems quietly under-build.

The broad-credential trap#

Here is how the gap opens in practice, and it is almost always the same way. You are wiring an agent to a tool — the CRM, the ticketing system, the internal search index. The fast path is to mint one service credential that can read the whole thing and hand it to the agent. It works in the demo. It ships.

What you have actually built is a confused deputy with a big credential. The agent now acts with the union of everything that token can touch, and the model deciding how to use it is steerable by whatever text lands in its context — a poisoned document, a malicious tool description, a user who shouldn't have reach they don't have. The agent didn't need to be hacked; it just needed to be convinced, and the blast radius is the size of the credential you gave it. Broad, static grants are the root cause behind a striking share of this year's agent incidents, and they are almost always chosen for convenience, not necessity.

The credential the agent should carry is not "what the agent can do" — it's the intersection of what the agent can do and what the current user can do.

That intersection is the whole discipline. An agent summarizing a customer's tickets should see the tickets that customer's requester could see — not every ticket the agent's service account can reach. And the check has to happen per action, at the tool call — not once, coarsely, when the session opens. Anything filtered after the model already has the data is theater; by then the bytes are in the context window.

Two engines, one shape#

You do not need to invent this. The access-control field has spent a decade building exactly these decision engines, and in 2026 they are being pointed at agents directly. They come in two families.

Relationship-based access control (ReBAC) is the Google Zanzibar lineage — now shipping as OpenFGA, SpiceDB, and Permify. It stores a graph of relationship tuples (user:ana is viewer of doc:42) and answers authorization as a reachability query: is there a permission path from this principal to this object? This is the natural fit for agents that roam over many related objects — the defining shape of retrieval-augmented generation. When an agent searches a corpus, ReBAC lets you ask the store to return only the objects this principal can reach, so the retrieval step is authorization-aware by construction. OpenFGA now documents modeling agents as first-class principals in the same graph as users, which is precisely what lets you express the intersection cleanly.

Policy-as-rules — OPA/Rego and AWS Cedar — evaluates conditions over attributes and context: time of day, dollar amount, environment, request shape. This is the fit when the decision is less "who is related to what" and more "under what circumstances." As Oso lays out in its comparison of the approaches, the two are not rivals so much as answers to different questions, and mature systems routinely run both — ReBAC for the relationship checks, a policy engine for the contextual guardrails.

The move that matters#

The reframing is architectural, not a product you buy. Recent work on runtime governance of production agents treats authorization as its own plane in the stack — a place decisions are made, continuously, as the agent acts — rather than a login-time formality. Concretely, that means three things: model the agent as a first-class principal in your authorization system, not a role bolted onto a service account; move every consequential check to the tool boundary, so the decision is made where the action happens; and scope each check to the intersection of the agent's grant and the acting user's grant.

Do that, and prompt injection stops being catastrophic. A compromised or misled agent can still try anything — but it can only do what the current principal was already allowed to do, one authorized call at a time. Authentication tells your system a real agent is knocking, backed by a real human. Fine-grained authorization is what makes that fact safe to act on.