An organization needs to satisfy a compliance requirement that every autonomous action taken by a Copilot agent — including file changes, branch creations, and API calls — must be attributable to a specific agent run, traceable to the triggering event, and reviewable by auditors. Which combination of practices best achieves this traceability and accountability?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Traceability for agent actions is like a chain of custody in a legal case — every link must be unbroken and independently verifiable. Using a dedicated GitHub App identity means every Git commit, API call, and PR is stamped with the agent's identity at the platform level (not self-reported). Audit log streaming to a SIEM captures this independently of the repository itself. And embedding the workflow run ID in commits creates a breadcrumb trail back to the exact triggering event — meeting the 'attributable, traceable, reviewable' trifecta.
Full explanation below image
Full Explanation
Comprehensive agent traceability requires addressing three distinct concerns: attribution (who did it), lineage (what triggered it), and auditability (can reviewers access a tamper-resistant record).
Option A is incorrect for multiple reasons. A shared service account makes attribution ambiguous — auditors cannot determine whether an action was taken by the agent or a human using the same account. Email summaries are agent-generated (potentially inaccurate or incomplete) and are not tamper-resistant. This approach satisfies none of the three traceability requirements reliably.
Option B is correct because it addresses all three requirements with platform-native mechanisms: 1. Attribution: A dedicated GitHub App identity creates a distinct actor in the GitHub audit log. Every commit, API call, file change, and PR created by the agent is attributed to this app identity — distinguishable from human actions and other bots. Commits are authored/committed by the app, and GitHub's API call logs capture the app's client ID. 2. Lineage: Including the GitHub Actions workflow run ID (${{ github.run_id }}) in commit messages and PR bodies creates a direct link from the artifact (commit, PR) back to the exact workflow execution. Combined with the PR or push event metadata, auditors can reconstruct the full chain: triggering event → workflow run → agent steps → resulting changes. 3. Auditability: GitHub audit log streaming to a Security Information and Event Management (SIEM) system (e.g., Splunk, Azure Sentinel) exports audit events in near real-time to a system outside GitHub's control. This makes the audit trail tamper-resistant even if someone with admin access attempts to modify GitHub's logs.
Option C is incorrect. A JSON log file stored in the repository is agent-authored and can be modified by anyone with repository write access, including the agent itself. Even CODEOWNERS protection only requires human approval for modifications — it does not create a tamper-resistant independent audit trail. It also relies on the agent accurately reporting its own actions, which is not an independent verification.
Option D is incorrect. GitHub Discussions are a collaboration feature, not an audit mechanism. They can be edited, deleted, or manipulated. Tagging the security team creates visibility but not accountability or tamper-resistance. This is notification, not auditing.
Key principle: robust agent accountability requires platform-level identity attribution + independent log streaming + breadcrumb metadata in outputs. No single mechanism covers all three.