Every AI agent that uses cryptographic identity has a private key somewhere. That key is the master secret: whoever holds it can impersonate the agent, sign transactions in its name, and decrypt communications addressed to it. If the key leaks, the agent's identity is compromised, and every action taken under that identity becomes suspect.
Private key security for AI agents is not primarily a cryptographic problem — the maths of asymmetric cryptography are well understood and well tested. It is an operational problem: where do you store the key, how do you use it, who can access it, and what happens when your storage layer is breached?
The organisations that get this right have a common answer: the key never leaves the HSM. Everything else is a workaround with a vulnerability.
How Private Keys Get Compromised
Before designing key custody, it is worth understanding how keys get exposed. The most common patterns, from most to least frequent:
Environment variables are the most common cause of AI agent credential leakage. A developer puts AGENT_PRIVATE_KEY=... in a .env file. That file gets accidentally committed to a repository. The repository is later made public, or the CI/CD system logs it, or a third-party tool syncs it. The key is now in a location the developer did not intend and cannot fully control.
Application memory is the next most common. The key is loaded at application startup and held in memory for the duration of the process. A memory dump — from a debugging session, a crash report, or an attacker exploiting a memory disclosure vulnerability — exposes the key. This is particularly concerning in containerised environments where memory dumps are commonly collected for diagnostic purposes.
Secrets databases and vaults that are not properly configured are the third common failure mode. A HashiCorp Vault or AWS Secrets Manager instance with overly permissive access policies gives any process running with certain IAM roles access to the secret. When one of those processes is compromised, the key is compromised with it.
Log files are a more subtle risk. Code that logs configuration on startup, or that logs error context including key material, can write private key bytes into log files. Log files typically have broader access than application code, and are often shipped to centralised logging systems with their own access control challenges.
The NIST Special Publication 800-57, Part 1, which covers key management best practices, specifically recommends that "cryptographic keys shall be protected at least as well as the data they protect." For AI agents making financial or medical decisions, that is a very high bar. The key must live in a hardware security module.
What AWS KMS Actually Provides
AWS Key Management Service is a managed service for creating and controlling cryptographic keys. When you generate a key in KMS, the key material is created inside a FIPS 140-2 validated HSM operated by AWS. The raw key bytes never leave that hardware — not to your application code, not to your logging system, not to your database, not even to AWS employees.
What you get instead of the key is a key ARN — a reference: arn:aws:kms:eu-west-1:123456789:key/abc-def-.... You use that ARN to call the KMS API and ask it to perform cryptographic operations with the key. KMS signs your data inside the HSM and returns the signature. Your application never touches the key itself.
This is architecturally fundamental for AI agent private key security. The consequences of a database breach change completely. An attacker who exfiltrates your database gets the key ARNs, not the keys. They can see which key was used for which agent, but they cannot use those keys to sign anything — signing requires an authenticated AWS API call that the attacker cannot make without your AWS credentials.
Kakunin implements this pattern for all certificate private keys. Every AI agent that registers with Kakunin gets a dedicated KMS key in the eu-west-1 region. The KMS key ARN is stored in Kakunin's database. The private key material never leaves KMS. Every signing operation — certificate issuance, audit log integrity signatures, agent operation signatures — is performed via KMS API calls.
For more on the certificate architecture, see the certificates documentation.
The eu-west-1 Requirement and GDPR Data Residency
The region selection for KMS is not arbitrary. EU AI Act and GDPR compliance for AI agents serving European users creates a data residency requirement: the cryptographic infrastructure underlying agent identity should be located within the EU.
AWS eu-west-1 (Ireland) is the primary EU region for AWS services. Keys created in eu-west-1 remain in eu-west-1. They do not replicate to other regions by default. This means that the cryptographic proof of your agents' identity is physically located within EU jurisdiction — relevant for data protection assessments and regulatory inquiries.
The GDPR's restrictions on cross-border data transfers apply to personal data, not cryptographic key material. But there is a broader principle at play: regulated entities serving EU customers should ensure their compliance infrastructure is located within EU regulatory jurisdiction. Using a US-based key management service for the private keys that sign AI agent operations creates questions about whether EU regulators can access or audit that infrastructure in the event of an investigation.
For organisations that need to demonstrate GDPR Article 32 (security of processing) compliance, the use of an EU-region HSM-backed key management service is a clear and defensible control.
Key Access Control: The IAM Layer
Even with private key material secured inside KMS, you need to control which processes can ask KMS to use the key. This is the IAM layer.
The principle here is least privilege: a given AI agent's private key should only be accessible to the specific service that needs to perform signing operations on behalf of that agent. If your agent fleet runs 100 agents, you should have 100 separate KMS keys, each with its own IAM policy that permits only the specific service (or services) responsible for that agent.
This granularity matters because it limits blast radius. If a specific service is compromised, the attacker can use the key material accessible to that service — but not any others. With a single shared key for all agents, a single compromised service compromises all agents simultaneously.
Kakunin creates one KMS key per registered agent. The key's IAM policy permits the Kakunin service to perform signing and verification operations. It explicitly denies key export. AWS CloudTrail logs every API call that uses the key, creating an independent audit trail of key usage that is separate from Kakunin's application audit log.
Key Rotation and Agent Certificate Renewal
Private keys should be rotated periodically. The 365-day certificate validity window that MiCA Article 70 requires creates a natural key rotation cadence: when the certificate expires, a new key pair is generated (the old key in KMS is disabled, a new key is created), and the new certificate is issued using the new key.
This annual rotation cycle means that even if an old key were somehow exposed — a hypothetical that is extremely difficult given the KMS architecture — the key material would be expired before it could be used maliciously in most scenarios. The combination of time-bounded certificates and annual key rotation provides defence in depth.
Kakunin automates the key rotation as part of the certificate renewal process. At renewal time:
1. A new KMS key is created with the same IAM policy as the previous key
2. The new key's ARN is stored in the database, linked to the agent record
3. A new X.509 certificate is issued using the new key
4. The old certificate is marked as expired
5. The old KMS key is disabled (not deleted — retained for historical signature verification)
Key retention after disablement is important: historical audit trail entries that were signed with the old key may need to be verified after rotation. KMS supports key disablement without deletion, preserving the ability to verify old signatures without allowing new signatures.
What Not to Do: Common Private Key Security Mistakes
Beyond the environment variable and memory risks already discussed, there are several patterns specific to AI agent deployments that create key security risks.
Shared keys across agents is the most common mistake. Organisations that issue one certificate and one key for all agents of a given type — "the trading agent key" — lose the ability to revoke individual agents without affecting all of them. If agent three in a fleet of trading agents is compromised, you need to revoke its key specifically. With a shared key, revocation affects all four agents.
Embedding keys in agent code or container images is a variant of the environment variable problem. Container images are frequently stored in registries that are accessible to many people. Key material in a container image is effectively public within your organisation. When the image is pushed to a cloud registry, the security boundary extends to the cloud provider's access control, which may be configured less carefully than you intend.
Not configuring key access logging undermines your audit trail. If you do not have logging enabled for KMS API calls (via CloudTrail), you cannot answer the question: "which process used this key, when, and to sign what?" This is both a security gap and a compliance gap — Article 75 of MiCA and Article 12 of the EU AI Act both require auditability of cryptographic operations.
Using symmetric keys for agent identity is a conceptual mistake. Symmetric key architectures require both parties to have the key, which makes them unsuitable for public verification. An X.509 certificate with an asymmetric key pair allows anyone to verify the agent's signature without having access to the private key. This is essential for the regulator-facing verification use case described in how regulators verify AI agents.
The CTO's Checklist for AI Agent Key Security
For engineering leaders responsible for AI agent security, here is a practical checklist for private key custody.
- [ ] All AI agent private keys generated inside a FIPS 140-2 validated HSM (KMS, Cloud HSM, or equivalent)
- [ ] No private key material stored in application databases, environment variables, or configuration files
- [ ] Separate KMS key per agent (not shared across agents of the same type)
- [ ] IAM policies configured with least privilege: only the specific service responsible for each agent can use its key
- [ ] AWS CloudTrail enabled and configured to capture all KMS API calls
- [ ] Key rotation aligned with certificate renewal (annually, or more frequently for high-risk agents)
- [ ] Old keys disabled (not deleted) after rotation, retained for historical signature verification
- [ ] Key usage anomalies monitored: unusual patterns of signing operations flagged to security team
The NIST SP 800-57 is the canonical reference for key management best practices. The FIPS 140-2 standard (relevant for HSM selection) is published by NIST and freely available.
Key Security as Competitive Advantage
Private key security is the kind of topic that separates security-forward AI agent deployments from ones that are hoping for the best. It is not visible to end users. It does not show up in product demos. It is boring infrastructure that nobody talks about until something goes wrong.
But for regulated industries — financial services, healthcare, legal — it is a procurement requirement and a regulatory obligation. Enterprise security teams reviewing AI agent deployments will ask: where are the private keys? If the answer is "in environment variables" or "in our database," the deployment will not pass enterprise security review.
If the answer is "in AWS KMS eu-west-1, with per-agent dedicated keys, IAM least-privilege policies, and CloudTrail logging," the security conversation moves on quickly. That is the answer that closes enterprise deals and satisfies regulatory audits.
For CTOs building the technical architecture for AI agent deployments, the /for-ctos page covers the integration architecture in detail, including the KMS configuration and audit trail setup.
---
Kakunin generates all AI agent private keys inside AWS KMS RSA_2048 in eu-west-1. Raw key material never leaves the HSM. Only the KMS key ARN is stored in the database. Read the certificates documentation or explore the CTO integration guide.