To audit MCP tool calls, collect evidence of who requested an action, which control allowed or denied it, and what the destination actually did. Correlate those records across the client, gateway, server and business system. A dashboard showing tool volume and latency can’t answer all four questions.
This guide proposes an evidence worksheet and acceptance tests for platform and security teams. They’re evaluation tools, not a certification checklist or a record captured from a deployed product.
Key Takeaways
- Separate a gateway’s permission decision from the tool’s execution result.
- Identify the system that can prove each fact; one gateway may not see the complete outcome.
- Test missing records, denied calls and timeouts, not just a successful demonstration.
- Keep credentials and unnecessary payloads out of audit storage.
Disclosure: Jarvis is an open source project built and maintained by ASCENDING Inc. We apply the same evidence requests to Jarvis below.
Start with the question your reviewer needs answered
Pick one workflow, such as checking a support ticket through an approved MCP server. Define its permitted users, data boundary and expected result before choosing log fields.
An access review might need to show that a restricted user couldn’t read a ticket. An incident investigation might need to identify which system disclosed it. Those require different evidence.
Tyk’s MCP audit guide distinguishes runtime activity records from source-code auditing and explains why isolated client and server logs are difficult to reconcile. Neither a code review nor a gateway dashboard substitutes for reconstructing a real request.
Use the MCP governance checklist to assign owners. Then agree on the events, collection coverage and retention requirements with the people who’ll review them. Don’t start by copying every request body into storage.
Map evidence to the system that can prove it
The following is our proposed collection worksheet. It isn’t a standard MCP schema or a promise that every product exposes these fields.
| Review question | Evidence to request | Where to verify it |
|---|---|---|
| Who initiated the request? | Authenticated subject or workload, client and environment | Identity validation and client records; not a name supplied in tool arguments |
| Which capability was requested? | Server identity, tool name and reviewed definition reference | Registry snapshot and invocation record |
| Why was access permitted? | Decision, relevant rule/version and decision time | The component that actually enforced the policy |
| Did the server run the tool? | Execution start, completion or failure, linked to the request | MCP server instrumentation |
| What happened to the business record? | Destination operation and confirmed result | The ticketing system, database or other destination |
| Can we trust the evidence? | Collector health, access controls and gaps in coverage | Logging pipeline and storage controls |
Connect these records with an application correlation identifier, or a documented mapping between identifiers. Don’t assume a JSON-RPC request ID is globally unique across sessions and systems.
Distinguish the initiating person from a service account used downstream. Record a safe credential reference or authentication method, never the credential itself. If the relationship isn’t available, mark it unknown instead of guessing.
The OWASP Logging Cheat Sheet recommends recording useful event context while considering the trustworthiness of each data source. It also warns against collecting secrets and unnecessary sensitive data.
Keep permission, execution and business outcome separate
A gateway can permit a call that the destination later rejects. A timeout can occur after a destination has completed an action. Treating either as a single success or failure loses important evidence.
Here is an illustrative proposed policy-decision event for a test environment. These field names aren’t an MCP or OpenTelemetry standard, and this isn’t Jarvis output.
{
"event_type": "policy_decision",
"event_id": "example-event-001",
"correlation_id": "example-request-001",
"occurred_at": "2026-10-19T10:00:00Z",
"environment": "test",
"actor_reference": "test-reader-a",
"server_reference": "ticket-test-server",
"tool_name": "read_test_ticket",
"decision": "allow",
"policy_reference": "test-policy-v2",
"downstream_outcome": "not_observed",
"payload_capture": "disabled"
}This event records only the emitter’s policy decision. Its evidentiary value depends on that emitter and the collection controls. A separate correlated server event must establish execution. The destination must establish any business effect.
For a read, that might mean confirming which permitted test record was returned. For a write, it means checking the resulting record, not merely an HTTP success code.
If you collect an approval reference, check that it covers the actual requested operation. An old approval for a different action isn’t enough.
Run an evidence test, not just a successful demo
Use synthetic records and test identities. Agree on expected behavior before running the following proposed tests; these aren’t results from a Jarvis deployment.
| Scenario | What to observe | What would leave the result unresolved |
|---|---|---|
| Allowed read | Permission decision, server execution and expected synthetic record | A gateway success without server or destination evidence |
| Denied user | Denial at the enforcing layer; controlled server receives no execution request | Only an empty client screen or missing server log |
| Destination rejection | Gateway allows; destination denies; both records remain distinguishable | One combined status hides where denial occurred |
| Server timeout | Request and timeout are linked; destination state is checked | Recording “nothing happened” without checking the destination |
| Retry | Separate attempt identifiers linked to the same workflow | Duplicate attempts look like one call or hide repeated effects |
| Collector interruption | Defined buffering, alerting and recovery behavior | Silent record loss or an untested assumption about blocking |
For the denied-user test, instrument the controlled server with an independent request counter. Absence of a log alone doesn’t prove that execution was blocked.
Set logging-failure behavior according to the workflow’s risk and availability requirements. A sensitive action may need to stop; another operation may use bounded buffering with an alert. Document and test the decision.
Product settings matter. Kong’s AI MCP Proxy documentation describes audit logging for allowed and denied tool access with a dedicated logging setting. Verify the deployed version and configuration. That feature doesn’t prove anything about another gateway.
Protect the audit store and measure coverage
Record enough to investigate without creating a second uncontrolled copy of business data. Exclude tokens, passwords and keys. Limit identifiers and payload details to the approved purpose.
Give collection, investigation and administration separate permissions. Check whether a producer or ordinary application administrator can alter historical evidence. Test the configured retention and deletion behavior, including any approved holds.
OWASP’s logging guidance also calls for testing collection failures and protecting records against unauthorized access or modification. Retention periods depend on your requirements; this guide doesn’t prescribe a universal number.
Measure coverage against known test requests. Ten visible records aren’t reassuring if twelve requests reached the server. Record which clients, routes and server versions participate, including any direct path around the gateway.
Payload minimization creates a trade-off: it reduces exposure but can limit reconstruction. Resolve that deliberately with security reviewers instead of switching on unrestricted capture.
What Jarvis documents, and what still needs proof
Jarvis observability documentation separates platform metrics from agent LLM traces. Platform metrics cover registry, authentication and MCP activity. Agent traces cover model/provider, token usage and latency, with content-capture controls.
These signals don’t establish a complete per-call audit record containing caller, policy version and downstream outcome. Collector configuration also determines which backends receive telemetry. Customer-hosted deployment doesn’t mean every configured export stays inside that account.
For a Jarvis MCP Gateway evaluation, request sanitized allowed, denied and failed-call evidence from the proposed deployment. Map it against the worksheet, identify missing instrumentation and agree who supplies it.
Keep the deliverable small: one workflow, a field-coverage table, observed test results and named gaps. Our gateway evaluation guide covers the wider purchase decision. Use the tool-definition review guide to test what happens when an approved capability changes.
References
- Tyk: Auditing MCP server access and activity.
- OWASP: Logging Cheat Sheet.
- Kong: AI MCP Proxy.
- Jarvis Registry: Observability.
Product and reference pages checked October 19, 2026. The worksheets are proposed evaluation methods, not claims of completed product testing.
MCP audit evidence questions
How do we audit MCP tool calls for compliance?
Define the evidence your reviewers need, then collect correlated records from the client, gateway, MCP server and downstream system. Test allowed, denied and failed calls, plus logging failures. Verify privacy, access and retention controls separately. This supports an audit; a log format alone doesn't establish compliance.
Are MCP metrics the same as audit logs?
No. Metrics summarize activity such as request counts and latency. Audit records need enough context to reconstruct a specific action and its authorization. Traces can help connect events, but their fields, coverage and sampling must be checked.
Should we log every tool argument and response?
Don't enable full payload capture by default. Keep the metadata needed for the review and exclude credentials and unnecessary sensitive data. If a specific investigation needs payload evidence, use a separately approved, restricted collection process.
Does Jarvis document a complete per-call audit schema?
The current observability documentation describes platform metrics and agent LLM traces. It doesn't establish a complete per-call record containing identity, policy version and downstream outcome. Request sanitized deployment evidence and map any missing fields before relying on that record.
