03 / AI & SECURITY
MCP Sentinel
Tool discovery is a capability. Execution is a permission.
Denied tools never enter the upstream execution path in the reference scenarios.
01 / CONTEXT
The problem.
An agent discovering a tool should not automatically gain permission to run it. Security rules need an enforcement point outside the model, with a predictable response to unknown tools and invalid policy.
02 / IMPLEMENTATION
The approach.
A small MCP policy gateway built with the official .NET SDK. It checks requested tool names against immutable rules, forwards only explicit Allow decisions and emits sanitized security audit events.
Simplified flow. Implementation details and boundaries are documented in the repository.
03 / TRADEOFFS
Decisions that matter.
Fail closed by default
Unknown tool names are denied. Invalid policy prevents startup. RequireApproval blocks because the reference implementation has no approval workflow.
Keep policy outside model behavior
Exact tool-name matching controls forwarding. The client may discover a tool without receiving permission to execute it.
Keep the audit useful and bounded
Generated correlation IDs connect decisions and terminal outcomes. Tool arguments and response content are excluded from audit events.
04 / EVIDENCE & BOUNDARIES
What was checked.
- Real MCP initialization, discovery and forwarding
- Policy validation and denied-call upstream counters
- HTTP integration tests and cancellation scenarios
- SDK continuation behavior and sanitized audit checks
Checks summarized from the project documentation. See the repository and CI for current details.
Scope of this reference project
Experimental local reference implementation with one trusted mock upstream. It is not a production security product. SDK continuations can reissue allowed requests; there is no exactly-once guarantee.
Run it locally
Follow the repository README for prerequisites and configuration before running:
pwsh -File ./scripts/run-demo.ps1WORKING ON A SIMILAR PROBLEM?