Scrollport keeps its customer-facing authentication planes separate.

## Human plane

The web app uses the human session for wallet, connections and other account surfaces. Anonymous visitors are sent through the app's sign-in flow before protected pages render.

## Agent plane

The device flow issues an API key bound to an account and the fixed scopes `discover`, `inspect`, `run`, `wallet`, `apps` and `files`. Keys are hashed at rest. Signing in and authorising the pending device request are separate human actions.

```http
Authorization: Bearer sp_live_<secret>
```

`sys-admin` is not requestable through device authorisation. It is an operator scope, not a customer or agent grant.

## Connector OAuth plane

Remote MCP connectors use the Scrollport OAuth issuer at `https://scrollport.com`. Authorisation code with S256 PKCE gives one connector its own short-lived access tokens and a stable refresh credential. The fixed six scopes are the same as device setup, and `sys-admin` is never available. Only hashes reach the database; no token is rendered to a human.

OAuth and `sp_live_…` are separate credential forms over the same account and nine-tool contract. The dashboard lists each connector authorisation as one revocable OAuth connection.

## Provider plane

Provider connections are keyed by account. The run layer resolves the account to a connection and a provider proxy; raw provider tokens do not enter the agent's context.

## Safe handling

Treat a key as a secret with account-wide spending authority. Store it in a secret manager, rotate it by issue → verify → revoke, and never include it in a URL, screenshot or support message.

See [headless setup](https://scrollport.com/docs/setup/headless) for the device endpoints, [transports](https://scrollport.com/docs/reference/transports) for how the same contract travels over HTTP and MCP, and the published [Remote MCP guides](https://scrollport.com/docs/mcp) for client-specific setup.