Your agent doesn't need a login. It needs delegated authority.

The short answer

Don’t give an AI agent a login session or a god-mode API key. Give it delegated authority: a revocable agent identity, an explicit human → agent → app → action delegation, an action-bound authority claim the app verifies before executing, and an approval that is still current at execution time. The credential should prove who delegated what — not who once logged in.

Why doesn’t a login session work for an agent?

A session is a claim that a human is present. It expires when the human walks away, it’s refreshed by a human re-authenticating, and every permission check downstream assumes the session holder is the one making decisions. An agent fails all three assumptions: it runs when the human is asleep, it can’t pass an MFA challenge, and the entity holding the cookie is not the entity that should be accountable. Teams that “solve” this by minting a service account with a never-expiring session haven’t given the agent an identity — they’ve given it a disguise. Every action the agent takes is logged as a human who wasn’t there.

Why are API keys the wrong credential for agents?

The API key is the default today, and it fails on five independent axes:

1. Long-lived. Keys live for months or years. An agent task lives for seconds. The credential outlives every intention behind it.
2. Over-broad. One key typically grants every endpoint. The agent that drafts replies holds the same secret as the one that could issue refunds.
3. No per-action granularity. The key can’t say “summarize: yes, delete: no.” Authorization collapses to all-or-nothing at the perimeter.
4. No approval moment. There is no point in the flow where a risky action can pause for a human. The key was approved once, at creation, for everything, forever.
5. No proof of delegation at execution time. When the request arrives, the app knows a key matched. It does not know which agent sent it, which human delegated that agent, or whether anyone would still approve. And revocation is all-or-nothing: rotating the key breaks every workload that shared it.

None of this is the key’s fault. API keys were designed to identify programs you wrote calling APIs you chose. Agents choose their own calls.

Don’t OAuth scopes solve this?

Partially, which is what makes them tempting. OAuth is genuinely better than a raw key: tokens can expire, scopes narrow the surface, and there’s a consent moment. But the consent moment happens once, up front, between a human and an app — not per action, not per agent, and not at execution time. A repo:write scope can’t distinguish “fix the typo” from “force-push to main.” Client-credentials tokens identify your client, not the agent runtime inside it, and carry no record of which human delegated what. The scope model answers “what can this app touch,” when the question an agent action raises is “who authorized this action, and is that authorization still live right now?”

What does delegated authority actually require?

Four properties, each one checkable:

1. A revocable agent identity. The agent is registered as a first-class identity with its own token — revoke one agent and nothing else breaks.
2. An explicit delegation. A human (or workspace) delegates specific authority to a specific agent for a specific app. Not implied by deployment, not inherited from a service account — written down as a permission matrix.
3. Action-bound authority claims the app verifies. Per action, the request carries a claim — which agent, who delegated, which action, what was decided — that the app verifies against published keys (JWKS) before executing. Allowed actions proceed; risky ones are approval-gated; everything undeclared is blocked, fail-closed.
4. Approval current at execution time. For ask-gated actions, the approval has to be live when the action executes, not when the task was queued. Then signed execution and a hash-chained audit trail record what actually happened.

Concretely, the claim shape (illustrative — to show the fields, not the wire format):

// action-bound authority claim — what the app verifies before executing
{
  "agent": "agt_billing_bot",        // revocable agent identity, not a shared key
  "delegated_by": "usr_maria",       // the human on the hook
  "workspace": "ws_acme",
  "app": "app_billing",
  "action": "issue_refund",          // this action, not "the API"
  "decision": "ask",                 // allow / ask / block
  "approval": "apr_7f2…",            // present and current, or no execution
  "exp": 1781560020                  // outlives the action by seconds, not quarters
}

Compare that to sk-prod-9f3a…, which asserts exactly one fact: someone, at some point, had this string.

What exists today, and what’s on the roadmap?

Being precise, because auth is the wrong place for optimism. In Arc today: the agent registry and revocable agent tokens, human-to-agent delegations, the per-action allow / ask / block matrix, the approval workflow for ask actions, signed execution delivery, action-bound authority claims, JWKS and OIDC-like metadata, app-side verification helpers, and the audit trail with export and verification. That is the delegated-authority core, running.

Not yet: Google or Apple login, full enterprise SSO, OAuth/OIDC provider certification, and a mature passkey/MFA/recovery surface. If you need those for your humans, keep Clerk, Auth0, or Okta — Arc sits alongside them and handles the agent side. The full Arc Auth product, packaging this as scoped, revocable identity for agents, is the next item on the roadmap.

FAQ

What’s the alternative to API keys for AI agents? Delegated authority: register the agent as a revocable identity, write an explicit human → agent → app → action delegation, and have the app verify an action-bound authority claim before executing — with risky actions gated on a human approval that’s current at execution time. The API key answers “is this string valid”; the claim answers “who authorized this action.”

Should I use OAuth client credentials for my AI agent? Only for what they’re good at: identifying your service to another service. Client credentials don’t identify the agent runtime, don’t record which human delegated authority, can’t make per-action decisions, and have no approval moment. Use them under a delegation layer, not instead of one.

How do I revoke one agent’s access without breaking everything else? That’s the point of per-agent identity: revoke that agent’s token and its delegations end, while every other agent and integration keeps working. With a shared API key, revocation means rotating the key and redeploying everything that held it.

Is this the same as MCP authentication? No, and they compose. MCP standardizes how agents connect to tools — the wiring. Delegated authority governs whether a specific wired-up action may execute: who delegated it, allow/ask/block, approval, signature, audit. Arc ships an MCP adapter so existing MCP tool calls pass through the same authority checks without modifying the agent.

---

Arc Auth — scoped, revocable identity for agents — is next on the Arc roadmap. Join the newsletter for early access →