Logging every GitHub MCP server tool call to produce SOC 2 and SR 26-2 audit evidence

Define what "every tool call" means before you log anything

Teams often say they will log every tool call without writing down what that includes. NIST SP 800-53 AU-2 treats this as an explicit organizational decision. You identify the event types the system can log, specify which of them are logged, and document why that selection is adequate to support after-the-fact investigation of incidents. You also review and update the selection over time.

For GitHub MCP activity, the event-type list should cover reads of repositories, creation and update of pull requests, changes to code, and any call that is refused before it reaches GitHub. AU-2 guidance on completeness refers to all protocols that are operational and supported by the system. In practice that means local MCP servers and calls from clients you did not sanction belong in scope, or must be explicitly blocked.

Assign an owner to the list and a review cadence. An auditor sampling your records will want to see the list, the rationale and evidence that someone maintains it.

Specify the minimum evidence record

NIST SP 800-228 gives a baseline for API telemetry: timestamp, client ID, request and response status, and an endpoint identifier. It frames the goal as knowing who called, what method, and from what origin. MCP tool calls need more than that baseline. The additional fields below are design choices, so validate them against the requests your auditors make.

Log the request and the response or result, not only the request. NIST's draft guidance on AI systems recommends recording API calls together with the corresponding AI responses. Treat calls that change code or pull requests as privileged operations and make them easy to filter, since logging privileged function use is a recognized way to detect misuse.

• Timestamp and record ID: A synchronized time and a unique identifier so records can be sampled and reconciled.
• Agent and initiating identity: The non-human identity of the agent or assistant, plus the person or system that started the call where one exists.
• Server and tool: The MCP server, tool name and target repository, flagged when the operation changes code.
• Arguments: The parameters sent, stored in full or in redacted form according to your data policy.
• Result and status: The response status and the content or summary returned to the agent.
• Policy decision: Allow, redact, block or escalate, with the policy version and, for escalations, the approver.

Capture at the MCP layer and record the enforcement decision

Where you capture determines whether the record is complete. Client-side logs show only what that client chose to write, and a platform audit log shows only what that platform sees. Neither is guaranteed to hold arguments, results and the decision made about a call. A single enforcement point in the MCP path sees every call routed through it, whatever the client, and can write the record as part of handling the call.

This is the core design choice: evidence is produced by policy enforcement, not reconstructed afterwards. When the same component that decides to allow, redact, block or escalate a call also writes the record, the decision and the record cannot drift apart. A blocked call produces a record with no downstream GitHub activity, which is exactly what an auditor needs to see to believe the control works.

Trussed operates in this position. It enforces policy in the execution path for MCP servers and tool calls, with allow, redact, block, rate limit and escalate for human approval, and generates audit-ready evidence from that enforcement. It deploys self-managed in the customer cloud, so records stay in your environment.

The capture point only works if traffic cannot bypass it. Restrict direct access to GitHub credentials from agents and assistants so that the MCP path is the only route.

Set integrity, retention and residency deliberately

Tamper resistance for agent logs is still an open question in NIST's work on agent identity and authorization, which asks how agents can log their actions in a verifiable way. Do not claim more than you have implemented. Common controls include append-only or write-once storage, hash chaining across records, separate credentials for writing and reading, and alerting on gaps in sequence numbers. Document which controls you use and what they do not cover.

Retention is a policy decision tied to your audit observation periods and your regulators' record-keeping rules. Set it explicitly, apply it to the evidence store rather than to individual clients, and record who may change it. Data residency matters because arguments and results can contain source code and secrets. Decide where records live and whether redaction applies before storage. Trussed supports configurable retention and data residency in a self-managed deployment, so these settings sit under your control.

Map records to SOC 2 and SR 26-2 evidence requests

Map from the requests your reviewers actually send, not from the control text alone. Start with the sampling and completeness questions an auditor is likely to ask: which tool calls changed code in a given period, who or what initiated each one, which calls were blocked or escalated, and who approved the escalations. For each request, name the record fields and the query that answers it.

Keep this mapping as a maintained document next to the schema. Your compliance and model risk teams decide which SOC 2 criteria and which SR 26-2 expectations apply to AI agent tool use, and the document should record that decision. The schema supplies the raw material. The mapping shows an auditor how a given request is satisfied from the records.

NIST's draft AI guidance favors automated, continuous logging over point-in-time evidence. Plan to give auditors a sample drawn from the live store, with the event-type list and policy versions that were in force at the time.