Auth & consent

Two surfaces splits your world into the control plane and your own Stack. Each half authenticates you separately, and connecting a Provider is a third, separate thing again — three different credentials, each doing one job.

Your control-plane sign-in

Signing up (via an invite) or signing back in happens through GitHub OAuth, and what you actually hold afterward is an opaque, revocable, server-side session — not a copy of your GitHub session, and not an API key. There is no tenant-facing API key anywhere in this system: a session is the only bearer credential a human ever holds against the control plane. Revoking a session takes effect on its very next use, because there is nothing else about it left to invalidate.

Your Stack's own session

The moment the one-time-code handoff (see the Quickstart) redeems your code, your Stack mints its own local session — structurally separate from your control-plane session. Only your Stack's own outbound call can ever redeem that code, so nothing shared crosses the boundary between the two surfaces; from that point on, being signed in to your Stack and being signed in to the control plane are two independent facts.

Connecting a Provider: Credentials and consent

A Credential is a Runtime's own auth artifact — what lets your Stack actually run Claude or Codex on your behalf. There are two shapes, and they are treated deliberately differently:

• A vendor API key. The blessed, unattended default for a hosted tenant — billed and issued by the vendor for exactly this kind of use. Providing one needs no extra step beyond handing it to your Stack.
• Your own personal subscription credential (an OAuth token or an uploaded auth file). This spends your existing subscription, not a vendor-blessed unattended mode, so your Stack requires an explicit, recorded consent before it will ever use one — checked and stored server-side, not just a checkbox that could be skipped by a different caller.

Either way, a Credential is validated by actually exercising the Runtime with it — never assumed valid just because it was provided — and its health is re-affirmed (or falsified) by ordinary use, not by a separate live check-in.

GitHub is a different credential again

Watching a Project also needs a GitHub credential, but it is your Stack's own operational access to read issues and open PRs — not a Runtime Credential, and not gated by the consent step above. It authorizes what your Stack can do to your repositories, which is a different question from which subscription a Run bills against.

Why consent is explicit and recorded

Credentials are the keys to a paid subscription relationship. Nothing about using one of your own is silent: your Stack only ever spends your personal subscription credential after you've said yes, and that "yes" is itself a recorded fact your Stack can point back to — not an assumption inferred from a credential merely being present.

Related

• Two surfaces — why there are two sessions to begin with.
• Quickstart — connecting a Provider with an API key end to end.
• Data & privacy — what never travels with a Credential, even inside your own Stack.