Who Authorized the Agent? Building an AI Trust Control Plane

Six open technologies, one provable answer to the question every security team is now asking.

Reference:https://www.linkedin.com/posts/lalisd_agentic-authnauthz-ugcPost-7463157709693997056--G-g/

The question nobody could answer

A year ago, “who is making this request?” was a solved problem. You had a human, a session, a token, and an audit log. The entity on the other end of the connection was a person at a keyboard, or at worst a service account running a boring, predictable workload.

That assumption is now dead.

The industry has been remarkably blunt about it. As one widely-shared analysis put it, the IAM industry spent decades building infrastructure to answer a simple question, is this human who they claim to be, and are they allowed to do this and AI agents break that assumption in ways the existing IAM stack was never designed to handle [1]. Agents authenticate to SaaS APIs, retrieve sensitive data, spawn sub-agents, and chain tool calls across systems, all at machine speed and with a degree of autonomy no service account ever had.

The numbers are the part that wakes up the CFO. The Cloud Security Alliance, summarizing the state of play at RSAC 2025, noted there are now roughly 45 non-human identities for every human identity, and that Gartner expects at least 15% of day-to-day work decisions to be made autonomously by agentic AI by 2028 [2]. In cloud-native environments the ratio is far worse: Entro Labs research put it at 144 to 1, up from 92 to 1 just half a year earlier [3]. The World Economic Forum found that 51% of organizations report no clear ownership of their AI identities at all [4].

And the agents are already misbehaving. A 2025 SailPoint survey found that 80% of organizations running AI agents had observed them taking unintended or unauthorized actions [5].

We need a trust control plane: a set of layers that, between them, can prove the answer to five questions for every single agent action, not reconstruct it from logs afterward, but prove it cryptographically at the moment of access. This post walks through the design, and more importantly the specific, documented industry problems that forced each decision.

Five questions, five technologies

The whole architecture collapses into one table. Each technology answers exactly one question, and none of them tries to do another’s job.

The discipline here matters. A recurring failure mode in agent security is identity conflation letting one credential answer two questions. The fix, as one 2026 engineering guide phrased it, is to strictly separate human authentication from delegated agent authorization. OIDC handles the human login session, and a separate authorization layer handles the tool calls, so a prompt-injected agent cannot reuse a human’s session to reach unrelated systems [6].

Let’s take the questions in order.

1. Who is the human? OIDC + PKCE

Alice logs in via OpenID Connect with PKCE. The ID token proves Alice is Alice. This is the boring, well-understood part, and it should stay boring. OIDC was designed for “a human clicks Allow and a single client gets a scoped token,” and for that purpose it is excellent [7].

The mistake teams make is stopping here treating the human’s login as if it authorizes everything the agent subsequently does. It does not. The login establishes identity, not intent. Which is the next question.

2. What did the human authorize? the signed mandate (JWS/JWT)

Once Alice is authenticated, she mints a mandate: a signed credential that says, in effect, “Alice delegates to agent X, scope [read:tools], budget $100." It's a JWS cryptographically signed, tamper-evident, and verifiable by anyone holding the issuer's public key.

This is where most of the industry’s pain is concentrated, because OAuth’s standard delegation model was never built for autonomous, multi-step actors. A widely-circulated preprint titled, with admirable directness, “OAuth Is Not Enough,” catalogued the gaps: coarse permission scopes, no dynamic policy enforcement, and insufficient support for multi-hop delegation [8]. Christian Posta a well-known voice on service-mesh and identity architecture framed the core insight that shaped our mandate design: token exchange must be understood as authority reduction, not amplification. Each hop should produce a token that is more constrained, narrower in scope, and bound to a specific actor [9].

A delegated mandate, done right, carries the full execution context as claims: the sub is the human (user:alice), the act is the agent (agent:X), the aud binds it to a specific resource server, and the scope grants a specific permission (read:tools, never a blanket grant) [6]. That tuple is the contract. Everything downstream must honor it and is forbidden from exceeding it.

3. Who is the agent? SPIFFE / SPIRE

Here is the question OAuth quietly assumes away: what is the agent’s own identity, independent of the human and independent of any secret it happens to be holding?

If the answer is “an API key in an environment variable,” you have already lost. That key can be copied, logged, leaked, and replayed, and the credential population is exploding precisely because every agent and microservice mints its own. GitGuardian’s 2026 secrets report found tens of millions of hardcoded secrets pushed to public repositories in a single year [4].

