Every team shipping agents hits the same question: how does the agent prove it is allowed to do what it is doing? Four answers dominate in practice. They differ less in convenience than in what happens on the worst day — when the agent is compromised, the vendor is breached, or the user wants out.
1. Raw API keys in the agent's environment
The default, because it is easy: put the key in an env var and let the agent use it. It fails on three axes. Blast radius: keys are usually account-wide and long-lived, so a single prompt injection can exfiltrate standing access. Auditability: the vendor cannot distinguish the agent from the human, or one agent from another. Lifecycle: rotation is manual, and revoking means breaking every consumer of the key at once. Acceptable for a personal script; indefensible for a fleet of agents acting on a user's behalf.
2. OAuth with the agent as client
OAuth is the mature standard for delegated access, and where a provider offers it, agents should use it: scoped tokens, refresh semantics, per-client audit. The friction is structural, though. Every vendor integration needs a registered client, a consent screen a human must click through, and token plumbing per provider. For an agent that discovers a new tool at runtime — the whole promise of agentic software — a human-in-the-loop consent redirect at first contact defeats the purpose. OAuth solves delegation to known services, not signup with new ones.
3. Vaulted secrets behind a proxy
Credential-injection brokers keep the user's real keys in a vault and attach them to requests at a proxy or egress layer, so the agent never sees them. This genuinely shrinks the blast radius — a compromised agent can misuse a capability for seconds, not steal it forever. The trade-offs: all traffic must route through the proxy, the broker becomes a custodian of everyone's raw secrets, and the vendor still sees an ordinary key with no signal that an agent is behind it. It also does nothing for the signup problem — the account and key must already exist.
4. Broker-issued verifiable credentials
The newest model, and the one Notlogin implements: no shared secret exists at all. The user proves their identity to the broker once, pre-authorizes vendors with scope, budget and expiry, and the agent carries a signed credential. Verification is a public-key check the vendor runs offline in under a millisecond — no API key to store on either side, because the signature is the auth. Compromise is bounded (scoped, budget-capped, instantly revocable by nonce), audit is built in (every redemption names the credential), and — uniquely — it solves first-contact signup: the vendor can create the account from the credential itself, at a verified-human tier. Details in how agents sign up without a form.
Comparison at a glance
- Blast radius on compromise: API key — account-wide and standing; OAuth — token-scoped; vaulted proxy — action-scoped but custodial; verifiable credential — scoped, budgeted, revocable, non-custodial.
- Works for first-contact signup: only the verifiable credential (with an auth.md contract as the discovery layer).
- Vendor integration cost: API keys — zero but liability-heavy; OAuth — an identity project; proxy — network plumbing; credentials — a five-line SDK verify call.
- Human accountability signal: only broker credentials carry proof levels (email, SMS, wallet, KYC) the vendor can require per its own risk bar.
Choosing in practice
These are not mutually exclusive. Use OAuth where a provider already offers it well. Keep truly static infrastructure keys in a vault. But for the growing class of interactions where an agent meets a service for the first time and needs an accountable account — the case the other three models simply do not cover — a broker-issued verifiable credential is the only pattern designed for the job. Issue one in a minute and see.