Rho puts a startup's financial stack on one platform: business accounts, corporate cards, bill pay, treasury, and an API underneath, with banking services provided through its partner banks. Its newest products assume AI does part of the work, like Close, which codes transactions automatically.
Finance work is exactly where agents are showing up first: an AP agent that processes bills, an expense agent that codes and flags transactions, a treasury agent that watches balances. And finance is exactly where "the agent used my login" is least acceptable. Money movement demands an audit trail where every action has the right name on it, and a shared human session gives every agent the CFO's name.
AgentID, the sign-in for AI agents from AgentMail, fixes the name. The agent signs in to Rho as itself, with a verified identity of its own, and Rho knows which human owns it. Nothing about what the agent may touch changes; that stays with Rho's roles, limits, and approvals.
In short
- Rho accepts Sign in with AgentID, so an AI agent can hold its own sign-in inside a business's Rho workspace instead of borrowing a human's.
- The agent's identity is a verified email address issued by AgentMail. It is a working inbox, so Rho can reach the agent with notifications and confirmations, and reach its owner when something needs a human.
- Rho receives a stable identifier for each agent and, through the owner scopes, the name and email of the human behind it.
- No password or reusable key crosses the sign-in. Each sign-in is a one-time signature, and authorization codes are single use.
- Rho keeps every product decision: roles, permissions, payment approvals, limits. AgentID only answers who is signing in.
Why would a finance platform want agent sign-ins?
Because the audit trail is the product. A platform that moves money is judged on being able to say, for every action, who did it, when, and under whose authority. Agents working under human logins break all three answers at once: the "who" is wrong, the session makes timing ambiguous, and the authority is whatever the human's role happened to allow.
Separate agent identities repair the trail. An AP agent that initiates a payment run does it as itself, under whatever access the business scopes it to, and the record shows the agent, its verified identity, and the human who owns it. Dual control becomes natural instead of awkward: the agent initiates, an approval routes to a human, and the owner claim tells Rho exactly which human stands behind the requester.
Revocation gets surgical too. An agent that misbehaves loses its own sign-in, not the controller's. Offboarding a human no longer silently strands or orphans the agents that were running under their credentials, because the agents were never inside those credentials to begin with.
How does an agent get its own Rho sign-in?
Sign in with AgentID is standard OpenID Connect, the same technology as Sign in with Google. For Rho, accepting it is configuration on their existing login, not new infrastructure.
On the agent side, its AgentID is its AgentMail inbox address. The agent reaches Rho's sign-in, picks AgentID, and approves the sign-in through the AgentMail API with an inbox-scoped key. The approval is remembered for 180 days per inbox and app, so repeat sign-ins continue on their own.
What Rho receives is an ES256-signed id_token, valid for ten minutes, with no refresh token. It carries a stable subject for the agent, its verified email address, and, because Rho is a registered app with the owner scopes, the owner's name and email. An agent that cannot share its owner's details cannot finish the sign-in alone; the organization owner approves it instead. Rho never gets a token that silently lacks the owner claim, which for a finance platform is the whole point.
The business's Rho account is unchanged. It belongs to the business, opened and verified through Rho's normal onboarding. The agent's identity attaches to that workspace with whatever access the business assigns it.
What does the agent's email address do for Rho?
It becomes the agent's registered email, and it works. Rho can send the agent a payment confirmation, a flagged-transaction notice, or a security alert, and the agent can read and act on all of it. Agents can even open and resolve support tickets. When something needs a person, the owner is one claim away.
The address is identity, not access. Signing in grants Rho no ability to read or send the agent's mail, and it grants the agent nothing inside Rho beyond what its assigned role allows.
Who controls what
| Stage | AgentID | Rho |
|---|---|---|
| Verified agent identity | Issues the verified email and stable subject | Not involved |
| Sign-in approval | The agent approves through its inbox-scoped key | Not involved |
| Owner attribution | Delivers owner name and email in the token | Decides how to use it |
| Roles and permissions | Not involved | Rho and the business |
| Payment approvals and limits | Not involved | Rho and the business |
| Compliance and enforcement | Supplies owner_sub for per-human policy | Decides and enforces |
What stays with Rho?
Everything that makes Rho Rho. Account onboarding, roles and approval chains, card controls, limits, the compliance posture that a finance platform lives by: none of it changes. AgentID answers one question at the door, who is this agent and which human is accountable for it, and hands the answer to Rho's existing controls. It is not a trust score and not an endorsement of any agent's behavior, and it grants no authority to move money.
Start at Rho, and use the AgentID sign-in guide to prepare your agent's inbox so it is ready the day the option goes live.
AgentID gives your agent a verified identity and its own email address. Free for apps to add.
Give your coding agent this prompt.
Add AgentID sign-in to this project. Read https://www.agentid.com/llms-full.txt for the integration reference, then run `npx @agentmail/agentid-cli init` from the project root and follow its prompts.