Skip to main content
Every Gateway has a complete /gateways/<id> URL plus protocol-specific MCP, OpenAI, and Anthropic endpoints.

​
High-level overview

A Gateway is a workspace entity that packages membership and grants behind one URL for both protocols. The same Gateway URL serves tool traffic at /gateways/<id>/mcp and model traffic at /gateways/<id>/v1/.... The Tools gateway and LLM gateway are ingresses on the data plane that require that Gateway prefix — they are protocol paths, not kinds of Gateway. Each Gateway carries two relationships:
  • Membership lists which tools, tool sources, pools, and model connections belong to this Gateway
  • Access grant lists which agents may call this Gateway
A resource in no Gateway is valid but Unreachable. An agent without a grant is rejected at the edge before Rules run. Membership and grants package reachability. Rules, Guards, and Quotas still decide what happens after admission. Standing up and calling through a Gateway looks like this:
  1. An operator creates a Gateway (or uses the Default gateway), adds the tools and models that surface should expose, and grants an agent access.
  2. The agent points its client at /gateways/<id>.
  3. Tool calls and model calls use the same Gateway id with different path suffixes.
  4. Dome admits the agent, checks membership, evaluates Rules, then serves the call through the Tools or LLM ingress.
A Gateway is the unit of curated reachability for both tools and models.

​
Why Gateways exist

Without Gateways, every callable resource in the workspace competes for the same front door, or operators encode reachability only in Cedar. Gateways give you a named bundle you can grant as one unit:
  • Attach related tools and models once, then grant the Gateway to each agent that should see that bundle
  • Keep credentials and Rules separate. Rotating a key does not change membership. Rewriting Rules does not redefine which endpoint an agent calls.
  • Fail closed without a Gateway prefix: every caller must choose a Gateway (/gateways/<id>/...)

​
When to use one Gateway vs many

One Gateway is enough when a workspace has a single shared set of tools and models and every active agent should reach that set. New workspaces start with a Default gateway that is empty until you attach members and grants. Free and Pro plans allow one Gateway per workspace. That Default gateway is usually the one you keep. Create another Gateway when you need a second curated front in the same workspace, for example:
  • A coding agent may reach repo and CI tools. A support agent may reach ticket and CRM tools. Same workspace, different memberships and grants.
  • Production models stay on one Gateway. Eval or shadow pools stay on another so agents cannot mix them by accident.
  • Human-operated MCP clients and automated agents should see different tool catalogs
The same resource can belong to more than one Gateway. An agent can hold grants to more than one Gateway and pick the URL that matches the job. Prefer another Gateway over duplicating connections when the split is “who may reach which set,” not “which upstream credential to store.”

​
How a call is authorized

Every /gateways/<id>/... request must pass three checks. The final decision is addressable AND admitted AND Cedar-allowed.
  1. Addressable: The path names an active Gateway in the caller’s workspace.
  2. Admitted: The agent has a grant to that Gateway (discovery such as tools/list and GET /v1/models is exempt and stays membership- and Cedar-filtered).
  3. Cedar: Workspace Rules permit the action on the resource. Forbid wins. Admission never overrides a deny.
So: Gateway decides whether this agent may use this front door and whether this resource is on it. Rules decide whether this action is allowed.

​
Default gateway

Every workspace gets one auto-provisioned Default gateway. It is real, editable, and deletable.
  • New workspaces start with an empty Default gateway and no grants. Attach members and grants explicitly.
  • Migrated workspaces may already have resources attached, but agents still need explicit per-agent or all-agents grants.

​
Next steps

With that Gateway reachability model in mind, continue with:
  • Gateways to create Gateways, manage membership and grants, and build client URLs
  • Architecture concept for where Gateways sit among components
  • Data plane concept for the runtime that serves Gateway URLs
  • Tools gateway concept for the MCP ingress under a Gateway
  • LLM gateway concept for the model ingress under a Gateway
  • Agents concept for identity before reachability
  • Rules concept for what an agent may do after admission