Skip to main content

​
High-level overview

The data plane is the process that enforces traffic to Gateway surfaces. A Gateway is the named access surface you configure (membership and grants). Two ingresses share one engine, credential store, and audit pipeline. Both require a Gateway prefix on the wire:
  • Tools gateway concept — MCP and related tool traffic at /gateways/<id>/mcp
  • LLM gateway concept — OpenAI- and Anthropic-shaped model traffic at /gateways/<id>/v1/...
A request through the data plane looks like this:
  1. An agent sends a request to /gateways/<id>/... with a Dome credential.
  2. The data plane resolves the Gateway, authenticates the agent, and checks admission.
  3. It evaluates Rules (and Quotas on metered calls) and applies request Guards.
  4. It calls the backend with Dome-injected credentials, applies response Guards, and writes an audit event.
The agent never receives the backend secrets. The data plane is fail-closed. Stale policy, missing rules, unknown Gateways, and evaluation errors deny the request rather than forwarding ungoverned traffic.

​
Why the data plane exists

Without a shared enforcement runtime, each agent integration would need its own way to authn, authz, inject credentials, filter content, and audit. The data plane centralizes that:
  • One hot path for tools and models, so Rules, Guards, Quotas, and audit mean the same thing on both protocols
  • Server-side credentials so agents authenticate to Dome, not to every upstream
  • Fail closed when policy or Gateway config cannot be trusted
  • Deploy the same engine as hosted, dedicated, or in-process SDK without changing rules

​
How a request moves

Each call walks the same stages on the hot path. Audit records the outcome at the end: Data plane pipeline: Agent → Ingress → Evaluate → Egress → Filter → Backend, with Audit below Protocol details for MCP live on the Tools gateway concept. Model ingress behavior lives on the LLM gateway concept. Connections and routing live on the Models concept and Pools concept. How Cedar decides a call is on the Rules concept and Authorization Model concept.

​
Credentials stay server-side

Backends declare an auth method (none, api-key, oauth) and a credential type:
  • Shared uses one credential for the connection. Every allowed caller reuses it.
  • Per-user gives each verified end user their own credential. First use can prompt provisioning (magic link / OAuth consent)
Dome stores runtime secrets and injects them on egress. Agents present Dome credentials only. Configure connections on Tools and Models.

​
Policy sync and fail-closed

The hosted data plane polls the control plane for Gateway membership, grants, Rules, and related config (about every 10 seconds by default). Each workspace has a freshness window. If policy has not synced inside that window, requests deny with staleness rather than using an untrusted cache. Widen the window when rule changes are rare and brief sync gaps are acceptable. Narrow it when policy changes must bite quickly.

​
Deployment shapes

The same engine runs wherever your infrastructure demands. Behavior matches. Only where the control plane and data plane run changes: All combinations run the same Cedar evaluation engine and produce the same audit events.

​
Next steps

With the data-plane hot-path model in mind, continue with:
  • Architecture concept for where the data plane sits on the request path
  • Gateways concept for the access surfaces the data plane serves
  • Tools gateway concept for MCP ingress
  • LLM gateway concept for model ingress
  • Rules concept for authorization after admission
  • Guards concept for content inspection on the path
  • Audit events concept for the evidence trail
  • Develop for denial and credential wire shapes