Deploy an open-source security layer around multi-agent systems so authorization decisions use each agent's cryptographic identity and the full delegation chain, rather than relying on bearer tokens or a statically defined request path.
AuthBridge is an Indian background-verification and identity-services company that provides employee background screening, identity verification, KYC and compliance solutions for enterprises and hiring organisations.
Envoy is a cloud-native, high-performance edge, middle, and service proxy hosted by the Cloud Native Computing Foundation (CNCF). In the cited AI-agent security setup, it validates inbound tokens before requests reach agent code.
Istio is an open-source service mesh for integrating microservices, managing traffic, enforcing policies, and collecting telemetry with few or no service-code changes. Its control plane, Istiod, provides service discovery, configuration, and certificate management, while Envoy proxies handle service traffic and provide routing, circuit breaking, policy enforcement, and telemetry. In Ambient mesh mode, the Rust-based Ztunnel data-plane proxy provides secure connectivity and observability without sidecar proxies; the videos describe this mode as providing encrypted, mutually authenticated networking between agents and tools.
Keycloak is an open-source identity and access management system for applications and services. It provides user federation, strong authentication, user management, fine-grained authorization, and support for identity protocols including OpenID Connect and SAML; in the described agent-security context, agents can be registered as OAuth2 clients. The project can be run from its distribution or Docker image and is licensed under the Apache License 2.0.
MLflow is an open-source AI engineering platform for agents, large language models, and machine-learning models, developed in the MLflow repository. It provides experiment tracking for models, parameters, metrics, and evaluation results, along with production observability, evaluation, prompt versioning and optimization, and model lifecycle tools. Its agent and LLM observability captures application traces using OpenTelemetry and supports different LLM providers and agent frameworks; its AI Gateway provides an OpenAI-compatible interface for routing requests, managing rate limits and credentials, handling fallbacks, controlling costs, and applying guardrails. MLflow can be run as a server and accessed through Python, TypeScript/JavaScript, Java, and other programming languages, with integrations including OpenTelemetry and MCP.
OpenTelemetry is an open-source, vendor-neutral observability framework for cloud-native software. It provides APIs, SDKs, automatic-instrumentation agents, and collector services for capturing distributed traces, metrics, logs, and contextual metadata such as baggage. Its context-propagation mechanism correlates telemetry across service boundaries and carries trace identity through an application’s request path, including standard HTTP communication. The OpenTelemetry Collector receives, processes, filters, and routes telemetry to observability backends such as Jaeger, Prometheus, commercial systems, or custom solutions. It supports native SDKs for more than 12 languages and is hosted as a graduated project by the Cloud Native Computing Foundation.
Phoenix is an open-source AI observability platform developed by Arize for experimenting with, evaluating, and troubleshooting LLM applications and agents. It traces application runtime with OpenTelemetry-based instrumentation, supports response and retrieval evaluations, and provides versioned datasets, experiment tracking, prompt management, and a playground for comparing models, adjusting parameters, and replaying traced calls. Phoenix also includes PXI, an AI engineering agent for debugging traces and iterating on prompts, plus a remote MCP server for querying traces, datasets, and experiments from MCP clients. It can run locally, in containers, through Kubernetes and Helm, or in the cloud, and is distributed through the `arize-phoenix` Python package, Conda, Docker images, and related TypeScript and Python packages.
SPIFFE (Secure Production Identity Framework for Everyone) is an open framework and set of standards for assigning strongly attested cryptographic identities to software workloads across heterogeneous infrastructure, including Kubernetes, virtual machines, public clouds, and private data centers. Workloads can use these identities for authenticated service-to-service communication through X.509 or JWT-based mechanisms, including mutually authenticated TLS and zero-trust authentication without passwords or API keys. SPIRE (SPIFFE Runtime Environment) is the companion toolchain that establishes trust and issues workload identities across hosting platforms. SPIFFE and SPIRE are graduated projects of the Cloud Native Computing Foundation.
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.