Tools & MCP
Tools are how an agent acts, reads a file, runs a command, calls an external system, hands work to another agent. On this platform every one of those actions is governed by the same grant machinery as every other capability, and exposed over the Model Context Protocol (MCP) so the surface is standard and interoperable.
This page covers the governed shell surface, tool orchestration, the catalogs, the MCP server, how tool access is gated, and the device's own tool surface at the edge.
The governed shell surface
The primitives most agent platforms hand out ungoverned are first-class, permission-gated, journaled, and egress-brokered tools here:
| Tool | What it does |
|---|---|
shell_exec | Run a command inside the leased sandbox |
file_read / file_write | Read and write inside the confined workspace |
web_fetch | Reach a network resource through the egress broker |
| An in-fabric dispatcher | Call another governed platform tool |
This is a governed tool surface, not an interactive terminal. There is no agent REPL to attach to. Each call is bound to one leased sandbox, passes a four-layer permission check, and is journaled before it executes, so a denied call returns the gate's verdict as a result rather than vanishing.
The surface is per leased sub-agent and carries that agent's cryptographic allowed-tools ceiling, so two agents in the same run can hold genuinely different powers. The ceiling is minted as the intersection of what was requested and what the parent holds (see Concepts).
The four layers a call passes
| Layer | What it is |
|---|---|
| Credential scope | The grant's allowed tools. Cryptographic, and no mode can widen it |
| Deployment policy | The organization's ceiling |
| Permission mode | Plan, ask, accept-edits or auto. Governs prompting only |
| Posture | Untrusted content or tainted data drops the network-class tools |
Only the third layer is what a "bypass" setting relaxes. The credential scope and the organization ceiling are not adjustable from inside a run.
Reading classified data closes the network
The posture layer is the one worth understanding, because it closes a specific attack. A file read or a tool result at or above the egress classification threshold taints the worker, and the taint informs the egress broker.
That shuts the read-then-exfiltrate path: an agent cannot read something sensitive and then reach the network, because reading it changed what it is allowed to do next.
Fail-closed, never degraded
Where the host cannot provide the sandbox, the surface refuses to start. It never falls back to an unsandboxed shell. A host missing the isolation loses the capability rather than quietly losing the boundary.
The security shell
Offensive and assessment work runs on a hardened variant of the same surface: a signed toolpack whose entries carry a hash, a signature, a licence and a risk tier, verified deny-by-default; a scoped egress allowlist; and required rules of engagement.
Out-of-scope targets are denied outright, and offensive verbs require an N-of-M quorum token even when in scope. It is exposed as a single governed verb rather than as a general shell.
Tool orchestration
Beyond individual tools, the runtime composes them:
- a tool orchestrator with adapters, holding the distinction between what an agent is permitted to call and what is currently advertised to it;
- a streaming pipeline connecting tools to live data;
- hook dispatch and hook events for reacting to a tool's lifecycle; and
- an agent-to-agent delegation tool for handing work to a peer, through the governed path rather than a direct call. See agents as a service.
The Tool Catalog and the Connector Catalog
External capability enters through two governed catalogs:
- The Tool Catalog is the live registry of tools and skills an agent can reach; registrations feed it directly.
- The Connector Catalog is the catalog of external connectors, the MCP connector lifecycle with health, leases, promotion eligibility, templates, publication, an egress allowlist, and a control guard.
A distinctive move is tool-to-skill projection: an external tool can be promoted into a first-class skill, so it inherits the platform's versioning and governance rather than remaining a raw connector call. Governed BI dispatch lets an agent operate, bind, publish, embed, and probe the capabilities of tools such as Power BI, Tableau, Looker, Sigma, Superset, and Grafana.
The Model Context Protocol server
The platform exposes its tools over an MCP server, the standard surface a reasoning agent, an external assistant, or another System9 agent calls through:
- 252 measured agent tools across roughly 55 modules;
- OAuth and token authentication;
- resource exposure and schema validation on every call; and
- a path-segment validator that rejects traversal.
Because the tool surface is MCP, work crosses vendor boundaries cleanly. A
coding run is itself exposed as agent tools
(coding.submit, coding.status, coding.cancel), so an external agent can hand
software-engineering work to the platform through the same front door.
How tool access is gated
Tool access is an authorization decision, not a prompt instruction. Capability gating scores the grantee's trust, the sensitivity of what the tool touches, and the tool's blast radius, and a consequential call passes the gate at the action boundary, with an audit record. See Security → Governance for the deny-closed model this rests on.
The consequential-action gate scores each call, not each tool name, the same tool scores differently according to what a given invocation would actually do (listing a directory and deleting a tree are not the same action). A call that genuinely cannot be scored is recorded unjudged, neither passed nor refused on the platform's authority, leaving the deployment to decide whether unjudged is tolerable for that tool. Do not read this as "every tool call is gated"; read it as "scored per call, and explicit about what it cannot score."
The tool surface at the edge
The Edge Agent wields the same kind of governed tool surface on the device, and can also serve one:
- The device is an addressable tool server and an addressable peer. It publishes its own governed tool surface over the open agent-tool protocol, so any tool host (a developer's editor, a coding agent, another device) can discover and call it, and it serves inbound agent-to-agent tasks. It publishes its signed agent card and the public half of its card-signing key at the protocol's well-known paths, so a peer has something to discover and to pin.
- Closed until an operator opens it. Both serving surfaces are compiled into every shipped artifact but each binds to loopback by default, refuses a non-loopback bind without an explicit credential, and admits no caller until the operator names the peers or token it trusts. Every inbound message must carry a per-message signature from a trusted key, and every call still runs through that tool's own ceiling, posture, and permission gate. This is a protocol adapter, not a way around governance.
- Governed egress and AI relay. Edge devices query models through the platform with classification, compartment, and data-grant enforcement on every query, and context attachments are filtered through grants before reaching the model.
It is validated in-crate and round-tripped against the platform's real verifier cross-repository; end-to-end validation against a live backend is pending.
The families
For the full family list grouped by domain, the family.verb naming contract, and
why a running cell either has the whole tool surface or does not boot, see
the agent tool families.
See also
- Skills, packaged capabilities, and tool-to-skill projection.
- The coding agent, the coding tool family and its run-as-a-tool surface.
- Agent Runtime, the sandbox tools run inside.
- Security → Governance, capability gating and the deny-closed model.