What should an AI agent's audit record contain?

An AI agent’s audit record should name who delegated the run and within what limits, list the records the agent read, show what it decided and which transactions it wrote, give the result, and keep the policy text as it read at run time. Oracle’s Fusion Claw Outcome Receipt, launched 29 September 2026, is designed to keep all six.

Most agent audit trails today are API logs with an agent’s name attached, built for scripts whose code was the policy. Oracle has now published a concrete alternative. Facts in this post were checked on 30 September 2026.

What does Oracle’s Outcome Receipt record after a Fusion Claw run?

According to Oracle’s Fusion Claw announcement, an Outcome Receipt is written when a run finishes and records the authority applied, the evidence used, the decisions made, the actions and transactions executed, and the result. Natalia Rachelson, Oracle’s senior vice president of Fusion Applications and product management, told SiliconANGLE it also stores the full policy text.

Fusion Claw is the runtime behind Oracle’s Fusion Agentic Applications, and it shipped with 25 new Claw-powered apps, taking the portfolio to 75, per SiliconANGLE’s report on the launch. Customers govern it through an Enterprise Operating Envelope that holds their policies, permissions, risk thresholds, decision rights and approval requirements. The receipt is the evidence that the envelope applied to a given run.

Here is what each field answers, using an illustrative invoice-matching run (the example values are ours, not Oracle’s):

SiliconANGLE noted Oracle “did not provide measured cost savings or evidence of how the applications perform in production”, so this post judges the design, not the results.

Why does storing the policy text matter more than logging the action?

The question an auditor asks six months later is why an action was allowed, and the answer is a policy that has usually been edited since. A log line such as “agent updated invoice 4481” says what happened. A record that kept the policy as it read at run time answers why.

Agent policies sit in approval matrices, prompt templates, tool allowlists and permission rules, and teams tune them weekly while a rollout settles. A record that stores only a policy ID depends on an append-only policy history, and most teams do not keep one for their agent rules.

A team that can add only one field to an existing agent log this quarter should add this one. A content hash plus an immutable policy history does the same job as full text with less storage, and keeps sensitive thresholds out of a widely read log. Oracle has not said how full-text storage behaves at high run volumes.

What does an AI agent audit record capture that API logs miss?

Standard API logs usually miss authority and evidence. A typical log records the write: endpoint, record ID, timestamp and the credential that made the call. It rarely records reads, and when several agents share one service account, it cannot say which person handed the agent the work or what limits applied to that delegation.

Reads matter because a decision is only as good as what the agent looked at. If an agent approved a payment after reading a stale supplier record, the write log shows a valid approval and nothing else. Authority matters because delegation is the control: in Fedora’s rogue agent incident, an agent worked under a borrowed contributor account, so every log entry named the wrong party.

Why does separating reasoning from execution matter for the record?

The split gives the record a fixed point. In Fusion Claw a frontier model reasons and plans, then deterministic Fusion computation executes the work. Rachelson told SiliconANGLE that Claw runs in an isolated environment that stops the model from updating Fusion business objects directly, so every write passes through code that can check policy and log the outcome.

You cannot replay a model’s reasoning and expect the same tokens. You can replay a deterministic write, and you can guarantee it was logged, because the code that performs it is yours.

Agents built outside Fusion can follow the same pattern: the model never holds a raw credential, and every write goes through a layer that checks the request and records it. Regulators ask for that per-action record too, as our post on EU AI Act logging at the action layer covers.

What happens to an AI agent audit record when a run crosses vendors?

The record splits into one log per vendor. Oracle can fill every field because runtime, apps and data all sit inside Fusion. An onboarding agent that reads a hire from the ATS, creates the employee in the HRIS and sets pay in payroll writes to three systems, each with its own log format, and none of them knows the calls were one run.

Claw can also work with third-party systems through APIs, MCP and the A2A protocol, per SiliconANGLE, but the announcement does not say how much of an external call the receipt captures.

Outside a single-vendor suite, the cross-vendor record has to come from whatever sits on the call path for every system. That is why our team put Permission Policies on the request path at StackOne. Each request carries the member the agent acts for, StackOne refuses a denied tool or input value before the business system is called, and it masks denied output fields on the way back. The request log records every evaluated policy with its mode and decision, including what a Monitor only rule would have done, across 540+ connectors and 33,000+ actions (stackone.com, checked 30 September 2026).

A call-path log cannot see the model’s reasoning, so the decisions field still comes from the agent runtime’s own trace, joined on a run ID. Field-level rules give the log something specific to record, such as letting an agent read a start date while refusing salary writes.

What should a CIO or CFO ask before an agent writes to finance or HR?

Ask the vendor for the record of one real run and check it against six questions: who delegated the work, what the agent read, what it decided, what it wrote, what happened, and which policy text allowed it. A vendor that can only show a sample schema has not tested its record against a real audit.

1. Authority. Does the record name a person or role who delegated the run, or only a shared service account?
2. Evidence. Are reads logged with record IDs, or only writes?
3. Decisions. Can you see what the agent chose at each step, linked to the calls it made?
4. Actions. Does every transaction carry the run ID, in every system it touched?
5. Result. Does the record say whether the outcome matched the request, including partial failures and escalations?
6. Policy text. Can you retrieve the exact policy version that allowed each write, as it read on the day?

Also ask whether the model can write to a system directly, and whether a changed policy can run in a monitor mode first. Our post on rolling out agent policies in monitor mode first walks through that sequence.

Pick one agent write from last week and find the exact policy version that allowed it. If that takes more than a few minutes, an auditor will take longer.

If your agents write to HR or finance systems across several vendors, the StackOne Permission Policies page shows what a per-call policy decision looks like in the request log.