AUTONOMY
Tools for autonomous agents¶
An autonomous agent can call tools while it reasons, and every call is a governed operation: authorized by a grant you made, carried out with a one-time key, and answered with a signed receipt.
This page is for whoever runs agents that need more than files: a code graph, an internal service, anything behind an MCP server.
The property that makes this different from giving an AI a tool directly: the agent never holds a credential and never learns the tool's address. Your Enclave sits between the AI and the gate, forwards each call with that tool's own key, and writes down what happened, including what was refused.
A question worth asking rarely takes one lookup. The agent follows the trail, as many calls as it needs up to the run's cap, and the receipt chain shows every step of the trail afterward.
See which tool gates your organization can reach:
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 must carry the capability:
Then grant the tools, one resource each. A tool gate names each 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 ekkaGraph \
--resource queryGraph --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 an attempt to call it by name 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 then offers the AI exactly those tools. Each call the AI makes goes from the Enclave to the tool's gate, is checked against that call's key, runs, and comes back with 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 that is read once and deleted.
- How many calls: the run carries a call 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.
What does the receipt chain show?¶
For each run, the signed record carries the tools the agent actually called, in order, a digest of every gate receipt, and every refusal with its reason. Read it back:
The receipts verify on your machine, against keys EKKA anchored when the gate was registered:
Which tools exist today?¶
Any MCP server your organization fronts with an EKKA tool gate becomes a set
of grantable tools: each tool the server advertises is one resource on the
gate, and the gate publishes each tool's input shape so the agent calls it
correctly on the first try. Registering a gate is an operator step; once it is
registered, ekka gate list shows it and grants work as above.
Limits¶
- Tools reach autonomous steps through an EKKA tool gate. 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.