The Model Context Protocol made agent tooling composable, and that is exactly why it concentrates risk. One MCP server can hand a model a dozen tools, each backed by a credential, each able to reach a system that matters. When we audit one, the first job is to stop seeing "an integration" and start seeing what it actually grants.

It comes down to four surfaces. Use them to compare the integration’s advertised purpose with the access it actually provides.

1. The tool surface

Every tool an MCP server registers is a callable capability. Alongside the tool’s intended purpose, ask what the most damaging permitted call could do. A tool named search_docs that accepts an arbitrary path can read files. A run_query tool with a writable connection can mutate data. A create_issue tool can be turned into an outbound notification channel.

We enumerate every tool, every parameter and the maximal effect of one call, independent of how the model is "supposed" to use it. Intended use alone does not constrain an agent or an attacker steering it.

2. The credentials behind the tools

Tools do not act as the model. They act as whatever token the server holds. Scope sets the blast radius. An MCP server wired to a personal access token with broad repo scope does not give the agent "GitHub access". It gives it that token's access, for the repositories and lifetime permitted by that token and the server-side policy.

Check for credentials provisioned for developer convenience: one broad token shared across tools that each need only a small part of its access.

For each credential we ask: what scope does it carry, what is its lifetime, can it be narrowed per tool, and is it ever exposed back to the model in an error message or result payload? The last one matters more than teams expect.

3. Network reach

A tool that can fetch a URL is an egress path. A tool that can reach an internal hostname is a pivot. MCP servers frequently run with whatever network the host process has, which in a CI runner or a dev container can be a lot. We map what the server can reach, outbound to the internet and laterally to internal services, because that defines where data can go and where an injected instruction can send it.

4. Trust in descriptions and results

This surface is easy to overlook when a review focuses only on executable code. Tool descriptions, parameter hints and tool results all flow back into the model's context. That means a compromised or malicious MCP server can inject instructions through a tool description, which Invariant Labs demonstrated as tool poisoning in April 2025, and a benign server can relay an injection that lives in the data it returns: a web page, an issue body, a row in a table. The protocol's own security best practices tell clients to validate and sanitize all input from MCP servers before processing it, and treat URLs a server supplies as attacker controlled.

Tool results are untrusted input. Treat every byte that returns from a tool the way you would treat a request body from the open internet.

If you accept that framing, prompt injection becomes one part of the MCP review: untrusted input may influence a privileged action. Authentication, authorization and implementation vulnerabilities also need their own checks.

What to enforce

You cannot audit your way to safety once and be done; MCP servers and their tools change. So the controls have to live at the boundary, deterministically:

  1. Allowlist tools per environment. An agent environment gets the specific tools it needs, not every tool the server happens to expose.
  2. Scope credentials to the tool. Narrow tokens, short lifetimes and never reflect a secret back into a result the model can read.
  3. Constrain network reach. Declare where each tool may egress and which internal hosts it may touch.
  4. Verify after the fact. Record which tools were called and with what, then compare against the policy that was supposed to be in force.
mcp-host · tool inventoryscoped
1read_repo    token: repo:read · ttl 1h ok
2run_tests   net: none          ok
3fetch_url   egress: allow.list only scoped
4run_query   conn: read and write → deny
5evidence → reported for review
The same MCP server, seen as capabilities and credentials instead of a tool list.

What this means for defenders

An MCP server is where models meet systems. Audit it as a credentialed gateway, scope every tool to least privilege, treat all results as untrusted and keep verifiable evidence of what was called. Test that these restrictions hold across the paths available to the workload.

For a scoped review of your implementation, see MCP penetration testing with Oktsec Assessment: tool authorization, tenant isolation, connected access and reproducible remediation evidence.