MPC vs HSM: Which Key Management Approach Secures Your Enterprise?
Feb 25, 2026
ArticleCompare HSM, MPC and software-defined HSM (SD-HSM) for cloud programmes: single points of failure, TCO and when each custody model fits.
Read articleAgentic Cryptography: Know Your Agent
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
- The problem
- What "Know your agent" means
- DuoKey's response
- Link to governed objects on the platform
- Where this shows up in DuoKey
- FAQ
The problem
Production agent deployments commonly share three failure modes:
- 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.
- 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.
- 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.
DuoKey's response
| Control | What it does |
|---|---|
| Cryptographic identity per agent | Issue a provable identity when the agent is created; no shared production service account for the fleet |
| Unit revocation | Pull one agent's authority in a single operation; other agents keep working |
| Signed attestation per action | Bind key use, signing, or sensitive calls to the agent identity and policy decision |
| Policy outside the agent | Limits, allow-lists and escalation live outside the agent process so a compromised agent cannot rewrite them |
| MPC-backed key material | Where agents hold signing or payment authority, key shares never reassemble as a single plaintext secret (MPC vs HSM) |
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.
Link to governed objects on the platform
Agentic cryptography sits on objects DuoKey already governs elsewhere on the platform:
| Governed object | Role for agents |
|---|---|
| Keys / KMS | Agents request unwrap or use under policy; no standing cloud-provider-only custody |
| Certificates / PKI | Machine and workload identities for agents that need TLS or mTLS without spreadsheet PKI |
| Secrets | Short-lived, agent-scoped material instead of a copied .env or shared AppRole |
| Crypto agility / PQC | Estate 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): per-agent wallets for spend and signing, with blast-radius control when money moves
- Platform pillar: Agentic cryptography on /platform
FAQ
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: 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 and policy outside the agent process. That is what "know your agent" means in practice, and why it belongs next to KMS, PKI and secrets on the same platform.
References
Written by
Nagib Aouini
Related Resources
Agent identity and key control
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.