A compliance audit team requires a complete, verifiable record of every code change made during a multi-agent refactoring workflow, including which specific agent produced each change and when. The audit team needs this to satisfy SOC 2 change management requirements. What should the multi-agent workflow produce to satisfy this requirement?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Compliance auditors don't accept 'trust me, the bot did it correctly.' They need a chain of custody: who did what, when, and provably. Each agent needs a unique commit identity so its changes are traceable, and a structured audit log needs to capture the full coordination timeline — not just that it ran, but exactly what each named agent produced.
Full explanation below image
Full Explanation
SOC 2 change management controls require demonstrable, immutable evidence of who made each change, what was changed, and when — with no gaps in the chain of custody. For multi-agent workflows, satisfying these requirements means:
1. Agent-attributed commits: Each agent commits under a unique, identifiable git author identity (e.g., refactor-agent-1 <[email protected]>). This makes git log and git blame queryable by agent identity, providing per-line attribution of agent-generated code.
2. Structured coordination logs: The orchestrator writes a machine-readable log of every decision, delegation, and action taken by each agent — including timestamps, agent IDs, input/output hashes, and the files each agent was authorized to modify.
3. Immutable artifact linkage: The coordination log should be stored in a tamper-evident location (e.g., an append-only GitHub Issue, a signed artifact, or an immutable log store) and linked from the pull request for auditor access.
Why the other options fail: - Option A (summary email) is informal, not machine-verifiable, and does not provide granular per-change attribution. Emails can be written after the fact and are not tied to the actual git history. Auditors will reject this. - Option C (PR description) lists files changed but does not attribute specific changes to specific agents. A PR can touch hundreds of lines across multiple agents without indicating which agent produced which lines. - Option D (Actions workflow run log) shows that a pipeline executed and whether it passed but does not provide the semantic content of what each agent produced or which specific code changes are attributed to which agent. Execution logs confirm process was followed; they don't satisfy change attribution requirements.
Attributed commits combined with structured coordination logs form the complete audit artifact that satisfies SOC 2 change management controls for agent-produced code.