An organization is preparing for a SOC 2 Type II audit that will evaluate their agentic CI/CD pipeline. The auditors require evidence that every code change merged by an automated agent can be traced to an authorized request, that the agent operated within its defined parameters, and that its actions can be reconstructed from logs. Which combination of artifacts satisfies all three audit requirements?
Select an answer to reveal the explanation.
Short Explanation
SOC 2 auditors need proof that every agent merge ties back to an authorized request, that the agent ran inside approved parameters, and that you can replay the actions from logs. You get that from structured trace events, immutable archived run logs with run IDs in commits, and per-run parameter manifests. Screenshots, weekly summaries, and git blame alone don't cut it.
Full Explanation
SOC 2 Type II evaluates the operating effectiveness of controls over an extended period, not just their design. For an agentic CI/CD pipeline, this means demonstrating, for every significant agent action during the audit period, that the three audit requirements are met.
Requirement 1 — Authorization traceability: structured trace events must link each agent action to the authorization record that triggered it. For example, a trace event might carry fields: run_id, triggered_by, issue_ref, authorized_by, action_type, target_resource. This allows auditors to follow the chain: 'This merge was authorized by issue #4521, which was approved by user john-doe on 2025-07-12.'
Requirement 2 — Parameter compliance: a parameter manifest artifact per run documents the agent's active configuration at execution time: the version of the agent, its system prompt version, the allowlist in effect, the environment it targeted. This proves the agent was operating under the approved configuration.
Requirement 3 — Log reconstructability: immutable workflow run logs archived to an append-only store (e.g., AWS S3 with Object Lock, Azure Blob with Immutability Policy) cannot be modified after the fact. Embedding the workflow run ID in commit messages creates a bidirectional link: from any commit you can find the run, and from the run you can find all commits it created.
The combination of structured trace events per run linking each action to its triggering authorization reference, immutable workflow run logs archived to an append-only store with the run ID embedded in commit messages, and a parameter manifest per run showing the agent's active configuration satisfies all three requirements because it provides authorization traceability, parameter compliance evidence, and reconstructible logs.
Git blame history and the agent's system prompt stored in version control is incorrect because git blame shows who wrote code but does not capture authorization records, parameter configurations, or structured trace events.
Weekly summary reports generated by the agent and stored in a shared drive are incorrect because weekly summaries are aggregations, not per-action audit trails. They cannot be used to reconstruct a specific agent action or prove a specific change was authorized.
Screenshots of the GitHub Actions run summary page stored in a compliance folder are incorrect because screenshots are static images that can be fabricated, are not structured or machine-readable, and do not constitute audit-grade evidence.