Platform
Connect AI to enterprise tools without losing control
MCP gives an agent reach. OpsAI decides what that reach may do — checking identity, policy and risk on every tool call, and recording the result.
Two different problems
- MCP solves reach
- A standard way for an assistant to discover and call a tool. It does this well.
- It does not solve control
- Nothing in the protocol decides whether a call should be allowed. That is not a gap in MCP — it is what a transport is.
What the protocol does and does not do
A tool description is written for a model to read. It is not a control.
MCP made it trivial to give an assistant real capabilities, and the thing deciding whether a capability should be used is a sentence of prose. That holds until an assistant is mistaken, persuaded, or acting on content somebody else wrote.
This is not a criticism of MCP. A transport’s job is to make a capability reachable, and it does that job. But reach and control are different problems, and the protocol only addresses the first — which means every MCP server that can change something is currently governed by whatever its own handler happens to check.
A tool that reads is an exposure. A tool that writes is an action in exactly the sense the rest of this platform means: it changes something in a system of record and somebody has to answer for it. Arriving over MCP rather than from an agent framework changes nothing about that.
The check has to live where the assistant cannot argue with it.
A rule inside the prompt is in the context window, which is the one place an instruction can be talked out of. A bound is evaluated at the boundary, is not in the context window, and there is no prompt to argue with.
Where the boundary sits
Five stops, and only one of them is new.
Stops one, two, four and five already happen. OpsAI adds the third — and the point is that it is the same third stop every other action passes through, not an MCP-specific mechanism bolted alongside.
A server describes its toolsprose
Names, arguments, and a sentence of prose per tool. The description is written for a model to read and is the only thing constraining when a tool is used.
An assistant chooses oneinference
From the description, the conversation, and whatever content it has been asked to work with. That last input is the one nobody controls.
OpsAI evaluates the callno model call
Identity, authority, policy and risk — the same path any other action takes. A tool call that writes is an action, so it does not get a separate policy engine.
The tool runs, or never receives the calldecided
An authorized call arrives with a grant scoped to it. A refused call does not arrive at all, and the assistant gets a reason it can relay.
Recorded either waysealed
Including the refusals. A tool call an assistant attempted and was stopped from making is the most useful line in any later review.
- Identity, not assertion
- An MCP session has to carry who it acts for. An anonymous tool call cannot be governed at all — there is no authority chain to resolve and nobody to hold accountable afterwards.
- Arguments, not names
- A bound reads the arguments. Governing a tool by its name is close to useless; governing it with a subject and an amount is a control.
- The same three outcomes
- Authorized, held for a person, or refused with the failing check named. No new vocabulary, because a tool call is not a new kind of thing.
Actions in the estate
10
any could arrive over MCP
That change something
9
governed as actions
Systems reachable
11
of 12 in the register
Separate policy engines for MCP
0
the same bounds apply
IllustrativeIllustrative figures for the OpsAI sample estate. The policies that would apply.
What a refused tool call looks like
A reason the assistant can relay, not an error it will retry.
This is the detail that decides whether governing MCP works in practice. An assistant that receives an exception assumes something broke and tries again; one that receives a sentence explains it to the person and stops.
- Refusals are results
- Returned as tool output rather than raised as a failure. The distinction is worth more than it sounds: it is the difference between a retry loop and a person being told.
- The reason names the check
- refund.ceiling refused this, the amount exceeded its ceiling, a person needs to approve it. All three are relayable.
- Why assistants retry more than code does
- Code retries on a schedule somebody wrote. An assistant retries because retrying is a reasonable thing to try — which is why an idempotency key keyed on the session and subject matters more here than anywhere else.
And the record exists either way
A refused tool call produces an evidence entry as complete as an authorized one. For MCP that is more valuable than usual, because the interesting question after an incident is what the assistant was persuaded to attempt — and that is exactly the half a success log discards.
The canonical action, reached over MCP, would produce the same record it produces today: ACT-7512, judged against refund.ceiling at v7, decided in 11ms.
Where to start
Find the handlers on your MCP servers that write, and govern those.
Most servers have one or two that change something and a long tail that only reads. The short list is where all the exposure is, and governing it is a morning's work rather than a project.