PKIaaS for AI Infrastructure and AI Agents

AI agents are no longer hypothetical. They are being deployed in production environments in 2026 to automate workflows, execute API calls, modify configurations, trigger transactions, and interact with critical systems at machine speed and scale. A single agentic AI workflow may involve five or more agents passing tasks between each other, calling external APIs, reading from databases, and writing to records, all without a human in the loop at each step.

The security question that most organizations deploying these systems have not fully answered is: how do you know which agent did what, and how do you prove it? Most AI agents today authenticate to APIs and services using static credentials: API keys, client secrets, shared tokens. These credentials carry no identity claim beyond their string value. They can be copied. They do not expire automatically. They provide no audit trail that binds a specific action to a specific agent instance. And according to the 2025 IBM Cost of a Data Breach Report, 97% of organizations that experienced breaches involving AI models lacked AI access controls.

The answer to the AI agent identity problem is the same answer that solved the machine identity problem for servers, devices, and workloads: cryptographic identity backed by a governed certificate authority. PKI as a Service provides the CA infrastructure that issues unique, short-lived, verifiable identities to AI agents, enabling mTLS for agent-to-service communication, certificate-anchored OAuth for delegation chains, and an audit trail that makes every agent action cryptographically attributable to a specific identity.

Quick Answer: What Does PKIaaS Do for AI Agent Identity?

PKIaaS issues each AI agent a unique X.509 certificate encoding the agent’s identity (its name, type, deployment environment, authorized scope, and issuing organization). The certificate is short-lived (minutes to hours for ephemeral agents; 24 to 48 hours for persistent agents), automatically rotated by the identity infrastructure, and signed by the PKIaaS CA whose root is in the trust bundle of every service the agent calls. When the agent makes an API call, it presents the certificate; the service verifies it against the PKIaaS root CA; and the connection proceeds only if verification succeeds. Every certificate issuance is logged in the PKIaaS audit log, providing a cryptographically attributable record of which agent was active during which time window and which actions it was authorized to take.

Key Takeaways

• Static credentials (API keys, client secrets, shared tokens) cannot provide accountability for AI agents. They carry no identity claim beyond their string value, can be copied and shared across agents, do not expire automatically, and produce no audit trail that binds a specific action to a specific agent instance. Certificate-based agent identity provides all of these properties structurally, not through policy that can be bypassed.
• Even ephemeral AI agents launched for a single task deserve a unique cryptographic identity. A certificate with a 30-minute validity period issued to a short-lived agent means that if the certificate is somehow extracted, it is useless within 30 minutes. The same API key given to the same short-lived agent is valid until someone manually rotates it, which may be never.
• The delegation chain problem is the hardest unsolved identity problem in agentic AI. When Agent A invokes Agent B, which calls a tool, which triggers a transaction, every hop in that chain must be cryptographically provable back to an accountable human or principal. Certificate-based identity combined with OAuth 2.0 Token Exchange (RFC 8693) anchored to those certificates provides the technical mechanism for a verifiable delegation chain.
• mTLS for agent-to-service communication is the AI equivalent of Zero Trust for workloads. An AI agent presenting a PKIaaS-issued certificate to an API is verified cryptographically before any application-level request is processed. An agent without a valid PKIaaS certificate is rejected at the TLS layer, regardless of whether it claims to be an authorized agent in the application payload.
• The regulatory environment for AI agent identity is moving. NIST’s NCCoE published a concept paper in 2026 on software and AI agent identity and authorization. The ITU has established a focus group on AI agent trust and identity. The EU AI Act’s accountability and human oversight requirements create implicit auditability obligations for agentic AI systems. Certificate-based identity is the most mature technical mechanism for satisfying these emerging requirements.

The AI Agent Identity Problem

AI agents differ from traditional software in one critical security dimension: they act autonomously. A web server serves requests; it does not initiate them. An AI agent does both. It receives a goal, reasons about how to achieve it, and takes actions across multiple systems, APIs, and tools in sequence, without human authorization at each step. The authority to take those actions was delegated to the agent at deployment time, and the controls on what the agent can do are typically coarse-grained: an API key with broad scope, a service account with wide permissions, or a system-level access token that was never scoped for the specific agent’s task.

This creates an identity and accountability gap that grows with scale. When an organization deploys ten AI agents, the gap is manageable: someone knows what each agent has access to. When the same organization deploys a thousand agents across dozens of workflows, no one can reliably answer: which agent made that API call at 2:47 AM? Was it authorized to do so? How do I prove that the action was taken by Agent A and not by someone who obtained Agent A’s credentials?

The Palo Alto Networks 2026 Identity Security Landscape report found a 109:1 ratio of machine identities to human identities in enterprise environments. AI agents are the fastest-growing component of that machine identity population. Managing their identity with the same static credential model used for early enterprise software is not a security posture; it is a liability accumulation program.

Why Static Credentials Fail for AI Agents

Static credentials fail for AI agents for the same reasons they fail for any machine identity, magnified by the autonomous nature of agent behavior:

No identity binding. An API key proves that the caller possesses the key, not that the caller is the authorized agent. If the key is extracted from the agent’s environment, any process with the key is indistinguishable from the agent. In an environment where agents interact with other agents (passing context, delegating subtasks, sharing temporary access), the opportunity for credential exfiltration multiplies with each agent-to-agent interaction.

No automatic expiry. API keys do not expire unless someone explicitly rotates them. An AI agent that is decommissioned leaves its API key valid until the operations team notices and revokes it. In a fast-moving environment where agents are provisioned and deprovisioned for specific tasks, the orphaned credential problem accumulates rapidly. A certificate issued to an agent with a 4-hour validity period expires with the agent, producing no orphaned credential and no cleanup obligation.

No non-repudiation. If an AI agent causes damage by calling an API it should not have called, or by triggering a transaction with incorrect parameters, the API key in the audit log does not conclusively identify which agent made the call if the key was shared or if the key’s custody was not tracked. An X.509 certificate with a specific serial number, issued to a specific agent deployment, provides non-repudiation: the audit log entry references the certificate, the PKIaaS audit log records when the certificate was issued and to which agent identity, and the chain of attribution is cryptographically complete.

X.509 Certificates as AI Agent Identity

An X.509 certificate issued by a PKIaaS CA to an AI agent encodes the agent’s identity in a cryptographically verifiable, standardized format. The certificate’s Subject Distinguished Name and Subject Alternative Name fields carry the agent’s identity attributes. A well-designed agent identity certificate might encode:

• CN (Common Name): The agent’s name and version identifier (for example, order-processing-agent-v2.1)
• O (Organization): The business unit or team that owns the agent
• OU (Organizational Unit): The deployment environment (production, staging, sandbox)
• URI SAN: A SPIFFE ID if the agent is deployed in a SPIFFE-compliant environment (spiffe://trust-domain/agents/order-processing)
• Custom OID extensions: Agent version, authorized workflow scope, or deployment ID in custom X.509 extensions if the agent authorization model requires policy attributes in the certificate

The certificate is signed by the PKIaaS CA, making it verifiable by any service that has the PKIaaS root CA certificate in its trust bundle. The private key corresponding to the certificate is generated in the agent’s execution environment and never leaves it. The PKIaaS CA signs the certificate based on the agent’s CSR (Certificate Signing Request), which contains the public key. The private key never passes through the PKIaaS CA, the secrets manager, or any shared infrastructure; it lives only in the agent’s secure memory for the duration of the certificate’s validity.

Agent Identity Provisioning at Launch

The agent identity provisioning flow operates as follows. When an agent is launched (whether as a container in Kubernetes, a serverless function, a process on a virtual machine, or an ephemeral compute job), the provisioning step requests a certificate from the PKIaaS CA. The request is authenticated using one of several mechanisms:

• OIDC token exchange: The AI orchestration platform issues the agent a short-lived OIDC token at launch time. The agent presents this token to the PKIaaS ACME endpoint (with External Account Binding) and receives a certificate in exchange. GitHub Actions, GitLab CI, AWS STS, Azure AD Workload Identity, and GCP Workload Identity all issue OIDC tokens that can serve this purpose. The OIDC token is the bootstrap credential; the certificate is the operational credential the agent uses for its actual work.
• Platform attestation: In Kubernetes environments, SPIRE attests the agent’s pod identity using Kubernetes node attestation and pod selectors, then issues an SVID (SPIFFE Verifiable Identity Document) to the agent directly through the SPIFFE Workload API. With PKIaaS as the SPIRE upstream CA, this SVID chains to the PKIaaS root.
• Secrets manager bootstrap: For agents not in Kubernetes, an authorized secrets manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) holds a one-time enrollment credential that the agent uses to authenticate its first certificate request. The enrollment credential is consumed on use and the agent’s subsequent operations use the issued certificate.

mTLS for Agent-to-Service and Agent-to-Agent Communication

Once an agent has a PKIaaS-issued certificate, it uses that certificate for mutual TLS authentication with every service it calls. mTLS for agent-to-service communication provides two security properties that static credentials cannot:

Service verification by the agent: The agent verifies the service’s TLS certificate against the PKIaaS root CA trust bundle before sending any data. An AI agent calling a spoofed API endpoint (a man-in-the-middle attack intended to exfiltrate agent context or manipulate agent actions) is detected at the TLS handshake because the spoofed endpoint cannot present a certificate signed by the PKIaaS CA. The agent’s request never reaches a system it has not cryptographically verified.

Agent verification by the service: The service verifies the agent’s certificate against the PKIaaS root CA trust bundle before processing any request. An unauthorized agent or a compromised process attempting to impersonate an agent cannot present a valid PKIaaS-issued certificate (the certificate is cryptographically bound to the private key that was generated in the legitimate agent’s execution context). The service rejects the connection before any application-level logic is executed.

For agent-to-agent communication in multi-agent workflows, the same mTLS pattern applies. Agent A presents its certificate to Agent B; Agent B verifies it against the PKIaaS root; Agent B presents its certificate to Agent A; Agent A verifies it. Neither agent can be impersonated by a process that does not hold the corresponding private key.

Certificate-Based OAuth: Securing Agent Authorization Flows

Many AI agents interact with APIs that use OAuth 2.0 for authorization. The standard OAuth pattern for machine clients is the Client Credentials grant: the client (agent) presents a client ID and client secret to obtain an access token. The client secret is a static credential with all the problems described above.

Certificate-based OAuth replaces the client secret with the agent’s X.509 certificate. In this pattern, which uses the OAuth 2.0 Mutual-TLS Client Authentication (RFC 8705), the agent authenticates to the OAuth authorization server using its PKIaaS-issued certificate in the TLS handshake (mTLS client authentication) rather than presenting a client secret in the request body. The authorization server verifies the certificate against the PKIaaS CA trust bundle and issues an access token bound to the certificate’s fingerprint. This access token is only valid when presented alongside the certificate that was used to obtain it: the bearer token and the client certificate must match, making stolen access tokens useless without the corresponding private key.

For multi-agent workflows, the OAuth 2.0 Token Exchange specification (RFC 8693) enables agents to obtain access tokens that encode the delegation chain: Agent B can request a token that proves it is acting under authority delegated from Agent A, which was authorized by the user or system principal that initiated the workflow. Combined with certificate-based authentication at each hop, the delegation chain becomes cryptographically verifiable: every access token in the chain is tied to a specific certificate, every certificate was issued by the PKIaaS CA to a specific agent identity, and the PKIaaS audit log records the issuance history.

The Delegation Chain Problem in Multi-Agent Workflows

The most technically complex identity challenge in agentic AI is the delegation chain: when Agent A delegates a task to Agent B, which calls a tool, which triggers a payment in a financial system, every system in that chain needs to know the chain of authority that produced the final action. Without cryptographic delegation chains, the financial system sees only “Agent B made this request” without knowing that Agent B was acting under Agent A’s authority, which was granted by a human workflow owner, which was scoped by an organizational policy.

This matters for three reasons. First, authorization: the financial system needs to verify that the ultimate authority in the chain (the human or organizational principal) had the right to authorize the payment that Agent B is requesting. Second, accountability: when the auditor asks who authorized a specific transaction, the answer must be traceable through every agent in the chain back to a human-accountable decision. Third, containment: if Agent B is compromised or misconfigured, the scope of damage is limited to what the delegation chain authorizes, not to everything Agent B’s API key can access.

The technical mechanism for cryptographic delegation chains combines certificate-based identity with token exchange. Agent A holds a PKIaaS certificate encoding its identity. Agent A authenticates to the authorization server using that certificate and obtains an access token scoped to its authorized workflow. When Agent A delegates to Agent B, it uses the RFC 8693 Token Exchange to obtain a delegated access token for Agent B, which encodes both Agent A’s identity and Agent B’s identity (and the scope limitations of the delegation). Agent B uses its own PKIaaS certificate for mTLS authentication when presenting this delegated token. Any system Agent B calls can verify the full delegation chain from the token’s claims and from the certificate presented in the mTLS handshake.

Securing AI Infrastructure: Beyond Agent Identity

AI agent identity is the most visible PKI use case for AI infrastructure, but not the only one. The infrastructure that supports AI also requires PKI-backed security.

Model Serving Infrastructure

AI model inference endpoints (whether hosted on-premises, in cloud provider ML platforms, or through API services) serve as the backends that agents query. These endpoints need TLS certificates for secure transport, and in environments where only authorized agents should be able to call inference endpoints, the inference endpoint also needs to verify the agent’s identity (mTLS at the inference API layer). A PKIaaS CA that issues certificates to both the inference infrastructure and the agents creates the trust root for this bidirectional verification.

Training and Fine-Tuning Infrastructure

AI model training and fine-tuning infrastructure handles sensitive data: training datasets, model weights, evaluation results, and feedback data. Communication between training infrastructure components (data loaders, compute nodes, model checkpointing storage, experiment tracking services) should use TLS certificates issued by the organization’s PKIaaS CA rather than self-signed certificates. This ensures that the training infrastructure’s internal communication is authenticated and encrypted under the organization’s trust hierarchy, and that audit logs capture the certificate identity of every component involved in model training.

Model Artifact Signing

AI model artifacts (weights, configuration files, prompt templates, tool definitions) should be signed with code signing certificates issued by the PKIaaS CA. A model artifact that has been signed by the organization’s PKIaaS CA can be verified as authentic (produced by the organization’s authorized model development process) and unmodified (the signature is invalid if the artifact has been tampered with after signing). This is the AI equivalent of software supply chain security: just as code signing ensures that deployed software was produced by an authorized build pipeline, model artifact signing ensures that deployed models were produced by an authorized training or fine-tuning pipeline.

Agentic Framework Infrastructure

The infrastructure components of agentic AI frameworks (orchestrators, memory stores, tool registries, agent management APIs, observability platforms) are themselves services that agents and operators interact with. These components should have TLS certificates issued by the PKIaaS CA, and the APIs they expose should require mTLS authentication from the agents and operators that call them. An orchestration API that any unauthenticated process can call is not a secure orchestration layer; it is a control plane vulnerability waiting to be exploited by an agent whose authentication context has been manipulated.

Machine Identity Inventory for AI Agents

The machine identity inventory challenge described in prior posts about workload identity is acute for AI agents because agents are deployed and deprovisioned faster than traditional workloads. An agentic AI platform may launch hundreds of agents per hour, each with a unique certificate. Without a machine identity inventory that tracks which certificates have been issued to which agents, and which agents are still active versus decommissioned, the organization loses visibility into its AI agent identity estate almost immediately after deployment begins at scale.

A CLM platform connected to the PKIaaS CA provides the machine identity inventory for AI agents: every certificate issuance is recorded with the agent’s identity attributes, the issuance timestamp, the validity period, and the PKIaaS audit log entry that links the certificate to the issuance request. For short-lived agent certificates (1 hour to 24 hours), the inventory shows the current active agent population: which agents have certificates that are currently valid, and which certificates have expired (and the corresponding agents should no longer be active). If the CLM inventory shows an active certificate for an agent whose deployment has been terminated, that is a signal that the agent’s termination did not include proper credential cleanup or that the certificate was exfiltrated before the agent was terminated.

For AI agent governance, the CLM inventory also provides policy enforcement: certificates issued to AI agents that exceed the maximum permitted validity period, that are issued to agents with naming conventions that violate organizational policy, or that are issued to agents in environments they are not authorized to operate in, all surface as policy violations that can be flagged for remediation before the agent causes an incident.

The Audit Trail: Making AI Actions Attributable

One of the governance requirements for agentic AI in regulated environments is that AI actions must be attributable: when an AI agent makes a decision, modifies a record, or triggers a transaction, there must be an auditable record of which agent made the decision, under whose authority, and during which time window. Certificate-based agent identity provides this attribution at the infrastructure level rather than relying on application-level logging that agents themselves control.

The attribution chain works as follows. The PKIaaS CA issues a certificate to Agent X at time T with serial number S, valid for 4 hours. Agent X uses this certificate to authenticate to the transaction API. The transaction API’s access log records the client certificate serial number S and the request details. The PKIaaS audit log records that certificate S was issued to agent identity “order-processing-agent-v2.1/production” at time T with validity of 4 hours. Combining the two logs produces a complete attribution: “At 14:32:07, the order-processing-agent-v2.1 instance in the production environment (certificate S, issued at 14:00:00) called the transaction API and initiated payment transaction #4472.”

This attribution is cryptographically non-repudiable: the certificate serial number in the access log corresponds to a specific private key that was generated in the specific agent instance’s execution context. No other process could have presented certificate S without holding the corresponding private key, and the private key was generated in the agent’s memory, not stored anywhere that a different process could access it. The attribution is not dependent on the agent’s own logging, which an adversary who has compromised the agent could modify.

Emerging Regulatory Signals for AI Agent Identity

The regulatory environment for AI agent identity is in early formation but moving quickly. Several signals from 2025 and 2026 indicate the direction:

NIST NCCoE (2026): The NIST National Cybersecurity Center of Excellence published a concept paper in 2026 on software and AI agent identity and authorization, indicating that formal guidance on cryptographic identity for AI agents is under development from the primary US standards body for cybersecurity. Organizations that build certificate-based agent identity now are ahead of what will likely become a formal recommendation.

ITU Focus Group: The International Telecommunication Union established a focus group in 2026 on trust and identity for AI agents, with a mandate to develop international frameworks for agent identity and accountability. This signals that AI agent identity is being treated as an international standards-level problem, not just a vendor-specific implementation choice.

EU AI Act accountability requirements: The EU AI Act, phased in from August 2024, requires AI systems classified as high-risk to maintain logs of operations sufficient for human oversight and post-hoc accountability. For agentic AI systems that take autonomous actions in high-risk categories (employment decisions, credit scoring, critical infrastructure management), the accountability requirement is most readily satisfied by cryptographic attribution of agent actions, which certificate-based identity provides.

Financial sector AI governance expectations: The EBA (European Banking Authority) and other financial sector regulators are incorporating AI governance into ICT risk management guidance. For financial institutions using AI agents to automate trading, credit decisions, customer service, or fraud detection, AI governance expectations include auditability of automated decisions, which requires attributable agent identities.

How Encryption Consulting Can Help

• PKI as a Service: Encryption Consulting’s PKIaaS offering provides the CA infrastructure for AI agent identity: ACME+EAB for OIDC-based agent certificate provisioning, REST API for direct integration with AI orchestration platforms, SPIFFE upstream CA plugin for Kubernetes-based agent deployments, and certificate profiles designed for short-lived ephemeral agent identity (15-minute to 4-hour validity). Contact us at Encryption Consulting to discuss your AI agent identity architecture.
• CertSecure Manager: Encryption Consulting’s CertSecure Manager provides the machine identity inventory layer for AI agent certificate estates: continuous discovery of PKIaaS-issued agent certificates, expiry monitoring with active agent tracking, policy enforcement for certificate validity periods and naming conventions, and SIEM integration that feeds agent certificate lifecycle events into the security monitoring stack alongside API gateway access logs for the attribution correlation described in this post.
• CBOM Secure: For organizations assessing their AI infrastructure’s cryptographic posture before deploying certificate-based agent identity, Encryption Consulting’s CBOM Secure provides cryptographic discovery that surfaces existing static credentials (API keys, tokens, client secrets) used by AI agents and infrastructure, enabling prioritized migration from static credentials to certificate-based identity.
• PKI Services: For organizations designing the AI agent identity architecture from scratch, including OIDC token exchange configuration, certificate profile design for agent identity attributes, mTLS configuration for inference endpoints and orchestration APIs, and delegation chain design using RFC 8693 Token Exchange, Encryption Consulting’s PKI Services provide architecture advisory and implementation support through each component of the agent identity program.
• Compliance Advisory Services: For organizations in regulated sectors deploying agentic AI (financial services under DORA, healthcare under HIPAA, federal agencies under FISMA/FedRAMP, or EU entities under the AI Act), Encryption Consulting’s Compliance Advisory Services map AI agent identity architecture against applicable regulatory accountability and auditability requirements, producing a compliance evidence framework that demonstrates how certificate-based agent identity satisfies the relevant obligations.

