PKI for AI Agents: How ACME and SCEP Actually Issue Certificates

AI agents are accumulating credentials faster than most security teams can track them. API keys get embedded in configuration files, OAuth tokens get reused across agent instances and static secrets get copied into pipelines and forgotten.

GitGuardian’s 2026 research found nearly 29 million secrets leaked publicly in 2025. Additionally, there were nearly 1.3 million leaked AI service secrets — an increase of 81% year over year.

The security community’s answer is consistent. Replace static secrets with X.509 certificates, use mutual TLS for agent-to-agent communication and issue certificates for ephemeral workloads.

But how does that happen, and how does an AI agent prove it’s authorized to perform a task or access data? Here, we’ll explain how an AI agent receives its certificate and what happens when an AI agent attempts to access resources.

What Is PKI for AI Agents?

PKI for AI agents is the application of public key infrastructure to non-human identities — autonomous systems, AI assistants, workflow bots and multi-agent pipelines that need to prove who they are to other systems without a human operator in the loop. Non-human identity PKI follows the same cryptographic principles as PKI for users and devices, but the enrollment, lifecycle management and revocation workflows must run at machine speed without manual steps.

In traditional PKI, a device or user submits a certificate signing request (CSR) to a certificate authority (CA). The CA validates identity, signs the certificate and returns it. The certificate then serves as the entity’s cryptographic identity, proving possession of the corresponding private key and enabling encrypted communication and mutual authentication.

When using PKI for AI agents, the same mechanics apply. The certificate binds a public key to the agent’s identity and the machine running it. The private key never leaves the agent’s compute environment. When two agents connect via mutual TLS (mTLS), each presents its certificate. Both parties verify the other’s identity before exchanging data, so no shared secrets or bearer tokens can be intercepted and replayed.

Around a third of organizations (35%) rank AI agent certificates among the top three emerging trends in Public Key Infrastructure (PKI), and 16% are already issuing certificates for AI agents.

HID Global 2026 PKI Market Study

Components of PKI for AI Agents

A working PKI deployment for AI agents relies on five components, each handling a distinct part of issuing and managing agent identity.

Certificate Authority (CA)

The certificate authority (CA) is the trust anchor of the system. It signs the certificates issued to AI agents and publishes revocation status through a certificate revocation list (CRL) and the Online Certificate Status Protocol (OCSP), which other systems use to verify a certificate is still valid. Enterprise deployments typically use a private CA, meaning only certificates issued by that specific CA are trusted within the organization.

Registration Authority (RA)

The registration authority (RA) is the gatekeeper that verifies an agent’s identity before the CA issues a certificate. In an ACME enrollment flow, the RA validates a domain challenge or hardware attestation statement. In a SCEP flow handled through a mobile device management (MDM) platform, the MDM acts as the RA. The RA separates the identity-verification function from the certificate-signing function, allowing the CA to remain isolated.

Enrollment Protocol

The enrollment protocol defines how the agent requests a certificate and how that request is validated. ACME, SCEP and Enrollment over Secure Transport (EST) are the three protocols used in enterprise environments. The protocol choice depends on the agent’s deployment model; cloud-native agents use ACME, and MDM-managed agents use SCEP.

Certificate Lifecycle Manager

Once a certificate is issued, something must track its expiration, trigger renewal before it lapses and revoke it when the agent is decommissioned. In production PKI deployments, this is a dedicated service (or a feature of the CA platform) rather than a manual process.

Warning:Without automated lifecycle management, certificate-based agent identity breaks down as agent counts scale.

Hardware Root of Trust (Optional)

For agents running on verified compute infrastructure, a hardware security module (TPM 2.0, Apple Secure Enclave or cloud confidential computing) can generate and store the private key. This prevents key extraction even if the compute environment is compromised. ACME Device Attestation (ACME DA) uses the hardware root of trust as the identity anchor for certificate issuance.

How SecureW2 PKI for Agents Works

PKI for agents works in two phases.

Phase 1: AI System Access Control

