Every AI Agent Needs a Certificate. Most of Them Don't Have One.

Keyfactor added something to their website last week

It's a solution page called "Secure AI Agents." Their SVP quoted in the announcement: "Every AI agent must have its own cryptographic identity, enforced through certificates and mutual TLS. Granting broad access to AI without cryptographic identity is handing over keys to your network without knowing who's driving."

When a company like Keyfactor, which sells into Fortune 500 security teams, creates a dedicated solution category for something, it means the problem is real and they've found enterprise buyers who have budget for it. That's a useful signal regardless of whether you buy their product.

What caught my attention wasn't the Keyfactor announcement itself. It was that the same week, GitGuardian published their NHI security tools roundup showing non-human identities now outnumber humans 10:1 in cloud-native organizations, and a detailed SPIFFE/SPIRE explainer landed on Substack describing how workload identity should be working. Three separate pieces from completely different perspectives, all pointing at the same gap.

The gap is this: the industry is having an animated conversation about governing machine identities that, in a large percentage of cases, were never properly issued in the first place.

The numbers are larger than you think

GitGuardian's report is worth sitting with for a moment. In cloud-native organizations, non-human identities, things like service accounts, API keys, workload tokens, machine certificates, and now AI agents, outnumber human identities by a factor of ten. That ratio has been growing for years as microservices proliferated, but AI agents are adding a new velocity to it. An LLM-based agent that orchestrates other tools or calls external APIs can generate new identity contexts at runtime, in ways that are much harder to pre-enumerate than traditional service accounts.

These numbers come from before AI agents became a significant portion of the NHI count. My guess is they look worse in 12 months.

There's also an asymmetry in how this risk distributes. Large organizations with mature security teams have SIEM tools, certificate inventory systems, and dedicated PKI engineers. They'll absorb the AI agent identity problem, probably badly at first, but eventually with some kind of structure. Mid-market organizations with a two-person security function and a stack of SaaS products are deploying AI agents right now, and their certificate infrastructure looks like a spreadsheet and three Let's Encrypt certs that get renewed when someone remembers to check the expiry date.

What "cryptographic identity" actually means for an agent

When Keyfactor says every AI agent needs a cryptographic identity, they mean something specific: the agent should have an X.509 certificate issued by a trusted CA, and the systems it talks to should verify that certificate before allowing the connection. Mutual TLS. The agent proves who it is. The server proves who it is. No ambiguity about which process is making the request.

In practice, AI agents today tend to authenticate via API keys, bearer tokens, or OAuth flows. These are not useless. But they have meaningful weaknesses when you start thinking about agents at scale. API keys don't expire automatically. They're often scoped too broadly because it's easier. They get committed to repos. They get copy-pasted into the wrong config files. Bearer tokens are better, but an agent calling twenty services with twenty different token mechanisms is a governance problem that compounds quickly.

Certificates issued by a private CA solve several of these problems at once. Short lifetimes (hours, not months) mean a compromised cert expires before it can do much damage. The CA as trust anchor means you have a single place where identity is minted and where revocation happens. And mutual TLS means the agent doesn't just present credentials, it verifies the service it's calling, which matters a lot when you're building agentic workflows where one agent is orchestrating others.

The governance trap

Most of the NHI security conversation right now is about governance. Detect rogue identities. Audit access patterns. Manage secrets. Rotate credentials. This is not wrong, but it's putting the tooling on top of a problem that should be addressed at the foundation.

If an AI agent spun up with a self-signed certificate it generated itself, or with no certificate and just an API key it sourced from an environment variable, then no governance tool can tell you with confidence what that agent is. A self-signed cert proves the agent has a private key. It doesn't prove anything about where the agent came from, who authorized it, or whether it's the same agent that was authorized last time. You're governing a shadow.

This is the issuance gap. The governance tools assume a world where identities were properly issued by some trusted authority. In a lot of real-world AI deployments, that assumption doesn't hold. The agents authenticate as best they can with whatever credentials their framework provisions by default, and then security teams try to layer audit trails and access controls on top of identities that were never rigorously established.

GitGuardian actually flags this explicitly in their NHI report: "AI agents autonomously creating identities" appears as one of the emerging threat categories. The threat isn't just that agents have identities. It's that they're creating them ad hoc, without a CA, without a policy, without a chain of custody back to something your team authorized.

What it looks like when you get this right versus wrong

The gap between these two columns isn't about tooling sophistication. It's about whether there's a CA in the picture. Governance tools, NHI platforms, CLM systems, they all work better when the identities they're managing were properly issued to begin with.

