DuoKey
Resources
Article

AI Agent Key Management: Agentic Cryptography and Know Your Agent

AI agent key management: a revocable identity per agent, keys kept out of agent processes, and KMS access through an MCP server under policy.

Nagib Aouini··10 min read

AI agent key management is how you issue, scope, use, rotate and revoke the keys and credentials that autonomous AI agents rely on. The goal is that every agent acts under its own identity, never holds a key it could leak in full, and can be cut off alone without disturbing the rest of the fleet.

AI agents in production already request keys, call APIs, sign transactions and touch regulated data. Most of them still authenticate like a batch job from 2012: a shared service account, a long-lived secret in a vault path, and an audit log that says "the automation user did something" without naming which agent.

Agentic cryptography is the control plane for that gap. Every agent gets a cryptographic identity you can issue, attest and revoke without rotating credentials for the rest of the fleet.


Table of Contents

  1. The problem
  2. What "Know your agent" means
  3. Principles of AI agent key management
  4. MCP server key management
  5. What is an agentic KMS?
  6. DuoKey's response
  7. Link to governed objects on the platform
  8. Where this shows up in DuoKey
  9. FAQ

The problem

Production agent deployments commonly share three failure modes:

  1. Broad, shared service accounts. One credential carries production access for many agents. Compromise one process and you inherit the standing privileges of the whole pool.
  2. No individual revocation. Turning off a misbehaving agent often means rotating a shared secret or disabling a role that other agents still need. Blast radius becomes a change window.
  3. Weak per-agent audit. Logs show a machine identity or a vault AppRole, not which agent instance acted, under which policy, for which task. Incident response cannot answer "which agent did this?" without reconstructing tribal knowledge.

None of that is a model-quality problem. It is an identity and key-management problem that classical cryptography vendors rarely treat as a first-class product surface.


What "Know your agent" means

Know your agent is the same idea as know your customer, applied to non-human actors that can spend, approve, or decrypt:

  • Every agent has a named cryptographic identity issued at creation
  • That identity is revocable as a unit, without fleet-wide rotation
  • Every sensitive action carries a signed attestation tied to that identity and the policy that authorised it
  • Access is scoped to task and owner, not a standing shared role

If you cannot name the agent, revoke it alone, and prove what it signed, you do not have agent governance. You have automation with a borrowed human credential model.


Principles of AI agent key management

Agents differ from classic workloads in one way that matters for keys: their behaviour is driven by inputs you do not fully control, including prompts, documents and tool results. A prompt injection or a bad tool response can make an agent misuse whatever it can reach. Key management for agents therefore assumes the agent process may be manipulated.

  1. Keep raw keys out of the agent. The agent asks a KMS or signing service to perform the operation. It never loads a private key or a long-lived secret into its own memory, prompt or context window.
  2. One identity per agent. Each agent gets its own credential, bound to an owner and a task, so audit logs and revocation work per agent.
  3. Short-lived, scoped credentials. Prefer tokens that expire and carry only the permissions the task needs over static API keys.
  4. Policy outside the agent. Spend limits, allow-lists and approval rules are enforced by the service that holds the key, where a compromised agent cannot change them.
  5. Split high-value keys. For keys that can move money or sign on behalf of the company, hold the key with multi-party computation so no single process, operator or provider holds it whole. See threshold cryptography for key management.
  6. Human approval for high-impact actions. Above a threshold you define, the operation waits for a person.

MCP server key management

The Model Context Protocol (MCP) is the open standard many AI clients use to call external tools. "MCP server key management" covers two related questions.

1. Protecting the credentials of an MCP server. An MCP server sits between an agent and real systems, so it holds or obtains credentials for those systems. The MCP specification makes authorization optional, but for HTTP transports it is based on OAuth 2.1. MCP servers must validate that tokens were issued for them, and must not pass the client's token through to upstream APIs; for local STDIO servers, the specification says to retrieve credentials from the environment (MCP authorization specification). In practice:

  • Store the server's upstream secrets in a secrets manager or KMS, not in the server's config file or the agent's context.
  • Give each MCP server its own credentials, scoped to the tools it exposes.
  • Log every tool call against the user or agent that made it.

2. Operating key management through an MCP server. Security vendors now expose their own platforms over MCP, so an AI assistant can query inventories or carry out changes. Keyfactor, for example, announced an MCP server for Keyfactor Command (press release). The question then becomes how far that agent can go.

DuoKey's answer is the Cockpit MCP endpoint (documentation):

  • One tenant per connection. Every connection resolves to exactly one tenant; an agent can never see another tenant's data.
  • Off by default. The endpoint is a separate entitlement and stays disabled until a tenant admin turns it on.
  • Capability packs with two gates. Tools are grouped into packs (PQC, KMS, vaults, PKI and others). A pack must be included in the edition and switched on by an admin. Read packs answer questions; write packs can create keys, issue certificates or deploy to network equipment.
  • Still the user's permissions. Every call is checked against the permissions of the user who approved the connection or created the key. Enabling a pack removes the MCP gate, not the underlying permission check.
  • Two ways to connect. An API key, shown once and valid until revoked or until an optional expiry, or an interactive OAuth connection with a consent screen.
  • No new business logic. Each tool call maps onto an existing DuoKey service, so the same audit trail applies.

