Skip to main content
About

An accountable reviewer for a bounded MCP review.

Independent review of one MCP authorization boundary: source, configuration, identity propagation, handler authorization, downstream resource access, remediation, and denied retest.

Reviewer of record
Founder and hands-on reviewer

Rasheed Farhat

Rasheed scopes, performs, documents, and walks through every review. The work focuses on the point where authenticated identity becomes a concrete authorization decision inside an MCP handler and its downstream resource lookup.

Tooling assists with evidence collection and bounded indicators. It does not decide whether a finding is real, and the work is not delegated to an opaque scanner.

[email protected]
Accountability
One named reviewer
Delivery
Evidence, fix, denied retest
Boundary
Point-in-time, not certification
Why this, narrowly

MCP moves a real trust boundary into a place few people are reviewing yet.

When a model can call tools that read files, hold credentials, or act on data, the interesting security questions stop being about the network and start being about which tool calls are actually authorized, and what a crafted argument or a poisoned tool description can reach.

That is a specific problem. MCP Detect examines agreed trust boundaries in context, instead of running a broad scanner that reports strings without deciding whether they matter.

How the work is done

Methodical

A fixed sequence, documented on the method page, so a review is repeatable and a client knows exactly what happened and in what order.

Transparent

The framework's rules and its reproducible measurements are open to inspection. You verify the work rather than take a claim on faith.

Accountable

Rasheed labels findings by confidence, writes down the limits, and stands behind the final report.

Honest about limits

Coverage is narrow and stated up front. A review that overclaims is worse than no review because it hides the risk it missed.

Why the method is open

Transparency is part of the operating model.

The service is human-led; the framework is internal delivery tooling, not the product being sold. Keeping it inspectable lets technical buyers and security leaders verify the work without trusting a black box.

A buyer pays for scoped source, configuration, identity, authorization, architecture and evidence review, not for a secret corpus or an automated scorecard.

Licensing

Why a permissive license

The tooling is offered under a permissive (MIT-style) license rather than copyleft. The business is a services engagement evaluated by technical buyers who need to read and verify code freely, not a product whose source has to be guarded. Openness serves the review; it does not compete with it.

Review the evidence
Next step

Bring one identity-to-resource path.

Rasheed will tell you whether it fits the bounded review before asking for evidence.

Discuss a boundary
A boundary

Discuss it with Rasheed

Name the authenticated identity, the MCP handler, and the downstream resource. Do not send source, credentials, or telemetry in the first message.

Discuss a boundary See the review scope