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. 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. Issue certificates for ephemeral workloads.

But there is a question that almost no article answers: how does an AI agent actually receive its certificate? Which protocol handles the request, the validation and the issuance?

That gap is where ACME (Automated Certificate Management Environment) and SCEP (Simple Certificate Enrollment Protocol) fit.

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. 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 percent) rank AI agent certificates among the top three emerging trends in Public Key Infrastructure (PKI), and 35% of leading IT organizations already rank agent certificates among their top three emerging PKI trends.

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 maintains the revocation records, known as certificate revocation list (CRL) and Online Certificate Status Protocol (OCSP), that 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. 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.

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 that authenticates one agent typically grants the same permissions to any process that possesses it. If a key leaks through a configuration file, a log or a repository commit, every system that key was meant to protect is now exposed.
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.
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 solve each of these problems:

• They bind to a specific private key that never leaves the issuing environment.
• 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.

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.

AI Agent Certificate Enrollment: Which Protocol Handles It?

Determining which enrollment protocol to use for AI agent certificates depends on two variables: how the agent is deployed and which infrastructure manages it.

Three protocols handle AI agent certificate enrollment in enterprise environments: ACME, SCEP and EST. Each fits a different deployment model. See the following table for more details.

Protocol	Best Fit	Auth Model	Transport
ACME	Cloud-native, ephemeral, serverless agents	Domain validation challenge or hardware attestation	HTTPS
SCEP	MDM-managed enterprise agents (Intune, Jamf)	Shared secret or CA challenge	HTTP or HTTPS
EST	Environments preferring TLS-native enrollment over SCEP	Certificate or shared secret	HTTPS (mandatory)

The choice is not binary. An enterprise running both managed on-premises AI workloads and cloud-native agent pipelines will likely deploy both SCEP and ACME, depending on the agent type.

ACME for AI Agents

ACME was designed for automated, unattended certificate lifecycle management. A client requests a certificate, completes a validation challenge to prove control over an identifier, and receives a signed certificate. The process is fully automated, requiring no human intervention after initial configuration.

For AI agents, ACME’s automation model is a natural fit. An agent instance that starts in a cloud environment can request its certificate at startup, complete the validation challenge, receive a certificate with a defined validity period and auto-renew before expiration. When the agent terminates, the certificate expires with it. And it’s all automated, so IT teams don’t need to revoke these manually.

ACME in Production: GoDaddy’s Agent Name Service

GoDaddy’s Agent Name Service (ANS) Registry, a production system for registering and authenticating AI agents at internet scale, uses ACME DNS-01 validation as a core component of its architecture.

When an agent registers, the registration authority validates domain ownership through ACME DNS-01 challenges. The agent then receives two certificates:

1. Apublic TLS certificate for securing its HTTPS endpoint
2. Aprivate identity certificate that cryptographically binds the agent’s key to its registered identity.

This is ACME working as an AI agent enrollment protocol in production, not in a lab.

Hardware-Bound Identity With ACME Device Attestation

ACME Device Attestation extends the base ACME protocol to support hardware-bound agent identity. Instead of completing a domain challenge, the client proves that its private key was generated inside a hardware root of trust: a TPM 2.0, Apple Secure Enclave or comparable hardware security module. The CA verifies the attestation statement before issuing the certificate.

For AI agents running on verified compute infrastructure such as confidential VMs or TPM-equipped edge hardware, ACME DA provides a stronger identity anchor than domain validation alone.

This walkthrough shows ACME Device Attestation issuing an X.509 certificate against a hardware root of trust:

The IETF ACME Device Attestation extension (draft-ietf-acme-device-attest) is already in active development, with multiple CA implementations shipping support.

SCEP for AI Agents

SCEP is the right choice for AI agents deployed through an enterprise MDM or orchestration platform. It has been the standard certificate enrollment protocol for managed device fleets for over two decades. Intune, Jamf, Kandji and Google Workspace all support SCEP-based certificate deployment natively.

