Agent Operations Platform
Authorization
Policy that enforces, not policy that asks. Rules are evaluated in the Gateway and the Broker, before any call leaves the perimeter. A buggy agent, a compromised process, or a developer who forgot a check cannot bypass it.
Workflow
Author a rule.Apply it everywhere.
The same loop for every rule. Write it, simulate against replayed traffic, ship it versioned.
- 01
Authorize
Write rules at org, tenant, workspace, or agent scope. Forbid wins across all four.
- 02
Evaluate
Every tool and model call evaluated against the rule set at egress. Fail-closed, sub-5ms.
- 03
Propagate
The registry record and the caller's claims carry through chained calls. Decisions reference the whole chain.
- 04
Filter
Sensitive fields in tool responses classified and redacted before they reach the agent.
Consistent operations
The decision contract
The language matters less than the contract. Forbid wins. Fail closed. Every decision is auditable to the rule version that produced it.
Central security baselines. Forbids that cannot be overridden downstream.
Business-unit specific rules — data residency, classification, regional constraints.
Team-level capability grants. The grain most rules sit at.
Per-agent constraints layered on top of broader grants.
Scope hierarchy
Rules cascade through four scopes, org to agent, and every scope is evaluated. Forbid wins across the chain, so central baselines hold while teams still author their own.
Cedar underneath
Rules are Cedar: an open, AWS-developed language with formal semantics. Versioned per scope, simulated against replayed traffic, applied through the CLI, the API, or Terraform.
Decision contract
Fail-closed by default, sub-5ms at the call boundary. Every decision is recorded with the rule version that produced it.
Options
What authorization lets you do
How rules ship, and what you can configure about the way they apply.
Simulation, two ways
Replay a candidate bundle against a window of recorded decisions and get a per-decision diff. Or evaluate one call — agent, action, resource, caller — with no side effects and nothing recorded.
Versioned, and traceable
Every rule set is versioned, and every decision names the scope, the rule, and the version behind it. Roll forward or back, and "why was this blocked" stays a lookup.
Bounded policy staleness
Set how long the data plane may serve cached policy before it fails closed, per workspace, from 30 seconds to a day. A gateway that loses the control plane stops allowing calls.
Policy on call arguments
Rules can name the arguments a call was made with, not just the tool or the model. "May update tickets" and "may update this ticket" are different rules.
Custom policy attributes
Tag connections with your own attributes and extend the request context per call. A rule reads them like anything else: classification, region, customer segment.
AI-assisted authoring
An assistant you enable per workspace drafts, refines and validates rules from a plain description, with the scope you are working in as context.
In practice
From rule to enforced call
One rule with request context enforces a non-trivial invariant: the agent may only update tickets whose requester matches the person it is acting for.
// The support-triage agent may only update tickets
// whose requester matches the end user the call is
// being made on behalf of.
permit (
principal == Dome::Agent::"support-triage",
action == Dome::Action::"mcp:call",
resource == Dome::MCPTool::"zendesk/update_ticket"
) when {
principal has act_as &&
resource.arguments.requester == principal.act_as.email
};# Check the file parses before deploying
dome rules validate tools/zendesk.cedar
# Evaluate the decision for a real caller
dome rules simulate \
--agent support-triage \
--action mcp:call \
--resource zendesk/update_ticket \
--eval-arguments '{"requester":"alex@example.com"}' \
--actas-email alex@example.com
Registry
Gateway
Broker
ManagementQuestions
Common questions about agent authorization
How does Dome authorize an agent's calls?
Policy is evaluated at the call boundary — in the Gateway and the Broker, inside the platform — before any tool or model call leaves the perimeter. Decisions are fail-closed and forbid-wins.
Can an agent bypass policy?
No. Enforcement sits in the call path rather than in the agent, so a buggy agent, a compromised process, or a developer who forgot a check cannot route around it.
Can a rule name the person the agent is acting for?
Yes. The decision is evaluated over both identities, the agent and the caller it acts for, so a rule can reference the caller's live directory claims: email, group membership, account status.
Can a rule change be tested before it ships?
Yes. A proposed rule set can be simulated against recorded decisions over a lookback window, returning a per-decision diff before the change reaches live traffic.