So the agent gets a SVID a SPIFFE Verifiable Identity Document issued by SPIRE. Its identity becomes a non-spoofable URI like spiffe://atcp.test/agent/X, embedded in a short-lived X.509 certificate that SPIRE rotates automatically, often hourly. The credential is a temporary badge, not a permanent key: if it leaks, it expires in hours, and there is no long-lived secret to steal in the first place [10].

This is not exotic. SPIFFE and SPIRE are graduated CNCF projects [11], the same maturity tier as Kubernetes itself. The adoption stories are at serious scale: Uber uses SPIRE to manage identity across more than 4,500 services spanning thousands of hosts and multiple clouds, and Macquarie Bank replaced manual LDAP credentials with SPIFFE identities in its hybrid environment [12]. Istio ships SPIFFE-compliant identity natively, and Envoy serves SVIDs to sidecars with zero application code changes [13]. We are standing on a turtle that a lot of other people have already proven holds weight.

4. Are we really talking to who we think? mTLS

The agent has an identity; the tool has an identity. When they connect, both sides present their SVID and both sides verify the other’s. That’s mutual TLS, and with SPIFFE underneath it, impersonation becomes impossible: you cannot present a SPIFFE ID you cannot cryptographically prove you own.

The important architectural note and a point the practitioners are careful to make is that mTLS by itself is necessary but not sufficient. It proves who is on each end of the channel; it says nothing about whether the requested action is permitted. The real power, as one machine-identity guide puts it, comes from pairing mTLS with a workload identity system and a policy engine that grants least-privilege access based on identity and context [14]. Which is the fifth question.

5. Is this action allowed? OPA / Rego

The decision point lives at a Policy Enforcement Point (PEP) that asks an external brain: does spiffe://atcp.test/agent/X hold read:tools in its granted scope? That brain is Open Policy Agent, and the policy is written in Rego, decoupled entirely from application code.

The decoupling is the whole point, and it is the lesson the largest engineering organizations already learned the hard way. Netflix uses OPA to enforce access control across microservices in thousands of instances, pulling in contextual data to evaluate policy consistently across languages and frameworks [15]. Pinterest, Goldman Sachs, Atlassian, and Yelp run OPA the same way — typically as a sidecar next to each service — because baking authorization logic into application code produces scattered rules, tight coupling, and a system nobody can audit [16]. OPA is, like SPIFFE, a graduated CNCF project [16].

For an agent control plane this is doubly valuable: policy becomes code, version-controlled and reviewable, and the same Rego that governs a microservice can govern an agent. The PEP enforces; OPA decides; the policy itself lives in git. Three concerns, three places.

The hard part: multi-hop delegation

Everything above handles the single-hop case beautifully Alice authorizes Agent A, Agent A calls a tool. But the defining technical challenge of enterprise agents is not the single hop. It’s what happens when Agent A spawns Agent B, which calls Agent C, which touches production data.

This is the problem the whole field is now circling. WorkOS named it directly: “This is the multi-hop delegation problem, and it’s becoming the defining technical challenge of enterprise AI agent adoption.” OAuth’s token-exchange spec (RFC 8693) handles Human → Agent A → Service B cleanly, but when the chain extends, the prior-actor claims it relies on are informational only — not enforced [17]. O'Reilly's analysis put the dilemma in one sentence: at each new hop, the agent either reuses the original token (overprivileged) or has no token at all (untracked) [18].

And this is not theoretical. In September 2025, security researcher Johann Rehberger demonstrated Cross-Agent Privilege Escalation, showing how a compromised agent could write malicious instructions into another agent’s config files, which would then execute attacker-controlled code on startup [17]. A March 2026 IETF OAuth mailing-list thread debated “delegation chain splicing,” where an attacker inserts themselves between legitimate hops in the actor chain [17].

The naive fix call a central Token Exchange to mint a fresh narrowed token at every hop has two fatal flaws. It makes the Token Exchange a synchronous dependency on the critical path of every delegation (if it’s down, no agent can delegate), and it still provides no cryptographic proof that B’s authority actually descended from A’s. You’re back to trusting the logs.

The answer: Biscuit tokens

A Biscuit is a chain of cryptographically signed blocks where each block can only narrow the previous block’s authority. Never widen it. The root block is signed by the Token Exchange; each subsequent block is appended offline by the delegating agent, signed with its own SVID private key.

The verifier checks every signature in the chain and enforces monotonic attenuation: for every block N, scope[N] ⊆ scope[N-1] and budget[N] ≤ budget[N-1]. If Agent A holds [read, write] and tries to grant Agent B [read, write, delete], the chain is rejected delete was never in A's authority to give.

