Delegated agents

Overview

Your application sends the identity on each request as X-Dome-Act-As. Dome verifies it, then Rules and audit can read principal.act_as. The agent still authenticates as itself. Act-As never replaces agent authentication. For a request to authorize as a person, three things have to be true:

Dome knows how to verify the person. You point Dome at an IdP (OIDC) or a shared HMAC secret, either as a workspace verification provider on this page or inline on the agent. You can also set a workspace floor that requires every agent to present verified Act-As and limits which methods are allowed.
The agent is configured to act for people. On the agent record you set the Act-As method, whether a person is required, which provider to use, and optional allow-lists. Do that when you register or update the agent.
Your application sends who the person is. Each request includes X-Dome-Act-As. Without it, Rules have no end user to evaluate. Refer to Pass identity for delegated agents.

Unverified headers never become Cedar claims. The agent credential still identifies the workload. Act-as never replaces agent authentication. A verified end user cannot expand access beyond a higher-scope forbid. The typical workflow is:

Create a verification provider: OIDC or HMAC, or inline OIDC/HMAC on the agent.
Configure Act-As on the agent when you register or update it.
Optionally require verified identity for every agent in the workspace.
Write claim-aware Rules that read principal.act_as. Claim names are on the Rules reference.

Verification methods

Each agent chooses how Dome verifies the Act-As envelope. Your application must send a matching X-Dome-Act-As value on MCP, OpenAI, and Anthropic requests.

Method	How Dome verifies	What your application sends in `X-Dome-Act-As`
`oidc`	Verify an end-user JWT through the provider’s OpenID Connect discovery metadata	Raw end-user JWT
`hmac`	Verify a signed identity header with a shared secret	Signed, timestamped act-as envelope
`none`	Act-As headers are not processed (standing identity only)	Canonical JSON encoded with standard base64 (development only)
`bound`	Server-bound enrollment identity with no client-supplied Act-As	No header. The platform supplies the enrolled user

Prefer OIDC or bound identity for production traffic. Agents can share a workspace verification provider or use inline OIDC/HMAC credentials on the agent record.

Identity claims

Verified identity is exposed to Cedar as principal.act_as:

Claim	Description
`sub`	Stable end-user subject identifier
`email`	End-user email
`roles`	End-user roles
`groups`	End-user groups
`claims`	Additional customer-defined claims

Attribute types for policy are also on the Rules reference.

Workspace floor

The workspace can require Act-As on every request and restrict which verification methods are allowed. That floor applies to every agent in the workspace. Agent settings can be stricter than the floor, but cannot weaken it.

Where verified identity is consumed

Verified identity can also:

Scope Quotas to an Act-As subject
Forward to upstream tools when a connection uses an Act-As egress header. Refer to Tools and Tools reference
Drive per-user credentials on the Tools reference and Models reference
Drive pool match_when conditions on principal.act_as.*. Refer to Pools reference

Requirements

Before you begin, authenticate to Dome and select a workspace.

Permissions

Workspace Act-As settings and shared verification providers use config.manage. Per-agent Act-As configuration uses agent register permissions. Refer to Agents.

Default roles	Permission	Grants
`admin`, `operator`	`config.manage`	Create, list, or delete verification providers and update workspace Act-As enforcement
`admin`, `operator`, `developer`	`agent.register`	Configure Act-As on an agent
`admin`, `operator`, `security`	`rules.deploy`	Required with `agent.register` when setting Act-As allow-lists

Create a verification provider

Create a workspace-scoped verification provider that delegated agents can share. Assign the returned provider ID when registering or updating an agent with --actas-provider / actas_provider_id. Agents can instead use inline --actas-oidc-url or --actas-hmac-secret without a shared provider. The method you pick here must match what your application puts in X-Dome-Act-As. Refer to Verification methods. How to send the header is on Pass identity for delegated agents.

Requires config.manage.

OIDC

Use OIDC when end users sign in through an IdP and your application sends their JWT as X-Dome-Act-As.

CLI
MCP
API
Agent

dome workspace verification-providers create \
  --name workforce-oidc \
  --method oidc \
  --oidc-discovery-url https://auth.example.com/.well-known/openid-configuration

Reference: dome workspace verification-providers create

Tool: dome_verification_providers_create

{
  "name": "workforce-oidc",
  "method": "oidc",
  "oidc_discovery_url": "https://auth.example.com/.well-known/openid-configuration"
}

Reference: dome_verification_providers_create

POST /dome.mgmt.v1.Management/CreateVerificationProvider
Content-Type: application/json

{
  "workspace_id": "<workspace-uuid>",
  "name": "workforce-oidc",
  "method": "oidc",
  "oidc_discovery_url": "https://auth.example.com/.well-known/openid-configuration"
}

Reference: CreateVerificationProvider

Create an OIDC verification provider

Create an OIDC verification provider named "workforce-oidc" using https://auth.example.com/.well-known/openid-configuration.

HMAC

Use HMAC when a trusted service constructs and signs the Act-As envelope with a shared secret.

CLI
MCP
API
Agent

dome workspace verification-providers create \
  --name internal-signer \
  --method hmac \
  --hmac-secret <shared-secret>

