Overview
This video demonstrates how NetFoundry secures artificial intelligence (AI) agents’ access to Model Context Protocol (MCP) tools and Large Language Model (LLM) services. Senior Sales Engineer Sheik Ahmed explains that traditional security falls short at both the connectivity layer, which relies on IP addresses rather than workload identity, and the application layer, which often uses vulnerable static API keys. To solve this, NetFoundry leverages SPIRE to provision short-lived, automatically rotated cryptographic identities (SVIDs) for AI workloads. These identities authenticate the agent at the network level and enable the MCP server to independently verify the workload through mutual TLS, effectively unifying zero-trust security across both layers and eliminating exposed inbound ports.
Key Takeaways
- Vulnerabilities in Traditional Security: Traditional security methods are insufficient for AI workloads because network layers rely on connection sources (like IPs) instead of identifying the actual workload, while application layers depend on static, easily compromised credentials like bearer tokens and API keys.
- SPIRE-Based Workload Identity: NetFoundry utilizes the SPIFFE/SPIRE framework to assign short-lived, cryptographically verifiable identities (SVIDs) to AI agents. This ensures that there are no long-lived credentials available to be stolen or reused elsewhere.
- Unified Zero-Trust Verification: The architecture uses a single identity to secure both network access and application-level authentication. The MCP server independently verifies the AI agent’s identity via mutual TLS before granting access, significantly reducing the attack surface alongside dedicated NetFoundry MCP and LLM gateways that provide routing, load balancing, and centralized visibility.
FAQs
Frequently Asked Questions
- What are the primary security vulnerabilities for AI agents accessing MCP tools and LLMs? Security breaks down at two levels: the connectivity layer and the application layer. The connectivity layer relies on IP addresses, ports, and firewalls, which identify a connection’s source but not the specific workload making the request. The application layer relies on static credentials like API keys or bearer tokens, which can be stolen and reused, offering no strong assurance of the live workload’s actual identity.
- How does NetFoundry secure AI agent connectivity? NetFoundry uses an identity-first, zero-trust network platform that grants AI workloads policy-based, least-privilege access. Instead of relying on IP addresses or static keys, it requires continuous cryptographic identity verification before network connectivity is ever established.
- What is SPIRE’s role in this zero-trust architecture? SPIRE is a workload identity framework that implements the SPIFFE standard. It acts as the Certificate Authority (CA) and provides AI agents with cryptographically verifiable, short-lived identities known as SVIDs. Because these identities automatically rotate, they eliminate the risk of long-lived credentials being compromised or reused.
- How is the AI agent authenticated at the application layer? Once network access is granted, the AI agent presents its SPIRE-issued SVID directly to the MCP server. The server independently verifies the workload through mutual TLS, enforcing a secondary, distinct security check at the application layer before any tool access is allowed.
- What are the operational benefits of the NetFoundry MCP and LLM gateways? These purpose-built gateways eliminate exposed inbound network ports, significantly reducing the attack surface. The MCP gateway handles tool aggregation, filtering, and session isolation, while the LLM gateway provides OpenAI-compatible semantic routing, load balancing, and full open telemetry metrics to ensure centralized visibility and control over all AI interactions.
Full Transcription
Hi everyone, I’m Sheik Ahmed, I’m the Senior Sales Engineer here at NetFoundry.
I work on solutions around identity first, zero trust connectivity, particularly how we can apply these concepts to secure modern applications and AI environments.
Today, I’m going to walk you through a demo that looks at how NetFoundry secures an AI agent’s access to MCP tools and LLM services using SPIRE-based workload identity.
The scenario is an AI agent that needs to communicate with two different types of services, that is, LLMs and MCP-based tools.
We will establish an identity for the AI agent and use the same identity consistently across the connectivity and the service access layers. So before getting into the architecture, let’s start with the actual problem statement.
When we look at securing access to MCP tools and LLMs for an AI agent, there are really two layers where zero trust connectivity breaks down.
The first is the connectivity layer, traditionally secured with IP addresses, ports, firewalls, or VPNs.
That tells us where the connection is coming from, but it does not really tell us which AI workload is making the connection.
The second is the application layer, which traditionally relies on static API keys, bearer tokens, or service credentials to authorize access.
But possession of these credentials doesn’t necessarily give us strong assurance about the live workload presenting it.
And if that credential is compromised, it can be potentially reused elsewhere.
So these two layers operate independently, and neither one is actually zero trust.
The network knows that something is allowed to connect, and the application knows that something has a valid credential.
But nothing verifies who or what is actually behind either one.
The question then becomes, how do we establish a strong workload identity and use that identity consistently to secure both the connection and the service access to the tools?
That is the way the zero trust framework actually requires.
Today let’s look into a solution that establishes identity-first connectivity with NetFoundry, leveraging SPIRE to provide the CA trust as well as workload identity.
NetFoundry is an identity-first, zero trust networking platform that provides AI agents and workloads secure, policy-based, least privilege access to the tools and services they need.
SPIRE is a workload identity framework that implements the SPIFFE standard, providing cryptographically verifiable identities to workloads through SVIDs.
Those identities are short-lived and automatically rotated, so there is no long-lived credential sitting around waiting to be stolen or reused.
Now here is how the two come together.
The AI agent requests access to the protected services or MCP tools.
The security or the platform team approves the access.
The AI agent receives a SPIRE-issued SVID.
NetFoundry leverages that SVID and SPIRE’s CA trust to authenticate the AI agent.
Then, the NetFoundry service and the service policy provides secure access for the AI agent to the MCP server.
And we can take that identity one step further.
When the AI agent connects to an MCP service, it presents the same SPIRE-issued SVID again.
The MCP server independently verifies the workload through mutual TLS, a second separate check at the application layer before any tool access is granted.
So at a high level, we are bringing together three things:
A strong workload identity from SPIRE, identity-first connectivity from NetFoundry, and independent identity verification at the service access layer.
And the key part is, it is the same SVID doing the work at both layers.
Now let me show you how this works in practice.
We start with the AI agent requesting access to the protected services or MCP tools.
At this point, there is no active SPIRE identity associated with the agent.
So the agent does not yet have access to protected MCP tools, firstly at the network layer and then at the application layer.
The request is then presented to the security or the platform team for approval.
The team reviews the request and approves the access.
Now, we provide the agent identity a name.
And at the back end, SPIRE establishes the identity and issues an SVID for that agent, at the same time, the approve action explicitly calls NetFoundry’s API to create a matching NetFoundry identity for that AI agent.
NetFoundry also supports automatic identity creation as a part of this workflow, as soon as the SPIRE identity is created.
So at this point, for the AI agent, we have a real SPIRE identity and a matching NetFoundry identity.
Now let’s verify the identity.
Here we can see the SPIFFE ID from the SPIRE-issued SVID along with the corresponding NetFoundry identity.
There are actually two distinct things happening here.
The first is access governance:
NetFoundry uses that SVID to decide at the network layer which tools and services the specific AI agent is even allowed to reach.
That’s enforced through NetFoundry services and service policies.
The second is the authentication to the application itself.
The AI agent presents the same SVID again, this time directly to the MCP server, which independently verifies it through mutual TLS before honoring any tool call.
That’s a different check at a different layer.
Now let’s access the calculator MCP tool.
Let’s stop and actually look at what just happened.
A minute ago, this AI agent had no access—firstly at the network and then at the application layer at all.
Now it can reach the MCP tool because it is allowed the connection over the NetFoundry zero trust network, authenticated with the SVID, and then the MCP server authenticating the AI agent for tool access with the same SVID.
That’s the whole story: one identity enforced at both layers.
We also have service and service policy for the AI agent to access LLMs over the NetFoundry zero trust network.
So what we have demonstrated is the complete trust chain.
NetFoundry provides identity-first connectivity, leveraging SPIRE as the CA and as a workload identity source.
The MCP server can then independently authenticate the AI agent using that same identity.
NetFoundry offers a comprehensive zero trust approach for securing AI enclaves.
The foundation is identity-first connectivity, where AI workloads are authenticated before connectivity is established.
And the policy is enforced to achieve least privilege access.
This significantly reduces the attack surface by eliminating exposed inbound ports and limiting each workload’s reachability to only the specific service it’s explicitly authorized for.
On top of that, we have purpose-built gateways for exactly the two things an AI agent needs.
The NetFoundry MCP gateway handles aggregation and namespacing across tools, tool filtering, and per-client session isolation.
Then, the NetFoundry LLM gateway gives you OpenAI-compatible routing across multiple providers, semantic routing, load balancing, and full open telemetry metrics.
And across all of it, you get centralized visibility and control.
You always know which AI workload is accessing which service, with one consistent policy model enforcing it.
Thank you.