← All transcripts

Kagenti’s Approach to Multi-Agent Security for AI Agents Transcript, AI Summary & Key Points

IBM Technology · Jun 16, 2026 · Education · 08:43 · EN

📄 Transcript

Searchable transcript of Kagenti’s Approach to Multi-Agent Security for AI Agents — IBM Technology (08:43). Search for a phrase, then click its timestamp to jump straight to that moment in the video.

Captions sourced from the original video on YouTube, published by IBM Technology. The video, its captions and all related intellectual property remain the property of their respective owners; AINotes claims no ownership. Provided for research, accessibility and search — see the Transcript Notice and Copyright Policy.

00:00 Today, we're going to look at how to use open source security logic at the infrastructure level to combat a common security problem when running multiple AI agents in production. Ever heard of a confused deputy security vulnerability? A confused deputy is when an agent with completely legitimate authority is tricked into using that authority for a request that shouldn't have it, and this can to invisible data breaches.

00:33 Malicious tool calls. And prompt injection. This is a huge deal. Protected information like patient records, financial histories, or internal communications could be stolen with audit trails that show nothing but normal authorized activity. And without the right security for a multi-agent system, you might end up with at least one confused deputy running around.

01:06 The project we will use to combat this is called Kagenti. Kagenti allows you to bring your own agent regardless of what framework you used to build it. And then it adds the security layer around it. Kagenti can retrieve your source code from GitHub or deploy directly from a container image you might have running locally and then adds that security infra.

01:31 The platform has four pillars, lifestyle orchestration, networking, security and observability. Today, we're going to be focused on the security pillar because that's where this confused deputy problem gets solved. Here's a confused deputy scenario showing credential leakage that can occur with security at the application level. A hospital has an agentic system.

01:57 It's for patient billing. And they grant a bearer token to this orchestrating agent. Now, this bear token is going to grant access to the hospital's patient data. And as agent A orchestrates the task, it's going to call subagents to help, agents B, C, and D. Now, Agent D gets the task to verify if the patient has insurance, but it also gets this access token because it's sitting in the context or has been passed the chain.

02:50 Now, agent D was never supposed to have access to patient records. It was just verifying if it had insurance, but it now does have that access because the token traveled with the request. Now that's a confused deputy, and here's what makes them so hard to combat in agentic system specifically. In a traditional application, you have a defined call graph.

03:14 You can say, this service goes to this service, and you can bake that into your network, and segment, and you're done. Agents don't work that way. The value of an agent is that it decides what to do next. You can't statically guarantee the path a request will take. You can't bake authorization into this topology. So what do you do? You stop trying to secure the path and you start trying to security the identity.

03:44 When you deploy an agent via Kagenti, two side cars are deployed along with your agent. The first is SPIFFE. This stands for Secure Production Identity Framework for Everyone. What it actually does is give your agent a cryptographic workload identity, an X.509 certificate called a SPIFFE Verifiable Identity Document. This is not a username or a password.

04:25 It's not a static API key that someone can copy and paste out of your context and reuse for years. It's a short-lived certificate tied to this specific workload in this specific namespace on this specific service account. And your agent proves who it is the same way a server on the internet proves it's actually your bank with a cert and not a secret.

04:48 Now, the second is the Kagenti client registration. And what this does is register the agent as an OAuth2 client in KeyCloak. KeyClock is an open source identity and access management solution. So it can, so that your agent can request limited tokens for specific tools. Okay, now here is where we solve the confused deputy problem. Remember agent A and D?

05:23 It was never supposed to touch these patient records, but it got the access token passed through it via the context. So, Kagenti ships a component called authbridge. And every time an agent makes a call, authbridge injects a header. And this header doesn't just say, this is agent D, it says, this agent D called by agent A on behalf of this specific user, and it has the full chain in order cryptographically signed.

06:08 Now, when the request arrives at the patient record tool, or the gateway in front of it, you can check whether every actor and the entire chain is authorized for this resource. If Agent D should never touch patient data, the policy fires and it's blocked, regardless of whether Agent D holds a valid token that it received via the chain. And that's the fix.

06:34 The authorization decision is made against the full delegation chain. You could not do this with traditional RBAC role-based access control because you need to know the path ahead of time. Whereas this approach works precisely because the identity travels with the request. From a developer experience standpoint, AuthBridge handles three things at deploy time.

06:57 So fetching and rotating that SPIFFE identity, registering the OAuth2 client in KeyCloak, and standing up in InvoidProxy. That validates inbound tokens before your agent code ever sees the request and your agent container is untouched. Now on the tool side, the MCP gateway sits in front of your tools like this patient access tool and every tool call goes through it.

