Identity is its own service
Authentication is not code inside the application. Two dedicated services sit in front of it: one owning identities, credentials and sessions, and one acting as the OAuth2 and OpenID Connect provider that issues tokens.
So sign-in, session lifetime, credential storage and token issuance are standard, independently upgradable infrastructure, not product code that has to be re-audited whenever the product changes.
Onboarding is invite-based, not open self-service: an account exists because somebody in an organisation created it.
No static API keys
Authority is derived from the caller, every time. Functional roles come from the session for operations inside an organisation; platform-wide operations require platform-administrator standing, which is held separately.
There is no long-lived shared secret that grants access on presentation - which is the failure mode where a key ends up in a repository, a notebook, or a departed employee's password manager, and grants exactly as much on the day it is found as on the day it was issued.
Tokens between services
When the control plane calls the process service on a caller's behalf, it carries an on-behalf-of token for that caller and not a blanket service identity. The authority crossing a service boundary is the user's, not the platform's.
The same rule holds for AI employees: an employee holds its own credentials and authenticates through the same path a person does, so a background actor is a subject, not an exception.
Where authority is then applied
Being authenticated decides nothing on its own. What a caller may see is decided by grants, row policies and column masks, evaluated per query.