The Four-Axis Audit Query: The Log Exists, the Interface to Ask It Does Not

Across ten-plus published auditor and GRC sources, client questions about AI agents deduplicate to 22 canonical forms (see the auditor question bank), and the most asked-about property is the audit trail: it appears in six or more of those questions and in every source organization surveyed. The universal move is "show me the audit trail for a specific decision." Every version of that question is the same query in different clothes, and it always resolves along four axes: by task, by actor, by environment, by time window. Call it the four-axis audit query. The session log is the substrate, and this is the read interface over it. The log that could answer the four-axis query often exists. The interface to ask it does not, anywhere, in any vendor's documentation.

Every auditor question decomposes onto the four axes

Auditors do not ask for logs; they ask for slices. The published question lists make the axes explicit:

The hard questions compose axes. A-LIGN's incident question, "could your organization reconstruct what it did and why," is task plus environment plus time. A SOC 2 Type II sample is actor plus time across the whole audit period. Vanta's distilled standard, "evidence, not policies," and its insistence on continuous monitoring "not point-in-time reviews," is a demand that the time axis cover every day, not the day of the audit. A log you can only read linearly answers none of these on demand.

The log exists; the query interface does not

Several platforms ship a usable substrate, and not one documents an auditor-facing way to query it. Graded against published documentation:

• Anthropic's managed-agents architecture has the strongest substrate in the field: the session is "the append-only log of everything that happened," stored durably outside the containers. But its read interface, getEvents(), returns positional slices built for the brain to resume work after a sandbox dies. Querying per actor or per time window, retention, and audit access control are unstated.
• GitHub Copilot's cloud agent documents that "session logs and audit log events are available to administrators" and links each agent-authored commit to its session log. That covers the task axis. Whether the log is append-only or queryable per actor and time window is not described.
• Cursor's cloud agents store full conversation history per run, with Enterprise retention controls and a per-run record of which environment was used. That is real per-run evidence. No cross-run query API by actor or time window is documented.

The platform-documentation synthesis states the field-wide finding plainly: there is "no auditor-facing, per-actor queryable audit API, even where the underlying log exists." Codex documents only a "work log." Jules documents a plan and a diff, which is visibility, not a trail. Brex's published build log does not discuss auditability at all. See the platform documentation survey for the full matrix.

One fence: absence of documentation is not evidence of absence. Some of these platforms may answer four-axis queries internally. But a control you cannot point to in writing is a control you cannot put in an audit.

The absence is the finding

Vendors document heavily exactly where single-user safety lives, and go silent exactly where auditor-scale evidence lives. Sandboxing, secrets handling, and egress controls are competitive surface area with detailed docs. The query interface over the resulting logs, the thing a Type II sample or an incident reconstruction actually consumes, appears in no vendor's documentation. The gap is not random; it clusters on the properties that only matter once a team and an auditor are involved. Every platform moved the execution off the laptop. The evidence interface stayed behind.

This is the same pattern the laptop never had to answer generally: the laptop model never needed a query interface, because "the human at the keyboard" was the whole answer.

The interface to demand: keyed on four axes, composable, exportable

Whether you build or buy, hold the audit trail property to this bar. The session log is the substrate; this is its read side:

• Keyed on all four axes, composable. "Everything actor X did in environment Y between these dates" is one query, not a grep project.
• Append-only and externally durable, so the answer survives the sandbox and cannot be quietly rewritten.
• Retention spanning the audit period, with access control on the audit reads themselves.
• Exportable, because the entity running the query is eventually not you.

The corpus is silent on what this API should look like in detail; no auditor has published a schema, and no vendor has shipped one to copy. The four axes are the spec until someone does. A system that answers them produces audit evidence as a byproduct of normal operation, which is the only way evidence gets produced at AI volume.