> ## 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.
# Identity patterns
> Choose standing or delegated identity per agent
export const identityPatterns = "Identity patterns decide whether an agent authorizes as itself (standing) or as a verified person it acts for (delegated). The choice determines which grants Cedar evaluates and how audit attributes each call.";
{identityPatterns}
## 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 diagram and table below compare how each model reaches a tool or model through the Gateway.
| | Standing identity | Delegated identity |
| ----------------------- | ------------------------- | ---------------------------------------------------------------- |
| **The agent** | Acts as itself | Acts for a human ([Delegated agents](/connect/agents/delegated)) |
| **Authorization reads** | The agent's own grants | The human's roles (`principal.act_as`) |
| **Credential** | Agent Bearer JWT | Agent Bearer JWT + `X-Dome-Act-As` |
| **Audit answers** | "What can this agent do?" | "What did this agent do, and for whom?" |
| **Choose when** | The agent does a job | The agent acts on someone's behalf |
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 an `X-Dome-Act-As` assertion naming the human, [verified](/connect/agents/delegated#require-verified-identity) 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:
```cedar title="information-barrier.cedar" theme={"system"}
// A person screened from a deal cannot open its records, whichever agent acts for them.
forbid(
principal is Dome::Agent,
action == Dome::Action::"mcp:call",
resource
) when {
principal has act_as &&
principal.act_as.roles.contains("barrier_screened") &&
resource.name like "*open_deal*"
};
```
The audit trail then names the human. That is often the reason the workflow could be automated at all.
If the agent does a job, give it standing identity. If it acts for someone, have it borrow theirs. A fat standing identity on an acting-for-someone agent cannot be reconstructed into who it was really for.
## 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](/connect/agents#register-agent), compiles those tools into a least-privilege [rule bundle](/govern/rules), admits it to a [Gateway](/concepts/gateways), 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 on `principal.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.
Because identity is delegated, the audit trail names the human. Audit answers "What did this agent do, and for whom?"
## Next steps
With standing vs delegated identity in mind, continue with:
* [Agent Identity](/concepts/agents/identity) concept for how agents authenticate and carry act-as context
* [Delegated agents](/connect/agents/delegated) to configure verification so agents can act for a verified person
* [Authorization Model](/concepts/architecture/authorization-model) concept for Cedar entities, permit and forbid semantics, and rule evaluation
* [Rules](/govern/rules) to author, simulate, and deploy Cedar rule bundles