How to Audit an MCP Server's Data Access Before You Connect It

Scopes describe categories. Tools describe the concrete verbs. Pull the full tools/list response with an unauthenticated request and read every description and input schema. This is where you learn whether "search documents" actually accepts an arbitrary URL, whether "send message" accepts a channel ID, and whether any tool takes a free-text query that a remote system will execute.

Harvard's information security guidance puts the question sharply: determine whether a tool can only read information or can also create, modify, delete, send, approve or execute actions, and grant only the permissions needed for the task (Harvard best practices for generative AI). The same page warns that the more access and autonomy a tool has, the more carefully you must evaluate what it can see, what it can do, and who remains responsible for the result.

Build a table with one row per tool and answer four questions for each. This is the artifact your reviewers will argue over, so make it explicit.

Also list resources and prompts. A resource URI template that accepts an arbitrary path or URL is a file-read primitive with extra steps. If the server exposes file:// or http:// templates, ask what stops a prompt injection from substituting a path you did not intend. Research on AI assistants consistently flags prompt injection through documents, websites and messages as a route to disclosure or unintended action (Harvard best practices for generative AI).

Now switch from reading to observing. Create an account that holds nothing you care about: a fresh mailbox, a separate tenant, or a sandbox workspace with synthetic documents. Never audit against a production identity, because the first thing untested tooling does is call something.

Point the MCP client at a capture proxy. HTTP Toolkit is a practical option because a published agent skill documents the working pattern: set the proxy environment variables, run the program in a non-interactive mode that emits machine-readable logs, export the outbound HTTP, and cross-reference that export against the program's own session log (the http-toolkit-intercept skill). The same source notes that proxy environment variables are runtime-specific, that Bun ignores plain HTTP_PROXY in favor of BUN_CONFIG_PROXY, and that TLS bypass flags are for controlled local debugging only, never production (the http-toolkit-intercept skill).

A minimal capture run looks like this.

HTTP_PROXY="http://127.0.0.1:8000" \
HTTPS_PROXY="http://127.0.0.1:8000" \
ALL_PROXY="http://127.0.0.1:8000" \
NO_PROXY="" \
mcp-client-invocation --output-format stream-json "list resources and read the sample doc" \
  > /tmp/session-stdout.log 2> /tmp/session-stderr.log

Then export the proxy's request log as JSON or HAR and join the two streams. The outbound export is authoritative for request bodies, headers and auth tokens; the session log is authoritative for what your client did with the responses (the http-toolkit-intercept skill). Keep the run bounded: you usually need to prove request shape, not wait for a long session to finish.

Exercise every tool once, in the least privileged way the schema allows. If a tool refuses without a write scope, that refusal is evidence worth recording. If it succeeds with a read token, you have found an authorization gap.

Your proxy shows network behavior during the test. Logs show what happens on the server side and what your client retains afterward. Auth guidance for MCP explicitly recommends authorization when the server accesses user-specific data, when you need to audit who performed which actions, or when you want per-user rate limiting and usage tracking (the MCP authorization tutorial). If the server cannot answer "who called this tool and when," the audit fails at this step regardless of how clean the scopes look.

Ask for three log properties in writing. Retention window in days, not adjectives. Whether tool arguments are logged or only tool names. Whether logs are exportable to your SIEM or only viewable in a vendor console. Vendor claims about not training on your data are cheap to write, which is why reviewers now push past the sentence and ask for named subprocessors, retention quoted in days, and a closed anonymized-data carve-out (questions that test a no-training claim).

Client-side logging matters too. Anthropic's addition of OpenTelemetry-based observability to its agent platform and GitHub's documented controls over whether individual Copilot interaction data feeds model training both point the same way: the provider side increasingly exposes telemetry, and the contract side determines what is allowed to flow (GitHub's Copilot data FAQ). For a connected MCP server, confirm the same two facts: what your client logs about tool calls, and whether the vendor's terms let it use tool arguments for anything beyond returning the result.

One practical check: look for tool arguments in plaintext logs. A server that writes an entire customer record into a debug line has created a second copy of sensitive data outside the access controls you just audited. Cyberhaven's research found that sensitive data appears in a large share of AI interactions, including prompt text, paste actions and uploads, with employees inputting sensitive data into AI tools roughly once every three days (Cyberhaven on sensitive data in AI tools). Your MCP server is another channel with the same pattern.

The deliverable is a list, not a report. For each server you approve, record the exact hostnames and paths it may contact, the scopes it may request, the tools it may invoke, and the date the approval expires. Anything not on the list is denied by default.

Three rules make the allowlist stick. First, pin the authorization server: if a server later advertises a different authorization_servers entry than the one you approved, treat it as a new integration (the MCP authorization tutorial). Second, bind tokens to your audience: OAuth guidance for MCP servers stresses validating the issuer, checking that the audience claim matches your server, and handling failures with proper WWW-Authenticate responses (a developer's guide to OAuth for MCP servers). Third, review the tool list at each renewal. Server updates add tools quietly, and an added write tool is a scope change even if the manifest is unchanged.

If your organization has an AI use policy, the allowlist belongs inside it. Frameworks for internal AI policy consistently call for identifying tools in use, defining approved tools, restricting what may be entered, and assigning human review before output is used (the Future of Privacy Forum checklist, the CTR workplace checklist). An MCP allowlist is the connected-tools annex to that policy.

Use a single gate instead of case-by-case debate. Approve if all four hold: every outbound host is named and justified; no write scope lacks a named business action; the server returns caller-attributable logs exportable to your SIEM; and the tool list under a read token contains no write or execute verbs. Block if any one fails. The reason for a hard gate rather than a score is that failures are not additive. A read-only server that sends data to an unapproved third-party host is worse than a write-capable server that talks only to systems you already govern.

A worked example makes the arithmetic visible. Suppose the capture shows 34 outbound requests across the test session: 22 to the vendor API, 6 to your identity provider, 4 to a telemetry endpoint and 2 to an address you do not recognize. The telemetry endpoint is a decision about data, not convenience, and the two unknown requests are a stop sign. Your allowlist would name the vendor API and the identity provider, and the review would return to the vendor with two questions: what is the telemetry endpoint, and what are those two requests? Without the capture, you would have approved all of it.

Scale this the way you scale other third-party reviews. A small team can complete the steps above for one server in an afternoon. A wider rollout across many servers benefits from putting every model call behind one gateway and a single set of credentials, which is what Quanta Inference centralizes: text, image, video, audio and embedding models through one OpenAI-compatible, prepaid API key, so the egress you audit is the egress you control.

Four failure modes account for most MCP audit problems. Auditing the manifest and skipping the capture: scopes describe intent, traffic describes behavior, and only the second one is evidence. Using a real account because the sandbox "doesn't have the data": the sandbox is supposed to lack the data, and the whole point of a throwaway account is that a mistake costs nothing.

Treating the tool description as documentation of behavior: descriptions are written by the publisher and can drift from the schema, so read the schema. And approving once and never again: a server you approved with read scopes can add a write tool in an update, and your allowlist has to be rechecked at each renewal or it becomes a historical document.

If your team needs help turning this into a repeatable review process across a portfolio of servers, a short working session is often faster than writing the checklist from scratch; a free discovery call covers your goals and a tailored recommendation with no obligation.