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
Log systems that can be overwritten are evidence, not proof. You need a compliance audit trail that's like a blockchain receipt: each entry links to the previous one, is signed, and lives in storage nobody can alter after the fact. Application logs are great for debugging, not courtroom-grade evidence.
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.
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.
The append-only, cryptographically signed audit log with immutable storage meets these requirements because it combines structured audit records, actor identity including agent and human authorizer, target resource, timestamp, before/after state hash, and a chain hash linking to the previous record in storage that cannot be altered after the fact.
Writing detailed audit entries to the application log system with full action details and configuring log retention for 7 years fails the tamper-evidence requirement. Standard log aggregators allow administrative modification and do not provide chain hashing, so retention length alone does not make the record immutable or tamper-evident.
Recording all agent actions in a GitHub Actions workflow log provides a permanent, timestamped record that cannot be modified by agents after the workflow completes, but it cannot record human authorizer identity, before/after state, or provide chain hashing at the individual action level.
Having each agent generate a post-execution summary document describing the actions it performed and storing it in a compliance-designated S3 bucket is a self-report generated after actions complete. It cannot be used as evidence of actions that deviated from what the agent claims it did.