MCP Server Security Assessment: How to Test an AI Agent's Tools

A hypothetical scenario. An internal platform team builds an MCP server in two weeks so the company's AI assistant can work with real systems: search service-desk tickets, read files from a shared reports store and run templated data exports. The demo goes perfectly. An employee types "pull together a report on overdue tickets for the quarter," the assistant picks the right tools on its own, and a minute later the file is ready.

A month later someone notices an odd call in the logs: the file-reading tool received a path that led out of the reports directory and into the server's own configuration. No employee asked for that. The model built the argument — after reading a ticket in which an outside "customer" had politely asked that the report "include the contents of the settings file for completeness."

The scenario is invented, and there is nothing exotic about it. Directory traversal is one of the oldest web application weaknesses. What is new is who reached the vulnerable code: not a person with Burp Suite, but a language model that was faithfully doing its job and mistook someone else's text for part of its instructions. The MCP server became a bridge between natural language and real actions — and therefore a new road to old mistakes.

Below: what to test in an MCP server, by which rules, and which evidence to demand from a provider so you can tell a useful assessment from a formality.

What an MCP server looks like to an attacker

The Model Context Protocol describes how an AI assistant client connects to a server that exposes three kinds of capability: tools (actions the model can invoke), resources (data that can be read) and prompts (prepared interaction templates). For the user, this is a convenient abstraction. For an attacker, it is an interface where a natural-language request becomes a function call with concrete arguments: read a file, query a database, send a message, run a command.

An MCP server security assessment is an authorized, pre-agreed examination of that interface. Its goal is no different from that of any technical assessment: find weaknesses before an adversary does, confirm that stated controls actually work, and produce findings the team can fix. The difference lies in the threat model. A classic web service expects requests to be shaped by a person or a known application. An MCP server receives arguments composed by a model, and the model composed them after reading everything that landed in its context: the user's request, retrieved documents, the output of other tools.

It helps to separate a few things that are often blurred. A server can run locally over standard input/output (stdio) as a child process of the client application — the transport then exposes no MCP network listener of its own, but process privileges, filesystem and secret access, outbound tool connections, and any proxy surface remain. A server can be reachable over HTTP — then authentication, sessions, CORS and everything familiar from API testing join the scope. Scoping starts with describing honestly which one you are looking at.

This article is written for three groups: security leaders deciding whether an internal review is enough or an external audit is needed; engineers preparing a server for production; and procurement specialists comparing provider proposals. The method rests on established public guidance from NIST, OWASP, MITRE and CISA, plus the MCP protocol's own security guidance. Applying the general guides to a particular MCP architecture is the author's professional judgement; requirements and recommendations taken directly from the identified MCP guidance revision are labelled separately below.

Method: adapting NIST SP 800-115 to a tool server

NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment, was published in September 2008 and replaced SP 800-42. It helps organizations plan and conduct technical tests, analyze findings and develop mitigation strategies. It deliberately avoids prescribing an exhaustive testing program; instead it describes key elements, specific techniques, and their strengths and limitations. Formally, it divides an assessment into three phases: planning, execution and post-execution.

That structure maps well onto MCP. Planning fixes which servers, tools, resources and environments are in scope, who authorized the work in writing, which actions are forbidden, and who can stop the work. Execution combines examination — reviewing configuration, tool descriptions, code, dependencies and logs — with testing a running server in an agreed environment. Post-execution turns raw observations into findings ranked by impact.

The remediation loop with owners and retesting is our own practical addition. SP 800-115 does not single it out as a separate phase; without such a loop, an assessment can remain a document with no verified remediation.

The document's age is a trade-off, not a reason to discard it. Its process guidance is still useful, but its catalogue of techniques predates tool-using AI assistants by many years. It is sensible to use SP 800-115 as the frame and draw the substance of the checks from current web guidance, weakness references and the protocol's own recommendations. NIST links the guide to control families including Assessment, Authorization and Monitoring, Risk Assessment, System and Services Acquisition, and System and Information Integrity — convenient anchors if the report will feed a risk management program.

Mapping the attack surface: tools, data, transport

Inventorying tools and their side effects

An assessment starts with inventory, because scope cannot be justified without it. For each server, record every exposed tool, resource and prompt, and for each tool, what it can read, what it can change, which credentials it uses, which systems it calls and which clients may connect to it. This step can reveal that a "document search" tool can read any path, or that a "view tasks" tool runs under a service account with write access.