Crucially, attenuation happens with no network call. An agent narrows its own authority and hands it down locally. This is exactly the property Biscuit was designed for. It was created at Clever Cloud, which describes the motivating goal precisely: what if we could attenuate the token, but still verify it with public-key cryptography? [19]. It merges JWT’s public-key signatures with the offline attenuation of Macaroons, and it runs in production today Clever Cloud uses it for Apache Pulsar multi-tenancy, where each customer gets a token for their namespace and can derive narrower tokens for specific topics with no server-side code, and it’s also in production at Space and Time, nixbuild.net, and Outscale’s IAM [20][21]. This is the same insight the broader industry is now converging on: as one authentication analysis noted, each hop should only be able to reduce permissions, never expand them a constraint standard bearer tokens simply cannot enforce [22].

The token can be stolen. So make stealing it useless.

There’s one more failure mode, and it’s the one that keeps showing up in breach post-mortems. A bearer token is exactly that: whoever bears it, uses it. RFC 6750 says so almost word for word any party in possession of a bearer token can use it [23]. WorkOS put it plainly: a leaked token makes the attacker indistinguishable from the legitimate client, “and it is the reason token theft keeps showing up in post-mortems” [24]. The high-profile attacks of the past year against major identity and infrastructure providers leaned heavily on exactly this class of credential [2].

So in our control plane the Biscuit is key-bound, not bearer. It’s minted bound to the agent’s SVID public key, and to use it the agent must sign a fresh challenge with the matching private key. Present a stolen token without the private key and the proof fails the token is inert.

This is the proof-of-possession idea standardized by the IETF as DPoP (RFC 9449), which sender-constrains tokens by binding them to a key pair the client holds, and requires a signed proof on every request [23]. The principle is endorsed across the ecosystem Okta and Auth0 both ship DPoP support and frame the motivation the same way: a stolen sender-constrained token is worthless because the attacker cannot produce a proof signed by the right private key [25]. And it’s why the SVID matters so much: SPIRE manages and protects the private key that is the proof of possession.

Putting it together, end to end

Every hop is cryptographically proven. Every decision is logged. Every scope is enforced. Nothing can be widened, forged, or replayed.

1. Developer self-registers a new agent: name, workload selector, requested scope tier. Creates IDENTITY only, not authority. Must complete in hours not weeks .

2. Writes the workload registration entry (SPIFFE ID + selectors) so the workload becomes eligible for an SVID once it attests.

3. Registers a least-privilege default policy so the agent starts with zero authority until a principal delegates or an admin grants scope.

4. Bidirectional. The node agent gathers workload+node attestation evidence and the hardware RoT returns it signed . No valid evidence → no identity (blocks shadow agents, ASI10).

5. The attested workload requests its identity. SPIRE validates evidence against the registration entry.

6. SPIRE mints and delivers a short-lived SVID (X.509/JWT), no static secret . The agent is now VISIBLE and INERT: known to the control plane, zero authority.

7. Rotates SVIDs before expiry and establishes cross-trust-domain federation for cross-vendor/cross-org agents .

8. Delivers rotated SVIDs ahead of expiry so identity never lapses mid-task.

Open items

A world-class design names what it hasn’t solved.

• Revocation. Short SVID TTLs limit the blast radius of a compromised key, but a Biscuit attenuated and cached downstream still needs a revocation story tighter than “wait for expiry.” This is an active problem area across the whole token ecosystem, not a solved one.
• The Token Exchange root of trust. We removed it from the per-hop critical path, but the root Biscuit block still originates there. Its signing key is the crown jewel; its compromise is catastrophic. HSM-backing and tight SPIRE attestation for that one service are non-negotiable.
• Biscuit ecosystem maturity. Biscuit is in real production use, but its authors are candid that the spec and implementations have not been formally audited [27], and library coverage varies across languages. That’s a deliberate, eyes-open risk acceptance, not an oversight.
• Standards are still moving. The IETF, NIST, and enterprise security teams are actively working the multi-hop problem right now [17], and emerging proposals like AAuth (from OAuth 2.0’s own author) treat agents as first-class identities with per-request signing [22]. Parts of this control plane may need to track those standards as they land.

References

