Auditability Is Not Authorization
← Back to Articles
AI Governance9 min read

Auditability Is Not Authorization

What the Record Shows and What the Boundary Decides

Auditability shows what an AI agent did and whether it complied. By itself, it does not establish that the action depended on authorization before it ran.

Edward MeymanOctober 9, 2026
AI agent auditabilityruntime authorizationpre-execution authorizationAI governanceauthorization artifactnon-bypassable authorization boundaryfail-closedinput provenanceABSTAIN verdictFive Tests StandardAuthorization Boundary Integrity Modelagent accountability

1. When auditable is taken for governed

A growing body of work treats auditability as a first-class requirement for AI agents that act. The requirement is well founded. Once an agent can call tools, move data, and trigger effects outside itself, its consequential actions must remain reconstructable, checkable against policy, attributable, and supported by trustworthy evidence.

The risk arises when that requirement is treated as sufficient for governance. Auditability can establish what an agent did and whether its actions complied with policy. It does not, by itself, establish that those actions depended on authorization before execution. An organization that treats it as sufficient will invest in better records and believe it has acquired control over what its agents may do.

Auditability and authorization establish different properties, and neither implies the other. With auditability, an organization can show after the fact what its agent did. With authorization, it can show that the agent was permitted to do it before it happened.

2. Three questions, three objects

Three properties are often discussed as though they were stages of one capability. They answer different questions, at different times, about different objects.

PropertyQuestion it answersWhen the answer is formedWhat it governs
ObservabilityWhat can be seen?During and after executionVisibility into behavior
AuditabilityWhat can be established afterward?After execution, from the evidence left behindThe sufficiency and trustworthiness of that evidence
AuthorizationWhat may execute?Before release, at the boundaryWhether the action takes effect at all

These are not rungs on a ladder. Adding fields, signatures, or retention to a record improves auditability. It does not move the record closer to being a permission.

Authorization is a different object: a determination, formed before release, on which release depends. Why observation cannot stand in for that determination is the subject of a separate result [Impossibility].

Monitoring creates evidence of what occurred. Runtime authorization creates evidence of what was permitted before occurrence. An audit may examine either kind of evidence. What distinguishes authorization is that the determination permitting the proposed action must exist before that action is released.

3. A complete record is not a permission

Consider one action across three systems. An enterprise agent prepares an export of customer records and transfers it to an external recipient.

  • System A executes the transfer and records it completely: the call and its arguments, the surrounding context, the applicable policy, and the chain of delegation that led to it, all in a record protected against modification.
  • System B checks policy before releasing the transfer through its standard tool interface. The agent can also reach the same recipient through a path the check does not cover.
  • System C releases the transfer only after an authorization verdict is formed at a non-bypassable boundary, on inputs whose origin is established, with enough bound evidence for an independent party to reconstruct it. A DENY blocks execution; an ABSTAIN blocks it pending authorized human override.

System A is fully auditable. An auditor can later determine what happened, in what context, whether it complied, and who set it in motion.

The auditability conditions described above concern whether sufficient, trustworthy evidence exists to reconstruct and assess an execution. None of them requires the execution to have depended on an authorization verdict.

The consequence is direct. A record that faithfully shows an unapproved transfer is a fully auditable record. The audit will find the violation after the data has left.

Compliance determined after execution is not permission determined before it.

The converse also holds. A system can evaluate policy before execution and block what it should block, yet keep too little bound evidence for anyone outside it to reconstruct why. Execution was mediated, but independent auditability was not established.

Neither property implies the other, which is why an architecture that needs both must specify both. System C describes the architecture FERZ specifies and is building. Sections 4 through 7 explain what separates it from A and B.

4. Integrity of the record is not integrity of the inputs

Auditability frameworks treat evidence integrity as foundational, and rightly so. Append-only storage, hash chaining, and signatures make a record harder to alter without detection. They protect the record after it is written.

They do not establish where the record's contents came from. Return to the transfer, and suppose the recipient address reached the agent through a tool response, a retrieved document, or a persistent memory file that an earlier session modified.

A perfectly protected record will preserve that address, and any verdict that relied on it, exactly as they were. Integrity guarantees the log was not altered. It does not guarantee that the logged inputs were admissible [Taxonomy].

The Five Tests Standard states this requirement as a test, Provenance. Provenance means established origin of the inputs grounding the verdict; it is origin, not truth. An input of established origin can still be wrong, but a verdict resting on an input of unknown origin cannot be shown to rest on what it claims.