SPIFFE already solved the underlying problem

The SPIFFE (Secure Production Identity Framework For Everyone) specification was designed for exactly this problem, and it predates the current AI agent wave by several years. The core idea: every workload gets a cryptographically verifiable identity called a SPIFFE Verifiable Identity Document, or SVID. In the X.509 variant, this is a short-lived certificate (typically one hour) issued by a SPIRE Server to each workload based on an attestation process.

Attestation is the important part. The SPIRE agent running on the same host as a workload attests to the SPIRE Server that the workload is who it claims to be, using node-level evidence (the underlying platform identity, kernel attributes, cloud instance metadata). The SPIRE Server evaluates the attestation against policy and, if it passes, issues a short-lived X.509-SVID. The workload can then use that cert for mTLS with other services that trust the same SPIRE root.

This is the architecture that Keyfactor is gesturing at when they talk about AI agent identity. SPIFFE/SPIRE is the workload identity standard most AI agent deployments are currently ignoring, partly because it takes effort to set up, and partly because the AI agent frameworks themselves don't yet have first-class SPIFFE support.

But here's the critical detail buried in the SPIFFE/SPIRE architecture: the SPIRE Server either operates as a CA itself, or it delegates to one. The X.509-SVIDs it issues have to come from somewhere in a trust hierarchy. For organizations that don't have a PKI team, that "somewhere" is the hard part. Running SPIRE on top of a well-managed private CA is the right architecture. Running SPIRE with a self-managed intermediate CA that nobody is watching is how you end up with the same institutional memory problems that cause CRL expirations to take down production MFA systems (yes, this happened, in r/sysadmin, in March).

Why this is a CA problem, not a CLM problem

Certificate lifecycle management tools are great at tracking and renewing certificates that already exist. They're not the layer that decides whether a new identity gets issued at all. A CLM platform can tell you that an agent's cert is expiring in 48 hours. It cannot tell you whether that agent should have been issued a cert in the first place, under what policy, for what purpose, scoped to what services.

That's issuance policy. And issuance policy is a CA problem. The CA is where you define what identities exist in your trust domain, what they're authorized to do, how long they're valid, and under what conditions they get revoked. CLM tools operate downstream of those decisions.

For enterprises with a mature PKI practice, this distinction is obvious. For organizations that have been getting by with Let's Encrypt and a few self-signed certs, it's not. They've never had to think about issuance policy because they've been outsourcing the trust decision to a public CA, which handles it automatically by only issuing server authentication certificates for domains you control via DNS. Simple. Scalable. Works fine until you need client authentication, or short-lived workload certs, or AI agent identity.

The private CA is the piece that fills the issuance layer for everything public trust doesn't cover. Not just for legacy internal services. For AI agents, for service mesh workloads, for IoT devices, for API gateways, for any identity that doesn't need to be trusted by a browser but does need to be trusted by your own systems.

Where we are in this cycle

The conversation about AI agent identity is about 18 months behind where it should be. Organizations are deploying agents now. The identity question is being deferred or patched over with API keys and best-effort token management. When the agents are small in number and low in privilege, this is fine. When an organization has dozens of agents with broad access to internal APIs, the patched-over identity model is a liability.

The good news is that the architecture is well understood. SPIFFE/SPIRE has been production-tested at companies like Uber and GitHub. The X.509-SVID model works. Short-lived mTLS certs from a private CA work. The pieces exist. What's missing for most mid-market organizations is the accessible entry point: a private CA that doesn't require a PKI engineer to operate, that supports ACME and can serve as the trust anchor for a SPIRE deployment.

Enterprise vendors like Keyfactor are staking out this territory from the top. They're right about the problem. Their solution involves a multi-year engagement, a six-figure contract, and an implementation partner. That's not the path for a company with 200 engineers and a two-person security team that wants to do this correctly.

The AI agent identity problem is going to get noisier before it gets quieter. My guess is the first major public incident of an AI agent being impersonated or its traffic intercepted because it lacked proper mTLS will accelerate things considerably. Until then, the organizations that build the CA layer now are the ones that won't be scrambling later.

And to be concrete about what "build the CA layer now" means: it means having a private CA that can issue short-lived certificates via ACME to services and agents, that has its root distributed to your internal trust stores, and that has OCSP or CRL infrastructure so revocation actually works. That's the minimum viable version. The rest, SPIFFE integration, policy-based issuance, agent attestation workflows, builds on top of that foundation. You cannot skip the foundation.