[1] Resilient Cyber — Identity Is the Agentic AI Problem Nobody Has Solved Yet. https://www.resilientcyber.io/p/identity-is-the-agentic-ai-problem [2] Cloud Security Alliance — Securing Non-Human Identities in the Age of AI Agents (CSA Summit at RSAC 2025). https://cloudsecurityalliance.org/artifacts/securing-non-human-identities-in-the-age-of-ai-agents-rsac-2025 [3] The Hacker News — The Non-Human Identity Crisis (Entro Labs / Rubrik Zero Labs ratios). https://thehackernews.com/expert-insights/2026/05/the-non-human-identity-crisis-why-your.html [4] Cloud Security Alliance Labs — The Non-Human Identity Governance Vacuum (WEF 51% ownership figure; GitGuardian secrets data). https://labs.cloudsecurityalliance.org/research/csa-whitepaper-nonhuman-identity-agentic-ai-governance-v1-cs/ [5] Aembit — Human vs. AI Identity: Why AI Agents Are Breaking Identity (SailPoint 80% survey). https://aembit.io/blog/human-vs-ai-identity-why-ai-agents-are-breaking-identity/ [6] Arcade (DEV Community) — How to Manage Multi-User AI Agent Authentication and Authorization in 2026. https://dev.to/arcade/how-to-manage-multi-user-ai-agent-authentication-and-authorization-in-2026-oauth-21-oidc-and-2943 [7] O’Reilly Radar — Who Authorized That? The Delegation Problem in Multi-Agent AI. https://www.oreilly.com/radar/who-authorized-that-the-delegation-problem-in-multi-agent-ai/ [8] TechRxiv — OAuth Is Not Enough: Authorization Challenges for Autonomous AI Agents. https://www.techrxiv.org/users/928372/articles/1299852-oauth-is-not-enough-authorization-challenges-for-autonomous-ai-agents [9] Christian Posta — Explaining OAuth Delegation, “On Behalf Of,” and Agent Identity for AI Agents. https://blog.christianposta.com/explaining-on-behalf-of-for-ai-agents/ [10] Ryan Spletzer — Zero to Trusted: SPIFFE and SPIRE, Demystified. https://www.spletzer.com/2025/03/zero-to-trusted-spiffe-and-spire-demystified/ [11] Red Hat — What are SPIFFE and SPIRE? https://www.redhat.com/en/topics/security/spiffe-and-spire [12] GoCodeo — Introduction to SPIFFE (Uber 4,500 services; Macquarie Bank). https://www.gocodeo.com/post/introduction-to-spiffe-secure-identity-for-distributed-systems [13] SPIFFE & SPIRE: The Workload Identity Standard Quietly Powering Zero Trust (Istio/Envoy native support). https://sameerbhanushali.substack.com/p/spiffe-and-spire-the-workload-identity [14] Petronella Cybersecurity — Machine Identity is the New Perimeter: mTLS & SPIFFE Guide. https://petronellatech.com/blog/machine-identity-is-the-new-perimeter-mtls-spiffe-for-zero-trust/ [15] Open Policy Agent — ADOPTERS.md (Netflix, Pinterest, Cloudflare, and others). https://github.com/open-policy-agent/opa/blob/main/ADOPTERS.md [16] Permit.io — An Intro to Open Policy Agent (OPA) (Netflix, Pinterest, Goldman Sachs; CNCF graduation). https://www.permit.io/blog/introduction-to-opa [17] WorkOS — AI Agents and the Multi-Hop Delegation Problem (RFC 8693 limits; Rehberger cross-agent escalation; IETF chain-splicing). https://workos.com/blog/oauth-multi-hop-delegation-ai-agents [18] O’Reilly Radar — Who Authorized That? (overprivileged-vs-untracked dilemma). https://www.oreilly.com/radar/who-authorized-that-the-delegation-problem-in-multi-agent-ai/ [19] Clever Cloud — Biscuit, the Foundation for Your Authorization Systems. https://www.clever.cloud/blog/engineering/2021/04/12/introduction-to-biscuit/ [20] Biscuit — Biscuit 2.0 Release (Apache Pulsar multi-tenancy use case). https://www.biscuitsec.org/blog/biscuit-2-0/ [21] Eclipse Biscuit — FAQ (production users: Clever Cloud, Space and Time, nixbuild.net, Outscale). https://www.biscuitsec.org/docs/help/faq/ [22] GitGuardian — AI Agents Authentication: How Autonomous Systems Prove Identity (per-hop reduction; AAuth). https://blog.gitguardian.com/ai-agents-authentication-how-autonomous-systems-prove-identity/ [23] IETF — RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP). https://www.rfc-editor.org/rfc/rfc9449.html [24] WorkOS — DPoP (RFC 9449) Explained. https://workos.com/blog/dpop-rfc-9449-explained [25] Okta Developer — Elevate Access Token Security by Demonstrating Proof-of-Possession. https://developer.okta.com/blog/2024/09/05/dpop-oauth [26] DEV Community — The Missing Protocol for AI Agent Authorization. https://dev.to/chudah1/the-missing-protocol-for-ai-agent-authorization-2532 [27] Eclipse Biscuit — FAQ (no formal audit; current production status). https://www.biscuitsec.org/docs/help/faq/