Who approved that?

The composition of work changed faster than the paperwork did.

Two years ago, "the team" meant people. Today almost every knowledge task has AI in the loop — drafting the contract, triaging the inbox, reconciling the invoices, pushing the fix. The org chart still says forty employees. The activity log tells the truth: forty humans and a few hundred agent identities, acting around the clock.

Most of that is good news. Here's the part that isn't settled: when humans and AI produce work together, authorization and accountability stop being obvious. And unlike most unsettled questions, this one has a deadline — because it gets asked, retroactively, by people with checklists: auditors, regulators, insurers, incident reviewers, courts.

• The agent issued the refund. Who approved it?
• The agent "fixed" the source data so validation would pass. Who authorized that?
• The model's summary was wrong and a customer relied on it. Which human signed off — and what exactly were they looking at when they did?

"An AI did it" has no standing anywhere that matters. Accountability always lands on a person. The only question is whether your systems can show which person, what they authorized, and what they saw when they authorized it.

Why today's answers fail the audit

Logs record what happened — not who meant it. Every platform has an activity trail. Almost none can distinguish "a human with authority deliberately approved this specific action" from "a request arrived from a session bearing this human's cookies." Those are different facts, and after an incident they're the only fact that matters — stolen sessions, over-privileged service accounts and rubber-stamp fatigue all collapse the first into the second.

Blanket delegation isn't authorization. "The agent is allowed to handle refunds" is a policy. It is not an answer to "who approved this refund, of this amount, to this customer." When the delegation chain runs human → agent → action, accountability needs per-action anchors somewhere in that chain — or every incident review ends in a shrug.

And the vendor's word isn't evidence. If the only proof of an approval lives inside the vendor's own database, the audit answer amounts to "the system being audited says it's fine." Evidence that matters has to be verifiable by a third party who trusts neither the vendor nor the platform — offline, after the fact, years later if needed.

Approvals that scale: the frequency law

The failure mode on the other side is just as real: drown people in confirmation dialogs and they will click yes to everything — accountability theatre. The design rule I keep coming back to:

Assurance should scale with blast radius divided by frequency.

Frequent actions must stay light or people stop reading them. Catastrophic actions must be rare enough that a deliberate ritual is affordable. Mapped onto how organizations actually operate:

Banking arrived at this junction first, and it's worth noticing why: the industry with the most hardened infrastructure is the one that wrote human transaction signing into law (PSD2's dynamic linking; chipTAN's independent displays). Trusted machines didn't remove the need for provable human authorization. They made it the standard.

The assurance ladder, level by level

The ladder only works if you're honest about what each rung proves — and what it doesn't:

	Level	Mechanism	Where the key lives	What it proves	What it does not prove
	L1Software confirm	Authenticated session + explicit click; event recorded in the audit trail	— (session credential)	The account holder's session confirmed, in the flow of work	That the person — rather than whoever holds their session — meant it
	L2Hardware-backed approval	System biometrics unlock a device-bound, non-exportable key (Secure Enclave / TPM / hardware keystore); that key signs this one action, with nonce and expiry	Inside your phone or laptop's protected hardware	The key's holder authorized this exact payload — replay-proof, per-action	Display integrity on a compromised device: the summary is app-rendered. The biometric is the unlock, never the root
	L3Dedicated-device ceremony	A standalone signer with its own display and physical confirm/cancel; separate smartcard-class secure element (chip-level EAL5+/6+ certified parts)	Inside the dedicated device; it never leaves	An authorized human saw this action on an independent display and physically confirmed it	That the policy itself is wise; anything happening outside the governed surface
	L4Multi-party + attested execution	2-of-3 or dual-control approval, plus runtime attestation of the executing environment	Split across independent custodians	No single actor could have fabricated the approval; the approved code ran unmodified	Provider conduct beyond the boundary; the hardware supply chain itself

The phone step, precisely: the biometric is the unlock — never the root

When people hear "approve it on your phone," many picture the app scanning your face or matching your voice — and they're right to be suspicious of that picture, especially now. An app-managed camera or microphone flow is exactly what AI has learned to beat: synthetic faces, cloned voices, replayed clips. And even when recognition works, all it produces is a yes/no from the app — nothing that binds you to this specific action.

L2 is built the other way around:

Two consequences worth spelling out. Privacy: nothing biometric is ever captured, stored or transmitted by the governance layer — no face images, no fingerprint templates, no voiceprints. The platform keeps the biometrics; the governance layer only ever sees a signature, so there is nothing biometric to breach. And the AI-era point: a synthetic face can beat a camera; it cannot conjure a signature from a key it does not hold. Even a fooled biometric on a stolen phone still requires that physical phone, in hand — remote, scaled attack has nothing to grab. Voice is never an approval factor here; at most it's an accessibility aid.

And one fair objection deserves a straight answer: isn't the Secure Enclave still Apple's silicon — a chip maker's root by another name? The distinction that matters is custody versus manufacture. The enclave vendor built the vault, but your key is generated inside your device, holds no copy anywhere, and signs nothing without you present — the manufacturer cannot produce your signature today, and cannot retroactively forge yesterday's. Attestation is different in kind: there the chip maker's own provisioned key actively signs every claim, so the vendor sits in the verification loop forever. You do still trust the safe-maker's engineering at L2 — which is exactly why L3 exists: a dedicated device built around a smartcard-class secure element, the kind that ships with chip-level EAL5+/EAL6+ Common Criteria certification — the same tier as banking cards and passports — from a vendor you choose. And why L4 splits authority across devices and vendors. No layer removes trust; each layer shrinks it, diversifies it, and keeps custody with you.

The chain has to end at a root your organization holds

The machine side of trust is genuinely improving — attested execution and confidential computing can increasingly prove that approved code ran unmodified. That end of the stack is being mapped well by practitioners like Imran Siddique, creator of the Agent Governance Toolkit. But every root in those chains belongs to a chip maker or a cloud. The human side — who had the authority, and did they really exercise it — can't be outsourced to either.

That's the direction we're building toward at Proofpane: agents governed by policy in the middle, every event landing in a tamper-evident log a third party can verify offline, and at the top, human authority anchored to keys the customer organization itself holds. We've been sketching that top layer as ProofKey — the customer-held hardware root previewed at the top of this piece. It's a concept, not a product; but concepts are where standards start.