GOVERNED MCP
Governed MCP tools¶
An autonomous agent can call MCP tools while it reasons, and every call is a governed operation: authorized by a grant, refused when it is not, capped, and answered with a signed receipt.
This page is for whoever runs agents that need real tools: a database, an internal service, a public MCP server, anything an agent should reach through the Model Context Protocol.
The difference from handing an agent a tool directly: the agent never holds the credential and never learns the tool's address. Your Enclave sits between the model and the gate, forwards each call with that one tool's key, and writes down what happened, including what it refused.
Everyone connects agents to MCP servers now. The two questions an enterprise then asks are who authorized this, and what did the agent actually do. EKKA settles the first in the grant, before the run, and answers the second with a signed receipt on every call, enforced where the call happens rather than by asking a server for permission.
See which tool gates your organization can reach:
Why does this need a gate?¶
Connecting an agent straight to an MCP server hands the model the server's address and its credential, and trusts it to behave. There is no record of which call it made, and nothing stops it from making one you did not intend.
EKKA fronts the MCP server with a tool gate. The agent talks to your Enclave, the Enclave talks to the gate, the gate talks to the server. Each tool the server offers becomes a resource you grant by name. A call to a tool you did not grant is refused and recorded, and every call that runs comes back with a receipt the gate signed.
How does an agent get a tool?¶
The same way it gets anything: a grant. There is no field in a plan that adds a tool, deliberately, because a plan asking for its own powers would be the caller authorizing itself. The operator grants; the plan only asks for the autonomous level.
First the agent's declaration carries the capability:
Then grant the tools, one resource each. A tool gate names every tool it serves as a resource, so a grant is exactly one tool on exactly one gate:
ekka gate grant add --agent my-agent --type mcp --instance my-gate \
--resource searchDocs --capability tool.mcp.invoke
Repeat for each tool the agent should hold. A tool you do not grant does not exist as far as that agent's runs are concerned: it is not offered to the model, and naming it is refused and recorded.
What happens during the run?¶
When a plan step runs at the autonomous level, EKKA signs the granted tools into that step's one-time key, each tool with its own key for the gate. Your Enclave offers the model exactly those tools. Each call goes from the Enclave to the tool's gate, is checked against that call's key, runs, and returns a receipt signed by the gate.
Three boundaries hold at once:
- Which tools: only the granted ones are offered, and only their keys exist on the machine, in a file read once and deleted.
- How many calls: the run carries a cap. The call after the cap is refused, the refusal is recorded, and the agent is told to answer with what it has.
- What is written down: every attempt has exactly one record, a gate-signed receipt or a refusal with its reason. A call with no record fails the whole step rather than passing unaccounted.
Is EKKA in the loop on every call?¶
No. The grant is authorized once, when the plan is dispatched, and signed into the run as a one-time key per tool. From then on your Enclave and the gate enforce that authorization between themselves: the gate verifies the key against one it pinned when the gate was registered, and signs the receipt itself. The EKKA control plane is not contacted on a tool call, and it is not on the path the data takes.
This is deliberate, and it is why the proof is worth anything. The receipts verify on your own machine, offline. If checking that an agent stayed inside its grant required a call back to us, the proof would only be as trustworthy as that call. It does not, so it is not.
What does the receipt chain show?¶
For each run, the signed record names the tools the agent actually called, in order, a digest of every gate receipt, and every refusal with its reason:
The receipts verify on your own machine, against keys EKKA anchored when the gate was registered:
Which MCP server, and which gate¶
Any MCP server becomes a set of grantable tools once a gate fronts it: each tool the server advertises is one resource, and the gate publishes each tool's input shape so the agent calls it correctly the first time.
The gate you register decides who may reach the server behind it, and that choice is the one to get right:
- A gate for your own service or a public MCP server can be shared across your organization. The data behind it is yours to expose to your own agents.
- A gate over anything private is scoped to the organization that owns it, so no other tenant can grant a tool on it. EKKA never puts a resource behind a shared gate that the resource's owner did not choose to share.
Registering a gate is an operator step. Once it is registered, ekka gate list
shows it and grants work as above.
Limits¶
- A tool reaches an autonomous step through an EKKA tool gate over the Model Context Protocol. An MCP server on the agent's own machine is not grantable this way today.
- A run's tool calls are metered as part of the step's governed operation.