{
  "id": 6706740,
  "title": "A happy-path MCP demo proves almost nothing about tenant isolation",
  "url": "https://urgent.news/2026/09/11/a-happy-path-mcp-demo-proves-almost-nothing-about-tenant-isolation",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-11T04:20:33.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/kielltampubolon/a-happy-path-mcp-demo-proves-almost-nothing-about-tenant-isolation-17p"
  },
  "original_language": "en",
  "account": "MCP demos are consistent. A tool is registered, a client calls it, and the tool returns the expected data. The demonstration signifies that the tool functions as intended, but it provides no insight into scenarios where the tool is given incorrect tenant information, or when it declares excessive scope, or when it is about to be used by users who did not create it. To address this gap, I developed a preflight scanner. This post explains what a bounded preflight can examine, and what it cannot.\n\nAn MCP tool is a capability. Certain capabilities are safe to share freely, while others are not. Typical risky declarations include: a tool that executes shell commands from user input, a tool with broad filesystem or network scope when it only needs to access one directory, a tool containing sensitive values from a copied configuration, a tool that writes without any approval, or a tool that takes unvalidated URLs or file paths from agents. Such issues are not rare; they appear in current MCP servers.\n\nThe scanner I built examines two types of checks: static and behavioral. Static rules analyze tool metadata, such as name, description, declared scopes, and any command patterns. Four rules address common cases: MCP-001: unsafe command declaration. Any tool that runs a shell or accepts free-form command strings. MCP-002: excessive filesystem or network scope. Any tool that declares filesystem:* or network:* scope when it does not need it. MCP-003: secret-like value in tool metadata. Any tool that includes an API key, token, or password in its description or default configuration. MCP-004: untrusted input reaching a sensitive operation. Any tool where user input flows into a command, file path, or URL without a clear boundary.\n\nBehavioral checks involve calling a local fixture server and observing the outcome: Tenant boundary: does a token for tenant-a access data from tenant-b? Write approval: does a write tool operate without explicit, request-bound permission? Quota: does an infinite loop execute indefinitely, or does it stop after a set limit? Each check results in pass, fail, blocked, or incomplete status. No finding is marked as pass if the check was not performed.\n\nThe scanner generates both a Markdown report and a JSON report. Each issue includes: a rule ID (MCP-001, etc.), severity (info, low, medium, high), affected tool, sanitized evidence line (with any secret-like value redacted), remediation, and status (open, accepted, resolved). Importantly, a finding becomes an engineering task rather than a vague warning.\n\nIt is crucial to understand that a preflight is not a penetration test, certification, or scan of a real customer environment. It does not replace a thorough security review. Instead, it is a bounded, repeatable initial screening that catches obvious issues before deployment, without overstating its capabilities. The primary limitation of a preflight is that it can only identify if a tool declares excessive scope, not whether that scope is appropriate for the business context. Similarly, it can indicate if a write tool ran without an approval, but it cannot determine if the approval was correctly granted in a real workflow. The scanner functions as a filter, narrowing the scope for human review that remains necessary.\n\nThe scanner source code is available at github.com/glatinone/mcp-security-preflight. If your team plans to expose MCP tools to users or internal agents and seeks a bounded first pass, I offer short sprints focused on this task.",
  "summary": "Most MCP demos look the same. A tool is registered. A client calls it. The tool returns the expected data. Everyone nods. That demo tells you the tool can work. It tells you nothing about what happens when the tool is given the wrong tenant ID, or when it declares scope it should not have, or when it is about to reach users who did not write it. I built a preflight scanner for exactly that gap.…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}