Findings · Security engineering

In a server built to exhibit the bug, tools filtered from the discovery listing remained reachable through the call surface: a presentation-layer authorization control with no execution-layer enforcement behind it.

Evidence

The audit reads the tools a server advertises for listing, then checks whether the tools it does not advertise are still callable. On a mock built to show the bug, they are: the listing is filtered to one tool while all three run. The vulnerability class is real and externally catalogued, but this number is a demonstration of the mechanism on a fixture, not a survey. The harness is deliberately conservative, an unrecognised denial reads as inconclusive, never as a pass.

Sample. One mock server: 1 of 3 tools listed, 3 of 3 reachable, the 2 hidden tools callable. A hand-built fixture, not a population.

Boundary

This is a demonstration against an authored mock, not a measurement of real servers. It does not test HTTP transport, prompt injection, or token scope, and a passing result does not mean a server is secure.

Independent reproduction. None known.

Reproduction

pip install -e '.[dev]' && cd examples && mcp-boundary-audit --config vulnerable_server.config.json --execute --i-own-this-server

Toolchain: Python, the Model Context Protocol SDK, stdio transport; no network
Expected output: Verdict: FAIL; Listed: 1 tool; hidden tools ping and whoami callable; exit 1
Claim stated at: repowazdogz-droid/mcp-boundary-audit · README.md:27-28; src/mcp_boundary_audit/mock_server.py:81-87
Verified at: repowazdogz-droid/mcp-boundary-audit@d932934f (2026-07-20)

This pass. Re-verified this pass: the audit and test suite were re-run at d932934f (FAIL and PASS reproduced, 11 tests passing).

Artifact: repowazdogz-droid/mcp-boundary-audit