Host
The application or agent runtime a user interacts with.
MINDBURN LABS
Inspect surfaceGlossary
Model Context Protocol (MCP)
MCP is an open standard for connecting models to tools and data. It standardizes how a model reaches outside its own context. It does not decide whether a tool's side effect should run.
MCP connects. Tools can change things. Something has to rule on the side effect.
What it is
A standard way to connect a model to tools and data.
Before MCP, each integration between a model and an external system was bespoke. MCP defines a common protocol so a host application can connect a model to many servers, and each server can expose tools, resources, and prompts in a consistent shape. It is plumbing, and it is useful plumbing.
Client
The connector inside the host that speaks the MCP protocol.
Server
The process that exposes tools, resources, and prompts.
Tools
The actions a server offers, from reading a file to making a change.
Why it carries risk
Connecting a tool is not the same as approving its effect.
MCP makes a tool call easy and uniform. Some tools only read. Others have side effects: they write a record, send a message, or change access. The protocol describes how the call is made, not whether the resulting change should happen. As a host connects more servers, the set of side effects a model can reach grows, and so does the surface a reviewer must account for.
Where execution authority fits
A verdict between the call and the effect.
Execution authority sits at the moment an MCP tool would run. It checks the proposed action against policy, denies the unknown by default, and records a receipt. An unregistered tool is quarantined instead of run.
Agent proposes
Model proposes a write through an unregistered MCP tool
HELM checks policy
Quarantines the unknown tool and checks the action against policy
Verdict
DENY
Proof
Quarantine receipt + integration EvidencePack
Questions
MCP, in plain terms.
What is the Model Context Protocol?
MCP is an open standard for connecting models to tools and data. A host application runs an MCP client that talks to MCP servers, and each server exposes tools, resources, and prompts the model can use. It standardizes how a model reaches outside its own context.
Why do MCP tool calls carry risk?
MCP makes it easy for a model to call a tool, and some tools have side effects: they can write a record, send a message, or change access. The protocol standardizes the connection, not the decision about whether a given side effect should run. That decision is left to the host.
Where does execution authority fit with MCP?
Execution authority sits between the MCP call and the side effect. It checks the proposed tool action against policy, denies anything unknown or unapproved by default, and records a signed receipt. The model can still propose tools; the boundary decides what executes.
Where can I read more about MCP and side-effect risk?
See MCP security for how a fail-closed boundary handles tool calls, and MCP quarantine for how unknown or unregistered tools are contained by default.
Keep reading
From the protocol to the boundary.
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.
Connect the tools. Then rule on what they run.
Bring one MCP tool action to the boundary and see the verdict and the receipt.