Two identities
Dome supports two identity models:- Standing identity means the agent is the principal: it acts as itself and authorizes on its own grants.
- Delegated identity means the agent still authenticates as itself, but every governed call also carries a verified human, and authorization reads that human’s roles.
The choice is independent of how the agent attaches to a Gateway. Standing and delegated agents use the same Registry, Cedar, Gateway, and audit primitives.
Standing identity
Give an agent standing identity when it does a job. A revenue analyzer reading customer data needs the same permissions regardless of which analyst triggers it. The agent is itself, acts as itself, and its permissions are its own: a governed service account.Delegated identity
Give an agent delegated identity when it acts for a person. The agent still authenticates as itself, but every governed call carries anX-Dome-Act-As assertion naming the human, verified against the workspace’s OIDC providers. Authorization then evaluates against that human’s context.
This unlocks something standing identity cannot express: the same agent, calling the same tool on the same record, allowed for one person and denied for another. Authorization reads the human on the token, so your rules can encode conflicts of interest or need-to-know:
information-barrier.cedar
Common examples
These two shapes show how standing and delegated identity usually look when you run many agents on one platform.Self-service agent platform
A self-service agent platform is a common example of standing identity. Any team declares an agent (instructions plus a tool list), and your platform builds, governs, and runs it. Governance is automatic and invisible to the author. Standing identity fits because the agent does a job, not a person’s job. Permissions come from the declared tools, not from who triggered the run. Behind the manifest, your platform registers the agent, compiles those tools into a least-privilege rule bundle, admits it to a Gateway, and runs it. The author never writes a policy or holds a credential. Each agent is a service account whose permissions are exactly its declared tools. Audit answers “What can this agent do?”Purpose-built agent service
A purpose-built agent service is a common example of delegated identity. Engineers build one high-stakes workflow so domain rules are exact, and the agent acts for a specific person. Delegated identity fits because authorization must follow the human, not a shared service account. A generic least-privilege grant from a manifest cannot express conflicts of interest or need-to-know. Authored policy reads the human’s roles onprincipal.act_as instead:
- Finance: an adviser agent that may act for one client’s book but is walled off from a deal it is screened from.
- Healthcare: a case agent held to minimum-necessary access: the records of patients in its care team, decided by the clinician it acts for.
- Multi-tenant SaaS: a support agent scoped to one customer’s data boundary, where the tenant is a property of the human on the token, not a parameter the model can change.
Next steps
With standing vs delegated identity in mind, continue with:- Agent Identity concept for how agents authenticate and carry act-as context
- Delegated agents to configure verification so agents can act for a verified person
- Authorization Model concept for Cedar entities, permit and forbid semantics, and rule evaluation
- Rules to author, simulate, and deploy Cedar rule bundles