Independent review of one MCP authorization boundary: source, configuration, identity propagation, handler authorization, downstream resource access, remediation, and denied retest.
We trace the full access path, not just the server.
An analyst reviews source, configuration, identity, authorization and trust boundaries. Tooling assists; it does not decide.
Five selected telemetry indicator classes, backed by inspectable rules. This is not a claim of comprehensive detection.
Every finding is traceable to source, configuration, or an approved test you can re-run.
What was tested, what was skipped, and what this review does not cover, stated in writing.
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.
Not sure it fits? and we'll tell you plainly whether it's in scope.
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. A scanner does not have that context.
The service combines implementation and configuration review, identity and authorization analysis, host permissions, and observed tool traffic. Each result is validated to determine whether it is exploitable in your environment.
The manual review is the product. The five telemetry checks are one input, never the conclusion.
Read the full methodWhere the host process, the MCP server, tools, credentials and data meet, and which of those crossings are actually authorized.
Tool definitions, argument handling, permission scopes, and identity, read directly rather than inferred from traffic.
Selected tests in an approved non-production environment, plus a bounded, minimized telemetry capture analyzed offline.
Each indicator and test result is verified for reachability, preconditions and impact before it becomes a finding.
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.
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.
Automated checks narrow the review. We then trace the source, configuration, identity and authorization path, reproduce failures in an approved test environment, and retest the fix.
Normalize telemetry and identify the boundary worth testing.
Inspect the implementation and run authorized negative tests.
Document the failure, remediation and focused retest.
| Security boundary | What we test | Passing condition | Evidence delivered |
|---|---|---|---|
| Identity and object access | Cross-user, cross-tenant and over-scoped calls. | Trusted identity is bound server-side and every object/action is authorized. | Source trace, negative test and retest result. |
| Filesystem boundary | Encoded, absolute, traversal and symlink escape attempts. | The canonical target stays inside the approved root and the host blocks escape. | Boundary configuration and reproducible denial evidence. |
| Tool and release integrity | Schema, description, package and artifact changes. | The running release and normalized tool manifest match an approved version. | Manifest diff, provenance check and approval record. |
| Secret flow and egress | Credentials entering model-visible data, logs or outbound actions. | Secrets use handles or redaction and unauthorized egress is denied. | Canary result, redaction trace and egress test. |
| High-impact writes | Write actions without the required role, scope or approval. | Every handler enforces authorization and the product's approval policy. | Handler trace, denied calls and focused retest. |
No automated match is treated as a confirmed vulnerability, and no quiet scan is treated as a passing control. The method and proof pages publish detector scope and residual limits.
A sample of the lines the checks emit, drawn from self-authored fixtures. This is a static illustration, not a live feed or customer data. Each adversarial line is an indicator that an analyst then has to confirm.
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.
Log JSON-RPC tool transactions through a transparent, inspectable pipeline proxy on your own network.
Run the documented redaction locally. It removes or replaces content-bearing fields while keeping the paths, identifiers, commands and descriptions the review needs.
Inspect the minimized file and its residual-disclosure report by hand. Nothing leaves your network unless you choose to send it.
Rasheed Farhat scopes, performs, documents, and walks through every review. Tooling assists with bounded evidence; it does not make the security decision.
Meet the reviewerThe $1,250 design-partner pilot covers a tightly bounded, authorized review. Systems, limits, and data handling are agreed in writing; larger environments are scoped separately. The experimental price remains unvalidated.
See scope & the offerName the authenticated identity, handler, and downstream resource. Rasheed will tell you whether it fits the bounded review.
Discuss a boundary