Kagenti's Identity-Based Security for Multi-Agent

Picture this: you've built a hospital billing agent. It's got sub-agents. One of them — let's call it Agent D — exists solely to check whether a patient has insurance. That's it. That's its whole job. But somewhere in the request chain, a bearer token with access to full patient records quietly hitches a ride. Agent D never asked for it. Nobody explicitly gave it. It just... arrived, tucked into context. Now Agent D can read patient records it was never authorized to touch, and your audit log shows nothing but clean, authorized activity.

That's a confused deputy vulnerability, and it's the kind of thing that keeps security engineers awake at 2am — not because it's loud, but because it's silent.

In a recent IBM Technology video, Legare Kerrison (whose affiliation with Kagenti versus IBM isn't explicitly clarified in the presentation) walks through how the Kagenti project approaches this problem. The framing is specific and technical, but the underlying insight applies to anyone building systems where AI agents hand off work to other AI agents — which is increasingly everyone.

Why traditional security falls apart here

Here's the thing about securing microservices the old-fashioned way: you know the call graph ahead of time. Service A calls Service B calls Service C. You draw a map, you bake it into your network segmentation rules, done. Role-based access control (RBAC) works because you can enumerate who's allowed to do what before anything runs.

Agents shred that assumption. The whole point of an agent is that it decides what to do next. You cannot statically predict the path a request will take through a multi-agent system, which means you cannot write authorization rules against a topology that doesn't exist yet. As Kerrison puts it: "You stop trying to secure the path, and you start trying to secure the identity."

That inversion — and I'll be honest, I find it genuinely clever — is the conceptual load-bearing wall of everything Kagenti does. You've probably experienced the old model from the other side: you paste an API key into a .env file, push to GitHub (😬), and spend the next six months wondering if you should rotate it. That key doesn't know anything about who's using it or why. It's just a string. Anyone who has it can use it. Static credentials are dumb by design, and in a dynamic multi-agent system, they become a liability that can propagate through an entire call chain before anyone notices.

What AuthBridge actually does — and why it's the interesting part

Kagenti deploys two sidecars alongside your agent at runtime. The first is SPIFFE (Secure Production Identity Framework for Everyone — that's the name per the CNCF/SPIFFE project), which hands your agent a cryptographic workload identity in the form of a SPIFFE Verifiable Identity Document (SVID). Worth noting: SVIDs can take the form of either X.509 certificates or JWT tokens depending on your configuration — Kerrison focuses on the X.509 case, which is short-lived and tied to a specific workload, namespace, and service account. This is categorically different from a static API key. It expires. It can't be copy-pasted into someone's config and forgotten for three years. It proves identity the way TLS certificates prove your bank's website is actually your bank.

The second sidecar handles OAuth 2 client registration in Keycloak (an open-source identity and access management tool, Apache 2.0 licensed), so each agent can request scoped tokens for specific tools rather than inheriting whatever token happened to be floating around in context.

But the component I keep coming back to is AuthBridge, because this is where the confused deputy problem actually gets solved — and the solution is elegant in the way that good security design sometimes is. Every time an agent makes a call, AuthBridge injects a header. Not just "this is Agent D." The header says: "This is Agent D, called by Agent A, on behalf of this specific user." The entire delegation chain, cryptographically signed, traveling with the request.

When that request hits the patient records gateway, the policy engine doesn't just ask "does Agent D have a valid token?" It asks: "Is every actor in this chain authorized for this resource?" If Agent D should never touch patient data, it gets blocked — regardless of whether it's holding a legitimately-issued token it received through the chain. As Kerrison explains: "The authorization decision is made against the full delegation chain. You could not do this with traditional RBAC because you need to know the path ahead of time. Whereas, this approach works precisely because the identity travels with the request."

That's the bit that I think is underappreciated in how it's framed. Most security approaches try to predict and constrain. This one says: I don't need to predict the path if every actor in the path is cryptographically identified and every step in the chain is auditable in real time. It's a fundamentally different posture, and it maps onto how zero-trust principles were always supposed to work — just finally applied somewhere they actually need to.

What the stack looks like (and what that stack costs you)

Okay, I'll be upfront: when I first ran through the component list, my reaction was somewhere between "this is a thoughtfully assembled toolkit" and "this is a lot of moving parts." Both are true, and they're not in contradiction.

Istio in ambient mode handles encrypted, mutually authenticated networking between agents and tools — no per-pod sidecar configuration required, which is genuinely a quality-of-life improvement over older Istio deployments. An MCP (Model Context Protocol) gateway sits in front of all tools, handling routing, rate limiting, and token validation in one place. OpenTelemetry instruments everything automatically since it all runs over standard HTTP, and Kagenti ships with Phoenix for end-to-end agent tracing and MLflow for experiment tracking — so when something goes wrong, you can reconstruct exactly what happened and who authorized what.

Most components here are open source (SPIFFE, Keycloak, Istio, Envoy, OpenTelemetry are all Apache 2.0). MLflow is also Apache 2.0. Phoenix is Arize AI's tracing tool — open source, but licensing is worth verifying independently if that matters for your deployment context. The blanket "Apache-licensed" framing from the video is mostly accurate but not universally precise.

The architecture is genuinely coherent — these tools are well-chosen and play together naturally. But "coherent" and "operationally simple" aren't the same thing. Running Istio, Keycloak, SPIFFE, and an MCP gateway in production means your team needs to understand, monitor, and maintain all of that. For a team already comfortable with service mesh infrastructure, this probably slots in without much friction. For a team that's been running agents as containerized scripts with .env files, this is a meaningful step up. That's not a knock — the security posture jump is proportional — but it's a real consideration.

This broader challenge around agentic AI security keeps surfacing across different implementations: the solutions that actually work tend to require infrastructure maturity that not every team deploying agents has yet.

The open questions

A few things the video doesn't fully address — not as criticism, but because they're the natural next questions:

Performance at scale. Every agent call now involves header injection, chain validation, and policy evaluation. That's not free. How AuthBridge performs under high request volume in a production multi-agent system is something you'd want to benchmark for your specific workload before committing.

Cross-organization chains. The hospital scenario is contained — all agents are in the same system. What happens when Agent A is yours, Agent B is a third-party service, and Agent D is a vendor tool? Delegation chains that cross trust boundaries are a harder problem, and it's not clear Kagenti addresses that yet.

LLM prompt injection. Kerrison mentions prompt injection as one of the threats confused deputy scenarios enable. Cryptographic identity solves the credential-leakage vector. But if an attacker can manipulate what instructions an agent receives at the prompt level, identity alone doesn't close that gap. The MCP security landscape has its own attack surface that sits adjacent to what Kagenti is protecting.

None of these undercut the core design. They're just the perimeter of what this particular solution covers.

Multi-agent systems are getting deployed into production faster than the security tooling around them is maturing. The breach scenario Kerrison describes — patient data exfiltrated with an audit trail that looks completely clean — isn't hypothetical. It's the category of incident that surfaces months or years after the fact, in a regulatory filing or a journalist's inbox. I keep imagining what that looks like when it's not a hospital billing system but something with broader blast radius: financial infrastructure, legal discovery systems, anything where "the audit log looked fine" is the scariest possible finding.

Chain-aware identity delegation is the right technical direction. Whether it gets adopted before that incident or after it is, honestly, the only question that matters now.

— Yuki Okonkwo, AI & Machine Learning Correspondent, Buzzrag