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." That includes your cloud's built-in approval workflows: an approval that exists only in the platform's own logs is the audited system grading itself. 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

(Numbered R0–R4, matching architecture spec v1.2.0 §16.3. This page numbered the same ladder R1–R4 until 2026-08-08, and L1–L4 before that; the lettering keeps it from ever being conflated with the spec’s conformance Level 1–3, which is a different ladder. Mapping from the older numbering: the click was R1 and is now R0; the single signature rung R2 splits into R1 when the hardware claim is self-asserted and R2 when attestation chains to an independently certified root; R3, R3-dev and R4 are unchanged.)

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

These R-numbers mean one thing only: how hard an approval is to fake. The architecture has a separate conformance ladder — observed, governed, provable — about how much of your AI work is reached at all. It used to be numbered too, which made merging the two almost inevitable; the numbers there are gone for that reason. A deployment can be fully provable and still approve everything with R0 clicks.

Level	Mechanism	Where the key lives	What it proves	What it does not prove
R0Software 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
R1 · R2Per-action key signature two rungs, and the difference is measured R1 · l2_standard phone or laptop biometric R2 · l2_high security key, attestation chains to a certified root	A device-bound, non-exportable key signs this one action, with nonce and expiry. Which rung it lands on is not a choice: a phone or laptop biometric (Secure Enclave / TPM) classifies l2_standard and sits at R1, because nothing independent confirms what the key is. l2_high — R2, the one we call hardware-backed — additionally requires the authenticator’s attestation to verify and chain to a FIDO-certified root, which in practice means a security key, screen or no screen.	Inside your phone or laptop’s protected hardware, or on a key you hold	The key's holder authorized this exact payload: replay-proof, per-action	Display integrity on a compromised device: the summary is app-rendered — look at the key in the picture, it has no screen, so what it signs is whatever the computer handed it. The biometric is the unlock, never the root. Removing that assumption is the entire reason R3 has its own display
R3Dedicated-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
R4Multi-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. 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.

The signature rungs — R1 and R2 — are 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. And even on the day deception wins, the record it leaves is not “the AI silently did X.” It is “this person was shown exactly this, and confirmed.” Accountability survives the failure of judgment; that is the entire design goal. Voice is never an approval factor here; at most it's an accessibility aid.

"This is just passkeys," a security veteran will say. Same silicon, same gesture, different job. WebAuthn proved this hardware path years ago. But a passkey answers login ("is the account holder's device present?") once, at the start of a session; everything after that first hello rides on the session. Accountability needs the other end of the interaction: a signature over this action (this refund, this policy version, this export), minted at the moment of decision. Authentication opens the door; authorization signs the deed. Banking regulators drew exactly this line when PSD2 refused to accept "logged in" as approval and demanded a fresh signature dynamically linked to each transaction.

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 R1 and R2. That is exactly why R3 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 R4 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.