A compliance team requires that every MCP tool invocation made by any agent in a multi-agent pipeline must be attributable to a specific pipeline run, the specific agent that made the call, and the human user who initiated the pipeline. Which traceability implementation best satisfies this audit requirement?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Compliance auditors need a chain of custody, not just a pile of logs. Each tool call should be stamped with who triggered it, which agent made it, and what run it belonged to — before the call fires, stored somewhere tamper-evident. Think of it like a notarized paper trail: structured, complete, and stored where it can't be deleted.
Full explanation below image
Full Explanation
Traceability in multi-agent systems requires that every tool invocation can be tied back to its full context: the pipeline run (when), the specific agent (which component), the human initiator (who), the tool called (what), and the inputs provided (how). This is not just logging for debugging — it is a compliance record.
Option A is correct. Emitting a structured log entry before each MCP tool call, containing all five required attributes (run ID, agent ID, user identity, tool name, input parameters), and persisting these to an immutable audit store (such as an append-only log service, SIEM, or write-once storage bucket) fulfills the compliance requirement completely. Structured logs enable automated querying and reporting; immutability ensures the audit trail cannot be tampered with after the fact. The pre-call timing ensures the log is written even if the call fails or times out.
Option B is wrong. GitHub Actions runner stdout logs capture whatever the executing code prints, but this is not structured for compliance purposes. Workflow logs are mutable (they can be deleted after a retention period), not formatted for audit querying, and do not inherently include agent-level attribution or the initiating user identity. They are useful for debugging, not compliance audit.
Option C is wrong. Recording only failed tool calls fundamentally misunderstands the audit requirement. Compliance traceability is specifically about showing what actions were taken, not just what went wrong. Successful deployments, successful data reads, and successful configuration changes may all need to be auditable — particularly in regulated industries where the what-was-done record matters as much as the what-went-wrong record.
Option D is wrong. GitHub's organization audit log captures GitHub.com API events at the platform level, but it does not attribute calls to specific agents within a pipeline or link them to an initiating user in the way a compliance audit requires. It also does not capture the MCP tool-level abstraction — it would show raw API calls, not the agent-level tool invocations with their input context.