A financial services company runs multi-agent pipelines that autonomously process customer data change requests. Their compliance team requires that every agent action must be auditable: each action must record who authorized it, what was done, when, to which data, and be tamper-evident. An engineer proposes writing audit logs to the application's standard logging system (e.g., a centralized log aggregator). A compliance officer argues this approach is insufficient. Which audit artifact design would BEST meet the compliance requirement?
Select an answer to reveal the explanation.
Short Explanation and Infographic
A log system that can be overwritten is evidence, not proof. A compliance audit trail needs to be like a blockchain receipt: each entry links to the previous one, is signed, and lives in storage that nobody — not even admins — can alter after the fact. Application logs are great for debugging; they're not great for courtroom-grade evidence.
Full explanation below image
Full Explanation
Standard application logging systems are designed for operational observability, not compliance accountability. They typically allow log entries to be overwritten, deleted, or modified by administrators, which makes them insufficient as tamper-evident audit records.
A compliance-grade audit artifact design requires five properties:
1. Append-only storage: Audit records can be added but never deleted or modified. Storage systems like AWS S3 Object Lock (WORM mode), Azure Immutable Blob Storage, or specialized audit databases provide this guarantee.
2. Cryptographic signing: Each audit record is signed with the generating agent's or system's private key. Any modification to the record would invalidate the signature, making tampering detectable.
3. Chain hashing: Each record includes a hash of the previous record (similar to a blockchain). This creates a cryptographic chain — any deletion or modification of a record breaks the chain, revealing tampering.
4. Structured content: Each record must include all required fields: action type, agent identity, human authorizer, target resource, timestamp, and before/after state hash. Ad-hoc logging cannot guarantee field completeness.
5. Before/after state hash: Capturing the hash of the resource state before and after the action provides cryptographic evidence of exactly what changed.
Option A (application log system) fails the tamper-evidence requirement — standard log aggregators allow administrative modification and do not provide chain hashing. Option C (GitHub Actions logs) provides timestamps and cannot be modified by agents, but cannot record human authorizer identity, before/after state, or provide chain hashing at the individual action level. Option D (post-execution summary) is generated by the agent itself after actions complete, meaning it is a self-report. It cannot be used as evidence of actions that deviated from what the agent claims it did.