Use case
Onboard agents
Two cohorts to onboard: the agents your teams build, and the agents your customers and partners run against you. Same registration primitive underneath, very different operational pain. One tenant, one registry record per agent, one place to look.
Agentic patterns
Onboarding looks different on each side of the wire
The verb is the same in both cases: register, issue credentials, declare capabilities, attribute every call. The cohort changes who is onboarding, what triggers it, and which operational pain it solves first.
AI In
Your internal estate
The agents your teams build outside platform: velocity engineers in product, ops, sales, and analytics. Embedded SaaS agents pulled in by business units. Desktop assistants reaching for enterprise data.
Scenario
A PM ships a workflow agent on Tuesday that queries Salesforce and the data warehouse. By Wednesday it's running in production with no audit trail. By Thursday two more teams have forked it.
Outcomes that matter
- Discovery: every agent surfaces the moment it tries to call
- Attribution: which team, which workspace, which policy
- Velocity preserved: registration is self-service, not a ticket
AI Out
Your customer and partner estate
The agents your customers wrap around your APIs. Integration partners building agentic products on your platform. Workflow tools wiring your endpoints into thousands of customer-built agents.
Scenario
An integration partner ships an agent that drives your support API. Traffic spikes, behavior shifts mid-week, a customer complains. You need to name whose agent, what version, acting for which end user.
Outcomes that matter
- Per-customer attribution, rate limits, and quotas
- Identity propagation back to the partner's end user
- Audit trail you can share with customer support
Why onboarding stalls
Restriction destroys value. Discovery is too late.
On the internal side, velocity engineers ship faster than platform can review. On the partner side, customer agents arrive before you have a contract with them. Both sides are doing their job. Neither has a governed path to resolve the tension.
The ungoverned path is the only path
There is no self-service way to register an agent, request tool access, and get credentials with policy and audit built in. So agents are built without it.
Retroactive governance reconstructs from fragments
Access logs that were never designed to track agents. Interview notes. Best guesses about which data flowed where. You cannot audit what was never recorded.
Restriction pushes innovation underground
Block one tool and usage moves to another. Restrict one pathway and the next team builds invisibly. The barrier to deployment is now a cron job.
Every week is discovery debt
Ungoverned agents do not pause while the platform team catches up. They multiply, connect to more tools, process more data. The reconstruction problem compounds.
Entry points
Every agent can be registered, however it was built
The same four surfaces serve both cohorts. Internal teams reach for the SDK and CLI. Partner agents typically arrive through the API. The control plane underneath is the same: one authentication scheme, one audit shape, one place to look.
| Surface | Best for | How it registers |
|---|---|---|
| SDK | Owned agents in your own code | Wraps the agent's API key into a short-lived JWT, syncs a local policy bundle, emits audit from the call site. |
| CLI | CI/CD pipelines and platform automation | `dome agents register` from a workflow. Declarative configuration through the Terraform provider. |
| API | Custom platforms and bespoke automation | REST and gRPC across the full control plane. Embed Dome operations in your existing tooling. |
| MCP | Desktop agents (Claude, Copilot, Cursor) | Dome's MCP server lets an assistant register agents and apply policy on a human's behalf. |
Registration in practice
What a registered agent actually carries
Registration is not a directory entry. It is the operational primitive on which everything else depends: authentication, authorization, audit, attribution, and lifecycle.
Credentials issued
Each agent receives a principal scoped to a workspace and tier. The principal is what Cedar policies evaluate against and the subject every audit event references.
Capabilities declared
Tools attach explicitly. Models attach explicitly. Both are governed by policy attached at registration, not at the call site. Nothing implicit, nothing unaudited.
Caller chained
When the agent acts on behalf of an end user, the user's identity propagates with the agent's. Backends know whose request this really is, not just which agent forwarded it.
Lifecycle governed
Agents can be suspended, activated, scoped down, or rotated through one surface. The same lifecycle on the agent that you already have on infrastructure.
Before and after
What changes when onboarding is the path of least resistance
The same agents still get built. The same teams still ship them. What changes is the route they take to production, and whether security, finance, and the platform team see them on the way.
Before
After
Discovery after the fact
Ungoverned agents surface through outage post-mortems, 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's running without asking around.
Restrict or guess
Without a governed path, the only response to an unknown agent is to block it. Restriction destroys the value that motivated the build and pushes the next attempt underground.
Enable, with attribution
Self-service registration gives velocity engineers a path that's faster than the ungoverned one. Platform and security gain visibility without saying no.
Audit assembled retroactively
Compliance evidence is reconstructed from access logs, interview notes, and best guesses. The bill comes due before every audit window and the cost compounds with the agent count.
Audit as a natural byproduct
Every governed action lands in the audit trail with full context: who, what, under which rule, with what result. Compliance evidence is produced as a consequence of running, not before audits.
Composes with
The enterprise systems you already have
Registration is the seam to the rest of the platform stack. Dome reuses the systems your team already operates rather than asking them to operate another.
IdP
Agent registry records backed by 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 moreSecrets
Tool credentials never travel with the agent. They are injected at the gateway from the secrets store you already manage.
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 moreSource control
Policy and tool configuration live in a repo. Versioned, testable, rolled back through the same lifecycle as the code your agents call.
Learn more