Answer whether an agent was allowed to do that, after the fact

The question arrives in a specific shape. Somebody in finance found a refund, or a customer found an email, or an auditor picked a row at random, and the question is whether the agent that did it was allowed to. The first place anyone looks is the current configuration, which answers a different question: what that agent may do today. The role has been edited twice since, and nothing in the configuration says what was in it at the time.

The second place is the access review, and this is the quiet failure that most estates carry. A review recording that agent X holds role Y certifies almost nothing, because role Y is editable and the review does not say what was in it. Six months later a named reviewer’s attestation sits beside a permission set they never saw, and nothing in the record distinguishes that situation from a genuine one.

The third place is the application log, which usually records that the call succeeded and not why it was allowed. That is the distinction between an outcome and a decision, and it is the whole difference between a log and evidence: an outcome tells you what happened, a decision tells you which rule permitted it and which named human the authority traced back to. Logs written by the agent framework are also written by the component under examination, which an auditor will notice before you do.

The fourth is the one people discover during the investigation itself. Refusals are missing. A trace that opens only for requests that succeed is a record of successes, and the interesting evidence in a governance review is the refusal: which agent tried to call which tool it did not hold a grant on, and when. An agent probing for grants it does not have is precisely the pattern an investigation needs, and it is invisible if a refused request never got a row.

The trace id is minted at step 3 of the eleven-step request path — before unicode sanitisation, before the personal-data and injection scanners and before the policy verdict — so a request blocked a millisecond later is recorded rather than missing, and the id comes back on x-acp-trace-id on every outcome including refusals. It cannot be first, because a trace belongs to an agent and authentication has to name one; the opening event carries counts and names rather than content, because at that point nothing has been sanitised, scanned or redacted and no payload text may be persisted yet.

The decision that follows is taken at one place rather than scattered across the path, and the internal order is fixed: engaged kill switches, then agent lifecycle status, then deny-by-default permissions including every link of any delegation chain, then budget and rate ceilings, then the policies whose scope selects this subject. Because it is one function with no input or output of its own, the identical logic decides a request at the gateway, a tool call on the tool path, a replay inside a backtest, and the bundle compiled for a developer’s laptop — so a rule means the same thing everywhere it is evaluated.

What lands on the trace is the reason as well as the verdict. An allow names the role and the resource pattern that produced it. A refusal on a delegation chain names the earliest failing link and out of how many, followed by the ordinary reason that link produced, which is the difference between a five-minute fix and an afternoon. A refusal with no matching allow ends in deny by default. A policy match writes a decision event carrying the policy id, its name, its mode, its action and the detail line explaining why it matched — including for a rule running in shadow, because a shadow policy nobody can see is not a dry run.

One narration detail matters more than it looks and it is worth checking in any product you evaluate. Shadow mode has to be answered before the verdict when a timeline is rendered, because asking what a policy did before asking whether it was live narrates a shadow match as an enforced block — the exact inversion shadow mode exists to let an operator avoid. That went wrong here in precisely that way once, painting a red blocked banner on a decision whose recorded verdict was require_approval, and the fix was to read all three shapes in which the pipeline writes a policy decision rather than only one of them.

Search takes the question in English and turns it into a validated filter object with fourteen allow-listed fields — never into SQL. That is a written decision with its alternatives recorded beside it: natural language to SQL is an interpreter input generated from untrusted text, and trace content is attacker-influenced by construction, since the events table holds prompts, tool arguments and tool results some of which were written by an external party who wanted them read. A read-only database user and a SQL parser narrow that blast radius without closing it; a filter object closes it, because there is no interpreter for a payload to reach.

The cost of that choice is named in the same place as the benefit. Misinterpretation replaces injection as the main failure mode: the model will confidently return a filter meaning something slightly different from the question, and the explanation shown beside the results is the only mitigation and is advisory. So the response carries the interpreted filter, a plain-English explanation naming every field that was set, and whether a model or the deterministic keyword parser produced it, and the console renders each field as an editable chip written into the URL — which makes an interpretation a link you can hand to somebody else.

The expressiveness ceiling is low and deliberate. There is no aggregation, no grouping and no cross-trace correlation, so which agents used the same card number twice is not a question you can ask, and adding a question shape is a schema, validator and query-builder change rather than a prompt change. When no translation model is configured or the call fails, the keyword parser answers instead and the response says which path ran — it is materially worse and it degrades quietly, falling through to an over-broad full-text term rather than raising an error, which returns too much rather than nothing.

Reading the evidence is itself an act, and it is recorded as one. Listing, searching, opening and exporting each append an audit entry naming the actor and the thing acted on: the list and search entries carry the interpreted filter, the teams the account was effectively authorised for and the row count, and the export entry carries the digest of the bundle it issued. Evidence reads are scoped by team, derived from the signed-in account rather than accepted from the request, and the same check is repeated on the detail page and on the export, because scoping the list and leaving the detail URL open is the usual way this goes wrong.