S02 E09 - SPIFFE Identity for AI Agents on Kubernetes

Matt Barker is betting on SPIFFE for AI agent identity on Kubernetes. He previously co-founded Jetstack and built cert-manager, which is the tool most Kubernetes clusters use to manage TLS certificates (it has more than 5 million downloads per day, and Barker estimates that it runs in more than 80% of Kubernetes clusters he sees). After cert-manager, Barker moved to identity, specifically the Secure Production Identity Framework for Everyone (SPIFFE); he also ran secure workload access at CyberArk before it was acquired by Palo Alto Networks. 

Now he's building BoltMCP with a business partner, Dan Kwiatkowski, to answer a narrower question: if the real value of an agent is wrapped up in what data and systems it can reach, how do we handle trust around the agent?

This is a surprisingly broad question, but it starts with a problem platform teams already know well: secrets sprawl. AI agents just make it worse, faster.

The secrets sprawl problem AI agents inherited

GitGuardian's State of Secrets Sprawl report for 2026 found nearly 29 million secrets leaked on GitHub in a year, up from about 24 million the year before, close to 21% growth. Developers working on applications might hardcode secrets like API keys into the source repo or put them into a vault and ignore them, leaving them unmanaged until the security team notices or something goes wrong. “I realized ten years ago developers hated certs because they always expired and they ended up killing applications," says Barker, "They also hate secrets because they get leaked… so let’s get rid of those."

AI agents raise the stakes – the same report for 2025 notes that AI-generated code is roughly 40% more likely to leak a secret than hand-written code. This is partly because it's harder to audit what's happening in generated code, says Barker, and partly because a much wider set of people (including non-engineers using tools like Replit or Lovable) are now shipping backend code without knowing what an API key is or how it's supposed to be handled. 

Barker pointed to one dramatic example: The founder of moltbook (vibe-coded with OpenClaw) said, it's great because he didn't even write one line of code…but that founder also left a database open and leaked 1.5 million API keys, plus emails and passwords.

Why SPIFFE beats another secret store for workload identity

The standard fix for secrets sprawl has been centralizing them: a vault, better rotation, tighter access policy. Barker thinks that the real issue is that a long-lived secret exists at all. Instead, SPIFFE replaces the static secret with a short-lived, cryptographically backed identity: a workload gets an identity just long enough to talk to the resource it needs, then the identity expires. This avoids the security issues of long-lived static credentials entirely, and dovetails nicely with zero trust and mutual TLS: instead of defending just at the perimeter, defend everywhere.

SPIFFE works really well for this kind of identity: it’s been running in production for years at companies like Uber, ByteDance (TikTok), and Bloomberg. But retrofitting an SPIFFE into an existing application is difficult: the application itself needs to be modified to be SPIFFE-aware, meaning that someone has to go in and carefully change the code.

AI agents, though, are greenfield code, which means that there’s a great opportunity to build SPIFFE in from the beginning, sidestepping the cost of retrofitting. Barker's read is that this is the actual reason SPIFFE is getting renewed attention now: not because the identity problem changed, but because AI agents finally created a reason for security teams to prioritize solving it at the same time as providing the opportunity to make the solution straightforward.

Workload identity is not the whole problem

SPIFFE doesn’t handle the whole identity problem, though. Barker draws a line between workload identity and human identity. On the workload side, irrespective of whether you’re working with physical or virtual hardware, ultimately you end up needing to identify workloads: instances of code running on the machine. At this level, an AI agent is ultimately just another workload, and SPIFFE handles workload identity very well.

However, AI agents can also act on behalf of a human user. SPIFFE was never meant to be used for human identity, much less the kind of on-behalf-of authorization that’s important for agents. That’s being worked on separately, largely through OAuth-based flows and newer proposals around delegated authorization scopes, and it’s a fundamental aspect of what BoltMCP is tackling.

What BoltMCP builds: API translation plus context authorization

BoltMCP is built around the idea that AI agents are only as valuable as the data and systems they can reach. Providing that reach safely runs headlong into both machine and human identity and the on-behalf-of problem, leaving BoltMCP with two jobs: translate existing APIs into a format an agent can use efficiently through the Model Context Protocol (MCP) and apply governance and authorization controls to the context that gets returned. (Barker is explicit that BoltMCP isn't trying to compete with identity providers on either the workload or the human-delegation side; instead, it's building on top of both.)