Reference: dome workspace verification-providers create

Tool: dome_verification_providers_create

{
  "name": "internal-signer",
  "method": "hmac",
  "hmac_secret": "<shared-secret>"
}

Reference: dome_verification_providers_create

POST /dome.mgmt.v1.Management/CreateVerificationProvider
Content-Type: application/json

{
  "workspace_id": "<workspace-uuid>",
  "name": "internal-signer",
  "method": "hmac",
  "hmac_secret": "<shared-secret>"
}

Reference: CreateVerificationProvider

Create an HMAC verification provider

Create an HMAC verification provider named "internal-signer" with my shared secret.

List verification providers

List the verification providers in the workspace.

Requires config.manage.

dome workspace verification-providers list

Reference: dome workspace verification-providers list

Tool: dome_verification_providers_list

{
  "name": "dome_verification_providers_list",
  "arguments": {}
}

Reference: dome_verification_providers_list

POST /dome.mgmt.v1.Management/ListVerificationProviders
Content-Type: application/json

{
  "workspace_id": "<workspace-uuid>"
}

Reference: ListVerificationProviders

Delete a verification provider

Delete a verification provider when no agent should use it.

Requires config.manage.

Deleting a provider breaks verification for agents that reference it. Move those agents to another provider or remove their provider assignment first.

dome workspace verification-providers delete <provider-id>

Reference: dome workspace verification-providers delete

Tool: dome_verification_providers_delete

{
  "provider_id": "<provider-id>"
}

Reference: dome_verification_providers_delete

POST /dome.mgmt.v1.Management/DeleteVerificationProvider
Content-Type: application/json

{
  "workspace_id": "<workspace-uuid>",
  "provider_id": "<provider-id>"
}

Reference: DeleteVerificationProvider

Require verified identity

Update the workspace Act-As floor so every agent must present a verified end-user identity (every agent in the workspace behaves as a delegated agent at the edge), and optionally restrict which methods are allowed. When the workspace requires verified Act-As:

Every request must include a valid identity envelope.
The verification method must be allowed by the workspace.
An agent configured with actas_method=none is rejected.
Invalid, expired, malformed, or unverifiable identity fails closed before authorization.

Agent settings can be stricter than the workspace floor, but cannot weaken it. An agent can require Act-As when the workspace does not, or narrow which verified identities it may present by group, email, or subject. Set per-agent options on Agents.

Requires config.manage.

CLI
MCP
API
Agent

dome workspace actas update --required

dome workspace actas update --allowed-methods oidc,hmac

Reference: dome workspace actas update

Tool: dome_workspace_actas_update

{
  "actas_required": true,
  "actas_allowed_methods": ["oidc", "hmac"]
}

Reference: dome_workspace_actas_update

POST /dome.mgmt.v1.Management/UpdateWorkspaceActAs
Content-Type: application/json

{
  "workspace_id": "<workspace-uuid>",
  "actas_required": true,
  "actas_allowed_methods": ["oidc", "hmac"]
}

Reference: UpdateWorkspaceActAs

Require verified identity

Require verified Act-As on every request in this workspace and allow only oidc and hmac.

Read the current floor with dome workspace actas get, dome_workspace_actas_get, or GetWorkspaceActAs.

Claim-aware Rules

Rules can require Act-As and test verified claims. When the workspace permits requests without Act-As, a Rule that reads claims should test principal has act_as first.

end-user-access.cedar

permit(
  principal,
  action == Dome::Action::"mcp:call",
  resource == Dome::MCPTool::"customer-records"
) when {
  principal has act_as &&
  principal.act_as.roles.contains("support")
};

forbid(
  principal,
  action == Dome::Action::"mcp:call",
  resource == Dome::MCPTool::"production-deploy"
) unless {
  principal has act_as &&
  principal.act_as.roles.contains("admin")
};

Refer to Authorize Access for the Rule lifecycle, Rules reference for claim names, and the authorization model concept for evaluation.

Next steps

Configure Act-As on an agent for method, required flag, provider, and allow-lists
Pass identity for delegated agents from your application
Identity Patterns concept for when to choose delegated vs standing identity
Agent Identity concept for tokens and act-as on the request path
Simulate Rules with representative Act-As claims before deploy

Get started

Core concepts

Connect

Govern

Operate

Manage

Develop

Reference

Delegated agents

Overview

Verification methods

Identity claims

Workspace floor

Where verified identity is consumed

Requirements

Permissions

Create a verification provider

OIDC

HMAC

List verification providers

Delete a verification provider

Require verified identity

Claim-aware Rules

Next steps

​Overview

​Verification methods

​Identity claims

​Workspace floor

​Where verified identity is consumed

​Requirements

​Permissions

​Create a verification provider

​OIDC

​HMAC

​List verification providers

​Delete a verification provider

​Require verified identity

​Claim-aware Rules

​Next steps

Overview

Verification methods

Identity claims

Workspace floor

Where verified identity is consumed

Requirements

Permissions

Create a verification provider

OIDC

HMAC

List verification providers

Delete a verification provider

Require verified identity

Claim-aware Rules

Next steps