Dome Systems

Auth0 and Dome

Your app signs users in. Dome checks every call made for them.

An agent sends the user's Auth0 access token with each call. Dome verifies it against your tenant, and rules decide on the user's email and the claims your Action adds. Audit records the agent and the user, every time.

Users in Auth0AgentsDomeTools & modelsCallersUsers in Auth0Agentssupport-agentAgentsdev-assistantAgentsbilling-agentGatewaysprod-gatewayGitHubMCP serverBillingInternal MCP serverclaude-opus-5-5Model poolRulesGuardsAuditsaudit-trail
dev-assistant→github/create_pull_request· as a.okafor@example.comAllowed

How Dome helps

Dome provides verified identity and access control with Auth0

Verified on every call

Dome checks the token's signature against your tenant's keys, its issuer and its expiry. Tokens signed with HS256 are refused.

Rules read the user

The user's subject and email reach every rule. Claims your Action adds reach rules too.

Custom claims, as strings

A namespaced claim with a string value is readable by name. Arrays under a namespace are not.

Get started

Auth0 in three steps

Register your Auth0 tenant with Dome, add the claims rules need in an Action, and have the agent pass the token on. Dome needs no Auth0 credentials of its own.

  1. 01

    Register your tenant as a verification provider

    The issuer is your tenant domain with a trailing slash. Pin the audience to your API's identifier.

    $ dome verification-providers create \
    --name app-auth0 \
    --method oidc \
    --oidc-url https://<tenant>.auth0.com/ \
    --oidc-expected-audience <api-identifier>
  2. 02

    Add claims in a post-login Action

    Auth0 reserves groups and roles, so Dome can't read Auth0 roles from the token. Call api.accessToken.setCustomClaim for email, and for a namespaced string such as https://example.com/team.

  3. 03

    Read a namespaced claim in a rule

    String claims arrive under principal.act_as.claims. Test that the claim is there before you compare it.

    principal has act_as &&
    principal.act_as has claims &&
    principal.act_as.claims has "https://example.com/team" &&
    principal.act_as.claims["https://example.com/team"] == "platform"

Commands and rules tested against a Dome workspace on October 1, 2026. For anything about Auth0 itself, see Okta's documentation.

Rules

A rule on the user's email

Only users with an example.com address may have the agent open pull requests. Everyone else can still use it to read.

forbid (principal, action == Dome::Action::"mcp:call", resource is Dome::MCPTool)
when {
resource.connection_name == "github" &&
resource.tool_name == "create_pull_request"
}
unless {
principal has act_as &&
principal.act_as has email &&
principal.act_as.email like "*@example.com"
};

Try it

One call, two outcomes

Switch the caller or the argument and watch the same call decide differently. Every decision lands in audit.

Acting for

agent dev-assistant · acting as a.okafor@example.com
github/create_pull_request(owner: "acme", repo: "web", head: "fix-login")
  1. CallerToken verified against app-auth0
  2. Emaila.okafor@example.com
  3. RulePull requests are open to example.com
DecisionAllowed

Agent workflow

Bringing it together

Connecting Auth0 to registered agents, tools, and models in Dome completes a governed agent application.

Dome

Acting for

Identity

Auth0

This page

Control point

Gateway

  • Rules
  • Guards
  • Quotas

Every call decided and audited

FAQ

Common questions

Can Dome rules use Auth0 roles?

Not as a list. Auth0 reserves the roles and groups claims, and Dome reads only string values from namespaced claims.

Do Auth0 custom claims need a namespace?

Only for reserved names such as groups and roles. Dome reads a namespaced claim by its full name when its value is a string.

Does Dome accept HS256 tokens from Auth0?

No. Dome refuses HMAC-signed tokens, and RS256 is Auth0's default.

Does Dome sync users from Auth0?

No. Dome reads identity from each verified token as the call arrives.

Next steps

Talk with our FDE team

Our forward deployed engineers work with your platform team to get your agents into production and under control: the first one governed on your own systems, and a pattern your teams can repeat for every agent after it.