Priority is set by capability, not by the tool's name. A wrapper around a shell, the filesystem, SQL queries or arbitrary HTTP requests deserves far closer scrutiny than a tool that returns a static reference list. Tools with side effects need to be flagged separately: sending messages, modifying records, creating payments, starting CI jobs.

Transport: stdio and HTTP

If a server runs locally and directly over stdio, attention shifts to the process environment: which privileges it runs with, which environment variables and secret files it can access, whether it can step outside its working directory, and where it can connect over the network. The transport has no network listener of its own, but outbound connections, abuse through the model, and any separate stdio proxy surface remain in scope.

If a server is reachable over HTTP, familiar API work joins the scope. HTTP itself does not keep state between requests, but that does not mean the server cannot maintain sessions: session identifiers, cookies and server-side tokens are ordinary practice. The tester establishes how the server authenticates clients, how tokens and session identifiers are issued, stored and revoked, and whether another client's session can be guessed or hijacked. If a browser-based component talks to the server, assess CORS on the MCP/API responses and Content Security Policy on the document or management UI that hosts the client. Many of these checks overlap with what we describe in our piece on REST API security assessment.

Trust boundaries

The core of the map is its trust boundaries. In an MCP deployment the user, the model, the client application (the host), the MCP server and downstream systems are distinct parties with different interests and privileges. Any text that can reach the model's context can influence which tool is chosen and with which arguments. In an assessment, tool arguments should therefore be treated as untrusted input, even when they formally arrive from "our own" assistant. This is our professional position, and it drives the rest of the testing logic.

1. Text enters the contextA ticket, document, web page or another tool's output contains an instruction the model will treat as part of its task.
2. The model picks a toolInfluenced by that text, the assistant decides to call a tool and composes arguments — a path, query, address or command.
3. The server runs the handlerIf the handler trusts its arguments, the path escapes its directory, the string reaches a shell, the address points inside the network.
4. A downstream system compliesA database, file store or internal service performs the action with the server's privileges, not those of the user in the conversation.

The diagram shows why testing "at the model layer" is not enough. Even if the assistant resists most known prompt injection phrasings, the server must itself limit what can be done with its tools. How to assess the agent scenarios themselves is covered in our article on agentic AI penetration testing.

Authorization: four distinct layers of control

One important logical error in an MCP deployment is assuming that once a client has connected and presented a token, it may do everything the server can do. In practice access control is spread across several layers, and each must be tested separately.

The first layer is the protocol: who can establish a connection to the server at all and how they prove their identity. The MCP security best practices, in the revision dated 25 November 2025, explicitly prohibit a server from accepting tokens that were not issued for it. Otherwise you get so-called token passthrough: the server accepts a token issued for another service, or forwards the token it received, and audience separation stops working. The assessment checks that the server validates the token's audience and issuer and calls downstream APIs with its own, separately issued credentials.

The second layer is host permissions. The client application decides which servers to connect to, which tools to show the model and when to ask a human for confirmation. This is an important control, but a client-side one: if the server relies solely on "the client won't call a dangerous tool without confirmation," any other client bypasses that restriction.

The third layer is tool and data scope: which tools are available to a given client or user, and which records, directories and tenants each call touches. A valid transport token does not, by itself, authorize every business action. If a user may only see tickets from their own department, that restriction must be enforced on every tool call, not just at connection time.

The fourth layer is authorization in downstream systems. The database, storage or internal API the server calls must apply rules of its own. A service account with maximum privileges turns any bug in a handler into full access.

A separate risk comes from OAuth metadata discovery. The MCP guidance warns that fetching authorization metadata can lead to SSRF if an attacker controls the metadata, endpoint or redirect URLs. This risk sits primarily on the client side — the component that performs discovery and follows the returned addresses — but it is worth describing next to server-side authorization in the report.

Finally, not every endpoint needs authentication. If a server deliberately serves public reference data, demanding a login for the sake of a checkbox only adds friction. The assessment's job is to confirm that what is public was meant to be public and does not grant access to more.

Weaknesses in tool handlers: where old bugs meet new input

Command injection and directory traversal

An MCP tool handler is ordinary code, and it breaks the way ordinary code breaks. The difference is where the input comes from. A tool that builds a shell command, a file path or an SQL query from the model's arguments effectively opens those capabilities to anyone who can influence the model's context.

In its materials for the 2025 CWE Top 25, MITRE notes that some weaknesses, such as command injection, attract particular adversary attention, and suggests taking that into account when prioritizing. CISA's Secure by Design alert series addresses eliminating OS command injection, directory traversal and cross-site scripting, and also warns about exploitation of buffer overflows.

