Most teams deploying autonomous agents reach for the same answer when asked how they govern them: "we issue an API key and log the requests." That answer survives exactly until the first security questionnaire, the first auditor, or the first agent that does something nobody approved.
There is a better frame, and it isn't ours. The US National Institute of Standards and Technology, through its National Cybersecurity Center of Excellence (NCCoE), describes machine and non-human identity around four pillars. They map almost perfectly onto what an AI agent needs. If you build to them, you're aligned to a standard the whole industry is converging on — not to one region's regulation.
The question: can you prove which agent did something, beyond doubt?
An API key identifies a service, not an instance. It can be copied, shared between agents, and rotated without a trace. When a regulator asks "which agent moved that money?", a shared key cannot answer.
Identification means every agent instance carries a forgery-proof identity. In practice that's an X.509 certificate issued by a KMS-backed certificate authority, with the agent's model hash pinned inside the certificate. The private key never leaves the hardware security module. The identity is per-instance and non-repudiable — not a credential three agents share.
The question: can the agent act outside what it was allowed to do?
Identity without authorization is a name tag with no boundaries. Authorization means the agent's scope — maximum transaction size, allowed instruments, counterparties, operating hours — is bound to the identity and enforced before the action runs, not checked optimistically afterward.
The harder version of this problem is delegation. When an agent spawns a sub-agent, who actually authorized the sub-agent? Legacy tooling loses that chain. The modern answer is RFC 8693 OAuth 2.0 Token Exchange, whose act claim carries the full human→agent→sub-agent authority chain. Now "who told this sub-agent it could trade?" has a cryptographic answer.
The question: can you reconstruct what happened, in full, after the fact?
Auditing is more than a log file. It means every action is scored against the agent's own behavioral baseline, so gradual drift is caught and not just sudden spikes — and it means watching what the agent says, not only what it does. An agent that stays inside its financial scope can still manipulate, deceive, or commit you to terms it shouldn't. Content-risk scoring of agent output closes that gap.
Good auditing also links related events into a single causal unit — a decision chain — so an investigator reconstructs one incident instead of grepping a thousand rows. And it lets you export that history with a signed, tamper-evident proof that the record wasn't altered.
The question: can the agent — or you — credibly deny an action happened?
Non-repudiation is the pillar that turns claims into evidence. Signed actions, signed kill-switch receipts, and a write-once-read-many (WORM) audit log mean every action carries cryptographic proof of authorship. When you export forensic data, it ships with an HMAC proof a third party can verify independently.
This is the difference between telling a regulator "our logs say the agent did X" and handing them a record they can verify themselves without trusting you.
The reason to anchor on NIST's pillars rather than a specific regulation is simple: regulations vary by region and slip by years; the pillars don't. Build to identification, authorization, auditing, and non-repudiation, and you can render the same controls to whichever regime asks — NIST AI RMF and CSF 2.0 in the US, the EU AI Act and MiCA in Europe, ISO 27001 globally. One engine, every framework.
A certificate proves who. The four pillars, implemented together, prove what, under whose authority, and verifiably so. That's the bar for governing an agent you let act on its own.
Ready to map your agents to the four pillars? Start free or read the Know Your Agent framework.