An agent can create its own Locus Pro account through the service's agent-native registration flow and prove its identity with AgentID. Once registration finishes, it can read the account and search the tool catalog. Paid execution needs a funded balance.
Our September 16 integration check completed that sequence. The new account was active, had a zero balance, and returned available capabilities from the catalog. No payment or paid tool execution was attempted.
In short
- Registration starts in Locus's API, not in a dashboard login.
- Locus returns an identity-verification step with an AgentID authorization URL.
- The agent completes that sign-in, then replays registration to finish account creation.
- The account could then be read and the catalog searched, with a zero balance.
- Identity, account management credentials, and funding are three separate stages.
How does an AI agent prove its identity to a service?
By completing a verification step the service itself controls, and returning something the service can check. Locus Pro is a clear example because it makes that step explicit in its API contract rather than hiding it inside a login page.
The agent-native onboarding guide describes a registration process designed for agents. The agent reads the onboarding contract and submits its account registration. Locus then returns an identity-verification step with an AgentID authorization URL.
The test agent completed that sign-in and reached a page confirming its identity was verified. Repeating the registration request as documented finished account creation.
AgentID is AgentMail's sign-in service for agents. It verifies an inbox-based identity through OpenID Connect, so a participating service can recognize the agent establishing an account. AgentMail supplies the inbox for email associated with that identity. In this flow, Locus requested the agent's name and email. It did not request the human owner's information.
An authenticated account read returned the same account ID. A catalog search returned discoverable capabilities. Together, those checks establish that the account could be created and used for the tested management operations.
Why does this matter for Locus?
Locus Pro handles the part of agent infrastructure where mistakes cost money: one prepaid balance that pays for tools across hundreds of APIs. A spending account is the last place credentials should be borrowed. If the agent spends through its owner's login, Locus cannot tell whose transactions are whose, and the human's payment relationship is sitting inside an autonomous process.
Locus built its registration agent-native from the start, and verified identity is what completes it. Three things follow.
The account holder is the agent, verifiably. Registration finishes only after the AgentID step, so every account traces to a verified agent identity rather than to whichever key happened to create it.
Discovery is safe before money moves. A freshly registered agent can read its account and search the tool catalog on a zero balance. It can find out whether Locus offers what its task needs, then ask its owner for funding, instead of needing money in place just to look.
Human approval has a natural place. Identity, the account credential, and funding are separate stages, so a developer can let the agent handle the first two alone and keep a person at the third, exactly where the money is.
Who controls what
| Stage | AgentID | Locus Pro |
|---|---|---|
| Identity verification during registration | Verifies the inbox-based identity through OpenID Connect | Requires the step, issues the authorization URL, checks the result |
| Account creation | Not involved | Owns the registration contract and creates the account |
| Account management credential | Not involved | Issues it and sets its permissions |
| Tool catalog and discovery | Not involved | Defines and serves it |
| Balance and funding | Not involved | Controls both |
| Paid tool execution | Not involved | Authorizes and meters it |
| Interactive MCP access | Not involved | Has its own separate OAuth setup |
Which account path should you follow?
Locus documents separate dashboard and agent-owned account journeys. The tested path here is agent-native registration. If you are building this into an agent, begin with that guide instead of assuming that a dashboard login completes the same setup.
The account's management credential is another part of the workflow. AgentID verifies the identity during registration; Locus supplies the credential and permissions for subsequent account operations. Interactive MCP access has a separate OAuth setup.
The next step after discovery is to review funding and execution requirements. Sign-in does not fund the balance or approve a purchase.
Start with Locus account setup and follow the agent-native path. The AgentID sign-in docs explain how to prepare the inbox identity that completes verification.