Route every agent through typed MCP gateways
Route external reads and writes through a typed MCP gateway instead of direct API calls. Governance, audit and identity live in the boundary.
The quickest way to give an agent a capability is to hand it an API. Give the model a tool that calls your database, your ticketing system, your finance backend, and let it decide when to call. It works in a demo. It is a liability in production.
The problem is that “the agent calls the API directly” collapses three concerns into one: what the agent is allowed to do, what it actually did, and how the call is shaped. When all three live inside the agent’s tool code, each is only as reliable as the model’s judgement on the day. You cannot audit an intention. You cannot rate-limit a prompt. You cannot prove that a model with write access will never write.
Governance lives in the boundary, not the prompt
Across our portfolio we route external input and output through a typed MCP (Model Context Protocol) gateway. Every read, every write, every call to a system of record goes through one governed layer built with FastMCP. The agent does not talk to your database — it asks the gateway, and the gateway decides.
You cannot audit an intention or rate-limit a prompt. A boundary that owns the I/O can do both, because the guarantee is a property of the gateway, not the model.
The same idea shows up three ways across the portfolio:
| System | Boundary | The guarantee |
|---|---|---|
| Orions | 15 read-only tools, two-layer allowlist | Refuses to boot unless read-only is on — no write path to grant |
| TAFI | FastMCP write-bus + contract verifier | Cross-checks each agent’s claimed calls against what the gateway saw |
| PMS MCP | ~130 typed tools, act-as-user | Agent operates as the specific person, every call scoped and audited |
Identity: acting as the right person
Our PMS MCP server exposes a project-management system and its finance module to agents as roughly 130 typed, governed tools. It supports a controlled act-as-user model: the agent operates under the permissions of the person it is representing, not a blanket service account with the keys to everything. This is the difference between “an AI has admin access to finance” and “an agent did what this specific user is allowed to do, and here is the log.” Only one of those passes a security review.
Typed contracts make agents predictable
When a tool has a typed contract, the agent calls it predictably. Parameters are declared, shapes are validated, and a malformed call is rejected at the boundary instead of reaching your backend as a surprise. The same server can speak more than one transport — stdio for a local runtime, streamable HTTP for a remote client — without the agent code changing. The contract is the stable thing; the transport can vary.
See the read-only boundary in practice in the Orions case file, or tell us what you are integrating at cal.com/agentix-tech.
