Skip to main content
There are two distinct identity surfaces on the platform, and conflating them is the most common modeling mistake. Operators are the people who build a workspace — they sign in with their own gavAI account and hold scopes against the workspace’s API. End users are the people who use the published app — they sign in to that workspace’s app, not to gavAI. By the end of this page you will know what the end-user identity surface looks like, what authentication methods it supports, and how end-user sessions appear in capabilities and audit.

​
Two identity surfaces, side by side

The pools are independent. A user with a customer@example.com account on Acme’s app does not have a gavAI account. An operator who can patch Acme’s pages does not, by virtue of that, have an end-user record inside Acme’s app. The two never share a session, a credential, or a token. The control-plane operator surface is documented under Authentication. This page documents the end-user surface, which is what your visitors see when they sign in to the app you built.

​
What the runtime supports

Each workspace’s identity service supports the patterns end users actually expect from a modern app. You enable the ones you want on the workspace’s auth configuration — you do not build them. A single workspace can offer all three at once. The end user picks the method on the sign-in page; the platform unifies them under one identity record once they have signed in.

​
Password reset, MFA, and lockout

All three are platform-owned. You configure them, you do not write them.

​
Session lifetime and refresh

End-user sessions are short-lived access tokens paired with a refresh token. The defaults — access TTL, refresh TTL, idle timeout — are workspace-configurable and applied consistently across passkey, password, and federated sign-in. A workspace owner can revoke any end-user session immediately — the next refresh attempt fails, and any in-flight access token is rejected on next use.

​
End users in capabilities

The authUser capability returns the currently signed-in end user’s profile and roles. Capabilities that act on the end user’s behalf — runQuery reading rows owned by them, storeFile writing to their bucket prefix — automatically pick up the session and resolve ownership against it. Two consequences worth holding:

​
End users in audit

Audit records that are caused by an end-user action carry the end-user id, not the workspace owner’s id. A capability dispatched on the end user’s behalf is attributed to them in the chain. This matters for compliance: “did the customer authorize this?” has a verifiable answer. The end-user id format is workspace-scoped. The same email registered on two workspaces produces two distinct ids — there is no cross-workspace end-user identity by design.

​
Where end-user data lives

End-user accounts live in the workspace’s per-tenant identity service. Profile fields, hashed credentials, and session state are stored alongside the workspace’s other data — not in a shared identity pool. The same isolation guarantees as the multi-tenant model apply: an end user in workspace A cannot be resolved to an account in workspace B. The trade-off is that end users do not have a portable identity across workspaces. A customer who uses Acme’s app and also uses Globex’s app holds two unrelated accounts — that is the right answer for security and the right answer for tenant isolation.

​
When this surface is the right answer (and when not)

Use the platform’s end-user identity when: Don’t use it when: