They should treat certificates as the start of governance, not the finish. The important controls are scoped issuance, short-lived trust, revocation tied to workflow changes, and logging that links each certificate to downstream actions. Without those controls, PKI authenticates the agent but does not contain its authority or explain what it did.
Why This Matters for Security Teams
PKI gives AI agents a cryptographic identity, but that is only the entry point. For autonomous workloads, the real risk is not whether a certificate can be validated, but whether the agent’s authority is bounded to a specific task, time window, and trust domain. Current guidance suggests treating certificates as workload identity, not as a substitute for governance. That means aligning issuance, policy evaluation, logging, and revocation around how the agent behaves at runtime.
This matters because agents can chain tools, call downstream services, and continue operating after the original task context has changed. Static certificate lifetimes and broad trust anchors make it easy for an agent to remain authenticated long after its purpose is gone. NHI Management Group research shows that Ultimate Guide to NHIs reports 97% of NHIs carry excessive privileges, which is a useful reminder that identity proof alone does not equal control. For PKI-based agent identity, the same failure mode appears when certificates are issued without scoped constraints and downstream observability. In practice, many security teams discover this only after an agent has already used valid credentials in ways no one expected, rather than through intentional governance design.
How It Works in Practice
Governance starts by separating authentication from authorisation. A certificate can prove that an AI agent is a known workload, but the policy engine still needs to decide what that agent may do right now. That is where workload identity, runtime context, and short-lived trust come together. In zero-trust terms, the certificate is the identity token; the permission decision is made per request, not once at onboarding. That pattern aligns with NIST AI Risk Management Framework expectations for govern, map, and measure functions, and with the agentic threat modeling approach in CSA MAESTRO agentic AI threat modeling framework.
Operationally, teams should issue certificates as part of a workflow, not as permanent machine credentials. Good practice is evolving toward:
- Scoped issuance, where certificates are bound to a specific agent, environment, and task class.
- Short TTLs, so trust expires with the job rather than surviving as a standing credential.
- Automated revocation when the workflow changes, the model version changes, or the agent is paused.
- Request-level logging that ties certificate subject, policy decision, tool call, and downstream action together.
- Policy-as-code evaluation at runtime, so new actions are judged against current context instead of a pre-approved role.
This is especially important because PKI authenticates possession of a key, not intent. If an agent can pivot from one tool to another, the control plane needs to observe and constrain that chain of actions. The NHIMG 52 NHI Breaches Analysis is useful here because it shows how identity failures often become action failures when trust is too broad. These controls tend to break down when certificates are reused across environments, because the same identity then inherits too many privileges across too many services.
Common Variations and Edge Cases
Tighter certificate governance often increases operational overhead, requiring organisations to balance faster automation against more frequent issuance, renewal, and logging. That tradeoff is real, especially for high-volume agent fleets and multi-agent pipelines. There is no universal standard for this yet, but current guidance suggests avoiding long-lived agent certificates unless there is a strong technical reason and compensating controls are in place.
One common edge case is cross-domain delegation, where an agent needs to hand off work to another agent or service. In that pattern, teams should not simply forward the original certificate. A safer model is delegated, purpose-bound credentials with a narrower scope and fresh policy evaluation. Another edge case is emergency access. If an agent must perform a recovery action, that access should be time-boxed, heavily logged, and explicitly approved, not left in the base certificate policy.
Teams should also distinguish between PKI for service-to-service trust and PKI for agent autonomy. The first is familiar enterprise hygiene; the second requires stronger runtime controls because the workload can change state, goals, and tool usage quickly. NHI Management Group’s Top 10 NHI Issues and the OWASP Agentic AI Top 10 both reflect the same practical lesson: identity without runtime containment is only partial protection. Best practice is evolving, but the safe default is to make every certificate temporary, contextual, and traceable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A09 | Agent identity needs runtime containment, not static trust. |
| CSA MAESTRO | M1 | MAESTRO covers agent trust boundaries and delegated actions. |
| NIST AI RMF | AI RMF applies govern and measure functions to agent identity risk. |
Assign ownership, monitor behaviour, and review agent trust decisions continuously.
