A quiet problem is spreading across teams running AI agents on Kubernetes in production: the API key mechanisms built for human engineers are simply being reused for AI agent authentication. Sooner or later, this approach breaks down. This article explains why static secrets hit their limit when running MCP (Model Context Protocol) servers on Kubernetes, and how a "keyless" authentication design combining Keycloak and SPIFFE/SPIRE can become a practical solution.
Why You Shouldn't Hand AI Agents "Keys"
Human engineer authentication has always assumed a model where a person logs in a few times a day, entering passwords and MFA each time. Under that assumption, covering the leak risk of secrets mostly meant protecting a small number of accounts that log in occasionally.
AI agents break this assumption. A single agent can call APIs dozens of times per second, and new agent instances spin up and down dynamically depending on the task. Login patterns that would look suspicious for a human become hard to distinguish once buried in agent-to-agent calls.
Across the industry, a growing argument holds that AI agents should be treated as a new, third identity category — neither a "human user" nor a traditional "non-human workload" (such as a service account). In fact, "identity and privilege abuse" involving AI agents is ranked among the top security concerns for agentic applications (AI Agent Identity Management: A 2026 CISO Playbook).
Typical Failure Patterns Caused by Static Secrets
- Expanding blast radius: A single API key gets reused across multiple agents and tasks, making the impact of a leak unpredictable
- Rotation in name only: Keys go un-rotated because "it's working, so nobody wants to touch it"
- Missing audit trail: Logs record "which key" was used rather than "who" used it, making root-cause tracing difficult afterward
In a managed K3s environment, how you systematize certificate and secret lifecycle management is an unavoidable theme. Managed K3s services like Kubo ship with cert-manager built in by default, so certificate issuance and renewal are already wired in from the start.
Why Static Secrets Hit Their Limit in MCP Server Authentication
MCP (Model Context Protocol) is an open standard that lets LLM-based AI agents connect to external tools and APIs. The official MCP specification defines that a protected MCP server acts as an OAuth 2.1 resource server, responsible for validating access tokens (Model Context Protocol Authorization Specification).
The problem is that teams often plug traditional "long-lived client secrets" straight into this OAuth client authentication step. Client secrets are inherently static shared information that is "rarely rotated," and they constantly carry the risk of leaking through human error — accidentally copied into logs or config files (Authenticating MCP OAuth Clients With SPIFFE and SPIRE).
MCP servers also carry risks of their own: "tool poisoning," where malicious instructions are embedded in tool descriptions, and cases where a tool's behavior is quietly rewritten after approval. As a practical defense against these risks, a "two-pillar" approach has been proposed: replacing static tokens with short-lived, narrowly scoped access tokens under OAuth 2.0-based authentication, combined with fine-grained, per-tool authorization (Securing MCP Servers: A Comprehensive Guide).
In other words, designing MCP server authentication as "hand out a static secret and call it done" carries a structural flaw whose failure probability rises as the number of agents grows.
A "Keyless" Design Using Keycloak, SPIFFE/SPIRE, and OPA
The practical answer to this problem is a design that anchors authentication in the workload's own cryptographic identity, instead of a static secret.
SPIFFE (Secure Production Identity Framework For Everyone — a standard specification for issuing cryptographic identities even to non-human workloads) is a CNCF Graduated project for workload identity, and SPIRE is the runtime that implements it. Each workload is issued a short-lived, verifiable identifier (an SVID), and SPIRE automatically manages its lifecycle — issuance, verification, and rotation (SPIRE Concepts | SPIFFE official documentation).
Implementations that combine this mechanism with Keycloak are also taking shape. In a 2026 release, Keycloak shipped Federated Client Authentication as a preview feature, letting Kubernetes ServiceAccount tokens be used as client authentication credentials in place of static secrets (Keycloak 26.5.0 released). Beyond that, a custom authentication extension built on Keycloak's SPI model to validate SPIRE-issued JWT SVIDs has also been demonstrated, letting MCP clients complete OAuth authentication using only "short-lived, automatically rotated" credentials (Authenticating MCP OAuth Clients With SPIFFE and SPIRE).
Once authentication (who is calling) is established, you still need authorization (what they're allowed to do). This is where Open Policy Agent (OPA) comes in. OPA goes beyond Kubernetes admission control — it's a general-purpose policy engine widely adopted across the CNCF ecosystem for handling authorization decisions in API servers and applications through a declarative policy language (Open Policy Agent official documentation).
Structuring this as a three-layer stack — "SPIRE (identity issuance) → Keycloak (token exchange/authentication) → OPA (authorization decision)" — makes it possible to achieve "keyless" MCP agent authentication that distributes no static keys anywhere. Indeed, industry discussion is increasingly setting an explicit design goal of driving static credential files, and manually created Keycloak clients, down to zero (KeycloakCon Japan 2026: Navigating cloud native identity and the AI frontier | CNCF).
When putting this architecture into practice on a managed K3s environment, the operational key is whether you can make certificate and token lifecycles visible across the cluster. Kubo Cloud comes with a Rancher-based management layer, and its ability to surface certificate- and identity-related state across multiple clusters pairs well with this kind of zero-trust design.
Do We Really Need a "New Identity Platform Built Just for AI Agents"?
As AI agents rise in prominence, the argument that "we need a brand-new identity platform built specifically for agents" is also gaining traction. But this claim is only half right.
Authentication, authorization, audit trails, and permission delegation are themselves classic problems that the identity industry has grappled with for years — AI agents haven't fundamentally changed them. The real challenge instead arises as the "chain of authority" grows longer — human → agent → another agent → API — and whether impersonation can still be detected if it happens at some link along that chain.
One mechanism drawing attention in this context is "Identity Assertion JWT Authorization Grants (ID-JAG)," which safely handles chains of token delegation, discussed as a countermeasure to the "Confused Deputy" problem, where authority ends up in the hands of an unintended party (KeycloakCon Japan 2026: Navigating cloud native identity and the AI frontier | CNCF). On MCP governance too, a view is gaining ground that a combination of existing standard technologies — OAuth 2.0 token delegation, token exchange, and fine-grained scope control — can already reach a "production-ready" bar.
In other words, before building a dedicated platform from scratch, it's well worth considering the approach of extending an existing identity platform like Keycloak with SPIFFE/SPIRE and OPA. For industries with strict data sovereignty or audit requirements, an option like Kubo On-Premise — where you keep the entire authentication foundation under your own management — becomes a realistic fallback in this context.
Conclusion
The more AI agent operations scale into production, the more quietly — but surely — mistakes in authentication design come back to bite you. Rather than simply carrying over static-secret operations built for humans, it's important to build in from the start a "keyless" design where SPIFFE/SPIRE cryptographically issues workload identity, and Keycloak and OPA separately handle authentication and authorization.
Running AI agents as full-fledged members of an organization in production requires robust infrastructure that includes this kind of authentication foundation. The idea of safely running an AI agent execution platform like Captain.AI on top of Kubo's K3s-based managed Kubernetes foundation is only going to grow more important as an infrastructure strategy for the AI era.