AI
Why API Keys Break Down in Multi-Tenant Agent Deployments
When GitHub receives a request with an API key, it assumes a human sent it. That assumption held for years. In enterprise agentic workflows, one user can trigger a chain of agents talking to multiple tools and other agents. Each hop still passes API keys, but now the organization, not the user, is responsible for vetting that behavior. Long-lived static credentials make zero-trust enforcement impossible. Worse, every downstream request loses context about whether one agent or three sat between the user and the resource.
OAuth 2.0, SPIFFE, and Token Exchange as the Replacement Stack
OAuth access tokens carry subject, authorized party, and audience in a single signed document. Every component trusts the central OAuth server (Keycloak, Microsoft Entra, Okta). When an agent calls another service, the context changes, so token exchange mints a new token reflecting the new audience. SPIFFE/SPIRE replaces static client secrets by interrogating the platform (for example, the kubelet in Kubernetes), mapping the resulting attributes to a name, and issuing a cryptographically signed workload identity. Short-lived tokens and platform-attested identity together enforce zero-trust posture without any shared secrets.
OBridge: Sidecar-Based Auth With No Agent Code Changes
OBridge is the Kajenti component that makes the full stack transparent to agent developers. The platform injects it as a sidecar via webhooks. An init container configures IP-table traffic interception. Inbound requests hit an Envoy proxy with an xDS filter that validates the JWT; an invalid token returns 401 before the application sees the request. Outbound calls are intercepted by the same sidecar, which performs token exchange with the correct audience for the target service. Subject claims are preserved across every exchange, so the tool always knows which user initiated the original request.
Demo: Token Validation and GitHub Issue Retrieval in Kajenti
The recorded demo walked through the Kajenti UI showing a weather agent and a GitHub issue agent. Calling the agent endpoint without an authorization token returned “authorization header missing” immediately at the sidecar. After logging in and obtaining a token, the same call returned the formatted list of open issues from the Kajenti GitHub repo. The injected containers visible in the pod were: Envoy proxy, SPIFFE helper, and the Kajenti client-registration sidecar that registers the workload with Keycloak at startup. No OAuth code existed inside the agent container itself.
Attesting Agent Semantic Attributes: The Open Problem
A health database with PII compliance requirements needs proof that the calling agent has PII guardrails, not just a platform identity. The A2A agent card is self-describing, meaning the resource server must implicitly trust it, which undermines the entire identity chain. The proposed fix is to extend SPIRE with stackable workload attesters: one attester covers platform attributes, a second covers agent semantic attributes, and both combine into a single SVID. This is not implemented in SPIRE today. IBM opened a proposal in the SPIRE GitHub, but the deeper question of where the ground truth for agent attributes lives remains unsolved.
Q&A
How does this apply to local, non-remote agentic workflows where an organization wants looser guardrails? Vault handles the boundary: local identities stay within the trust domain, and personal access tokens stored in Vault are retrieved only when a call must cross into an external domain. ▶ 30:20
How should elevated privileges be granted mid-run when an agent needs more access than it has? The team is researching “human in the loop” via eventing, where the agent fires a callback event asking the user for elevated privileges, and is also evaluating client-initiated back-channel authentication. ▶ 31:16
How does token exchange work when an agent must reach multiple resource servers including MCP tools and knowledge bases? An MCP gateway sits between the agent and tools, holds fine-grained per-user per-tool permissions, and handles routing so the agent is not overloaded with tool context. ▶ 35:26
Notable Quotes
Generative AI does not bypass traditional engineering disciplines. Mariusz Sabath · ▶ 08:25
Agents are just workloads. They need identity authent uh uh authentication, authorization, the same things as any other workload. They they don’t get a free pass just because they smart. Mariusz Sabath · ▶ 08:46
Token exchange is a cryptographic trail of the actors involved in the exchange from the initiator all the way to the resources. Mariusz Sabath · ▶ 11:26
the key to this answer is multiple keys. It is not like any one entity has one key that that can do everything. It’s more like the Star Trek self-destruct sequence where every captain or every Yeah. every uh captain must provide their own authorization code. Maia Iyer · ▶ 27:31
Key Takeaways
- Static API keys cannot carry the context needed for zero-trust agentic deployments.
- OBridge sidecars handle all OAuth and SPIFFE logic transparently, with no changes to agent code.
- Subject identity is preserved through every token exchange, giving resource servers a full audit chain.
- SPIRE needs stackable workload attesters before agent semantic attributes can anchor authorization policy.
- Kajenti is built entirely on open standards, so any OAuth provider or SPIFFE implementation can plug in.
About the Speaker(s)
Mariusz Sabath is a Senior Technical Staff Member at the IBM T. J. Watson Research Center with extensive experience in system management and distributed environments. He has led numerous development projects, authored technical papers, and holds numerous patents.
Maia Iyer is a Research Software Engineer at IBM Research. During her three-year tenure she has focused on open-source, zero trust, and the multicloud identity problem. She maintains the open-source Tornjak project in the SPIFFE community to ease SPIRE adoption.