Evidence and audit trails as OS services for AI agents

You shouldn't have to reconstruct an agent's work from scattered logs after it changes a file. An AI agent audit trail should let you inspect the instruction behind an action, the evidence it used and the change it actually made. Without that record, you're left asking the same agent to explain itself after the fact. Its explanation may sound convincing while leaving the mistake untouched.

What an AI agent audit trail should explain

An AI agent audit trail is a connected record of what an agent attempted, what authorized it, which evidence it used and what happened. In an operating system built for an AI user, we argue that keeping this record should be a system service, available across tools and preserved across sessions.

Our AI operating system explainer places evidence and recovery beside identity, memory, tools and permissions. The practical consequence is that a task's history must survive a change of app or model. You should be able to follow the work without joining different vendors' logs by hand.

The system needs to connect an instruction to the steps taken under it. A file edit should point back to the source the agent read, the permission it used and the resulting file version. That lets you examine the basis for the edit even when the conversation has ended.

Why chat logs and app logs leave gaps

A chat transcript records what was said. An app log might record that a request succeeded. Neither establishes that the agent changed the intended file using current evidence. Once tools can change state, the useful record has to connect the agent's request to what the tool and the destination observed.

Consider an illustrative document task. You ask an agent to update a draft from the latest source notes. It reads an old summary from memory and writes a confident revision. The final response says the task is complete. A successful write tells you that bytes reached a file; it doesn't tell you whether those bytes came from the right notes.

Yiqi Wang and colleagues make this distinction in their survey of evidence tracing and execution provenance. They explain that answer accuracy cannot establish the evidence behind a claim, justify a tool call or reveal how memory affected later decisions. Their framework connects those records to debugging, audit and recovery.

This matters for a desktop AI agent working on files and apps just as much as for a large automated workflow. Your draft is still wrong even if every request returned successfully.

What a useful AI agent audit trail records

Start with the action you may need to explain later. Keep enough context to identify the task, establish the authority behind it and compare the intended effect with the observed result. Use this checklist to decide whether you could reconstruct the action from the record.

Evidence to retain for a consequential agent action

Record	What to retain	What it lets you check
Intent	The instruction, task identifier and constraints in force	Whether the action served the work you requested
Authority	The acting agent, authorizing party and applicable approval or grant	Whether the agent acted within the authority it received
Evidence used	References to the source versions and memory entries the agent consulted	Whether the decision rested on current, relevant information
Tool action	The tool, target, relevant arguments and attempt identifier	Which operation was attempted against which resource
Policy decision	The rule version, allow or deny result, and any required review	Which boundary the system applied before allowing work
Effect	The tool response, observed state change and unresolved uncertainty	Whether work completed, failed or still needs inspection

Each action needs a stable identifier so its authorization, execution and result can be joined. A retry needs its own attempt record while remaining attached to the original operation. Otherwise, a reviewer may mistake repeated attempts for separate tasks or assume that a timeout means nothing happened.

The permissions policy supplies the authority boundary. The trail preserves which grant applied to this particular action. Recording that a person approved something is too vague if the file changed after approval. Bind the approval to the version and scope it covered.

Evidence references need care too. A source URL can change; a stored copy or version identifier makes the reference useful later. Keep credentials out of routine records, restrict access to sensitive evidence and record deliberate redactions. A record that exposes every document to everyone creates another problem for the owner.

A saved rationale can help explain the agent's stated basis for acting. Treat it as a statement to check against evidence. It cannot establish what the model internally relied on, and fluent reasoning cannot substitute for an observed result.

Record before execution, verify after it

For an action that changes state, the system should durably record the proposed operation and authorization before allowing it to proceed. After execution, append what the tool reported and what could be verified. If the result is uncertain, preserve that uncertainty instead of marking the task complete.

The Agent Audit Trail Internet-Draft, revision 07, makes timing explicit. It requires pre-execution records for specified denials and escalations, and a principal identifying whose authority the agent used. Section 5.2 recommends independent recording at trust level L2 and above. This is a work in progress, not an adopted IETF standard.

