Skip to main content
Human-led MCP integration review

Find the dangerous trust and authorization paths in your MCP integration before you ship it.

We review one MCP server and one host integration using source and configuration analysis, selected controlled tests, minimized telemetry, and analyst-led validation. Automated indicators are narrow and are never exploit confirmation by themselves.

See the review scope

Rasheed Farhat is accountable by name for every review. Findings come with reproducible evidence and a written statement of what was not covered.

Illustrative — the boundary under review
Host app / AI agent review boundary MCP server tools credentials · data tool calls

What defines the review

Human-led

An analyst reviews source, configuration, identity, authorization and trust boundaries. Tooling assists; it does not decide.

Bounded indicators

Five selected telemetry indicator classes, backed by inspectable rules — not a claim of comprehensive detection.

Reproducible evidence

Every finding is traceable to source, configuration, or an approved test you can re-run.

Explicit limits

What was tested, what was skipped, and what this review does not cover — stated in writing.

Who this is for

You are wiring an MCP server into something that matters.

This review is built for teams shipping an MCP integration into a product path — where a tool can read files, hold a credential, or act on data on a user's behalf.

  • You are launching a remote or local MCP server and want a second set of eyes before it reaches customers.
  • An agent in your product can call tools that touch credentials, customer data, or a filesystem.
  • You are entering an enterprise security review and need a defensible, evidence-backed account of one integration.

Not sure it fits? and we'll tell you plainly whether it's in scope.

Why a scan isn't enough

A free scanner reports strings. A review decides whether they matter.

Local stdio MCP traffic is not visible to network monitoring alone, and an automated match is only a starting point. Whether a matched pattern is actually a vulnerability depends on the code path, the identity making the call, the permissions behind it, and the surrounding architecture — context a scanner does not have.

The service combines that context: implementation and configuration review, identity and authorization analysis, host permissions, and observed tool traffic, correlated by a person who can say why a finding is — or isn't — exploitable in your environment.

What we review

One integration, examined as a whole.

The manual review is the product. The five telemetry checks are one input to it — never the conclusion.

Read the full method
1

Architecture & trust boundaries

Where the host process, the MCP server, tools, credentials and data meet — and which of those crossings are actually authorized.

2

Source, configuration & authorization

Tool definitions, argument handling, permission scopes, and identity — read directly, not inferred from traffic.

3

Controlled testing & telemetry

Selected tests in an approved non-production environment, plus a bounded, minimized telemetry capture analyzed offline.

4

Analyst validation

Each indicator and test result is verified for reachability, preconditions and impact before it becomes a finding.

What you receive

A report an engineer can act on the same day.

  • Prioritized findings, each with the evidence behind it and reproduction steps where a controlled test applies.
  • Implementation-ready remediation written against your code and configuration.
  • A clear line between analyst-confirmed findings and unverified automated indicators.
  • An explicit scope-and-limitations statement: what was tested, skipped, or out of scope.
Sanitized example finding — illustrative, not a customer result
High SAF-T1105 · path traversal Analyst-confirmed

Tool argument reaches outside the intended workspace

A file-read tool accepted a relative path that resolved above its configured root. Confirmed reachable from the host agent in an approved test; a crafted argument returned a file outside the workspace.

Remediation: resolve and canonicalize the path, then reject any result outside the configured root; enforce the workspace boundary at the host as defense in depth.

Details, identifiers and paths are fabricated for illustration.

Evidence, bounded honestly

The numbers we publish measure the harness — not your environment.

The public sample reproduces hit counts against self-authored fixtures and one self-authored benign corpus. These verify that the tooling behaves as reported; they do not establish independent accuracy or predict how it performs on your traffic.

5
Telemetry indicator classes, each backed by inspectable rules and tests.
0 / 4,727
Indicator hits on one self-authored benign corpus. A regression baseline, not a false-positive guarantee for your data.
See how to reproduce it
What the checks catch — and miss

Capabilities and their gaps, side by side.

The automated checks are partial by design. Each row states what it flags, where it can be evaded, and the compensating control that closes the gap. Automated indicators require analyst verification.

Telemetry indicator classes, their detection status, known gaps and compensating controls
Indicator Target vector Status Known gaps Compensating control
SAF-T1001 Tool poisoning via hidden text Partial Plain-text directives; homoglyph keywords. Unicode normalization; manual schema review.
SAF-T1104 Sensitive absolute-path read Partial Paths outside the known-sensitive list. Host-level jail / container access limits.
SAF-T1105 Relative path traversal Partial URL-encoded traversal sequences. Enforce workspace jail at the host.
SAF-T1201 Rug-pull baseline drift Partial Updates that keep the same size and hash. Hash pinning; periodic manual code audit.
SAF-T1502 Credential-exposure indicators Partial Base64 payloads; custom argument names. Egress filtering; TLS inspection.

Behavior-only compromise that leaves telemetry unchanged is not covered by these checks — the manual review is where that risk is addressed.

What an indicator looks like

Illustrative indicator lines.

A sample of the lines the checks emit, drawn from self-authored fixtures. This is a static illustration — not a live feed, and not customer data. Each adversarial line is an indicator that an analyst then has to confirm.

[SYSTEM] Context window hydrated with 2,401 tokens.
[ALERT: path_traversal] Argument contains parent-directory traversal toward a sensitive path; analyst validation required.
[SYSTEM] Tool call executed: get_weather("San Francisco").
[SYSTEM] Token usage nominal (15%).
How your data is handled

No credentials, no production access, no standing data.

We do not ask for credentials, production access, or raw database contents. You capture and minimize telemetry on your own network, review the residual-disclosure report, and decide whether the file is safe to share. The minimizer removes known content-bearing fields — it is not a general secret or PII guarantee.

1

Capture

Log JSON-RPC tool transactions through a transparent, inspectable pipeline proxy on your own network.

2

Minimize

Run the documented redaction locally. It removes or replaces content-bearing fields while keeping the paths, identifiers, commands and descriptions the review needs.

3

Review & decide

Inspect the minimized file and its residual-disclosure report by hand. Nothing leaves your network unless you choose to send it.

Who runs the review, and the design-partner offer

Who runs the review

Rasheed Farhat runs the review.

The review is performed by one independent specialist, not a rotating team or an automated pipeline. The method is kept inspectable so you can verify the work rather than take it on trust.

About the practice
Design-partner offer

An early, honest engagement.

The current design-partner pilot is a fixed experimental $1,250 for one authorized MCP server and one host integration. Customer demand and the price have not been independently validated. Scope, authorization, data handling, exclusions, and price are agreed in writing first.

See scope & the offer
Next step

Have an MCP integration going to production?

Tell us what it does and where it's headed. We'll reply with whether it's in scope and what a review would look like.

Read the method first
Request a review

Start a conversation

We review one MCP server and one host integration, and validate selected automated indicators in their source, identity, authorization, and architecture context. Tell us about the integration and the trigger — we'll reply with scope and next steps.

Email ops@mcpdetect.dev See the review scope