AI agents are terrible at signup forms — and that is a feature, not a bug. Every password an agent types, every API key it copies into context, is a credential that can leak the moment the agent is prompt-injected or reads a malicious page. An auth broker for AI agents solves this by moving authentication out of the agent entirely: the human authorizes once, the broker issues a scoped credential, and the agent presents that credential instead of a secret it could lose.
The problem: agents can't (and shouldn't) do human auth
Today most SaaS assumes a human in the loop at exactly the wrong moment. The agent researches a tool, decides to use it, and then hits a wall: a signup form, an email confirmation, a CAPTCHA, an OAuth consent screen. The workarounds are all bad:
- Sharing the user's password gives the agent standing access to everything the user can do, forever, with no audit trail distinguishing agent from human.
- Pasting API keys into the agent's context puts a long-lived secret one prompt injection away from exfiltration.
- Browser automation through signup flows is brittle, violates most terms of service, and gives the vendor zero signal that an agent — acting for a real, accountable human — just created an account.
What an auth broker actually does
A broker introduces a third party that both sides already trust. The flow has three parts:
- The human verifies once. Email, phone, a wallet signature, or full KYC — whatever level of proof they are willing to establish. The broker signs a transcript of those proofs.
- The human pre-authorizes vendors. Instead of approving each signup as it happens, the user grants categories or specific vendors ahead of time, with scope, budget and expiry attached.
- The agent presents a credential, not a secret. When the agent wants to use a service, it hands over a signed, verifiable credential. The vendor checks the signature — offline, in under a millisecond — and grants access at a verified-human tier. No form, no OAuth dance, no password ever touches the agent's context.
Why verifiable credentials beat proxied secrets
Some credential brokers work by holding the user's API keys in a vault and injecting them into requests at a proxy layer. That contains the blast radius, but the vendor still sees a raw key and the broker becomes a high-value custodian. The verifiable-credential model goes further: the credential is the auth. It is signed (Notlogin uses Ed25519 over a canonical payload), scoped to a vendor, revocable by nonce, and verifiable against published keys at /.well-known — so the vendor needs no shared secret and no callback to the broker on the happy path.
This matters for the failure case. If an agent holding a bearer credential is compromised, the attacker gets one scoped, budget-capped, revocable capability — not the keys to the user's digital life. Security researchers call the underlying risk the confused deputy problem, and brokering is the standard answer to it.
What it looks like for a vendor
On the service side, accepting brokered agents is a few lines, not an identity-platform migration. With the notlogin-sdk a TypeScript backend verifies a credential and grants a verified-human tier in one call — declaring which proofs it requires (a newsletter tool might take email; a financial product might demand email + SMS + wallet + KYC). Read more in how AI agents sign up without a form, or register as a vendor to try it.
The bottom line
Agent traffic is becoming a first-class client of every API and SaaS product. An auth broker is how that traffic becomes accountable: humans stay in control of what they delegate, agents stop carrying secrets they can leak, and vendors finally get a cryptographic answer to "is there a real person behind this bot?". That is the gap Notlogin exists to close — pre-authorize once, and your agents sign in everywhere.