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.
Workflow
Two identities.One decision.
The agent proves who it is. It asserts who it is acting for. Dome verifies that assertion rather than trusting it, 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
If a call is authorized on the agent's identity alone, everyone who can invoke that agent inherits everything it is permitted to do. Passing a user's token through to the backend solves the credential problem. It does not mean the decision considered who the user was.
The agent's own credential, issued at registration.
The acts-as assertion checked by OIDC or HMAC, per agent.
Rules evaluate over the agent and the caller together.
The audit event names the agent and the person it acted for.
Asserted, then verified
An agent declares its caller on a header, but the declaration is not the identity. Dome verifies it with the method configured for that agent, and an assertion that fails verification never reaches a rule.
Rules can name the caller
Once verified, the caller is available to policy as sub, roles, groups and claims. A rule can require that a call is on behalf of a named person at all, or restrict it to a directory group.
Identity that survives the hop
The verified caller propagates to the upstream call and into the audit record, so a backend and an auditor both see the same answer to who this was really for.
Options
What Access lets you configure
Verification is set per workspace and per agent, so a trusted first-party service and a third-party integration do not have to be held to the same 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
For services that cannot forward a user token, a shared secret signs the assertion. Secrets are held in Vault; only references leave the control plane.
Replay and expiry
Assertions carry a lifetime and are checked for reuse, so a captured header cannot be replayed later 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 that does not carry a verified caller, making on-behalf-of the only permitted mode for a workspace or an agent.
Onward propagation
The verified caller can be forwarded to the upstream as a header, so a backend with its own per-user access control keeps enforcing it.
In practice
Rules that name the caller
Once the assertion is verified, the caller is just another thing a rule can reason about — which makes joiner-mover-leaver apply to agents without anyone building a separate process for it.
// No unattended calls in this workspace: every request must
// carry a caller that passed verification.
forbid (
principal,
action,
resource
) unless {
principal has act_as
};// 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")
};// 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"
};Architecture
Where Access sits
Access is one of the three control-plane concerns shared by every control point. Whether a call reaches a tool or a model, it is authenticated and attributed the same way.