An AI agent audit trail has to survive the handoff
Consider an agent that changes a customer’s account permissions. The application logs the request. A trace connects the agent run to the API call. The identity service records a successful update.
A week later, the customer asks who approved the change and which permissions were granted.
Your engineers can investigate. They have access to the services, know the identifiers, and understand which events belong together. The customer’s security team has none of those advantages. Sending a dashboard screenshot transfers your conclusion. Giving them dashboard access transfers far more information than they need.
An AI agent audit trail has two jobs here: help your team investigate and give the other team evidence it can assess. Those jobs have different requirements.
Telemetry gives you visibility. A handoff needs context.
OpenTelemetry collects and exports traces, metrics, logs, and other signals. It is built for observing systems, and that includes activity across services. Logs can be exported. Traces can cross company boundaries. None of that is inherently confined to one dashboard.
The difficulty is what remains understandable and verifiable after the export.
A reviewer needs to know which system made each statement, which action it refers to, what the record covers, and how to check that it has not changed. They also need enough context to distinguish a permission request from an approval and an approval from an applied change.
A trace identifier helps join events. It does not answer all those questions. A CSV export may contain the answers, but the recipient still needs a way to establish its provenance and interpret its fields.
Sampling adds another consideration. OpenTelemetry’s sampling documentation explains how teams can retain a representative selection of traces. That can be appropriate for diagnosing aggregate behavior. An approval required for reviewing one particular permission change cannot depend on that change happening to survive a sampling decision.
Keep operational telemetry. Define a separate capture rule for the actions that require individual review.
Start with the decision the recipient must make
For the permission change, the customer’s question might be: “Did this update stay within the administrator’s approval?”
That question tells you what to preserve:
| Evidence | Why the reviewer needs it |
|---|---|
| The approval, with its scope | Establishes what the approval system reported allowing |
| The requested permission change | Shows what the caller asked the service to do |
| The identity service’s result | Shows what that service reported applying |
| A later state observation, if available | Helps assess whether the relevant permissions were present afterward |
These are related statements from different points in the workflow. Combining them into a single “success” label would discard the distinctions the reviewer needs.
The issuing system should record only what it can support. An API can report receiving a request and returning a result. An approval service can report the approval it issued. A separate observer can report the state it read. Each statement has a source and a limit.
That is the useful starting point for signed interaction records.
What the signature contributes
A digital signature lets a recipient check whether a record validates under a particular public key and whether the protected content has changed. The recipient must separately establish why that key is acceptable for the claimed issuer.
This is stronger than relying on a screenshot’s appearance. It is also narrower than proving the entire event occurred as described.
An issuer can sign an incorrect statement. A compromised system can produce valid signatures. An operator can omit an event. A timestamp inside a record remains a claim made by its issuer unless additional evidence supports it.
Good verification keeps four questions separate:
- Does the signature validate under the supplied key?
- Does the record satisfy the applicable format and claim constraints?
- Does the key meet the recipient’s issuer and trust policy?
- What additional evidence supports the underlying event?
The first three questions can support a repeatable verification process. The fourth depends on the workflow and the evidence available. A green signature check should never silently answer it.
Preserve a reviewable case
For this example, a useful handoff would contain the selected records, the relevant approval artifact, verification material, and a short account of the findings.
It should say whether the permission set reported by the identity service matches the approved scope. It should also say whether the approval artifact was independently checked, whether a later state observation exists, and whether any relevant attempts are missing.
An attached public key is not automatically a trusted public key. Preserve the recipient’s basis for accepting the issuer, along with the verification time and checks performed. Offline verification can reproduce checks against supplied material; it cannot discover a later key compromise or revocation without updated information.
The export also needs a privacy boundary. Permission identifiers and scoped references may be sufficient. Session tokens, unrelated account data, and whole conversation histories usually are not. Choose what to disclose before signing the record. Editing protected fields afterward invalidates the signature.
Keep any restricted originals under the appropriate access controls, and state when the reviewer is assessing a reduced representation. A digest alone does not make sensitive content anonymous or available for inspection.
Where Originary fits
Originary develops software for issuing, verifying, and packaging selected interaction records. PEAC Protocol is the open protocol behind those records. A recipient can verify them locally with the required material, without depending on an Originary-hosted service.
The useful contribution is a handoff that preserves who reported what and gives the recipient a repeatable way to inspect it. That work sits alongside observability, authorization, and the systems that execute the action.
There are workflows where an existing native export already does the job. Use it. There are also workflows where the other party cannot accept your internal investigation as its sole evidence. That is where a portable signed record earns its place.
Before instrumenting every agent action, choose one action another team already reviews. Assemble the evidence and give it to that team without your dashboard. Ask whether they can identify the issuer, reproduce the checks, and make the intended decision.
If they still need an engineer to explain every field on a call, the handoff is unfinished.