The tool, not the prompt
A model can be careful and still call a tool that writes data, moves money, or changes access. The risk lives in what the tool does, not in how the request was phrased.
MINDBURN LABS
Inspect surfaceMCP security
Securing what MCP tools can actually do.
MCP connects models to tools. The risk is the side effect a tool performs, not the protocol. HELM checks the proposed action against policy before it runs, treats external tool output as untrusted, and records a verifiable receipt.
No tool call without a verdict. No effect without a receipt. No output trusted by default.
Where the risk lives
The risk is the side effect, not the protocol.
MCP is plumbing. It lets a model reach tools and data. The consequence appears when a tool runs: a record is written, a payment is made, an access grant changes. Securing MCP means owning that action, not just watching the connection.
Untrusted tool output
Tool results and MCP server responses flow back into the model. HELM treats external tool output and MCP servers as untrusted unless explicitly normalized and approved.
Unregistered tools
New or unknown MCP tools appear without review. Unless an action is explicitly allowed, it should be denied, with a record of the attempt.
Gateway vs authority
A gateway routes the call. HELM decides whether the action may run.
Routing and observation are useful, but they do not stop an unauthorized side effect. HELM is the layer that returns a verdict on the action itself.
An MCP gateway
- Routes tool calls between clients and servers.
- Observes traffic and aggregates logs.
- Sees the request, not the consequence.
- Leaves the side effect ungoverned.
HELM
- Checks the proposed action against policy before the effect runs.
- Returns ALLOW, DENY, or ESCALATE on the side effect.
- Treats external tool output and MCP servers as untrusted unless explicitly normalized and approved.
- Records a signed receipt and EvidencePack for what happened.
Authorization at the action
Every tool call takes the same path.
Authorization happens at the action, not at the prompt. Unknown tools and unapproved actions stop by default.
Step 1
A tool is invoked
An agent or MCP client proposes a tool call that would cause a side effect.
Step 2
The action is checked
HELM checks the proposed action against policy and context, before the effect runs.
Step 3
A verdict returns
ALLOW, DENY, or ESCALATE. Unknown tools and unapproved actions are denied by default.
Step 4
A receipt is signed
The decision and the effect are bound together and recorded as a signed receipt and EvidencePack.
Receipts for tool calls
A tool call you can prove, after the fact.
A log says a call happened. A receipt says the action was checked, what the verdict was, and which policy applied. HELM records the second.
Bind the effect
An allowed tool call is bound to the verdict that authorized it, with scope and policy.
Record the denial
A denied or unknown tool call is recorded too, so the attempt is never silent.
Verify offline
The receipt and EvidencePack verify outside any dashboard, by anyone.
Questions
MCP security, in plain terms.
What is the security risk in MCP?
MCP connects a model to external tools and data. The risk is not the protocol itself but the side effect a tool performs once it is called: a write to a record, a payment, an access change. Securing MCP means deciding whether that action may run, not just routing the call.
Is HELM an MCP gateway?
No. A gateway routes and observes MCP traffic. HELM checks the proposed action against policy before the side effect runs, denies anything unknown or unapproved by default, and records a signed receipt. It sits at the decision, not at the wire.
How does HELM handle untrusted tool output?
HELM treats external tool output and MCP servers as untrusted unless explicitly normalized and approved. Output that has not been normalized does not get to act on your behalf, and the disposition is recorded.
What evidence do I get for a tool call?
Each governed tool call produces a receipt that binds the verdict to the effect, plus an EvidencePack that verifies offline. Anyone can check what was allowed, what was denied, and under which policy.
Keep reading
Follow the tool-call proof path.
Terms
Plain-language terms
- EvidencePack
-
A small bundle of records used to verify one event or review path.
Use for replayable evidence slices. - ProofGraph
-
A record chain that helps replay and check what happened.
Use for HELM proof records and replay paths. - ALLOW
-
HELM lets the action run.
Use as a canonical verdict. - DENY
-
HELM blocks the action.
Use as a canonical verdict. - ESCALATE
-
HELM stops and asks for more facts, policy, or human approval.
Use as the canonical non-dispatch path for missing facts, policy hold, or approval.
Don’t trust the tool. Verify the action.
Bring one MCP tool call to the boundary and see the verdict and the receipt.