AI Agent Audit Trail for Compliance: Evidence Mapping
Map AI agent compliance questions to identity, authority, policy, execution and outcome evidence without treating logs or signatures as automatic certification.
An AI agent audit trail supports compliance when it answers a defined requirement with evidence from the system that can substantiate it. Logs, traces and signatures are not automatic compliance. Applicability, retention, access, human oversight and evidentiary sufficiency depend on the organization, jurisdiction and use case.
The technical owner page is AI Agent Audit Trails. Use this worksheet with legal and control owners.
Map questions to evidence
| Review question | Evidence | Important caveat |
|---|---|---|
| Who was accountable? | organization, principal, agent and owner records | identity lifecycle must be reliable |
| What authority existed? | signed or versioned grant and revocation state | scope must cover the exact time and action |
| What was requested? | canonical request digest and protected fields | digest needs resolvable source under access control |
| Which control ran? | policy digest, decision and reason codes | deployment must enforce the path |
| Did a person approve it? | approver identity and exact approval digest | display and identity assurance matter |
| What happened? | adapter, provider and system-of-record observations | later outcomes may change |
requirement_id: internal-control-AP-17
control_statement: material supplier payments require independent exact approval
population: supplier-payment.create above threshold
evidence_fields:
- request_digest
- approval_digest
- approver_id
- policy_digest
- execution_reference
test_method: sample and compare approval payload with provider submission
owner: finance-controls
Avoid overclaiming
A valid signature shows that a payload has not changed under the selected cryptographic and key-trust assumptions. It does not prove the invoice was genuine, the provider settled, or no bypass route existed. A complete audit log can still be wrong if a trusted source emitted false data.
Build a sampling procedure
Define the population from the domain system, not only the agent evidence store. Otherwise actions that bypassed the gateway disappear from the sample. Select transactions by risk class and period, then retrieve the matching identity, authority, decision, approval, execution and outcome records.
For each sample, compare protected values across stages. The amount and destination approved should match the provider submission. The policy digest should resolve to the bundle active at decision time. The agent and owner should have been active under the lifecycle record.
Record pass, fail and unknown. Missing evidence is not a pass, and it is not always proof the action was unauthorized. Investigate the collection path and decide how the gap affects the control conclusion.
Preserve reviewer identity, test procedure, queries and evidence references. Another reviewer should be able to repeat the sample without relying on a model-generated narrative.
The European Commission's AI regulatory framework page links to official AI Act resources and implementation context. NIST's AI Risk Management Framework provides voluntary risk-management structure. Counsel and control owners should determine how either applies.
Test retrieval and access
Run a sample from domain-system transaction back to agent evidence, and another from receipt forward to the external outcome. Confirm that authorized reviewers can retrieve it inside target time and that unrelated tenants cannot. Document missing data as a finding.
Use audit retention and privacy and incident reconstruction for operating details. The OATI Receipt documentation is a developer-preview technical resource, not a compliance certificate.
Evidence review decisions
One receipt may support a control claim, but the reviewer may also need population completeness, enforcement-path evidence, access controls, key lifecycle, retention and sampled outcomes. Define the requirement, population and test before choosing fields. Avoid presenting a receipt as universal proof simply because its signature verifies.
Build the population from the authoritative business or infrastructure system, then join it to gateway and agent evidence. Starting from the receipt store excludes actions with missing receipts and can create a falsely perfect sample. Record exclusions, unmatched operations and evidence whose source cannot be resolved.
For each sample, compare material values across approval, policy decision and execution. Verify the policy version active at event time, the approver's authority, the request digest and the provider or system-of-record outcome. A current policy bundle should not be applied retrospectively to an earlier transaction without preserving the historical version.
Technical signature validation does not determine legal validity, admissibility or regulatory applicability. Report algorithm, issuer, key status, payload integrity and unresolved references precisely. Legal and compliance owners decide how that evidence supports a particular obligation in a jurisdiction and organizational role.
Evidence of human oversight should include the exact request displayed, verified approver, decision, time, authentication context and later execution match. A button click without protected fields is weak support. Reviewers should also inspect override rates, approval mutations and whether a supposedly independent role changed a destination or prepared the same request.
When evidence is missing, name the gap, affected population and period, possible impact, compensating sources, owner and remediation date. Use fail, partial or unknown according to the approved method. Do not ask a model to recreate facts. Preserve reviewer identity, queries and evidence references so another reviewer can repeat the test.
Keep product claims outside the control conclusion. A platform may support signed receipts, policy versions and evidence export, while a particular deployment leaves a direct service route open or omits one business system. Audit the implemented workflow and its population. Vendor documentation can explain intended features, but it cannot prove customer configuration or operating effectiveness.
For recurring controls, retain the sampling code or query and a small set of non-sensitive fixtures. Re-run after schema, gateway, provider or policy changes. If the population definition changes, show the break rather than comparing percentages that no longer mean the same thing.
Make the evidence map readable without product terminology. An auditor should see the control objective, source system, protected fields, test and limitation before learning which Intelliger or OATI object carries it. This keeps the conclusion portable and prevents a vendor-specific record name from being mistaken for a regulatory requirement.
Record the reviewer’s independence where the control requires it. A service owner can explain implementation, but the same person should not always select the sample, resolve every exception and approve the conclusion for a material financial or security control.