Agent Operations Platform

Access

An agent almost never acts for itself. It acts for someone. Access authenticates the agent, verifies the person it is acting for, and carries both identities into every decision and every record that follows.

Read the docs

dome — access

Workflow

Two identities.One decision.

The agent proves who it is. It asserts who it is acting for. Dome verifies that assertion, and everything downstream sees both.

01
Authenticate
The agent presents the credential issued at registration. That credential is the root of trust for everything that follows.
02
Assert
The agent declares the end user it is acting for on the X-Dome-Act-As header, alongside its own credential.
03
Verify
Dome verifies the assertion with the method configured for that agent. An unverified assertion never becomes an identity.
04
Propagate
Both identities travel onward into the policy decision, the audit event, and the upstream call.

Consistent operations

Why the caller belongs in the decision

Authorize on the agent alone and everyone who can invoke it inherits everything it may do. Passing a user token to the backend solves the credential problem, not the decision.

Authenticate

The agent's own credential, issued at registration.

Verify

The acts-as assertion checked by OIDC or HMAC, per agent.

Decide

Rules evaluate over the agent and the caller together.

Record

The audit event names the agent and the person it acted for.

Asserted, then verified

An agent declares its caller on a header, and the declaration is not the identity. Dome verifies it with the method set for that agent, and a failed assertion never reaches a rule.

Rules can name the caller

Once verified, the caller reaches policy as sub, roles, groups and claims. A rule can demand a named person, or a directory group.

Identity that survives the hop

The verified caller travels to the upstream call and into the audit record. A backend and an auditor get the same answer to who this was for.

Options

What Access lets you configure

Verification is set per workspace and per agent. A trusted first-party service and a third-party integration need not share a mechanism.

OIDC verification

The agent forwards a token from your identity provider. Dome validates it against the issuer and lifts the claims into the request context.

HMAC assertion

Where a service cannot forward a user token, a shared secret signs the assertion. The secret stays in your secrets store; only references leave the control plane.

Replay and expiry

Assertions carry a lifetime and are checked for reuse. A captured header cannot be replayed against the same agent.

Required or optional

Whether an agent must present a caller is configured per agent. A batch job that legitimately runs unattended is a different case from a chat assistant.

Ban unattended calls

A rule can refuse any call without a verified caller, leaving on-behalf-of as the only permitted mode.

Onward propagation

Forward the verified caller to the upstream as a header. A backend with its own per-user access control keeps enforcing it.

In practice

Rules that name the caller

Once verified, the caller is one more thing a rule can name. Joiner-mover-leaver then applies to agents with no separate process to build.

Require a verified callercedar

// No unattended calls in this workspace: every request must
// carry a caller that passed verification.
forbid (
  principal,
  action,
  resource
) unless {
  principal has act_as
};

Scope by directory groupcedar

// The finance tools are reachable only when the agent is
// acting for someone in the finance group.
permit (
  principal,
  action == Dome::Action::"mcp:call",
  resource in Dome::MCPTool::"ledger"
) when {
  principal.act_as.groups.contains("finance")
};

Offboarding, enforced at the callcedar

// When the directory says someone has left, every agent acting
// on their behalf stops — the same day, with no separate process.
forbid (
  principal,
  action,
  resource
) when {
  principal.act_as.claims.status == "terminated"
};