A team reports that after an agent autonomously modified several files and created a pull request, they cannot determine which specific tool calls the agent made, in what order, or what parameters were passed. A compliance review requires full traceability of all agent actions. Which approach best provides the required audit trail?

Traceability and accountability in agentic systems require that every tool invocation be recorded so after-the-fact reconstruction is possible, showing exactly what the agent did. This is distinct from observing outputs of agent actions (commits, PRs, file changes) — it means recording the agent's decision process and the specific API calls made.

The approach that best provides required audit trail is configuring the agent to emit structured, machine-readable logs of each tool call — including tool name, parameters, timestamp, and outcome — persisted to append-only audit storage.

Proper audit trail for agentic tool use should capture, at minimum: - Tool name: which MCP server tool was invoked. - Input parameters: the exact arguments passed (e.g., which file was edited, what text was written). - Timestamp: when the call was made. - Outcome: success/failure, return value or error message. - Run context: which agent session and workflow run triggered the call.

This log should be written to append-only storage (such as immutable object storage bucket, write-once logging service, or signed audit log) to prevent tampering.

Why the other approaches are wrong:

Requiring human review of every agent-created pull request to catch unexpected changes before they are merged provides governance control that catches problems before merging but does not provide technical audit trail. After review, there remains no record of which tool calls were made. Human review and audit logging are complementary; one functions as gate, the other as record.

Enabling GitHub repository event webhooks to capture push and pull request events triggered by agent actions captures repository-level events (pushes, PR creation, reviews) generated by agent actions, but it does not capture agent internal tool call sequence. Webhook payloads tell you 'the agent pushed to branch X,' not 'the agent called the write-file tool with parameters {path: X, content: Y} at time Z.' The tool-level detail required for compliance is not present in webhook payloads.

Adding summary sections to every agent-created pull request description listing high-level changes made during the run produces LLM-generated prose summaries, not structured audit records. They may omit steps, use imprecise language, or be manipulated by model interpretation of what is worth mentioning. They are also stored in PR itself, which can be edited after the fact. These are useful for human readability but do not satisfy compliance requirements for complete, tamper-evident audit trails.