Efficiently using resources matters more than it might sound: what Barker sees in the wild is that it’s very simple to connect an MCP to a given resource, but to do so consistently and at scale can be very difficult. In Barker's words, getting consistency and cooperation across even “a few MCP servers is incredibly hard. In fact, it’s almost not even possible.”

For example, an agent using an API that’s not designed for efficient MCP use can end up with the agent being handed an entire folder of documentation to answer one specific question. This is the “context window flooding” problem: the agent has to burn tokens and attention hunting for the one fact it needs, and the user gets a degraded response. BoltMCP has found that shaping API responses so that an agent gets the specific answer at the specific moment it needs it, not an entire dataset to sort through, is a critical part of providing MCP access in the real world.

These concerns around efficiency and safety aren’t just academic, either: Barker sees boards and CEOs pushing AI adoption because they see falling behind a competitor who gets AI right as an existential problem, making it more important to provide safety for CISOs and security departments pushed to enable AI adoption irrespective of risk. “I don't think that the results of the industry show the productivity gains yet with AI agents or AI generally,” he acknowledges. “But I think we can all feel and see that done in the right way, it's going to be tremendously powerful and productive.”

Kubernetes as AI agent infrastructure

Barker's read on Kubernetes' role in AI infrastructure has, of course, evolved over time: where he originally saw companies like OpenAI directly using Kubernetes for training and inference, what he sees now is that a lot of agent consumption happens through fully abstracted products like Claude Code, Salesforce Agentforce, or ServiceNow, where the infrastructure is invisible to the end user.

However, Barker expects that token economics, data sovereignty, and a simple desire to keep more control of their data or their IP will push AI users to bring the AI implementation back into their own clusters. He notes that we’ve seen much the same thing with SaaS platforms already, where Kubernetes became a primitive to build on rather than just a hidden piece of infrastructure for SaaS vendors – and in that world, open-source AI will be an important foundation.

What this means if you run Kubernetes today

Barker recommends platform engineers and SREs watching this from the outside to start learning more about AI. A good starting point is whatever the Linux Foundation has already blessed, since these projects are more likely to be Kubernetes-native by default. This obviously includes CNCF projects, but it’s also worth keeping an eye on the newly formed Agentic AI Foundation (AAIF), for example, MCP itself was recently donated to the AAIF.

“The knowledge that you've got from building and running cloud native infrastructure is going to become very valuable as we start to build and manage and run a lot of these agentic frameworks on-prem," Barker notes. Skills like running Kubernetes in production, understanding failure modes, or building internal platforms that other teams actually adopt aren’t going to go away now that agents are here. If you can connect what you know from being a Kubernetes engineer to what the business needs and help them shorten that feedback loop between business outcomes and the technology on Kubernetes, “that's when you become super, super valuable,” Barker adds. 

FAQ

What is SPIFFE, and why does it matter for AI agents?

SPIFFE gives workloads a short-lived, cryptographic identity built on X.509 PKI, so nothing has to store a long-lived secret. Since AI agents are greenfield code, they sidestep the cost of retrofitting applications to be SPIFFE-aware, which is why Barker sees this as SPIFFE's moment.

How is SPIFFE different from a secrets manager like HashiCorp Vault?

A secret manager like Vault stores and rotates long-lived secrets. SPIFFE skips the secret entirely: a workload gets a short-lived identity for the moment it needs to talk to something, then it expires. Nothing sits around waiting to be leaked.

Does SPIFFE handle authorization when an agent acts on a human's behalf?

No. SPIFFE proves workload identity, not delegated human intent. On-behalf-of authorization runs through separate OAuth-based flows, which BoltMCP builds on top of rather than replaces.

What does BoltMCP actually do?

BoltMCP translates existing APIs into a format AI agents can efficiently use through MCP (Model Context Protocol), then applies governance and authorization to control what context an agent gets back at query time.

Why does Barker think Kubernetes stays central to AI agent infrastructure?

As we’ve seen with other SaaS platforms, Barker expects more enterprises to build agent frameworks on Kubernetes-based platforms as data sovereignty and model control become bigger priorities.