Skip to main content
Method

How a review actually runs.

We take an agreed MCP review boundary from intake to re-test: architecture and source review, controlled testing, evidence analysis, and a re-check of what you fix. Automated checks are one input; anything an analyst has not verified is labeled unverified.

The process

The review process, step by step

A fixed sequence and a traceable evidence trail. Each step produces material the next builds on.

1

Intake & scoping

You describe the environment and the trigger. We agree, in writing, the systems and capabilities in scope, authorization for testing, the evidence path, exclusions, and data handling.

2

Architecture & trust-boundary review

We map where the host process, MCP server, tools, credentials and data meet, and which crossings are actually authorized versus merely possible.

3

Source, configuration & authorization review

Tool definitions, argument handling, permission scopes and identity are read directly. This is the core of the engagement and the part a scanner cannot do.

4

Controlled testing

With written permission and only in an approved non-production environment, selected tests such as tool poisoning, path traversal, and permission-boundary checks are run and recorded.

5

Telemetry capture & evidence analysis

A bounded, minimized telemetry capture is analyzed offline with five inspectable rule families plus normalized, recursive and correlated checks. Matches and gaps are recorded as evidence, not conclusions.

6

Manual validation

Every automated indicator is checked against source, configuration and intended authorization for reachability, preconditions and impact before it can become a finding.

7

Risk prioritization

Confirmed findings are ranked by real-world impact and exploitability in your environment, not by raw indicator count.

8

Remediation guidance

Each finding ships with implementation-ready remediation written against your code and configuration, plus compensating controls where a full fix is out of reach.

9

Re-test

Fixes you apply within the agreed window are re-checked against the original evidence, so a "resolved" finding is verified rather than assumed.

Where the line sits

Automated work assists. It never concludes.

Analyst

Judgment

Trust boundaries, source and configuration, identity and authorization, reachability, impact, prioritization, and remediation. The reasoning that turns an indicator into a finding.

Framework

Assistance

Inventories observed MCP traffic, normalizes nested arguments, correlates sensitive flows, and runs five inspectable rule families. It surfaces candidates for review; it does not decide whether a control passed.

What this method is not

This is a documented, inspectable process. It is not an independently certified or universally standardized methodology, and it does not replace a full source-code audit, a complete identity and authorization assessment, or business-context risk work outside the agreed integration.

It is deliberately bounded: systems and trust boundaries are agreed in writing, then reviewed carefully. The reproducible measurements behind the automated checks and their limits are on the evidence page.

See exactly what's in and out of scope
Next step

Want this run against your integration?

See the evidence
Request a review

Start a conversation

Tell us what your MCP environment can reach and what prompted the review. We'll reply with a clear scope and next steps.

Email ops@mcpdetect.dev See the review scope