If an enterprise is running AI workloads on managed servers or containers that are already enrolled in an MDM, SCEP is the most direct path to certificate issuance. The MDM acts as a SCEP proxy:

• It authenticates the workload.
• It communicates with the SCEP server on the workload’s behalf.
• It delivers the signed certificate into the managed environment.

The agent does not need to handle the enrollment challenge directly.

This model works particularly well for longer-lived AI agents. Examples include:

• A managed AI service running on a corporate server
• A dedicated inference endpoint registered in Intune
• An on-premises AI gateway that needs a certificate tied to its Active Directory identity

The MDM-SCEP path integrates with existing 802.1X authentication infrastructure, so network access policy can be enforced at the same layer as agent identity.

The difference between ACME and SCEP for AI agents comes down to the management model. ACME agents are self-sovereign: they request their own certificates, complete their own challenges, and manage their own renewal lifecycle. SCEP agents are managed: the MDM or orchestration platform controls the enrollment process on their behalf. The two models are not ranked by security. They serve different deployment patterns.

The IETF Is Formalizing This Now

In June 2025, an IETF Internet-Draft (draft-huang-acme-scalable-agent-enrollment-00) was submitted proposing formal extensions to SCEP and EST specifically to address scalable certificate enrollment for agentic AI. The draft identifies a core problem where full attestation validation per request creates performance bottlenecks when thousands of ephemeral agents are spawning simultaneously.

The draft proposes two models:

1. Zero-Knowledge Proof (ZKP) attestation: Agents prove compliance with security policies using compact mathematical proofs, without revealing underlying evidence to the registration authority. The CA learns only that policies were satisfied. This provides strong privacy guarantees for multi-tenant or sensitive agent deployments.
2. Host Endorser bootstrapping: A trusted host undergoes full attestation once and receives an authorization certificate. Individual agents running on that host then request lightweight endorsements from it. The RA validates the host certificate and agent signature rather than re-running full attestation for each agent. This amortizes attestation cost across potentially thousands of short-lived agents on a single verified host.

This draft is the first IETF standardization effort specifically targeting agentic AI enrollment at scale. It signals that SCEP and EST (protocols that SecureW2 has shipped in production for managed device environments) are being extended to cover the agentic workload model.

Organizations that have already deployed certificate-based enrollment infrastructure do not need to rebuild for AI agents. The protocols are the same; the deployment scope expands.

Certificate Enrollment 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 both ACME and SCEP enrollment:

• The same PKI infrastructure can serve managed enterprise AI agents through the SCEP path and cloud-native ephemeral agents through the ACME path.
• Certificate lifecycle (issuance, renewal and revocation) is automated.
• 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.

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 JoinNow 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.

As agentic AI moves from experimental to production, certificate enrollment becomes an infrastructure requirement. The protocols exist, the IETF is standardizing the extensions and real deployments are already running. Building PKI infrastructure now puts organizations in position to scale agent identity without retrofitting it later.

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 bearer credentials: any process that possesses the token can use it. X.509 certificates require proof of possession of the corresponding private key. A stolen token can be replayed; a stolen certificate cannot authenticate without the private key. Certificates also support automated revocation through the issuing CA, whereas token revocation depends on the authorization server’s token introspection behavior.

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.

What is ACME Device Attestation?

ACME Device Attestation (ACME DA) is an extension to the ACME protocol that binds certificate issuance to verified hardware identity. Instead of completing a domain validation challenge, the client proves that its private key was generated inside a hardware root of trust (such as a TPM 2.0 or Apple Secure Enclave). This extends naturally to AI agents running on verified compute infrastructure.

What is the Agent Name Service (ANS)?

The Agent Name Service is a registry system developed by GoDaddy that provides globally unique, cryptographically verifiable identities for AI agents. Registration uses ACME DNS-01 challenges to validate domain ownership, and each registered agent receives both a public TLS certificate and a private identity certificate. The project is built on emerging IETF standards for agent identity.

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.