Skip to main content

​
High-level overview

Registering an agent creates a durable identity in a workspace. That identity is separate from credentials and from access. An API key or short-lived token lets the runtime authenticate as the agent. Allowed resources, Gateway access grants, and Rules decide what requests Dome permits. You can rotate a key without changing permissions, or change permissions without issuing a new key. Registering an agent and calling through Dome looks like this:
  1. An operator registers data-pipeline, allows a Gateway and the tools behind it, and creates an API key.
  2. The runtime exchanges the key for a session token and calls through the Gateway.
  3. Dome authenticates the agent, checks the access grant and resource membership, evaluates Rules (and Guards and Quotas on the content path), and records the outcome against that agent identity.
  4. Suspending the agent later stops traffic for that identity without deleting the record.
One agent identity covers authentication, authorization, and audit. Credentials and access stay separate.

​
Identity is not permission

An agent credential identifies the caller. It does not contain the agent’s permissions and is not bound to a specific Gateway. The same agent credentials can use multiple Gateways when the agent has an access grant to each one. Three separate checks must allow a request: Allowed resources on the agent record are shorthand for creating Rules in the agent’s rule bundle. Changing them needs rules.deploy in addition to permission to edit the agent. When the shorthand cannot express a condition, author Rules directly. Refer to Rules concept and Agents.

​
Credentials

Agents authenticate with an API key or a short-lived agent token minted from a key. Keys are issued once and cannot be retrieved again. Rotate or revoke a key to cut off that credential. Session tokens carry the agent UUID, tenant and workspace context, capabilities, and the API key id that minted them. Details are on the Agent Identity concept.

​
Capabilities

Capabilities are permission strings declared on an agent and carried in its token, such as mcp:call or llm:invoke. They describe classes of action the agent may attempt. Cedar Rules then authorize each specific request. Dome derives many capabilities from allowed resources. You set a capability yourself when a Rule tests a string Dome would not derive.

​
Delegated identity

An agent can act for a person rather than only for itself (delegated identity). When it presents an act-as claim, Dome verifies the claim before authorizing the request, and the audit trail records the end user alongside the agent. Workspace and per-agent settings control whether a claim is required and which verified identities the agent may present. Refer to Delegated agents and Identity Patterns concept.

​
Lifecycle and hierarchy

Every agent has a lifecycle state: provisioned, active, suspended, or revoked. Provisioned and active agents can send traffic. Suspended and revoked agents are rejected. Revocation is permanent and always cascades to descendants. An agent can have a parent in the same tenant (max depth 10). Hierarchy grants no access on its own. Refer to Agent Lifecycle concept.

​
Next steps

With the agent identity model in mind, continue with:
  • Architecture concept for where agents sit among components and controls
  • Agent Identity concept for API keys, tokens, and act-as claims
  • Agent Lifecycle concept for states and transitions
  • Identity Patterns concept for standing vs delegated design
  • Gateways concept for reachability after identity
  • Rules concept for what an agent may do once it reaches a resource
  • Agents to register, issue keys, and manage agents