Authorization that cannot establish the provenance of its inputs is authorization in form, not in substance.

This is why System C's definition names input origin explicitly. A boundary can be complete, fail-closed, and replayable, and still issue a verdict grounded on an input no one can trace. Established origin is necessary but not sufficient: the boundary must also enforce the conditions under which an input may be used. Admissibility is not a layer above authorization; it is what separates shallow authorization from sound authorization.

5. What reconstruction after the fact cannot establish

Two familiar limits bound any reconstruction after the fact. Information that was never captured, and left no surviving trace, cannot be recovered by later analysis. Protection applied to a record later can strengthen it from that point forward, but it cannot certify that the record was unaltered before.

Both bounds point the same direction. Evidence has to exist at the moment it matters, in the form it will be needed.

For an audit, that moment is when the record is written. For authorization, it is earlier. Evidence of permission must exist before the action is released, because release is what it governs.

There is also the question of which policy an audit applies. A retrospective check evaluates a record against a policy the auditor supplies. Unless the policy and its version in force at decision time were bound to the decision, the audit answers a different question: whether the action complies with the policy as the auditor now holds it.

Replay of an authorization verdict requires that binding, fixed at the moment of decision.

FERZ draws a practical consequence. Authorization evidence is not a side effect of enforcement; it is a precondition to release. A record produced alongside an enforcement decision documents that decision. An authorization artifact, by contrast, binds the verdict to the evidence required for independent reconstruction, and release waits on its completeness.

6. A gate is not necessarily a boundary

System B is a real advance over System A. It intercepts the transfer before it takes effect, applies written rules, and can refuse. Pre-execution interception of this kind has become common across agent frameworks, and it should be built.

Interception is not closure. System B's check governs the path it sits on. When the same effect can be reached through another integration, a script, or a direct call, the check governs a route, not the action.

Governance that can be bypassed is not governance; a control that can be executed around is not an authorization boundary. A companion note sets out the conditions that separate an interception point from a boundary: closure over execution paths, decision state, release, failure, reconstruction, and authority [Hook].

Three questions distinguish a gate from a boundary at the interface, without reference to how either is built:

  1. Is release contingent on the verdict? An action that can execute without an affirmative ALLOW at the boundary is not governed by it.
  2. Can the boundary be executed around? Its scope must be declared, and every path to the governed effect inside that scope must pass through it.
  3. What happens when a verdict cannot be formed? If the evaluator is unavailable, an input is missing, or the policy cannot decide, the action does not proceed. DENY blocks. ABSTAIN blocks pending authorized human override. Neither degrades into a soft allow.

A system that records every intercepted call with full fidelity can still fail all three. Its record will show what passed through the gate. It cannot show what went around it.

7. What the boundary must establish

The Authorization Boundary Integrity Model states three orthogonal integrity properties [ABIM]. Three tests in the Five Tests Standard map directly to those properties [5TS].

  • Output Integrity. No unauthorized action executes. The test is Stop: execution can be halted before side effects occur, and no pathway bypasses the boundary.
  • Input Integrity. No verdict rests on inputs whose origin is not established. The test is Provenance.
  • Replay Integrity. A verdict is independently reconstructable from the bound inputs, the policy and version state that applied, the authority chain, and the proposed action. The test is Replay.

Orthogonality is load-bearing: holding one property implies nothing about the others. System A holds none of them, because it issues no verdict for them to govern. System B holds Output Integrity only on the paths it covers, which is to say it does not hold it.

Ownership and Escalation are operational requirements on this integrity core. Ownership requires an identified authority to sign the governing policy before the execution window, with responsibility chains established and attributable. Escalation fixes where custody goes on denial or at a threshold: an ABSTAIN blocks execution pending authorized human override, and escalation is its consequence, not a separate verdict.

Provenance is a normative test of the standard. Machine-checkable conformance for it is deferred until input-origin binding is specified.

Output Integrity cannot be supplied after the fact. An audit can establish whether an action should have been prevented, or whether a boundary did prevent it; it cannot prevent an action that has already run. That control has to exist at the boundary, before release.

8. Conclusion

Auditability is a necessary property of any system that acts in the world, and the effort to make agents auditable is worth making. It establishes what can be reconstructed. It does not establish what may execute.

An authorization boundary that binds its evidence at the moment of decision leaves a record an auditor can use, because that record is the condition of release rather than a description of it. The reverse does not follow. No amount of record quality turns an execution that did not depend on a verdict into one that did.

The record answers for the action. The boundary decides whether there is an action to answer for.

References