Member key vs agent key vs browser sign-in: which to use
Four credentials, two kinds of principal. What each one reaches, where spend caps attach, and which credential an unattended agent should carry.
Use browser sign-in for the agent you drive from your own machine. Use a member API key (sk-cs-) when that same agent runs without a browser and should still act as you. Use an agent key (sk-csa-) for an unattended agent that needs an identity of its own and should reach only the organization's shared connections.
| Aspect | sk-cs- member key | sk-csa- agent key |
|---|---|---|
| Acts as | the member who created it | an agent principal with its own identity |
| Private connections | reachable | never |
| Shared connections | reachable | reachable |
| Monthly spend cap | optional, in credits | optional, in credits |
| Approval card goes to | the member | the agent's owner; the agent never approves itself |
| Session-gated manage tools | jwt_session_required | jwt_session_required |
| Best for | you, in CI or a client without a browser | an unattended job you operate |
What are the four credentials?
Every request to CoreSpeed resolves to one principal inside one organization. There are two kinds of principal, a member and an agent, and four credentials that carry them.
| Credential | Who is calling | Reaches | Spend cap |
|---|---|---|---|
| Browser sign-in (MCP OAuth token) | You, a member | Your private connections and the org's shared ones | The organization wallet only |
sk-cs- API key | The member who created it | The same as that member | Optional monthly cap on the key |
sk-csa- agent key | An agent principal with its own identity | The org's shared connections only | Optional monthly cap on the key |
| Session JWT | You, a member, through the cs CLI or the dashboard | The same as browser sign-in | The organization wallet only |
Two header forms carry them. Authorization: Bearer takes any of the four. x-api-key takes the two key types only.
Authorization: Bearer sk-csa-...
x-api-key: sk-cs-...The full reference is on the authentication page.
When is browser sign-in the right choice?
Browser sign-in is for interactive clients: Claude Code, Codex, Cursor, Copilot in VS Code, claude.ai, ChatGPT, and any client that speaks MCP Authorization. The first call answers 401 with protected-resource metadata, the client finds the authorization server at login.corespeed.io, registers itself, and runs OAuth 2.1 with PKCE in your browser. Nothing is pasted anywhere.
The result is a member session. Everything you may do, the agent may do. That includes the manage__* account tools and every private and shared connection in your active organization. A first sign-in from a client also creates your organization on its first tool call, so no dashboard visit is needed to start.
The token is audience-bound to /mcp and works only on POST /mcp. It is the right choice whenever a person is at the keyboard, because the person's own reach and accountability are exactly what the agent should have.
When should an agent act as you with a member key?
A member key is for the same agent in a place where a browser is not available: CI, a headless run, a client without OAuth. The key acts as you. It sees your private connections and the organization's shared ones, and role checks bind to you. Registering a remote MCP server with manage__remote_add needs an org admin, so a key created by a non-admin is refused there with admin_required.
Three things differ from the browser path. The session-gated tools (manage__keys_*, manage__agents_*, manage__accounts_*, manage__whoami, manage__switch_org) are listed for a key but answer 200 with isError: true and code jwt_session_required. A key can carry a monthly spend cap in credits, which the browser path has no equivalent for. And keys are per environment, so a key from one environment is rejected on another.
Read the key from an environment variable such as CORESPEED_API_KEY rather than writing it into a config file. Claude Code's claude mcp get prints headers, key included, so keep it out of transcripts.
When does an agent need its own identity?
An agent key belongs to an agent principal, the organization's third kind of principal alongside members and the platform. Any member can create one in Dashboard → Settings or with manage__agents_create and becomes its owner. Ownership is accountability, not permission. The agent inherits neither the owner's connections nor the owner's role.
Choose an agent key for an unattended agent you run elsewhere: a nightly job, a bot built with an SDK, a service that acts on behalf of the team rather than one person. Its reach is the organization's shared connections only, never a member's private ones. That is the point. A member's personal Gmail or Notion stays out of a job nobody is watching.
The identity shows up everywhere the member's would. Activity attributes each call to the agent. An approval card raised by the agent's call goes to the agent's owner, who is the one that can decide it; the agent itself can never approve its own action. And the lifecycle is explicit: suspend is reversible, every request answers 403 agent_suspended and the keys stay intact; retire is terminal, the record survives for attribution, and the keys answer 401 invalid_api_key.
How do you decide between them?
Ask three questions. Is a person at the keyboard? Use browser sign-in. Is it you, somewhere without a browser? Use a member key with a monthly cap. Is it a job or a bot acting for the team? Create an agent, mint an sk-csa- key, cap it, and connect the accounts it needs as shared.
The one case people get wrong is handing a personal member key to a long-running job. It works. It also carries every private connection the member has, and every action is attributed to that member rather than to the job. If the job matters enough to run unattended, it is worth an identity of its own. The security notes on the MCP server page say the same thing in one line: give unattended agents an agent key.
FAQ
Can an agent key reach a connection I connected as private? No. An agent principal reaches shared connections only. Reconnect the account as shared if the agent should act through it.
Does a member key expire?
It lives until it is revoked, rotated, or reaches an optional expiry you set. Manage keys in Dashboard → API keys, with the manage__keys_* tools from a signed-in session, or with cs keys.
What happens to a suspended agent's keys?
They stay intact and answer 403 agent_suspended until the owner or an org admin resumes the agent. Do not rotate them.
Which credential does the cs CLI use?
A session JWT from cs login. The CLI takes no API key; a CI job sends a key directly in the header.
Where do spend caps attach? To API keys, member or agent, as a monthly cap in credits. The browser sign-in path has only the organization wallet threshold, described on the billing page.