Dora NodaGive an AI agent a scoped API key and permission to deploy, and you have built something the industry has a name for: a script with credentials that can improvise. The key says what the holder may touch. It says nothing about who is holding it right now, on whose behalf it acts, or whether the thing holding it is still the agent you approved last Tuesday. When that key leaks — pasted into a log, exfiltrated through a prompt injection, copied to a laptop — the finder inherits every permission you ever granted the agent, with no expiry and no delegation trail.
This is the problem the 2026 zero-trust-for-agents work is converging on, and Red Hat's June 2026 series on the subject wires three pieces together: SPIFFE for cryptographic workload identity, RFC 8693 token exchange to carry human-delegation context, and Kagenti for agent lifecycle management and policy binding. The governing rule, stated in part one of that series, is the permission intersection pattern: an agent's effective permission is the user's permissions intersected with the agent's own — agents can only reduce authority, never expand it.
This post makes that abstract rule concrete: what an agent lifecycle manager sitting in front of a deploy/rollback MCP server actually gates, decision by decision, versus the scoped-key-plus-audit-log model most agent-operated platforms ship today.
The three pieces, and what each one proves
Every agent-to-infrastructure call needs three questions answered, and each piece of the stack owns exactly one. Here is the core deliverable up front — the gate table for a single tool call, say deploy against a tenant's staging app:
| Layer | Question it answers | Mechanism | What it stops |
|---|---|---|---|
| SPIFFE / SPIRE | Which workload is calling? | Short-lived X.509-SVID certificates (1-hour TTL in Red Hat's demo), verified over mTLS; no bearer secret ever crosses the wire | Stolen API keys — there is no static credential to steal, and a compromised cert dies within the hour |
| RFC 8693 token exchange (AuthBridge) | On whose behalf, with what attenuated scope? | The agent's workload identity is exchanged for a short-lived, audience-scoped token whose sub is the human user and whose act (actor) claim is the agent | Confused deputy and over-privilege — the token carries both identities and only the intersection of their permissions |
| Kagenti lifecycle + policy binding | Is this agent registered, in good standing, and allowed this action? | Agents run as Kubernetes workloads (Agent/Component/AgentBuild CRDs), discoverable through an AgentCard catalog; policy binds each registered agent to the tools and tenants it may touch | Rogue and stale agents — an unregistered, suspended, or out-of-policy agent never reaches the tool, no matter what token it holds |
Read the table bottom-up and you get the lifecycle manager's real job: it is a registry of principals with states, not a bigger firewall. A scoped API key authenticates a permission. Kagenti authenticates an agent — a named entity with a lifecycle (deployed, active, suspended, retired), a policy binding, and a discoverable card — and then checks that entity against the action. Revoking a key kills a permission; suspending an agent's registration kills the principal.
Kagenti itself is deliberately boring infrastructure, which is the point. It is an open-source Kubernetes operator: you bring your own agent framework (LangGraph, CrewAI, AG2), and Kagenti handles workload lifecycle around it — deploying agents as standard Deployments, building their images from source through Tekton-orchestrated AgentBuilds, and cataloging them via AgentCards fetched from each agent's /.well-known/agent-card.json. Its own positioning says it plainly: the infrastructure layer beneath the agent, with zero-trust identity via SPIFFE/SPIRE and AuthBridge injected at deploy time and no agent code changes required.
A deploy call, gate by gate
Make it concrete. A tenant's on-call engineer tells their deploy agent, over chat: "roll staging forward to main." The agent decides to call the platform's deploy tool. Under the coarse model, the request carries a long-lived scoped key and the platform checks the scope string, runs the deploy, and writes an audit row. Under the lifecycle-managed model, four gates close in sequence:
Gate 1 — Registration and standing. Before any credential is even examined, the platform asks Kagenti: is this agent a registered principal? Is its lifecycle state active rather than suspended or retired? Does its policy binding permit deploy on this tenant's infrastructure? An agent registered for tenant A cannot touch tenant B even with a valid token; an agent whose registration was suspended after anomalous behavior yesterday cannot deploy anything today. This is the decision scoped keys cannot express: keys don't have states, principals do.
Gate 2 — Workload proof. The agent proves it is the registered workload, not something presenting the agent's name. SPIFFE SVIDs make this cryptographic rather than declarative: the calling pod presents a short-lived certificate for its SPIFFE ID, verified over mTLS. No shared secret means nothing to phish out of the agent's context window or environment — a meaningful property when the caller is a system that can be talked into revealing secrets.
Gate 3 — Delegation with attenuation. AuthBridge, running as a sidecar, exchanges the agent's workload identity plus the user's identity for a downstream token via RFC 8693: an audience-scoped, minutes-lived token with sub = the engineer and act = the agent, carrying only the intersection of their permissions. If the engineer lacks production access, the agent cannot conjure it — the intersection forbids expansion. If the token leaks, it is scoped to one tool audience and expires in minutes, not months. This is the direct fix for the "script with credentials" problem: the credential now names its holder, its principal, and its expiry.
Gate 4 — Per-tool enforcement. At the MCP Gateway — the Envoy-based layer from the Kuadrant project that routes and polices MCP tool invocations — fine-grained policy evaluates the actual call: this agent, under this user's delegation, may invoke deploy on staging but not production, may invoke rollback but not destroy, within these rate limits. Coarse-grained inter-agent exchange happens higher up (via Keycloak-issued JWTs); the gateway is where "allowed to deploy" narrows to "allowed to deploy this." Two-level authorization like this is explicitly on the AuthBridge roadmap, with end users able to see and control what tools agents may use on their behalf.
Notice what the audit log becomes in this world: not the security control, but the receipt. The coarse model audits after the call and hopes someone reads the log. The managed model enforces before the call and the log records decisions that were already policy-checked.
What the coarse model can't see: the comparison
Put the two models side by side and the gaps in scoped-keys-plus-audit sharpen:
| Property | Scoped key + audit log | Lifecycle manager + delegation |
|---|---|---|
| Credential lifetime | Long-lived bearer token; leak = full scope until manual rotation | Minutes-lived, audience-scoped tokens minted per call chain |
| Who is acting | Unknown — key says what, never who | Dual identity on every call (sub = user, act = agent) |
| Enforcement point | Scope string checked at the API edge; audit written after | Registration, standing, policy, and per-tool rules checked before the tool runs |
| Revocation granularity | Rotate the key; every holder (legit and otherwise) breaks at once | Suspend one agent's registration; everything else keeps working |
| Stale agents | No concept — an old key works until expiry/rotation | Lifecycle states retire agents; unregistered callers never reach tools |
| Human-delegation proof | Absent — the key can't say which human authorized this call | Token exchange carries the delegation chain, narrowable at every hop |
The row that matters most for a deploy platform is revocation granularity. Incident response with bearer keys is a fleet-wide credential rotation under fire. Incident response with registered principals is suspending one agent — the blast radius is one principal, decided in one place, effective within token TTL.
There is also a standards tailwind worth noting: the IETF is profiling exactly this delegation for agents (a credential-delegation draft built on RFC 8693 with proof-of-possession and rich authorization), and AWS's Bedrock AgentCore documents the same on-behalf-of exchange pattern for multi-tenant agents. The wire format for "this agent acts for this user with this slice of authority" is converging, not fragmenting.
The honest costs
None of this is free, and a post this specific about the mechanism should be specific about the price too. Operating the managed model means operating a control plane: a SPIRE server as your CA and registry, an identity provider such as Keycloak for the exchange, Envoy-based sidecars intercepting agent traffic, and the MCP Gateway as a new hop in front of every tool call. Each hop adds latency to tool invocations — negligible for a deploy that takes minutes, worth measuring for high-frequency read tools. Policy has mid-flight semantics to define: what happens to a running deploy when the agent's binding changes underneath it — finish, freeze, or roll back?
And the software is young: Red Hat's own series carries the explicit caveat that these are upstream technologies under active development, not supported products. You would be adopting a pattern with reference implementations, not a finished platform.
So when does the coarse model suffice? For single-tenant, human-supervised agents where the operator watches every deploy and rotates keys routinely, scoped keys plus diligent audit review are proportionate. The lifecycle-managed model earns its keep at the point this publication's audience lives at: multi-tenant platforms where agents act while humans sleep, where one leaked credential can cross tenant boundaries, and where "which human authorized this 3 a.m. production deploy" must be answerable from the token itself rather than reconstructed from logs.
That is the actual meaning of "policy-bound, registry-tracked." Not bureaucracy around agents — the difference between authenticating a permission and authenticating a principal. A platform whose pitch is letting agents deploy directly needs the second one, because direct deployment without principals is just anonymous remote code execution with good logging.
Agents that deploy are first-class operators on Bex.co — the open-source, AI-native Render alternative. Scoped, logged, revocable tool access over MCP is the baseline the zero-trust work now demands. Star the repo on GitHub or deploy your first app today.