When the user or device requests a certificate, the SecureW2 policy engine checks with the identity provider (IdP), mobile device management (MDM) platform and the endpoint detection and response (EDR) solution before issuing the certificate. If the device is not in compliance with the policies in place, the certificate isn’t issued.

The certificate is hardware-bound to the device after issuance. Even if the certificate is exfiltrated, it can only be used by the machine it was issued to, unlike an API token or other credentials, which can be re-used by threat actors.

Phase 2: Accessing the Data

The user or device presents the certificate to the SPIRE (SPIFFE Runtime Environment) server. SecureW2 CertIQ ML Anomaly Detection continuously monitors the certificate behavior against real-time signals from the MDM, IdP and EDR. If the device’s compliance status changes, the certificate is revoked immediately.

If the certificate is valid and in good standing, the SPIRE server issues a short-lived SPIFFE Verifiable Identity Document (SVID).

Note: This credential typically lasts 5-15 minutes and gives access only to the specific data source requested.

The certificate acts as a long-lived identity credential, while the SVID acts as a short-lived task credential. The AI agent needs both the certificate and the SVID running from a trusted machine in order to perform tasks or gather data.

Why API Keys and Tokens Fall Short

API keys and OAuth tokens work well for deterministic, static integrations. They fail when applied to modern agentic architectures for three reasons.

1. Static credentials have a wide blast radius. An API key or bearer token that authenticates one agent can typically be used by any process that possesses it. If a credential leaks through a configuration file, a log or a repository commit, an unauthorized process may be able to use it to access the systems that credential protects. OAuth also supports sender-constrained tokens, such as mutual-TLS-bound tokens and DPoP, which require proof of possession of a cryptographic key rather than relying solely on possession of the token.
2. Tokens are difficult to revoke cleanly. Revoking an OAuth token in a multi-agent pipeline means identifying every downstream process that may have cached that token. In an architecture with dozens of ephemeral agents spawning and terminating on demand, that inventory is often impossible to maintain. Sender-constrained tokens reduce the risk of token theft and replay, but they still require the underlying cryptographic keys to be securely managed throughout the agent’s lifecycle.
3. Static credentials do not scale to the speed of agentic workloads. An agent that spins up for 90 seconds to complete a task and then terminates needs a credential that is scoped to that task and expires with it. Issuing, rotating and revoking API keys at that cadence requires automation that most secrets management systems were not designed to provide.

X.509 certificates provide a way to establish cryptographic identity and proof of possession for these workloads:

• They bind a public key to an identity, with the corresponding private key used to prove possession.
• Revocation is handled through CRL or OCSP at the CA layer.
• Automated enrollment protocols can issue certificates in seconds with built-in expiration, so a certificate for an ephemeral agent can expire in hours or minutes with no manual cleanup required.

Sender-constrained OAuth approaches use similar cryptographic principles.

For example, RFC 8705 binds an OAuth access token to a client’s mutual-TLS certificate, while RFC 9449 (DPoP) uses a proof-of-possession key. At agent scale, managing these cryptographic identities still requires secure key storage, automated enrollment and lifecycle management, which are core capabilities of PKI.

Benefits and Challenges of PKI for AI Agents

Certificate-based identity solves real problems for agentic workloads, but deploying it comes with operational tradeoffs worth understanding before you commit.

Benefits

Certificates give AI agents several advantages that static credentials can’t match:

• Cryptographically verifiable identity: Each certificate binds a public key to a specific agent identity. No other process can impersonate the agent without access to the private key, which never leaves the issuing compute environment.
• Short-lived credentials with automated expiration: Certificate validity periods can be set to minutes or hours. Ephemeral agents receive a certificate at startup and let it expire when the task ends. No revocation workflow is needed because the credential’s lifetime matches the agent’s lifetime.
• Mutual authentication without shared secrets: In a mutual TLS (mTLS) connection, both the requesting and responding agent present certificates. Each side verifies the other’s identity before any data is exchanged. This removes the need for API key sharing between agent services.
• Revocation at the CA layer: When an agent is compromised or decommissioned, the issuing CA revokes its certificate. OCSP and CRL propagate the revocation to all relying parties without touching the agent directly.

