The other day someone proposed a taxonomy for AI agent configuration — five layers, from the model itself to fleet orchestration. It was the cleanest framing I'd seen of how agents are structured. But something was missing from every layer.
Nobody had named it yet.
Observability tells you what happened. Auditability tells you it's true.
Most agent frameworks today have observability. You can see what the agent did, what tools it called, what outputs it produced. Logs, traces, dashboards.
What they don't have is auditability — a cryptographic guarantee that the record is authentic and was not altered after the fact.
These are not the same thing. And the difference matters more than most teams realize.
The scenario that makes it concrete
Imagine an agent that handles financial operations. It reads account data, evaluates conditions, and approves or rejects transfers automatically.
Your observability stack tells you the agent approved a $47,000 transfer at 3:42 AM. The log is right there.
But can you prove it?
Can you prove that log wasn't written after the fact? Can you prove the agent that approved it was the agent you deployed — and not a compromised version running with altered instructions? Can you prove the action wasn't injected by a malicious prompt that slipped through your guardrails?
Observability says "this happened." Auditability says "this happened, here is the cryptographic proof, and it cannot be disputed."
In financial systems, healthcare, legal workflows, or anywhere agent outputs have real consequences — the difference between those two statements is the difference between a log and evidence.
Why this gap exists
Agent frameworks are built around capability and reliability. Can the agent do the task? Does it do it consistently? Those are the questions that dominate the design space right now.
Security is treated as a layer you add on top. And auditability — the ability to prove what happened — isn't even in the conversation yet.
Researchers working on agent memory authorization are running into the same root problem from a different angle. Their question is whether the memory the agent retrieved was authorized to govern the action it took. My question is whether the action the agent took can be proven authentic after the fact. Both gaps share the same absence: no authority chain attached to the action.
The agent acted. But nothing signed for it.
What auditability actually looks like
The model is straightforward. Every agent action produces a signed token:
const { token } = await pq.sign({
sub: "agent_payment_processor",
action: "approve_transfer",
amount: 47000,
accountId: "acct_8821",
expiresInSeconds: 300
})
The token is cryptographic proof that this specific agent performed this specific action at this specific time. If the token verifies, the action is authentic. If it doesn't verify, something was tampered with or the agent was compromised.
Revocation is the other half. If the agent is compromised, you revoke its credentials instantly — not wait for tokens to expire. Every subsequent verify call rejects immediately.
This gives you two things observability cannot:
Tamper-evident records — the action log cannot be altered after the fact without breaking the signatures.
Instant credential revocation — when something looks wrong, you pull the agent's credentials and it stops being trusted immediately, not in five minutes when the token expires.
The post-quantum angle
The signing infrastructure matters. If you build agent auditability on RSA or ECDSA today, you're building on algorithms that quantum computers will break within this decade. NIST finalized post-quantum standards in August 2024 — ML-DSA-65 (FIPS 204) is the signing standard.
Building auditability now means building it on algorithms that will still hold when the threat materializes. The migration cost later is much higher than doing it right today.
FIPSign is the API I built for exactly this — post-quantum signing, verification, and revocation as a service. An agent is just another sub. No changes to your existing architecture. The auditability layer sits on top of whatever you're already running. JS/TS and Python SDKs available.
The question worth asking
Most teams deploying agents in production today can answer "what did the agent do?"
Fewer can answer "can you prove it?"
If your agents are making decisions with real consequences — financial, legal, medical, operational — that second question is coming. The teams that answer it now will have the compliance story when the audit arrives. The teams that don't will be rebuilding their auditability layer under pressure.
The infrastructure exists today. The threat model is real. The migration is cheap now and expensive later.
If you're thinking about agent auditability in your stack, I'd genuinely like to hear how you're approaching it. Drop a comment — especially if you've run into the detection latency problem that makes revocation timing tricky.
Top comments (0)