What is an agentic KMS?

An agentic KMS is a key management system built so that AI agents can operate it safely: through a standard interface such as MCP, under explicit policy, with every action tied to a named identity and the person accountable for it. It covers both directions: agents using keys (signing, unwrapping) and agents managing keys (inventory, rotation, certificate issuance).

DuoKey's documentation describes its platform as an agentic KMS and crypto agility plane, where AI and MCP clients can operate cryptography in natural language (docs.duokey.com). The guardrails are the ones above: tenant scoping, opt-in capability packs, the user's own permissions, and human approval for high-impact changes unless the customer's policy explicitly allows otherwise.


DuoKey's response

ControlWhat it does
Cryptographic identity per agentIssue a provable identity when the agent is created; no shared production service account for the fleet
Unit revocationPull one agent's authority in a single operation; other agents keep working
Signed attestation per actionBind key use, signing, or sensitive calls to the agent identity and policy decision
Policy outside the agentLimits, allow-lists and escalation live outside the agent process so a compromised agent cannot rewrite them
MPC-backed key materialWhere agents hold signing or payment authority, key shares never reassemble as a single plaintext secret (MPC vs HSM)
Governed MCP accessAI clients reach the Cockpit through a tenant-scoped MCP endpoint with opt-in capability packs

This is the same architecture summarised on the platform: every agent gets a revocable identity; no shared service account carries production access; know your agent.


Agentic cryptography sits on objects DuoKey already governs elsewhere on the platform:

Governed objectRole for agents
Keys / KMSAgents request unwrap or use under policy; no standing cloud-provider-only custody
Certificates / PKIMachine and workload identities for agents that need TLS or mTLS without spreadsheet PKI
SecretsShort-lived, agent-scoped material instead of a copied .env or shared AppRole
Crypto agility / PQCEstate renewals and algorithm change under the same automation plane agents already use

Agents are not a separate product silo. They are principals on the same control plane as certificates, keys and secrets.


Where this shows up in DuoKey

  • Product: Agentic Crypto Agility: identity issuance, rotation, revocation and audit for agents
  • Use case: Agentic wallet (MPC): Agent Vault gives each agent its own wallet for spend and signing, with blast-radius control when money moves. It is rolling out by invite.
  • Key management: DuoKey KMS, where keys are split with 2-of-3 threshold signing
  • AI access: the Cockpit MCP endpoint, for Claude, ChatGPT, Microsoft Copilot and other MCP clients
  • Platform pillar: Agentic cryptography on /platform

FAQ

Q: What is AI agent key management?

It is the practice of giving each AI agent its own scoped, revocable credentials and keeping the keys it uses inside a KMS or signing service rather than in the agent's process. Every action is logged against the agent and the person who owns it.

Q: Is this the same as giving each agent an API key?

No. An API key is still a single secret that can be copied and replayed. A cryptographic agent identity is issued, attested, and revocable as a principal, with policy and key material designed so compromise of one agent does not imply compromise of the fleet credential.

Q: What is MCP server key management?

It covers two things: protecting the credentials an MCP server uses to reach backend systems (OAuth 2.1 for HTTP transports, no token passthrough, secrets kept out of config files), and controlling what an AI agent may do when it operates a key management platform through an MCP server.

Q: What is an agentic KMS?

A KMS that AI agents can use and operate through a standard interface such as MCP, under explicit policy, with every action tied to a named identity. DuoKey implements this with a tenant-scoped MCP endpoint, opt-in capability packs and the connecting user's own permissions.

Q: Do we need MPC for every agent?

Not for every low-risk read-only bot. For agents that sign, pay, or unwrap regulated data, MPC removes the single plaintext key that shared service accounts and simple vault secrets recreate. See MPC vs HSM and the agentic wallet use case.

Q: How does this relate to human IAM?

Human SSO and MFA remain. Agents need a parallel, non-human identity model with the same properties security teams already expect for people: unique identity, least privilege, revocation, and an audit trail that names the actor.


Conclusion

Agents already operate in production. Shared service accounts do not scale to that reality. Agentic cryptography makes each agent a revocable cryptographic principal, with attestation on actions, keys held outside the agent process, and policy the agent cannot rewrite. That is what "know your agent" means in practice, and why it belongs next to KMS, PKI and secrets on the same platform.


References

Share

Written by

Nagib Aouini

Discuss the decisions that matter most to your security programme.

Tell us where control is difficult today. We will help you identify a practical next step.