LLM-as-a-Judge Is Not Authorization
An inline LLM judge can block an action before execution. That stop comes from the surrounding gate. Authorization still requires admissible inputs, an accountable authority chain, fail-closed verdict semantics, and independent reconstruction.
The harder case
The impossibility argument against observability-based authorization begins with temporal order. A record produced after execution cannot constitute the pre-execution permission on which that execution was supposed to depend. The obvious reply is to move an evaluator in front of the action. An inline judge model receives the proposed action before execution, evaluates it against instructions, and returns a label on which the surrounding system may block. Positionally, this resembles enforcement. It is therefore the residual case left by the impossibility result: it closes the temporal gap by moving assessment before execution, but it does not close the authorization gap.
The pattern earned its place as an evaluation technique: offline evals, quality measurement, regression triage, telemetry. Depending on their use, these are Visibility or Alignment functions, competently performed. Nothing here argues against them. Some vendor materials now describe the same pattern as real-time policy enforcement and as a semantic runtime guardrail for evaluating whether outputs or tool calls match policy. Lasso Security and Domino Data Lab provide current examples.
The claim examined here is therefore precise. It is not that a language model can never participate in authorization. It is that LLM-as-a-judge does not, by itself, constitute authorization.
The judge is not the gate
In an inline LLM-as-a-judge deployment, the wrapper can withhold execution, but the judge contributes an assessment. That assessment does not by itself establish the authority, input provenance, verdict semantics, or replay path required for authorization. The question is therefore not merely whether the deployment can stop an action. It is whether the complete architecture converts a model-generated assessment into a pre-execution authorization verdict that is non-bypassable, fail-closed, and independently reconstructable.
The model supplies the judgment. The wrapper supplies the stop. Authorization requires the boundary to supply the verdict and the authorization artifact.
The judge sits in the execution path. Sitting in the execution path does not make it an authorization boundary.
Consider an agent proposing a $7,500 refund. A judge may label the request consistent with company policy. That assessment, by itself, does not establish the requester's identity, delegated refund authority, transaction ceiling, account scope, applicable policy version, or separation-of-duties requirements. The judge's label may be relevant evidence. It is not the act-specific authorization verdict.
Three questions
The Authorization Boundary Integrity Model gives the test. A complete authorization boundary satisfies three independent properties: Output Integrity, Input Integrity, and Replay Integrity. Holding one tells you nothing about whether you hold the others. Locate the inline-judge pattern by the properties it satisfies and the ones it only appears to.
Output Integrity. Potentially satisfied by the surrounding enforcement. A wrapper supplies Output Integrity only if every relevant execution path traverses it, it blocks before side effects, and timeout, model failure, or malformed output cannot become permission. The judge does not supply this property. The wrapper does.
Input Integrity. Not supplied by the judge pattern. The judge's label does not establish the origin or admissibility of the evidence on which it relied. Where policy instructions and the material under judgment enter the same inference context, message roles do not themselves create an independently enforced admissibility boundary. Input Integrity must therefore be supplied by independently enforced provenance and admissibility controls over the bound inputs. The sharper consequence of the shared inference context is worth stating plainly: the material under judgment can participate in its own evaluation. Shi et al. demonstrated an optimization-based prompt-injection attack in which content embedded in a candidate response steered an LLM judge toward the attacker-selected result.
Replay Integrity. Not established by a transcript. A logged prompt, response, and rationale show what the model emitted. They do not let an independent third party rederive the assessment unless the operative model, prompt, version state, configuration, and inference path are preserved and reproducible. A provider-hosted deployment satisfies that condition only if the provider fixes, preserves, and makes available enough of the operative model and inference state for independent replay. If the judge's assessment is instead fixed and carried as an input to a separate deterministic authorization function, the resulting authorization verdict can be reconstructed without rerunning the judge.
The placement follows. The minimal fail-closed, non-bypassable wrapper-plus-judge architecture occupies the output-only cell: the wrapper supplies Output Integrity, while the judge pattern supplies neither Input nor Replay Integrity. The broader class is not structurally confined to that cell. Additional controls can supply the missing properties. Greater judge accuracy cannot. Accuracy can improve the assessment; it cannot create an authority chain.
The five tests
The vendor-neutral Five Tests Standard states what the Proof-Carrying Decision for an effect-bearing AI action must establish: Stop, Ownership, Replay, Escalation, and Provenance. In FERZ's register, the authorization artifact is an implementation of that proof-carrying decision object. Run the inline-judge pattern through each test.
| Test | What the inline-judge pattern can show | What it does not establish | Disposition of the pattern alone |
|---|---|---|---|
| Stop | A wrapper waits for a label and may block execution | Coverage of every execution path, absence of prior side effects, non-bypassability, and fail-closed behavior on error or timeout | Conditional on the surrounding enforcement |
| Ownership | An authority selected the model, prompt, or rubric | How the governing authority and policy map through the inference step to the act-specific verdict | Not established |
| Replay | The prompt, response, label, and rationale can be logged | Independent reconstruction from the bound inputs, policy and version state, authority chain, and proposed action | Not established; requires a reproducible verification path |
| Escalation | A threshold or label may route the case to review | ABSTAIN as an explicit verdict that blocks execution pending authorized human override | Can pass only if policy defines the mapping and the wrapper enforces the hold |
| Provenance | Model, provider, and input identifiers may be recorded | The admissible origin of every input grounding the verdict | Requires a separate provenance mechanism |
On Escalation, the distinction bears repeating in full. An uncertainty score is not itself ABSTAIN. It becomes ABSTAIN only when governing policy maps it to ABSTAIN and the boundary blocks execution pending authorized human override.
On Provenance, one note of standard discipline. Under 5TS v1.2.0, Provenance is a normative requirement. The current machine-checkable conformance bundle covers Stop, Ownership, Replay, and Escalation; machine-checkable Provenance vectors are deferred until input-origin binding is specified. The requirement applies now. The conformance vectors are pending. Provenance means established origin of the inputs grounding the verdict. Origin, not truth.
Ownership through the inference step
Approving the model, prompt, or rubric identifies who selected the instrument. It does not by itself show how the authority chain reaches the act-specific verdict. That chain must survive the inference step and be represented in the authorization artifact.
This is not a demand for per-result guarantees. Organizations accept accountability for probabilistic instruments in many domains without guaranteeing each result. The requirement is accountability, not prediction: the act-specific verdict must map to an identified authority chain, and the authorization artifact must preserve that mapping.
The regress
One proposed repair is a second model. A judge for the judge, a critic reviewing the critic. Placing a second probabilistic evaluator in front of the first can improve detection, but it does not terminate the authorization question. For automated execution, the regress terminates only when a non-bypassable authorization function issues a verdict that can be independently reconstructed from fixed, bound inputs and the applicable policy, version, and authority state. If the automated boundary cannot reach a deterministic verdict and designated human authority is required, it must ABSTAIN. ABSTAIN blocks execution pending authorized human override.
The drift
There is a quieter failure that surfaces only at audit time. The operative assessment function may change when the provider changes the model or endpoint on its own release schedule. Unless the deployment pins and preserves the applicable model, prompt, configuration, version state, and inference environment, the operator may be able to show which endpoint was called without preserving the function needed to reconstruct the assessment.
Yesterday's label may not be reproducible against today's endpoint. A record of the endpoint call can show what answered without preserving the function needed to reproduce the answer.
The remedy is a position
An LLM judge does not fail by being an LLM. The category error occurs when its assessment is treated as the authorization verdict rather than as an input to one.
In the admissible configuration, the judge's assessment is fixed at decision time and bound with the proposed action, the material assessed, its provenance, the judge prompt or rubric, the model and version identifier, and the relevant inference configuration. A separate deterministic boundary evaluates the proposed action and the carried assessment under explicit policy and authority state, then issues ALLOW, DENY, or ABSTAIN. If the assessment is missing, indeterminate, or cannot be bound, the architecture fails closed.
Replay then establishes that the authorization verdict followed from the carried assessment and governing policy. It does not prove that the judge's assessment was substantively correct. That distinction is exactly why the Authorization Boundary Integrity Model treats Replay Integrity and Input Integrity as independent properties.
Judge-as-input is the admissible configuration. Judge-label-as-authorization is the category error.
A judgment is not a verdict
The claim throughout has been architectural, not empirical. This piece does not measure how often deployed judge configurations fail these tests in production. It shows why the pattern, by itself, cannot satisfy them.
A judgment is not an authorization verdict. A model in the execution path is not an authorization boundary. Authorization exists only when the proposed action cannot execute without a fail-closed, act-specific verdict grounded in admissible inputs, mapped to an accountable authority chain, and independently reconstructable.
References
Meyman, E. (2026). The Authorization Boundary Integrity Model. FERZ, Inc. https://ferz.ai/articles/authorization-boundary-integrity-model. https://doi.org/10.5281/zenodo.20929115
Meyman, E. (2026). On the Impossibility of Observability-Based Authorization. FERZ, Inc. https://doi.org/10.5281/zenodo.19647542
Meyman, E. (2026). Five Tests Standard (5TS), v1.2.0. FERZ, Inc. https://doi.org/10.5281/zenodo.21040295
Shi, J., Yuan, Z., Liu, Y., Huang, Y., Zhou, P., Sun, L., and Gong, N. Z. (2024). "Optimization-based Prompt Injection Attack to LLM-as-a-Judge." Proceedings of the 2024 ACM SIGSAC Conference on Computer and Communications Security, 660–674. https://doi.org/10.1145/3658644.3690291