Introducing AgentOnboard: Sign in with Google for agents
Your agent needs to do one thing on a service you already use. Create a note. Read a ticket. Update a record.
The current standard answer is: connect its MCP server. Green dot. Fifty tools appear. You ask for the note. And the agent you pay the most for gets it wrong. Wrong tool. Invented parameter. A task that worked when it knew 10 things fails when it knows 50.
It is not the model. It is the bill you pay before the task starts.
GitHub's official MCP server costs around 42,000 tokens just to describe itself. Add Slack, Notion, Linear, and Postgres and you've spent 60,000+ tokens on schemas before your system prompt, before history, before the actual request. On a 128K to 200K window, a third to half your memory is tool definitions you will not use this turn. One benchmark: correct tool choice at 95% with a focused set, 71% with the full server loaded. Same model. More noise.
So clients cap you. Cursor allows 40 tools in total, then the rest silently do not exist. Copilot caps at 128. The fix is unchecking boxes in mcp.json every conversation, or adding a proxy to manage the proxies. You wanted autonomous access to everything. You got settings to babysit.
And when there is no MCP server, people fall back to the old way: paste the API key into env or prompt. Shell history, a .env file, the context window, someone else's log. Prompt injection did not invent that leak, it priced it — over 90% success in evals, one breach spreading across 700+ orgs last year.
Companies live the mirror image. To give you that green dot they run a new server in front of the API they already had. The 2026 data is brutal: 91.8% of public MCP servers with no auth, 30+ CVEs in 60 days, only 8.5% on OAuth. Even done well, every tool description is an instruction the model trusts, every tool result is text that can carry new instructions. The server has to sanitize, scope, rate-limit, and log all of it. Ship MCP or look behind. Both cost.
The assumption underneath both pains is the same: that letting an agent use an API means describing everything upfront, always on.
It doesn't. Browsers solved this twenty years ago. You don't pre-connect every site. You arrive, you prove who you are, you leave. Identity at the moment of use.
Sign in with Google, for agents
That is AgentOnboard. Not a proxy. Not a broker that sees your traffic. Not another server to host. One job: prove who this is to the service, then get out of the way.
You sign up once. One API key — aon_live_..., shown once — lives only on the machine where your agent runs. The agent never sees it.
Your agent needs notes.com. It reads https://notes.com/auth.md. Not 42,000 tokens. A few hundred: the audience to mint for, the endpoints that matter, what a rejection means. The auth.md convention is WorkOS's invention from May 2026 for agent registration — we use a minimal profile of it, because identity needs less.
Then: aon token get notes.com
Five minutes. One domain. Signed RS256. The service verifies locally off a cached public key — under a millisecond, zero network calls — checks audience by exact match, checks expiry, maps the verified email to its own user. Known? Serve. Stranger? 403 ACCOUNT_REQUIRED. Connect your account, then retry. No loop fixes a stranger.
No schemas in context. No 40-tool cap. No definitions to poison. The agent calls the plain HTTPS API with a token that dies in five minutes and never worked anywhere else. notes.com.evil.com is not notes.com, and math enforces it when humans are tired.
What it isn't
No per-service consent. You trusted the machine once. The service must reject strangers in its own data — a verified inbox is not your customer.
No traffic graphs. Tokens we issued are not requests they served. We will not sell the gap.
No directory, no badge. Two docs pages are the contract: connect your agent, verify agent requests.
If you run an agent — connect once. Delete three servers you babysit. If you run an API — publish one file. Verify one token. Reject strangers. The docs have the contract. This post was the why.