AI security · Machine identity · Credential governance

AI Key Management
What PKI Architects Bring to Identity, Credentials and Agentic Authority

AI systems are creating a familiar problem in a new shape: who—or what—is trusted to access a sensitive system, and what is that identity allowed to do?

PKI architects already work with identity, keys, certificates, trust chains, issuance, revocation and lifecycle controls. That experience is useful in AI governance, but the connection needs care.

An API key, OAuth access token, service account and cryptographic private key are not the same thing. They have different security properties and failure modes. “AI key management” is therefore best treated as a practical umbrella for the identities, credentials and permissions used by an AI-assisted workflow—not as a claim that every credential belongs in a PKI.

“The useful overlap is not one technology. It is the discipline of controlling authority through its complete lifecycle.”

Start by Naming What the Workflow Uses

An AI-enabled workflow may rely on:

• Cryptographic keys used for encryption, signing or authentication.
• API keys and client secrets used to identify or authenticate an application.
• OAuth access and refresh tokens that carry delegated authority.
• Service or workload identities used to reach cloud, data or automation platforms.
• Model access credentials and tool-specific permissions.
• Retrieval connections that expose enterprise information.
• Human approval paths for sensitive or irreversible actions.

The first control is accurate classification. A team cannot choose suitable storage, rotation, expiry or revocation rules while calling every item a “key.”

NIST SP 800-57 Part 1 remains guidance for cryptographic keying material. It should not be stretched into a complete governance model for OAuth, service accounts or tool permissions. Those controls also need identity, access-management and application-security disciplines.

Ask the Question PKI Has Always Asked

The better question is not simply, “Does this use PKI?” It is:

“What identity is acting, what authority has it been given, and how is that authority controlled from issue to revocation?”

For each workflow, trace the full authority chain:

human intent → AI workflow → executing identity → credential → downstream policy → action → evidence

That chain exposes a common design error: the model appears to make a decision, but the real security boundary is the identity and permissions used by the tool that carries the decision out.

Excessive Agency Makes Credentials Part of the Boundary

OWASP's 2025 Top 10 for LLM and Generative AI applications describes excessive agency as a combination of excessive functionality, permissions or autonomy. The risk becomes concrete when a system can call tools, read data, write files, create tickets, send messages or trigger workflows.

OWASP recommends limiting tools and their functions, minimising downstream permissions, executing actions in the user's context where appropriate, requiring human approval for high-impact actions, and enforcing authorisation in downstream systems rather than relying on the model to decide.

This is where PKI lifecycle thinking helps:

• Issue: who approved the identity and its initial scope?
• Use: where can the credential be presented, and for which actions?
• Monitor: what evidence links a request, identity, tool call and outcome?
• Rotate: can the credential change without breaking the workflow?
• Revoke: how quickly can access be removed after compromise or role change?
• Audit: can a reviewer reconstruct what happened without exposing secret values?

The lifecycle is familiar. The implementation may not be.

Design the Authority Boundary Deliberately

A defensible workflow should make several controls visible:

• Use a dedicated workload identity instead of a shared human or administrator account.
• Grant only the tools, functions and resource permissions needed for the defined task.
• Prefer short-lived credentials where the platform can issue, renew and revoke them safely.
• Keep credentials out of prompts, retrieved content, model context and ordinary application logs.
• Enforce authorisation at the downstream service; do not treat model output as permission.
• Require separate approval for high-impact, irreversible or policy-exception actions.
• Record the requesting user, executing identity, tool, action, policy decision and outcome—never the secret itself.
• Test rotation, revocation, offboarding and emergency disablement before the workflow is relied upon.

NIST's Zero Trust Architecture reinforces the underlying principle: authentication and authorisation are distinct decisions, and access should focus on the identity, resource and request rather than assume trust from network location or ownership.

NIST's Generative AI Profile also frames AI risk management across the lifecycle. That supports treating credential and authority decisions as ongoing governance work, not a one-time integration setting.

One Concrete Step

Pick one AI-assisted workflow and list every identity, credential and approval path it can use. Record:

• Workflow and accountable owner.
• Action and downstream resource.
• Executing identity and credential type.
• Permission scope and whether it is read, write, approve or administer.
• Expiry, rotation and storage method.
• Human-approval boundary.
• Revocation and emergency-disable path.
• Evidence retained for review.

Then mark each identity or credential as human-owned, service-owned, shared, long-lived, privileged or unknown. The labels can overlap.

Every shared, long-lived, privileged or unknown entry deserves review. Start with the item that combines the broadest permissions with the weakest ownership or revocation evidence.

Ownership Should Be Combined, Not Ambiguous

AI security ownership rarely fits neatly inside one team. Identity specialists understand authentication and delegated authority. Application security understands tool and output risks. Platform teams operate workload identities and secret stores. Data governance defines acceptable use. Business owners decide which actions require judgement or approval.

A combined model is stronger when one accountable service owner coordinates those controls and each supporting team has a named responsibility. “Everyone is involved” is not the same as ownership.

“PKI thinking helps most when it turns invisible authority into a visible lifecycle with an owner, a policy and evidence.”

In your environment, which team can currently explain the complete authority chain for an AI-assisted workflow—and where does that explanation become uncertain?

Sources

• OWASP: 2025 Top 10 Risk and Mitigations for LLMs and Generative AI Apps
• OWASP LLM06:2025 — Excessive Agency
• NIST AI 600-1: Artificial Intelligence Risk Management Framework — Generative Artificial Intelligence Profile
• NIST SP 800-57 Part 1 Rev. 5: Recommendation for Key Management — General
• NIST SP 800-207: Zero Trust Architecture