How to Govern AI Agents Without a PKI Team

There are two kinds of company shipping autonomous agents into production.

The first is a Fortune 500 with an existing public-key infrastructure (PKI) program — a team of cryptography specialists, a six-figure 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 can't afford the incumbent's $100k 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 can't 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 don't run the certificate authority — it's issued by API. 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}/certify

That's 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, hours — checked before the action runs, not regretted afterward.

In Python it's a decorator:

@verify_agent_scope("write:drafts")
def submit_invoice(...):
    ...

If the agent is out of scope, suspended, or revoked, the function never executes. And when behavior 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: 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 the 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

Certificate issuance is table stakes — the incumbent does it, and so does Kakunin. The 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's the part a mid-market team can finally afford.

Put an identity, a leash, and a paper trail on your agents. Start free — no PKI team required.