Use case
Onboard agents
Using Dome's Agent Registry
Onboarding an agent is four resources. An Agent record carrying the credential, the Callers it may act for, the Rules that bound what it reaches, and the Audits that record what it did. Register once and every call after that has a name on it.
Composed from
Four resources, one record
Agents, Callers, Rules and Audits. The registry is the name for those four working together, and the agents your teams build and the agents your customers point at you both run on them.
The record and the credential. Name, owner, declared capabilities, and a lifecycle that runs provisioned, active, suspended, revoked.
The person the agent is acting for. Asserted per request and verified by OIDC or HMAC before it counts as an identity.
What this agent may reach. Written once, evaluated on every call, versioned in a repo.
What happened. Agent, caller, rule, result, in one vocabulary across every call.
Nothing here belongs only to the Agent Registry. One policy language, one audit vocabulary, one access layer, across every composition. See the whole resource set.
Scenario
The agents your teams already shipped
A product manager wired an agent into Salesforce and the warehouse on Tuesday. By Thursday two other teams had forked it. Nothing in your logs tells any of them apart from the apps they run inside.
What makes it hard
Registration has to beat not registering
A review queue loses to a cron job every time. The governed path has to be the fast one.
Discovery arrives with the incident
The first record of an ungoverned agent is usually a post-mortem, reconstructed from logs that were never designed to name agents.
Blocking relocates the work
Restrict one tool and the next attempt routes around you. The agent still ships.
Exceptions compound
Per-team fixes get more fragile with every agent added. The count grows faster than the fixes.
The work, in resources
Agents. Register from the SDK, the CLI, or a CI job. The credential issued here is the root of trust for every call that follows.
Callers. Point Dome at your identity provider. The person behind the agent travels with the request instead of stopping at the front door.
Rules. Attach the tools and models this agent needs. Anything unattached is unreachable, and it does not appear in discovery either.
Audits. Every call lands with the agent, the caller, the rule and the result. Nothing left to reconstruct.
Scenario
The agents your customers point at your product
An integration partner ships an agent that drives your support API. Traffic triples on Wednesday, the call pattern changes, and a customer opens a ticket. You need to name whose agent, which version, acting for which end user.
What makes it hard
An API key names a company
It does not name the agent, the version, or the person the agent is working for.
Isolation is the product
One scoping mistake is a cross-customer data incident. Nobody files that as a bug report.
Support asks for the record
Answering what a partner's agent did at 14:20 needs a per-tenant trail. API access logs do not produce one.
Attribution comes before billing
You cannot charge for, or contain, what you cannot attribute to a tenant.
The work, in resources
Agents. Each customer agent registers under its own tenant and gets its own credential. Suspend one without touching the others.
Callers. The partner asserts their end user per request. Your backend learns whose request it really is, not just which agent forwarded it.
Rules. Write once at tenant scope. Per-customer exceptions go in as overrides rather than forks.
Audits. One trail per tenant, filterable and exportable. Hand it to support, or stream it to the customer.
What changes
When registration is the fast path
The same agents still get built and the same teams still ship them. What changes is the route they take to production, and who sees them on the way.
Before
After
Discovery after the fact
Ungoverned agents surface through outages, compliance reviews, or incidents. Each one becomes a reconstruction project from logs that were never designed to track agents.
Discovery as a consequence
Every agent surfaces the moment it tries to call. Registered, identified, attributable. The platform team sees what is running without asking around.
Audit assembled retroactively
Compliance evidence is rebuilt from access logs, interview notes, and best guesses. The bill comes due before every audit window, and it grows with the agent count.
Audit as a byproduct
Every governed action lands in the trail with who, what, under which rule, and with what result. Evidence is produced by running, not before audits.
Composes with
The enterprise systems you already have
Registration is the seam to the rest of your stack. Dome reuses the systems your team already operates rather than asking them to operate another.
IdP
Callers verify against your existing identity provider. End-user identity propagates from the front door through every tool call.
Learn moreSIEM
Audit events stream to the security data lake. Decisions are queryable in the system your SOC already lives in.
Learn moreSource control
Registration and policy live in a repo. Versioned, testable, rolled back through the same lifecycle as the code your agents call.
Learn moreAPM
Agent health, denial rate, and behavior anomalies surface in the same dashboards as your application metrics.
Learn moreSOAR
Denials and anomalies can trigger playbooks. The audit trail provides the evidence chain those playbooks need.
Learn moreMCP
Dome's own MCP server lets an assistant register agents and apply policy on a person's behalf.
Learn moreNext steps