> ## Documentation Index
> Fetch the complete documentation index at: https://docs.domesystems.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Architecture
> How Dome Platform components govern agent access to tools and models
Dome governs how AI agents access tools and models. The following components decide what happens to each request.
For a high-level platform overview, start with [What is Dome?](/what-is-dome).
## High-level overview
Dome architecture separates into three kinds of concept: the **components** you define, the **controls** you apply to them, and the **audit** that records what happened.
The **control plane** is where you configure those components and controls and sync that configuration. The **[data plane](/concepts/architecture/dataplane)** is where requests are enforced on the hot path.
**Components** are what you define in the control plane:
* **Agents** identify the applications and automated processes making requests.
* **Resources** are the tools, model connections, and model pools exposed through Dome.
* **Gateways** group resources behind named endpoints and control which agents can reach them.
**Controls** are what you apply to components to govern traffic:
* **Rules** authorize what an agent may do after reaching a Gateway.
* **Guards** inspect request and response content before it reaches its destination.
* **Quotas** cap what an agent can spend on model calls over a window.
**[Audit events](/concepts/audit)** record every request's outcome across control-plane changes and data-plane decisions, so you can review or investigate it later.
Within a workspace, these concepts have the following relationships:
An agent reaches a Gateway through an access grant, then reaches the tools, model pools, and model connections behind it through membership. On every call that passes through the data plane, Rules, Guards, and Quotas govern the traffic, and Audit logs the outcome.
The access grant, membership, and rule are three separate checks, and all three must allow the request:
| Check | Asks |
| ---------------- | --------------------------------------------------- |
| **Access grant** | May this agent use the Gateway? |
| **Membership** | Is this resource in the Gateway? |
| **Rule** | May this agent perform this action on the resource? |
### Agents
An **agent** is an identity in Dome. It represents the application, assistant, or automated process making a request. Dome does not run the agent.
An agent authenticates each request with an API key or a short-lived agent token. The credential identifies the agent, but it does not contain the agent's permissions and is not bound to a specific Gateway. Each agent can have one or more API keys.
Because identity is independent from the endpoint, you can use the same agent credentials with multiple Gateways, as long as the agent has access to each Gateway. Refer to [Agents](/concepts/agents) concept for how identity works across Gateways.
### Resources
A **resource** is something an agent can call through Dome. Dome supports three resource types:
1. **Tools** are MCP servers, local processes over stdio, or catalog-backed tool integrations.
2. **Model connections** point to LLM providers such as Anthropic, OpenAI, Google, or a self-hosted runtime.
3. **Pools** group model connections and add routing, weighting, and failover.
Refer to [Resources](/concepts/resources) concept for how backends are modeled, and [Tools](/concepts/resources/tools) concept, [Models](/concepts/resources/models) concept, and [Pools](/concepts/resources/model-pools) concept for each type.
### Gateways
A **Gateway** is a named logical access surface in Dome. Each Gateway packages a selected set of resources behind an endpoint and defines which agents may use it. A Gateway is not a separately deployed data-plane process. A Gateway can contain many resources, and the same resource can belong to more than one Gateway. A registered resource that belongs to no Gateway is **Unreachable**.
A Gateway exposes both tools and models through different protocol endpoints:
* Tools use `/gateways//mcp`
* Models and model pools use `/gateways//v1/...`
For a model call, the request can target a direct model connection or a model pool. Configured routing can also select a matching or default pool. A direct model connection must be a member of the Gateway. When a pool is selected, Dome chooses one of its model connections.
Tools and models do not have to share a Gateway. You can use different Gateways for different jobs, as long as each Gateway grants that agent access and Rules permit each request.
An **access grant** gives an agent permission to use a Gateway. A Gateway can also grant access to every agent in its workspace.
### Rules
An access grant and membership get the request to the resource. A **rule** then controls what the agent may do once it's there, deciding tool calls and model calls the same way.
Cedar, the default rule engine, evaluates the agent, requested action, resource, and request context, and denies the request by default when no rule matches. Dome combines rules from organization, tenant, workspace, and agent scopes. Rules can permit access to one tool while forbidding another, even when both belong to the same Gateway.
Dome fails closed if it can't verify current policy, rather than falling back to a stale or default configuration.
### Guards
**Guards** inspect content in both directions. Request Guards inspect prompts or tool arguments before Dome calls the resource. Response Guards inspect model output or tool results before content returns to the agent.
Guards use ordered, connection-specific Filters. A Filter can redact, omit, or block matching content. Dome fails closed when an assigned Filter cannot be evaluated, rather than forwarding uninspected traffic. Refer to [Guards](/concepts/controls/guards) concept for the model and [Configure Guards](/govern/guards) for configuration.
### Quotas
**Quotas** cap spend on model calls. Each Quota sets a budget over a window at a chosen scope: workspace, agent, Gateway, pool, model, or verified end user.
Dome checks applicable Quotas before it authorizes the call. An exhausted total cap rejects the request. An exhausted per-model budget can spill to another member of the pool. Refer to [Quotas](/concepts/controls/quotas) concept for the model and [Set Usage Limits](/govern/quotas) for configuration.
## How requests move through Dome
Every request passes through Dome before it reaches a tool or model. Dome identifies the agent, enforces access and authorization, applies request Guards, calls the resource with protected backend credentials, and applies response Guards before returning content.
The agent runtime sends an API key or agent token to a Gateway endpoint.
Dome validates the credential, identifies the agent, and checks the active Gateway, access grant, and resource membership.
If the request carries an act-as claim for an end user, Dome verifies it before exposing it to Rules or backends.
For a metered call, Dome checks applicable spend Quotas. An exhausted limit stops the request here.
Dome evaluates the agent, action, resource, and request context. A denied request stops here.
Dome inspects configured prompts or tool arguments before they reach the resource. A Guard can transform or block the request.
For an allowed request, Dome retrieves the backend credentials and calls the tool or model provider. The agent never receives those credentials.
Dome inspects configured model output or tool results before disclosure, then returns the governed response.
Dome writes an audit event for the permitted, denied, failed, or filtered result.
Tool discovery follows the same core model. Tools blocked by Rules are omitted from the catalog. Other access or operational failures can return an empty catalog or deny the request.
If a model produces a tool call, the model does not invoke the tool itself. The agent runtime receives the tool request and makes a second call through the Gateway's MCP endpoint. The model call and tool call are separate requests governed with the same agent identity.
## Workspaces and isolation
An **organization** is a company's top-level account. It contains one or more **tenants**, hard isolation boundaries usually drawn around a business unit or product line, such as a `Commerce` tenant kept separate from a `Support` tenant. Each tenant holds **workspaces** that scope day-to-day work, such as separate production and staging workspaces for the same team.
Agents, resources, Gateways, Rules, Guards, Quotas, and audit events all live inside a workspace. Dome enforces tenant and workspace boundaries on every configuration and runtime request, so nothing scoped to one workspace leaks into another.
## Next steps
With the component and request-path model in mind, continue with:
* [Scopes](/concepts/platform/scopes) concept for organization, tenant, and workspace isolation
* [Agents](/concepts/agents) concept, [Resources](/concepts/resources) concept, and [Gateways](/concepts/gateways) concept for the components you define
* [Rules](/concepts/controls/rules) concept, [Guards](/concepts/controls/guards) concept, and [Quotas](/concepts/controls/quotas) concept for the controls on each request
* [Audit events](/concepts/audit) concept for the evidence trail
* [Data plane](/concepts/architecture/dataplane) concept for fail-closed runtime placement