Skip to main content

Identity and Access

Identity in Worka is not only about signing in. It determines who can open a workspace, who can approve risky actions, which devices may contribute local capability, and which packs or services may act on a user’s behalf.

If your identity model is vague, everything built on top of it becomes vague as well.

The identities you need to think about​

In production, Worka deals with several different kinds of identity:

  • people using the product
  • devices that contribute local capability
  • AI team members acting inside a workspace
  • packs and services acting through platform-authorised paths

Those actors do not all get the same rights and they should not share the same trust model.

User access​

For people using Worka, decide:

  • how users authenticate
  • who may create workspaces
  • who may invite other people
  • which roles exist in a workspace
  • whether public or anonymous access is allowed anywhere

Keep the model understandable. People need to know whether they can:

  • view a workspace
  • change it
  • approve actions
  • connect services
  • publish shared views
  • manage AI team members

If two roles differ, the difference should be visible in product behavior, not only in a policy document.

Workspace roles​

At a minimum, you should think in terms of:

  • owners who can fully manage the workspace
  • admins who can operate it day to day
  • members who can use and improve it
  • viewers who can inspect but not change it

You may later refine that model, but do not start with dozens of narrowly named roles. A smaller clear model is easier to audit and explain.

Device identities​

Worka also needs to know which devices it trusts.

That matters when a device offers:

  • local Codex, Claude, or Gemini access
  • local inference
  • browser control
  • desktop computer control
  • shared network contribution

Registering a device is not the same thing as granting it every capability it can technically see. Each capability still needs its own enablement and consent path.

Service and runtime identities​

Persistent services, pack runtimes, and internal platform components also need identity. This identity is usually not something an end user edits directly, but operators still need to understand it because it affects:

  • secret grants
  • pack invocation
  • workspace-scoped access
  • audit trails

The key rule is simple: actions must be attributable. When something invokes a tool, publishes an artifact, or changes access, you should be able to see which actor did it.

Joining and leaving​

Plan the full lifecycle, not just sign-in:

  • invite and onboarding
  • role change
  • workspace removal
  • access revocation
  • device retirement
  • service account rotation where relevant

You should assume users leave teams, laptops are replaced, and external connections need to be revoked. Those should be normal operations, not unusual emergencies.

What to review regularly​

Review identity and access on a schedule:

  • who can administer each workspace
  • who can approve capability expansion
  • which devices are still active
  • which shared/public views are still intended
  • which service connections are still granted

The goal is not paperwork. The goal is to stop stale access from becoming the default.