The MCP gateway

A trusted registry

MCP servers are governed like any other asset: approved, refused or unreviewed, each with an owner and an identity. An identity is an exact HTTPS address with its path, or an exact command line. A server’s name is not an identity, and a policy that approves a server by name alone is flagged when it compiles. An unreviewed server is blocked when the policy enforces and counted when it only observes or warns.

Approved servers are published read-only through the official MCP Registry API, so a client that reads a registry sees only what the organization approved. The registry lists servers; it does not enforce.

Pins and digests

An approved server can be pinned to an exact set of up to 256 tools, and adding a tool is another two-person change. ARC1 also keeps a digest of each pinned tool’s definition: its name, title, description, input and output schemas and annotations. A server that changes a tool’s description after approval, the move researchers call a rug pull, then fails the digest check.

Where the check runs matters. The managed gate on coding-agent machines sees tool names, not definitions, so it enforces the pin but cannot see a changed description. The inline MCP proxy can.

The inline MCP proxy LAB

The proxy fetches the server’s full tool list before every call and refuses the call if a pinned definition changed or disappeared. It admits an agent only with a signed policy lease of at most five minutes and an identity lease of at most sixty seconds, charges call budgets before dispatch, guards arguments for SQL queries, command lines and file paths, and signs a metadata-only receipt for every decision.

On one machine in our lab, on loopback with synthetic tools, it added 8.2 milliseconds at the 95th percentile across 30 paired calls, against a 15-millisecond target, and refused all five attack cases. An earlier design measured 59 milliseconds and was held back. Neither figure is from production.

Exact-action authority

Each agent has an authority record: the actions and outcomes it may take; the models, tools and MCP servers it may use; its spend and rate; the preconditions it must meet; and rules for its arguments. The agent asks before it acts, and the answer is allow, route to a person, or refuse, with a reason. Some outcomes, such as a denial in a utilization review, are never delegable and always go to a person.

Changes to authority take two people, and every step is a signed receipt. Narrowing takes effect at once; widening waits for the second approval. These checks bind agents that ask. An agent that does not ask is governed only where its traffic crosses an enforcement point.

Sub-agents and lineage LAB

When an agent starts a sub-agent, ARC1 issues the sub-agent a signed workload identity claim naming its agent, runtime and principal and carrying the full parent chain, up to seven links. A child can hold fewer tools and a shorter life than its parent, never more, and no claim lives longer than 24 hours. Revoking a root claim revokes the sub-agents beneath it. Claims verify offline, which also means an offline check cannot see a revocation until the claim expires.

OAuth 2.1 NEXT

Today an agent reaches ARC1’s own MCP endpoint with a static bearer key. Next, ARC1 acts as the authorization server and resource server that the MCP authorization specification describes: protected resource metadata, tokens bound to their audience, and no token passthrough. Each tool call will carry both the authenticated principal and the agent’s identity, and so will its receipt.

Where it stands

LIVE: in the released product and running on our hosted production deployment, with synthetic data. LAB: built or being built, and run only in our lab or against a vendor’s documented interface. NEXT: designed, not yet built. How we use these words.