Identity providers & sign-in
This is about your identity, not the agent's. Before you can open the dashboard or a chat, the platform has to know who you are — and that signed-in identity becomes the subject every request is authorized against in the same graph the agents use.
Two ways in
- A local admin password. On Desktop — and any single-operator install — you set an admin password at setup and sign in with it. Simple, local, no external dependency.
- A connected identity provider. On a shared cluster you connect an OIDC provider (your company SSO) via
a
ClusterIdentityProvider, and people sign in through it. The install offers to set this up, or you configure it later withoap idp.
Either way, an unauthenticated request to a gated surface is redirected to sign in; only after that does the request carry a real identity.
From sign-in to a subject
A successful sign-in mints a session for the browser, and the verified identity — an email from the trusted provider — is what becomes the SpiceDB subject on every subsequent request. So "can this person see this session / install this agent / approve this step" is answered by the same per-subject check as everything else. There's no second, weaker access model for the human side.