These are the classes the tester looks for first in handlers. Are arguments passed to a shell without parameterization? Is a path normalized and checked to remain inside the permitted directory? Are database queries parameterized? Is tool output rendered in a browser interface without escaping? For components written in memory-unsafe languages, handling of long and malformed input is added to the list.

SSRF and network reach

Tools such as "fetch page content" or "call a webhook" let the model reach addresses it chooses itself. If the server sits inside an internal network, such a tool becomes a proxy to cloud metadata services, admin panels and internal APIs. The check comes down to whether the set of addresses is restricted, how redirects are handled and what exactly the server returns to the model.

Tool descriptions and output as a channel of influence

MCP has a peculiarity of its own: tool descriptions and tool results also enter the model's context. Text returned by one tool can therefore influence the arguments of the next call, and an overly broad or misleading description can influence tool selection. It is worth checking whether tools return untrusted content without marking its source, and whether a third party can alter the tool descriptions the model sees. How to constrain an agent's powers so that such influence does not cause damage is covered in our piece on excessive agency security testing.

How to write up a finding

If the server has HTTP endpoints or a management interface, the 2025 edition of the OWASP Top 10 gives stakeholders a shared vocabulary for describing risk. For engineers, though, something else matters: map a technical weakness to a CWE identifier where one applies, noting whether the class appears in the 2025 CWE Top 25 or in the CWE Top 10 KEV Weaknesses list, which MITRE derives from CISA's Known Exploited Vulnerabilities catalogue. For a process or architecture finding with no suitable identifier, state why the mapping is not applicable.

Above all, a finding should describe the chain: where the input came from, which tool carried it, which weakness fired and what it led to. Without that chain a developer sees "path traversal in read_file" and does not understand why it is critical if "users never type there anyway."

Verification standards: WSTG, ASVS 5.0.0 and their limits

The OWASP Web Security Testing Guide is a practical collection of test cases for web applications. This method uses WSTG 4.2 as a pinned example; the contract and report should name the version actually chosen. For applicable MCP HTTP endpoints and web interfaces, select relevant test cases for authentication, session management, input validation, error handling and configuration, and mark non-applicable cases explicitly.

OWASP ASVS is a standard of verifiable application security requirements, intended to normalize the coverage and rigor of security verification on the market. Version 5.0.0 is published in formats including CSV and JSON, which lets teams build requirements into their own checklists and trackers. The project's rules call for citing requirements with a version prefix, for example in the form v5.0.0-1.2.5, because numbering can change between releases. ASVS includes a requirement to protect against OS command injection using parameterized calls or context-specific command-line output encoding — directly applicable to tools that wrap a shell.

The trade-off is plain: both standards were built for web applications, not AI tool servers. They cover the plumbing well but say nothing about how a model chooses tools or how untrusted content shapes arguments. A good report therefore states explicitly which requirements were applied, which were deemed not applicable and why, and which MCP-specific checks were added on top — including those that follow from the protocol's security guidance. For assessing the model layer, the approaches in our article on OWASP LLM Top 10 assessment are useful.

Testing safely: depth, coverage and production risk

Examination or live testing

Reviewing code, tool descriptions and configuration is low-risk and surfaces design mistakes early, but it can miss runtime behaviour: how the server actually handles an unusual path, or how a proxy behaves on a redirect. Live testing finds genuinely reachable chains but carries operational risk. SP 800-115 stresses that every technique has both advantages and limitations. A convincing MCP server assessment combines both and explains why that particular balance was chosen.

Staging or production

Tools with side effects — sending messages, modifying records, executing commands — should be tested in an isolated environment with test data and dedicated accounts wherever possible. If production testing is unavoidable, the rules of engagement limit actions to non-destructive checks, describe in advance which calls are allowed, and name a contact who can stop the work at any moment. A vulnerability is then demonstrated with a harmless marker rather than a real action.

Automation or expert analysis

Scanners, argument fuzzing and machine-readable ASVS requirements make coverage repeatable. Trust-boundary intersections require separate expert attention: the model, the server and a downstream system may each behave correctly on their own yet produce a dangerous result together. Budget for both approaches rather than treating them as interchangeable.

One-off review or change control

A single assessment captures a single version of the server. Adding a tool or changing its privileges, transport or authentication model should trigger a proportionate review of scope and depth; a calendar-based annual audit does not replace that change review. This is practical advice, not a standard requirement.

