Document Audit Trails: Who Requested, Approved, and Made the Change?

An invoice’s cost-centre metadata changes from 1004 to 1040. Its history says “updated by invoice-connector.” That identifies the service that made the API call, but leaves the reviewer asking who requested the correction, who approved it, and whether the service applied the approved change.

A useful audit trail connects the business request to the identities, authority, and outcome behind it. This matters whenever an application, support engineer, workflow, or AI agent acts for someone else.

1. Record the identities that played different roles

Start with questions a reviewer can understand. In a direct user action, one person may fill several roles. In a workflow, those roles can belong to different people and services.

Choose field names for your application, but keep these meanings distinct. An “on behalf of” identity is not proof that the named person approved the action. Preserve the actual caller even when the interface displays a represented user.

2. Establish identity and authority through trusted controls

Derive the caller from authentication. Bind the initiating person to a validated application session, signed identity context, or another trusted record. A free-text username or client-supplied “on behalf of” header must not establish attribution or grant permission by itself.

For delegation, retain who granted authority, who may use it, the permitted actions and resources, validity period, reason, approval where required, and revocation state. Evaluate the applicable authority when the action executes, including after a queue delay. If permission has ended, record the denial rather than carrying out an old request.

AWS source identity can help trace configured role sessions through role chaining. The integration must still establish its trusted identity binding and connect cloud activity to the business request. A recognisable session name alone does not establish the whole chain.

3. Link the request, decision, and execution

Give each business request a stable reference and connect its proposal, decision, and execution events. Record what each decision covered: document or record revision, proposed values, rule version, and any conditions. If those inputs change before execution, decide whether approval must be repeated.

For AI-assisted work, retain a reference to the proposal, relevant input versions, model or processing configuration, validation results, and the human decision or automation policy that authorised execution. Keep sensitive inputs in appropriately controlled evidence storage rather than copying whole prompts and documents into every log.

Separate accepted, queued, completed, failed, and denied outcomes. An accepted API request does not establish that a background change finished. Retries should share the business request reference while retaining distinct attempt identifiers and outcomes.

Example: make the invoice correction explainable

1. Record Maya’s request

   The invoice application records the target invoice, the proposed change from cost centre 1004 to 1040, the correction reason, and Maya’s authenticated identity. It assigns one request reference for the rest of the workflow.

2. Record Rina’s decision

   Rina reviews the proposed values and supporting evidence. The application retains the approval against that exact correction and the applicable approval rule. A rejected or revised proposal keeps its own history.

3. Record the service’s result

   The invoice-connector checks that the request remains authorised, applies the approved update, and records the resulting values and outcome. Its service identity remains visible alongside the request and approval references.

A readable history can then say: “Maya requested the correction; Rina approved it; invoice-connector changed the cost centre from 1004 to 1040.” Keep the underlying identifiers and timestamps available for investigation. If execution failed, the history must say so even though approval succeeded.

4. Make missing evidence observable

Design the business update and its audit evidence together. Writing the change first and then making an unrelated logging call leaves a failure window. For integrations you build, consider a transactional outbox or change-data-capture pattern that durably connects committed changes to event publication. Consumers still need duplicate handling and reconciliation.

Retain event identity, business request reference, relevant resource/version, recorded and occurrence times, result, and links to the decision and prior step. Use those links to reconstruct order; timestamps alone can be misleading across systems. Monitor failed writes, delivery gaps, and records with no final outcome.

Use restricted audit writers, controlled retention, and separately administered storage where appropriate. If immutable copies are required, configure and verify their retention and deletion protections. Preserve corrections as new evidence linked to the earlier entry.

Cloud and application records answer different questions. CloudTrail data-event coverage must be configured for relevant operations such as direct S3 object access. A cloud event may identify a service role without recording the caseworker, approval, or business reason. Correlate the layers and test the access paths you permit.

5. Give reviewers a usable history

Present a plain-language account of what changed and why, with authorised access to the supporting technical records. A case reviewer may need one invoice’s history, while security needs denied actions and unusual exports. Preserve common event references across those views.

Minimise sensitive values in the event itself and control access to detailed before-and-after data. Exported reports need stable identifiers, time-zone labels, and the same attribution as the underlying history. Keep evidence available when an employee leaves or a service account is renamed.

• A forged represented-user value cannot replace the authenticated caller or create authority.
• A changed proposal, revoked grant, or stale approval is handled correctly before execution.
• Retries, failed changes, and delayed audit publication remain distinguishable from completed work.
• A reviewer can trace one change from request through decision to outcome without manually guessing which logs belong together.

For temporary vendor access, pair this evidence model with a defined support-access process so the grant and the actions taken under it can be reviewed together.

Technical guidance reviewed: November 10, 2026. Validate attribution, authorization, and audit coverage in the deployed integration.

Preserve who acted, under whose authority, and with what result

Connect the initiating actor, delegated authority, executing service, request, and actual outcome through trusted identifiers. Keep failed attempts, retries, and missing audit publication visible so reviewers can reconstruct one action without guessing how separate logs relate.