There are two kinds of company shipping autonomous agents into production.
The first is a Fortune 500 with an existing public-key infrastructure program, a team of cryptography specialists, a certificate-management platform, and a multi-quarter rollout. They have governance handled, expensively.
The second is everyone else: the 10–200 person company whose agents move money, touch customer data, or act on a regulated buyer’s behalf and who gets asked “how do you govern your agents?” in every security review with no good answer. They cannot afford the incumbent’s six-figure floor and a PKI department, so they ship the agent anyway and hope.
This post is for the second company. You do not need a cryptography team to govern an agent properly. You need three things, and you can have them today.
1. An identity — that isn't a shared API key
The default is an API key, and the problem with an API key is that it identifies a service, not a specific agent instance. It can be shared, leaked, and rotated with no audit trail. The moment something goes wrong, you cannot prove which agent did it.
The fix is a real cryptographic identity: an X.509 certificate per agent, with private keys held in a cloud KMS so they never leave secure hardware. You do not run the certificate authority yourself. The hard cryptography is somebody else’s operational problem. Your code makes one call and gets back an agent that can prove who it is.
POST /v1/agents/{id}/certifyThat is the whole PKI program, from your side.
2. A leash — scope enforced before the agent acts
An identity with no boundaries is a name tag. The leash is scope bound to the certificate — maximum transaction size, allowed actions, counterparties, operating hours — checked before the action runs, not regretted afterward.
In Python it can be as simple as a decorator around the sensitive function.
@verify_agent_scope("write:drafts")
def submit_invoice(...):
...If the agent is out of scope, suspended, or revoked, the function never executes. And when behaviour drifts past a risk threshold, the certificate is revoked automatically — no human in the critical path, no admin scrambling to rotate a key while the agent keeps acting.
You can even put the leash in CI via a GitHub Actions gate that refuses to promote an agent whose recent risk is too high and revokes its certificate on a hard fail.
3. A paper trail — proof, not claims
When the auditor or enterprise buyer asks what your agent did, “our logs say…” is a weak answer. A strong answer is a WORM audit log where every action is cryptographically signed, decision chains link related events into one reconstructable incident, and you can export the history with a tamper-evident signed proof.
That same trail renders to whatever framework the asker uses — NIST AI RMF and CSF 2.0, the EU AI Act, MiCA, ISO 27001 — because the underlying controls are the same. One engine, every framework. You answer the questionnaire in one click instead of one quarter.
The honest comparison
A traditional PKI program gives you X.509, but it expects your team to own the rollout, vendor selection, and operational burden. A lighter governance layer aims for the same identity primitive with an API-first setup, built-in behavioral monitoring, and compliance evidence that works across regions.
Certificate issuance is table stakes. The real difference is everything after issuance: watching what the agent actually does and says, stopping it when it goes off the rails, and proving control to whoever asks. That is the part a mid-market team can finally afford.
Put an identity, a leash, and a paper trail on your agents.