Conclusion

AI agents are machines. They need machine identity. The technology for cryptographic machine identity has been production-tested for decades in PKI; what is new is applying it to a class of machines that are faster, more autonomous, and more consequential than traditional workloads. An AI agent that modifies configurations, triggers payments, or interacts with critical systems should not be less well-identified than a web server or a domain-joined laptop. It should be more carefully identified, because the consequences of an unidentified or impersonated AI agent are not a 503 error; they are autonomous actions taken with the wrong authorization.

PKIaaS provides the CA infrastructure to issue unique, short-lived, verifiable identities to AI agents at the scale and speed that agentic AI deployments require. The patterns, OIDC token exchange for provisioning, SPIFFE/SPIRE for Kubernetes-based agents, mTLS for agent-to-service communication, certificate-based OAuth for authorization flows, and RFC 8693 Token Exchange for delegation chains, are all production-ready today. The work is in configuring and integrating them with the specific AI orchestration platforms and infrastructure the organization is using.

The organizations that build certificate-based AI agent identity into their agentic AI programs now, before agent deployments scale past the point where retrofitting is practical, will have the audit trail, the accountability, and the access controls that regulators are moving toward and that security teams will eventually require. The organizations that wait until a regulatory requirement forces the issue will be retrofitting identity infrastructure onto a deployed agent population that was designed without it.

If your organization is deploying AI agents and wants to design a certificate-based identity architecture for them, reach out to Encryption Consulting.

This post is reviewed on a six-month cadence and when NIST, ITU, EU AI Act implementing regulations, or major agentic AI frameworks publish material updates to AI agent identity requirements or recommendations.

Frequently Asked Questions

Why do AI agents need cryptographic identity rather than API keys?

API keys are static, shareable, do not expire automatically, and provide no cryptographic proof of which specific agent used them. A PKIaaS-issued X.509 certificate is short-lived, cryptographically bound to the specific agent’s execution context, non-repudiable, and automatically rotated. A stolen certificate is useless after the validity period; a stolen API key is useful until manually rotated. The IBM Cost of Data Breach 2025 report found 97% of organizations that experienced AI model breaches lacked AI access controls.

What is the AI agent delegation chain problem?

In multi-agent workflows, Agent A delegates tasks to Agent B, which calls tools and triggers transactions. Every hop must be cryptographically provable back to an accountable principal. Without cryptographic delegation chains, any agent can claim any authorization. Certificate-based identity combined with OAuth 2.0 Token Exchange (RFC 8693) anchored to PKIaaS-issued certificates provides the technical mechanism for a verifiable delegation chain where every hop’s identity and authorization scope is cryptographically provable.

How does mTLS work for AI-to-service communication?

mTLS requires both the AI agent and the service to present and verify certificates before the connection proceeds. The agent verifies the service’s certificate (preventing calls to spoofed endpoints) and the service verifies the agent’s certificate (rejecting unauthorized agents at the TLS layer). Certificate-based OAuth (RFC 8705) extends this by binding OAuth access tokens to the agent’s certificate fingerprint, making stolen access tokens useless without the corresponding private key.

How short-lived should AI agent certificates be?

For ephemeral agents launched for a single task: 15 minutes to 4 hours, matching the expected task duration. For persistent agent deployments: 24 to 48 hours with automated renewal before expiry. The validity period should be short enough that a compromised certificate expires before an attacker can meaningfully exploit it, and long enough that automated renewal infrastructure reliably replaces it before the agent runs without a valid credential.

What is the regulatory status of AI agent identity requirements?

Emerging but moving quickly. NIST’s NCCoE published a 2026 concept paper on software and AI agent identity and authorization. The ITU established a 2026 focus group on AI agent trust and identity. The EU AI Act creates accountability and auditability obligations for high-risk AI systems. Financial sector regulators are incorporating AI governance into ICT risk management guidance. Certificate-based cryptographic identity is the most mature technical mechanism for satisfying these emerging accountability and attribution requirements.