Kival separates authentication, workspace participation, and object access. Signing in establishes who you are; workspace membership establishes where you participate; object roles determine which knowledge you can read or change.
The most important consequence is simple: being a workspace member does not make every object in that workspace visible.
Authentication and passkeys
Interactive users authenticate with passkeys rather than normal passwords. A passkey proves which Kival user is signing in; it does not itself grant workspace or object access.
Users can have multiple active passkeys and browser sessions. Security-sensitive credential changes require fresh authentication. If a user loses access to their passkeys, an operator can perform account recovery without changing the authorization model around that user.
Programmatic clients authenticate differently: API keys belong to users and act through their authority. See Agent access for API-key lifecycle and delegation.
Workspace membership
A workspace has two membership roles:
member: participates in the workspace;
admin: administers the workspace and receives administrative access to its objects.
Global administrators have broader authority across active workspaces.
For ordinary users, active workspace membership is required before object grants can take effect. Creating an object also requires workspace membership; its creator receives an explicit administrator grant on that object.
Object roles
Object access has three cumulative roles:
| Role | What it allows |
|---|---|
| Viewer | Read the object and participate in commentary. |
| Editor | Viewer capabilities plus editing canonical content. |
| Admin | Editor capabilities plus object administration and grant management. |
When several valid grants apply, Kival uses the strongest effective role.
Direct and group grants
An object can grant a role directly to a user or to a group.
A direct grant only remains effective while the user is an active member of the object's workspace. Group-derived access additionally depends on active group membership, an active group, and an active link between that group and the workspace.
This lets teams reuse access groups without making group membership equivalent to workspace membership.
For practical sharing patterns, see Working with others.
Administrative access
Workspace and global administrators do not need explicit grants on each active object inside their administrative scope. Their broader role gives them effective object-admin authority.
That is an administrative override, not a hidden object grant. Ordinary workspace members receive no comparable implicit visibility.
Lifecycle state also matters: archived workspaces and objects leave ordinary active use, while authorized administrators retain the operations needed to inspect or restore them.
Programmatic access
API keys never become independent principals. A request made with a key is bounded by:
the owning user's current authority;
the key's scopes;
its delegated workspaces for workspace-scoped operations.
These restrictions can narrow a user's authority but cannot expand it. An admin scope, for example, does not turn its owner into a global administrator.
Authorization at the operation boundary
Kival checks authorization when an operation crosses its access gate. Once admitted, that operation may complete even if a role or membership changes concurrently; subsequent requests are evaluated against the new access state.
This keeps authorization explicit without repeatedly re-checking permissions halfway through one operation.