If you are deciding right now what can realistically go into scope, the tool inventory and environment description are the natural starting point. Those are exactly the materials worth discussing with the Pentest.red team when agreeing a pentest scope: which tools have side effects, whether a staging environment exists, and which accounts can be set aside for testing.

What the output should look like: findings, evidence and retesting

CISA's Secure by Design initiative starts from the premise that customer security is a business requirement, not an add-on: products should be secure out of the box, and logging, multi-factor authentication and single sign-on should not be sold at extra cost. For an MCP server this translates into a clear set of expectations. Tools are closed by default and opened explicitly for specific clients. Clients of non-public servers authenticate strongly. The audit log is enabled without extra configuration. Each tool holds only the credentials it needs, and high-impact actions require human confirmation.

Assessment results should land in three places. In the development backlog: fixes with owners and retest criteria. In the risk register: residual risk consciously accepted by an accountable owner. In detection engineering: log events that would reveal abuse of each high-risk tool — who invoked which tool, which necessary redacted argument fields were used, and how the call ended. Do not copy secrets or sensitive payloads into the log; define its access and retention. NIST CSF 2.0 helps fold these results into the organization's overall cybersecurity risk program.

Acceptance is where a formal assessment is easiest to tell apart from a useful one.

A note on retesting: a fix in a handler is easy to make too narrow — blocking "../" but forgetting encoded variants or symbolic links. How to build a retest that checks remediation in agreed scenarios and explicitly bounds its conclusion to that coverage is covered in detail in our piece on penetration test remediation validation.

How to buy an MCP server audit without buying a formality

CISA's Secure by Demand guide is aimed at software customers negotiating with vendors and resellers; together with Australia's ACSC, the agency has also published guidance on choosing secure and verifiable technologies. The common principle is simple and applies equally to buying an assessment: demand verifiable evidence, not assurances.

When comparing providers, ask for an anonymized sample report and a description of the method. Ask how the provider maps applicable findings to CWE and versioned ASVS requirements, and how it explains the absence of a suitable mapping, how it handles tools with side effects, whether retesting is included, and how it distinguishes protocol, host, tool-level and downstream access controls. A good test question is to ask them to explain how text from an untrusted document could reach a tool handler in your architecture. A provider that cannot answer is unlikely to find the problems specific to MCP.

If you are buying a third-party MCP server rather than commissioning a test of your own, ask the vendor whether it publishes a vulnerability disclosure policy, documents its security logging, and has signed the CISA Secure by Design Pledge. The pledge is a public statement of intent, not a certification, so it can only be one factor among several. And remember that a pentest is not a certification or an attestation either: it is a snapshot of what could be found within an agreed scope and timeframe.

How deep the assessment should go

Depth is best chosen by what the server can do, not by what it is called. For a server that only reads non-sensitive reference data, an internal review may be sufficient only after verifying the architecture: transport, process and outbound-network privileges, credentials, data classification, dependencies and absence of side effects; use ASVS and WSTG only for applicable web controls. A server that reads sensitive data or opens access to internal systems needs a deeper structured assessment following the SP 800-115 phases, with relevant WSTG test cases for HTTP surfaces and checks on data scope. For side-effecting tools — writing data, sending messages or executing commands — strengthen the scope with expert analysis of those tools, independence proportionate to risk, CWE mapping where applicable, and retesting before broad rollout.

Repeat the assessment when a new tool is added, an existing tool's privileges change, the transport or authentication model changes, or a related weakness class rises noticeably in the CWE lists or the CISA KEV-based list. If a server moves from one category to another — say, a search tool gains the ability to modify records — that is a reason to revisit the scope, not just to append a couple of test cases. For servers with side effects, the format and composition of the work can be discussed as part of our penetration testing service: which tools to analyze manually, where a staging environment is needed and how the retest will be organized.

Conclusion

A useful MCP server security assessment is built not on inventing new techniques but on applying proven approaches with discipline to a new trust model: general standards supply the process, test cases and priorities, while the MCP security guidance covers the specifics of tokens and metadata discovery.

The practical takeaway fits into a handful of principles. Scope by the server's capabilities, not its name. Treat every tool argument as untrusted input. Test authorization at each layer separately, and never mistake a transport token for permission to do anything. Test side-effecting tools only safely and with authorization. Demand chains, standard versions and retesting from your provider. Then a one-off check becomes a repeatable control that lives alongside the server.