Assurance
What is provable authorization for AI agents?
Provable authorization means being able to demonstrate afterwards that a specific action was permitted by a specific rule — not that it looked normal at the time. It requires two properties: the decision has to be deterministic, so it can be reproduced, and it has to be recorded at the moment it was made rather than inferred from logs later. Probabilistic detection satisfies neither.
What makes a decision provable
Three properties have to hold together, and dropping any one of them turns evidence back into an assertion.
- Reproducibility. Re-evaluating the same action against the same policy returns the same decision. This is why the enforcement layer cannot be a model: a scored decision cannot be replayed, because the scoring model, its threshold, and its baseline have all moved since.
- Attribution. The record names the rule that produced the decision, not a summary of why the system felt uneasy. "Blocked by SoD rule AP-04" is a control that can be tested. "Flagged with 0.87 confidence" is the start of an investigation.
- Contemporaneity. The record is written at the moment of the decision. Evidence assembled afterwards from application logs, gateway traces, and ticket systems is a reconstruction — a plausible account of what probably happened, produced by whoever did the assembling, months later.
The third is where most enterprises actually fail, and it fails silently. Nobody discovers that their agent evidence is a reconstruction until an auditor asks for a specific action and the answer takes three weeks to produce.
What an audit record has to contain
An auditor asking "who authorized this action?" is asking a compound question. A record that answers it fully contains:
- Which agent attempted the action, and which person or workflow it was acting for. Both, because delegated authority is the thing being tested.
- The action itself: the tool, the operation, the parameters, and the system of record it targeted. Parameters matter — they are what determine whether the action crossed a threshold.
- The policy evaluated, at the version in force at the time, and the mapped scope it was evaluated against.
- The decision returned — allow, block, or escalate — and the moment it was made.
- The named approver, their decision and their timestamp, wherever the action was escalated.
- The upstream path: which model, gateway, and agent harness the action moved through.
LangGuard records this through GRAIL — Governance AI Runtime Links — as a linked context graph rather than a flat log line, so the relationships between agent, human, policy, and action are part of the record rather than something to be joined afterwards.
Transparency is not the same as explainability
The two get conflated, and the distinction decides what kind of evidence you end up with.
Explainability is the discipline of producing a human-readable account of why a model produced an output — feature attributions, saliency, counterfactuals. It is approximate by construction, because it is a second model's account of a first model's behaviour, and it remains an active research problem.
Transparency in authorization asks for something much simpler and gets it exactly: which rule applied, and what it decided. There is no approximation involved because there is nothing to approximate. The rule is a written artifact, the decision is a comparison, and the record cites both.
This is the practical argument for keeping models out of the enforcement path. Governing agent actions with a model means inheriting the explainability problem for the governance layer as well as the agent, and having to defend an approximation at exactly the moment precision matters most.
Evidence as a by-product, not a project
The usual arrangement treats audit as a separate workstream: the agent runs, systems emit logs, and someone later builds a report by correlating them. That model breaks for agents for a specific reason — the logs record effects, not authority. An application log says a record changed. A gateway log says a call was routed. Neither says the action was permitted, by which rule, on whose authority, because no component ever made that determination.
When authorization happens in the path of the action, the determination exists, and recording it is nearly free. Evidence becomes a by-product of enforcement rather than a reconstruction of it. There is nothing to assemble at audit time because nothing was ever missing, and quarterly reporting draws from records that already answer the question rather than from logs that have to be interpreted into an answer.
Common questions
What evidence does LangGuard produce for an agent action?
A record per decision, written when the decision is made, containing the agent that attempted the action and the person or workflow it acted for, the tool and operation attempted with its parameters and target system, the policy evaluated and the scope it was evaluated against, the allow, block, or escalate returned, the named approver and their decision where the action was escalated, and the upstream model, gateway, and harness path. Denials are recorded on the same terms as approvals, which matters more than it sounds: demonstrating that a control fires is how you show it exists.
How is this different from logging or observability?
Logs record what happened; authorization records record what was permitted and by what. The difference is not verbosity but the presence of a determination. An observability platform can trace an agent action in exhaustive detail and still not contain the sentence an auditor needs, because tracing sits beside the execution path rather than in it and never ruled on anything. This is why evidence assembled from logs is a reconstruction: the authorization fact was never captured at the time, so it has to be inferred later from things that were.
Can an auditor replay a decision from months ago?
Yes, and that is the practical test of provable authorization. Because the decision is deterministic and the record cites the policy version in force at the time, an auditor can take an action from March, evaluate it against March's policy, and get the answer the system gave then. Tightening a rule since does not retroactively recharacterise the earlier action or obscure what the rule was. This is what auditors mean when they ask about the control environment during the period under review, and it is not a question a probabilistic system can answer at all.
What does tamper-evident mean for an audit ledger?
That an alteration to a past record is detectable rather than merely prohibited. Access controls stop people who follow the rules; tamper-evidence means that if a record is changed after the fact, the change is visible on inspection. For agent governance this matters because the records are the primary evidence of control operation — if they can be edited without trace, an auditor has to treat the whole set as an assertion by whoever administers the system rather than as an independent record of what occurred.
Does provable authorization help with anything other than audits?
Incident response benefits most immediately. When something goes wrong, the question is what the agent did, in what order, on whose authority, and what else it was permitted to do — and those answers already exist rather than needing reconstruction while the incident is live. The same records support access reviews, since what an agent actually exercised is more useful than what it was theoretically granted, and they make change safe: you can see which actions a policy would have affected before you tighten it.
See what your audit record for an agent action looks like.
LangGuard maps your complete agent action surface in minutes. Free for the first five managed agents, with every Scope included from day one.