Identity and tenant isolation
Can a caller use another tenant’s record ID, reuse a token outside its intended audience or reach a tool without the required authorization?
MCP penetration testing / Oktsec AssessmentYour MCP server.
Your MCP server.
Tested beyond the happy path.
Find the tool calls that reach another customer’s data, expose a credential or exceed the access you intended.
A scoped assessment of your server and its deployment, with evidence your engineers can reproduce.
Your deploymentLocal stdio · Remote HTTP
Engineering evidenceReproduction · Impact · Remediation
Follow-throughFindings review · Scoped retest
The server. Its permissions. The systems it can reach.
MCP penetration testing examines a server, its tools and the systems behind them. We test the implementation and its deployed permissions, including what happens when an authorized caller supplies an unexpected argument.
Tools and arguments
Can a file path, query, URL or command exceed the operation the tool was intended to provide? We follow the request through to the backing system.
Instructions and responses
Can a tool description or returned document redirect the connected agent into an unauthorized action? Agent behavior is tested when the client workflow is in scope.
Credentials and outbound access
Which credentials does the server use? Can a tool expose them or send data to an unapproved destination?
Installation and dependencies
When source access is agreed, review launch commands, install scripts and dependencies alongside the permissions they receive.
The proposal identifies the servers, transports, tools, clients and connected systems included. Testing a remote HTTP service and a local stdio process requires different access and test conditions.
Follow the tool call into the system behind it.
A schema tells you what a tool accepts. The assessment checks what the implementation does with it: whose credentials it uses, which records it can reach and where authorization is enforced.
- 01
Establish the intended access.
Agree on test identities, seeded data, tool permissions and stop conditions.
- 02
Exercise the exceptions.
Change the record, path or destination. Follow the request through the server to the backing system.
- 03
Make the finding reproducible.
Keep the request, preconditions and observed result. Explain the missing check and verify the agreed fix.
Evidence engineering can reproduce.
Security gets a prioritized view of the tested risks. Engineers get the requests, preconditions and remediation needed to address each finding.
- Scope and coverage
- Servers, versions, tools, identities and environments tested, with exclusions and access limitations.
- Technical findings
- Reproduction steps, supporting evidence, observed impact and remediation for each confirmed issue.
- A findings review
- Walk through the results with the people responsible for the server and the systems it can reach.
- Retest of original findings
- One retest is included. Its scope, environment and request window are defined in the proposal.
Start with the server and its intended access.
Share the number of servers, their transports, the important tools and your timing. We agree on access, permitted tests, stop conditions and deliverables before work begins.
Building an MCP server?
Test before exposing it to customers or giving it access to sensitive systems. Source access can help trace a finding to the handler and authorization check that need changing.
Adopting a third-party server?
Test the version, deployment and permissions you actually plan to use. We agree on testing authorization and any limits imposed by the server owner.
Remote, on-site or hybrid delivery can be agreed. Travel, lodging, travel days and other agreed on-site expenses are paid by the client and specified in the proposal.
Discuss your MCP testing scopePublic work you can inspect
Research backed by engineering.
Review the founder’s published disclosures and merged fixes. The work is linked to its original source.
Inspect public findingsUnderstand where MCP trust breaks.
Start with a clear answer.
What is MCP penetration testing?
MCP penetration testing is a scoped security assessment of a Model Context Protocol server, its tools and connected systems. It tests whether callers can exceed intended permissions through tool arguments, authorization failures, exposed credentials or connected agent behavior.
Is this a pentesting tool that uses MCP?
No. This is a professional service to test the security of MCP servers and their deployments. The server and connected workflow are the assessment targets.
Do we need to provide source code?
Source access helps trace handlers, dependencies and authorization checks, but the available access is agreed during scoping. A deployment-only assessment has different coverage and limitations from a source-assisted review.
Can you test local stdio and remote HTTP servers?
Both can be considered in the scope. A local process requires an agreed test environment; a remote server requires authorized endpoints, test identities and relevant access. Client behavior and backing systems are included only when agreed.
Does the engagement include remediation verification?
One retest of the original findings is included. The proposal defines its scope, environment and request window. New tools, versions or systems may require additional testing.
Can testing take place at our offices?
Remote, on-site or hybrid delivery can be agreed. Travel, lodging, travel days and other agreed on-site expenses are paid by the client and specified in the proposal.
Put your MCP server to the test.
Tell us what it exposes, who uses it and what it must protect. We will define a testing scope with your team.