MCP servers
The servers your agents connect to
mcp: connect issue-tracker
Platform · Enforce
Controls that
hold while
agents work.
Monitor, warn or block, at the moment the agent acts. Not a review queue. Not a report you read on Monday.
An agent tried to
mcp: connect file-transfer.external
Blockedon the machine, before it ran
Nobody in your org has approved this server.
Where the decision happens
Evaluation runs where the agent is working, against a policy document that was delivered signed and self contained. The engine does not call home to make a decision, so a network problem never becomes a control problem.
What can be governed
Six things a control can act on.
All six, across Claude Code, Codex and Cursor.
MCP tools
Individual tools within a server
tool: issue-tracker/create
Skills
Skills loaded into a session
skill: bulk-export
Plugins
Plugins, and their specific builds
plugin: review-helper@2.4.1
External domains
Destinations your agents reach outside your walls
https: api.example-vendor.com
Commands
Commands executed in a session, matched after normalization
$ terraform destroy
Decision modes
Three postures, plus a default.
Every rule runs in one of three modes.
Monitor
Record it and carry on. This is where every control starts.
The developer sees› connected · noted by Backplanes
Warn
Surface it to the developer, and record it.
The developer sees! bulk-export · warned: Approved tools only
Block
Stop it. The action never runs.
The developer sees✕ blocked by Backplanes · never ran
Everything unlisted
Separately, you set what happens to anything a rule does not mention. That single setting is the difference between an allowlist and a watchlist.
Default, per kindMonitorWarnBlock
Determinism
Models propose. Code enforces.
Every decision is made by deterministic code. Same input, same answer, every time. Only the consequence changes.
- A model may draft a rule. It never makes the call.
- A control you can test, not one you have to trust.
The same callmcp: connect file-transfer.external
- MonitorRecorded. The connection opened, and nobody was interrupted.
- WarnThe developer was told which rule and why. The connection opened.
- BlockThe connection never opened.
Same rule, same input, same answer. Only the consequence changes, and all three write the same record.
Integrity
The policy is the policy.
Signed and content hashed. The bytes that reach an engine are the bytes you approved.
- A plugin is checked against catalog build digests, never trusted by name.
- What cannot be verified is labelled unverifiable. Never banned, never a pass.
- review-helpermatches the catalog build digestOfficial
- repo-toolsone copy on disk does not matchModified
- internal-scaffoldno catalog entry to compare againstUnverifiable
Unverifiable is allowed and flagged, under every mode including block. Cannot-verify is never treated as banned.
Honest failure states
What happens when we cannot be sure.
Every governed plugin gets one of four verdicts, and two of them are admissions.
Official
Matches an approved catalog build.
Modified
Content differs from every official release.
Not yet verified
Not in the catalog yet. Verification pending.
Unverifiable
We could not compare it, and we will not pretend otherwise. Never reported as a pass, and never as a violation.
Silence is not an all clear
When we cannot be sure, we say so.
- IfA machine stops reportingthenIts last verdict stands, and the report says so.
- IfThe catalog is downthenYour controls still arrive. Nothing waits on it.
- IfA build cannot be comparedthenIt is labelled unverifiable. Not banned, not a pass.
- IfAn MCP server has a namethenThat is an identifier, not an identity. We never present it as one.
Next
Test it the way you would test any other control.
Point it at your own agents, run it monitored, and look at what it would have stopped last week.