Logging every GitHub MCP server tool call as audit evidence

What an auditor will test

AI coding assistants and agents use the GitHub MCP server to read repositories, open issues, create pull requests and change repository state. When an auditor asks what an agent did, the answer has to come from records that can be tested, not from recollection or from whatever the client happened to print.

Five properties are worth designing against. Completeness: every call is recorded, not only the ones that executed. Attribution: each call ties to a requesting identity and a client or agent. Integrity: records cannot be altered without detection. Retention: records survive as long as the audit cycle needs them. Decision: the record shows what the policy said about the call, not just that the call happened.

Published MCP security guidance points the same way. It recommends logging all tool invocations with parameters, user context and timestamps, collecting them centrally, and keeping immutable audit trails. Limited telemetry from MCP servers and agents is described as an obstacle to investigation and incident response. The GitHub context makes this concrete: prompt injection through a malicious issue, or cross-repository data exfiltration, can only be investigated if identity, parameters and target resource were recorded.

Define the record schema

Start with the schema, because it decides what you can prove later. The fields below draw on general audit record content (identities, event types, resources involved, times and success or failure) and on what MCP-specific guidance asks for. Write the schema down once and require every capture point to emit it.

Write operations such as issue and pull request changes deserve the closest attention, because they change repository state. Confirm which tools in your deployment do so and mark them in the record so they can be filtered during review.

• Identity and client: The human or service identity the call acts for, the agent, and the MCP client that sent it.
• Tool and target: Tool name and the repository, issue or pull request it addressed.
• Parameters: Structured arguments with sensitive values redacted before storage, plus a stated purpose where available.
• Timing and correlation: Timestamp, request ID and a correlation ID that links the request, decision and response.
• Policy decision: Allow, redact, block or escalate, with the rule ID and, for approvals, the approver and expiry.
• Outcome: Success or failure and response metadata, such as status and size, rather than full content by default.

Where capture can be made complete

The comparison below is analysis of architectural position, not a product evaluation. The question for each point is whether it sees every call, whether the party being observed also writes the record, and whether it can record a decision.

A record supplied by an agent or server is a claim. Guidance on verifying execution evidence recommends an independent observer, and corroboration against a gateway or boundary the operator controls. Any completeness claim is limited to what that observer could see and reconcile.

• Client-side logging: Format and content vary by MCP client, and the component being observed writes its own record. Calls from an unlogged client are missing entirely. Weak on tamper resistance and consistency.
• GitHub-side records: Reflect only calls that reached the server and are the supplier's own report. Calls stopped or modified before they arrived, and the policy decision behind them, are not visible.
• Proxy: Can see all traffic routed through it and gives an independent record. Completeness depends on there being no bypass. It records a decision only if it also makes one.
• Enforcement in the execution path: The point that decides also records. Allowed, redacted, blocked and escalated calls are captured by construction, with the decision attached.

Record the decision with the call

Authorization belongs in the execution component, outside the agent's context, so the model cannot talk its way past it. Unknown tools and missing approval requirements should fail closed. If that component is also where the record is written, the decision and the call cannot drift apart.

Each of the four outcomes needs its own shape. An allowed call records the rule that permitted it and the outcome. A redacted call records what was redacted by category, not the removed value, and what the downstream tool received. A blocked call records the rule ID, target tool and server, and request identifiers, so a blocked prompt injection attempt is evidence rather than a gap. An escalated call records the pending approval and, later, the human decision.

Approvals need care. A boolean such as user_confirmed is not evidence. The approval should belong to the current actor and the exact tool call, include normalized parameters, a timestamp and an expiry, and be consumed atomically before execution so it cannot be reused. Record the approval and the call under the same correlation ID.

Decide the failure behavior in advance. Failing closed when logging or policy lookup fails protects evidence but turns a recording outage into an availability failure. Setting the behavior by risk tier is reasonable: fail closed for state-changing tools on sensitive repositories, and a defined degraded mode for lower-risk reads, with the degraded period itself recorded.

Retention, integrity, access and sensitive content

Guidance conflicts on parameter logging. One recommendation is to log full parameters. Another is to avoid raw tool arguments and tool input and output by default, because they may contain secrets or personal data. A workable resolution is to store structured parameters with redaction applied before the record is written, and to store response metadata instead of response bodies. Source code and credentials should not be copied into the evidence store unless a specific, documented need justifies it.

For integrity, aim for records that are append-only and tamper-evident. Common techniques include write-once storage, hash chaining and signing at the capture point. Reconcile records against an independent boundary so deletions are detectable.

For access, separate who can write records from who can read them, and keep both separate from the engineers whose agents are being audited. Reading evidence should itself be logged.

Retention periods and data residency come from your own obligations, so set them per policy and per jurisdiction rather than by default. Choose a storage location and retention setting that you can change and demonstrate, because evidence that expires early or sits in the wrong region fails an audit in a different way than evidence that is missing.

How Trussed applies this

Trussed enforces policy on MCP server tool calls in the execution path, alongside models, agents and coding assistants. Policy is enforced at runtime, not reviewed after the fact, and each call can be allowed, redacted, blocked, rate limited or escalated for human approval. The audit-ready evidence is generated by that enforcement, so the decision and the call are recorded together, and it is mapped to frameworks including NIST.

Trussed deploys self-managed in the customer cloud, with configurable retention and data residency. Its scope is individual interactions and tool calls. It does not provide end-to-end tracing of agentic workflows or transaction-level governance across tasks and agents.

The design principles above apply whichever tooling you use. The test is whether one point sees every call, decides, and records the decision.