The draft also specifies separation between an independent recorder and the agent's security identity, with signing keys the agent cannot access. It uses hash chaining to expose changes to recorded history, while warning that a valid chain alone cannot prove its end is complete. Missing records remain a problem even when the records you have pass verification.

Our design argument follows from that distinction: the recorder belongs at the boundary through which actions pass. A helper that an agent may skip cannot provide complete coverage. The system needs to observe every supported route that can produce the effect, including routes used during retries and recovery.

There is still a gap between allowing an external action and learning its outcome. If the process crashes in that gap, the next run needs an unresolved action to investigate. An absent completion record must not become permission to repeat the action blindly.

Observability and auditability answer different needs

Agent observability helps an operator understand execution, including slow steps, failed calls and unexpected behavior. Auditability adds an accountability requirement: a reviewer must be able to reconstruct a consequential action from records whose origin and integrity can be checked. The same event data can support both, but a performance trace does not automatically satisfy that requirement.

Two uses of the same execution history

Use	Example evidence	What remains to establish
Diagnose execution	A trace shows that a file update timed out	Whether the destination changed despite the timeout
Audit an action	A linked record identifies the authorized file version and the resulting change	Whether that change satisfied the owner's instruction

Sending logs to a monitoring service can make them easier to search. It cannot recover an approval reference that was never recorded. Nor can a chart of successful calls establish that the agent used the correct source. Decide what the record must establish before choosing where to display it.

For the owner, access matters as much as collection. The case for owning agent capability extends to the work's history. A useful trail should remain inspectable when you replace the model or stop using an app.

Runtime contracts need evidence to check them

OS research is asking what the runtime must guarantee when an agent chooses its own actions. That moves the discussion beyond whether a task received a success label. A guarantee about preserved state or valid authority needs evidence at the point where that guarantee could fail.

The AgenticOS workshop at SOSP 2026 lists observability, provenance and debugging among its topics. Laurent Bindschaedler's keynote abstract proposes contracts for effect, state, composition and intent, and calls for "the evidence needed to check it". A contract names the required behavior; the execution record gives a reviewer something against which to test it.

In his published keynote notes, Bindschaedler describes a workflow that reuses an approval after a rebase changes the code. The relevant evidence is the approved revision and the revision that actually merged. A general log entry saying that approval occurred leaves the failure hidden.

Ankur Sharma and Deep Shah's June 2026 AOS paper includes "observability and audit" among system responsibilities and proposes evaluation based partly on auditability and operator understanding. Their August reference architecture assigns auditability to a control and governance plane, with a goal of "reconstructing why consequential actions occurred".

Those papers propose architectures, including arrangements above existing operating systems. They do not prove that ERIKA implements their mechanisms. Our conclusion is narrower: when authority, state and tools span an agent's lifetime, evidence must cross those same boundaries. Leaving each app to define an unrelated history makes that harder to inspect.

Use the evidence to decide what can resume

Recovery starts by establishing which effects already happened. The record should let the system distinguish a blocked action from an attempted action with an unknown result. That difference determines whether it can proceed, needs to inspect the destination or must ask the owner to resolve the uncertainty.

Return to the illustrative draft update. If the trail identifies an outdated source, follow its links to the revisions that used it. Mark those results as needing review and regenerate the affected work from the correct source. That is why memory needs provenance: a remembered claim should retain a connection to where it came from.

Before retrying a timed-out write, check the destination for the expected version or operation identifier. If the change already exists, record that observation. If the system cannot establish what happened, leave the outcome unresolved. A retry that creates another effect can make the original failure harder to repair.

Rollback also has conditions. A saved file version may support restoring an earlier state, provided later work is accounted for. An external action may require a separate corrective action or human review. An audit trail supplies evidence for that decision; it does not make every effect reversible.

Evidence and recovery in ERIKA

eFreedom is building ERIKA, its one product, as an operating system whose user is purely AI. Its architecture keeps evidence and recovery with the resident's identity, memory, tools and permissions. The decision to build ERIKA as an operating system puts that responsibility below individual apps and model calls.

The ERIKA product page describes actions leaving records and failed work being inspected, resumed or rolled back. It also states that ERIKA is in active development. The record fields and recovery checks in this article are criteria for evaluating that architecture; they are not a claim that every mechanism described here is already implemented.