Testing MCP Servers
Aikido Pentest can test your Model Context Protocol (MCP) server. Point an assessment at your MCP endpoint, tell Aikido how to authenticate, and the agents handle the rest.
Run MCP server pentests on a staging or test environment. Agents send requests to your endpoint and may create, modify, or delete data through it.
What gets tested
Aikido probes the tools, resources, and prompts your server exposes. Typical focus areas:
Tool discovery – which tools, resources, and prompts the server exposes, and whether any should not be reachable
Authorization – whether unauthenticated or low-privilege callers can invoke tools or read resources they shouldn't
Unsafe tool use – parameter injection, SSRF-style behavior, command execution, and data exfiltration through tool calls
Sensitive data exposure – secrets, tokens, or cross-tenant data returned by tools or resources
Integration risk – weak trust boundaries between the MCP server and the downstream systems its tools reach
For background on agent- and tool-specific risks, see OWASP Top 10 for Agentic Applications.
What you need
A remote endpoint for the MCP server (for example,
https://mcp.staging.example.com/mcp).The authentication the server expects, usually a token or API key sent as a header.
Ownership of the domain so it can be verified.
Aikido's pentest IP addresses added to your firewall, WAF, or API gateway allowlist so agents can reach the endpoint.
Set up the pentest
Add the endpoint to scope
Create an assessment, and on the Scope step enter the MCP server's endpoint as the target. Use the exact URL and path clients connect to, such as https://mcp.staging.example.com/mcp.
Complete domain verification for the host serving the endpoint. If the server is only reachable on an internal network, use the Aikido Broker: add the internal MCP URL as a broker resource and select that broker URL in scope.
Provide authentication
On the step Test Users, provide the instructions on how to connect to your MCP. This can be done in two main ways:
Authenticating to the MCP server directly:
Bearer token (most common). MCP's authorization standard is OAuth 2.1, so most servers expect an access token. Mint a token for a test identity and add it as
Authorization: Bearer <token>.API key. Some servers use a key header instead, such as
X-API-Key: <key>.Multi-tenant routing. Add any tenant or workspace headers your server requires alongside the token.
Authenticating through an interactive user login flow: provide the step by step instructions on how the user can log in with the browser and can get access to the session token.
Add context, then launch
For the best results, link the MCP server's code repository in the Code & Documentation step. This promotes the run to a whitebox pentest and gives the agents the maximum context to uncover deeper logic-flow vulnerabilities. Aikido reads the source to map the tools, their callers, and the downstream systems they reach.
If you can't link the repository, use Additional context to describe the actions the server exposes, which callers or roles should reach each one, and the downstream systems they touch (databases, internal APIs, file storage).
Finish the remaining Safety Check, Pricing, and Summary steps, then start the run. If the server is sensitive to high request volume, lower the Maximum Requests Per Second on the Safety Check step to ease load.
Tips
Use a dedicated test instance with non-production data, and mock or disable destructive actions where you can.
Issue a test token with the permissions you want validated, and rotate it after the assessment.
Match production. The endpoint, path, and auth you scope should be what real clients use.
Need help?
If agents can't reach your endpoint or authentication fails, open the Intercom chat in the bottom right corner. Our team is here to help!
Last updated
Was this helpful?