Permissions and visibility

Whagons combines role permissions with operational context. Authentication answers who is acting; authorization decides what that actor may see or change right now.

Authorization layers

Layer	Examples
Tenant	The user, key, or agent must belong to the requested tenant.
Role	Permissions allow actions such as viewing tasks, assigning work, deleting tasks, or managing integrations.
Team	Membership affects ownership, creation, visibility, and status changes.
Workspace	Users may only see workspaces granted by their role and team structure.
Task	Reporter, assignee, team, workspace, and action context can affect visibility.
Field and lifecycle	A user may see a task but be unable to edit a protected field or make an invalid status move.

Whagons includes protected system roles such as tenant owner, administrator, leader, member, and viewer, with a system-administrator role for platform operations. Tenants can also use custom roles and permission sets.

Role names are only one part of the decision. An administrator may manage configuration while still being limited by operational team membership for certain task actions.

API keys

An API key created in Settings → Integrations acts as the user who created it. The key adds API scopes, but it does not bypass that user's current product permissions.

If the creator loses a role, team, workspace, or tenant membership, the key loses the corresponding access. Disabling, expiring, or revoking the key blocks it entirely.

Agent tokens

A user-claimed agent token acts on behalf of the user who approved the agent for the selected tenant. It is short-lived, scoped, revocable, and auditable.

The token does not grant the agent more access than the approving user has.

The built-in assistant

The Whagons assistant uses the signed-in user's context. Read operations remain permission-bound. Write operations use curated actions, and sensitive or destructive changes require explicit user intent and, where supported, a confirmation step.

Integration design guidance

Create integration users with only the teams and workspaces the integration needs.
Create separate API keys for separate systems or environments.
Prefer expirations and rotate keys regularly.
Test visibility with the same user who will own the key.
Treat a 401 as an authentication or scope problem; treat a denied operation as a product-permission or policy problem.

See API keys and Agent safety for operational guidance.