Challenges

The tradeoffs are mostly operational rather than cryptographic:

• Enrollment infrastructure is required: PKI for AI agents only works if there is a CA, an enrollment protocol and a registration authority to validate identity before issuance. Organizations without existing PKI infrastructure face a setup cost before they can issue the first agent certificate.
• Private key protection on ephemeral compute: The certificate’s security depends entirely on the private key remaining secret. On ephemeral cloud compute without hardware security modules, protecting keys during the agent’s lifetime requires careful key management practices.
• Certificate lifecycle monitoring at scale: As agent counts grow, monitoring certificate expiration, anomalous issuance requests and unexpected certificate subjects requires dedicated tooling. Issuance automation is not enough on its own; observability is just as important.

Certificate Management for AI Agents at Scale

The infrastructure question for AI agent PKI is operational: how do you issue, rotate and revoke certificates at the pace of an agentic workload without creating a manual management burden that exceeds the security benefit?

JoinNow Dynamic PKI supports AI certificate management throughout the certificate lifecycle:

• Certificate lifecycle (issuance, renewal and revocation) is automated and based on real-time signals from IdPs, MDMs and EDRs.
• CertIQ ML Anomaly Detection monitors certificate activity for anomalous behavior: unusual issuance rates, unexpected certificate subjects or patterns that suggest a compromised agent is requesting credentials it should not have.
• Short-lived SVIDs limit access to Model Context Protocol (MCP) contexts based on group policies.

For AI agents that need to authenticate to the network, JoinNow Cloud RADIUS enforces access policy based on the certificate identity. An AI edge system connecting to a secured network segment, for example, uses the agent certificate to pass network access control at the connection layer. An agent presenting a valid certificate issued by Dynamic PKI gets access; an agent without one does not. Policy is enforced at the connection layer without requiring the agent to manage a separate set of network credentials.

Schedule a demo to see how Dynamic PKI supports ACME and SCEP certificate enrollment for both managed enterprise devices and cloud-native AI agent workloads.

---

Frequently Asked Questions

How do AI agents authenticate with other systems?

AI agents authenticate using the same mechanisms available to other non-human identities: API keys, OAuth tokens or X.509 certificates. For high-security environments and agent-to-agent communication, certificate-based mutual TLS (mTLS) provides the strongest guarantees because identity is bound to a private key that never leaves the agent’s environment.

What is the difference between OAuth tokens and certificates for AI agent authentication?

OAuth tokens are typically used to authorize access to specific resources or actions, while X.509 certificates establish a cryptographic identity and prove possession of the corresponding private key. OAuth also supports sender-constrained tokens, such as mutual-TLS-bound tokens and DPoP, which add proof of possession but require many of the same key management and PKI capabilities as certificate-based authentication.

How do digital certificates work for ephemeral AI agents?

Digital certificates for ephemeral agents are issued with a brief validity period (minutes to hours) and are not renewed after the agent terminates. The ACME protocol handles the request-issue-expire cycle automatically, so an agent can receive a fresh certificate at startup and let it expire when the task is complete. No revocation infrastructure is required because the certificate is already expired by the time any incident response would begin.

How do you manage certificates for AI agents at scale?

Certificate management at scale requires an automated enrollment protocol (ACME or SCEP), a CA with API-driven issuance, and monitoring to detect anomalous certificate activity. For enterprise AI agents deployed through an MDM, SCEP handles enrollment automatically. For cloud-native agents, ACME’s automated request-issue-renew lifecycle removes the manual overhead.

What happens if an AI agent’s device or environment is compromised after a certificate has been issued?

CertIQ ML Anomaly Detection from SecureW2 continuously monitors certificate behavior against real-time signals from the IdP, MDM and EDR. If the device’s compliance status or risk score changes, the certificate is revoked immediately through CRL or OCSP. The agent loses access within minutes instead of waiting for the next scheduled rotation or manual intervention. Since the certificate is hardware-bound, even if the certificate is exfiltrated, it can’t be used from any other machine.