07:33 It handles routing, rate limiting and token validation all in one place. Swapping out a tool is one URL change Connecting all of this is Istio in ambient mode, which handles encrypted, mutually authenticated networking between every agent and every tool with no additional configuration request per pod. Now, because all of these runs over standard HTTP, OpenTelemetry instruments it automatically.

08:00 You can get a single trace ID that follows the entire request path. Kagenti ships with Phoenix for end-to-end agent tracing and MLflow for experiment tracking. So when something goes wrong, you can see what happened and who authorized it. Every component in this stack is open source, Apache licensed and wired together via Kagenti. If you're building a multi-agent system and this hits close to home, drop me your setup in the comments.

08:28 I wanna know what you're working with. And if this was helpful, please like and subscribe. Thanks so much.

🧠 AI Summary

Kagenti addresses confused deputy vulnerabilities in multi-agent systems by securing workload identity and delegation chains rather than relying on a statically defined call path. It deploys SPIFFE identities, registers agents as OAuth2 clients in KeyCloak, and uses AuthBridge to cryptographically sign the full chain of agents and users involved in each request. Gateways can then authorize every actor in the chain before allowing access to protected tools. Kagenti also integrates MCP gateway routing and token validation, Istio mutual authentication, OpenTelemetry tracing, Phoenix agent tracing, and MLflow experiment tracking.

🔑 Key Points

  • A confused deputy occurs when an authorized agent is tricked into using its authority for an unauthorized request.
  • Bearer tokens passed through an agent chain can give subagents access to protected data they were never intended to access.
  • Agentic systems cannot rely on static network call graphs because agents dynamically decide their next actions.
  • Kagenti uses SPIFFE X.509 certificates as short-lived workload identities instead of reusable passwords or API keys.
  • AuthBridge enables authorization against the complete delegation chain rather than only the identity holding a valid token.
  • The MCP gateway centralizes tool routing, rate limiting, and token validation.
  • Kagenti integrates Phoenix for end-to-end agent tracing and MLflow for experiment tracking.

✅ Actionable items

  • Deploy agents through Kagenti to add SPIFFE identity, OAuth2 client registration, and inbound token validation without modifying the agent container.
  • Use AuthBridge to attach a cryptographically signed delegation chain to every agent call.
  • Place an MCP gateway in front of tools to centralize routing, rate limiting, and token validation.
  • Authorize requests by checking every actor in the delegation chain before allowing access to protected resources.
  • Use Istio in ambient mode for encrypted, mutually authenticated networking between agents and tools.
  • Use OpenTelemetry, Phoenix, and MLflow to trace requests and track experiments.

🧭 Frameworks

Identity-based authorization with full delegation chains05:37
  1. Give each agent a short-lived cryptographic workload identity.
  2. Register the agent as an OAuth2 client for limited tool access.
  3. Attach the complete, cryptographically signed chain of agents and users to each request.
  4. Validate the entire chain at the protected tool or gateway.
  5. Block the request if any actor in the chain lacks authorization.

🧰 Tools & AI usage

  • Kagenti — Deploy agents and add infrastructure for orchestration, networking, security, and observability.01:06
  • GitHub — Source code repository from which Kagenti can retrieve an agent.01:23
  • SPIFFE — Provide agents with cryptographic workload identities through short-lived X.509 certificates.03:41
  • KeyCloak — Register agents as OAuth2 clients so they can request limited tokens for specific tools.04:59
  • authbridge — Inject a cryptographically signed header containing the full agent and user delegation chain.05:38
  • InvoidProxy — Validate inbound tokens before requests reach the agent code.06:57
  • MCP gateway — Route tool calls and provide rate limiting and token validation.07:20
  • Istio — Provide encrypted, mutually authenticated networking between agents and tools in ambient mode.07:43
  • OpenTelemetry — Automatically instrument standard HTTP traffic and provide a trace ID across the request path.07:54
  • Phoenix — Provide end-to-end agent tracing.08:06
  • MLflow — Track experiments.08:06

⚖️ Advantages, risks & lessons

Advantages

  • Authorization works without statically defining the path a dynamically acting agent request will take.
  • Agent containers remain untouched when inbound token validation is handled at deploy time.
  • Tool replacement can be performed with one URL change.
  • The stack provides a single trace ID across the entire request path.

Risks

  • Bearer tokens passed through an agent context can expose protected records to unauthorized subagents.
  • Malicious tool calls and prompt injection can contribute to confused deputy vulnerabilities.
  • Protected information could be stolen while audit trails show only normal authorized activity.

Lessons

  • Multi-agent security should focus on identity and delegation rather than only network topology.
  • A valid token is insufficient when the holder is not authorized within the full delegation chain.
  • Traditional role-based access control cannot provide this authorization model when the request path is not known in advance.

💬 Quotes

You stop trying to secure the path and you start trying to security the identity.