Nexma

Permissions & roles

Authority and access control

Nexma scopes what every actor — each person and each agent acting on their behalf — can read, write, and run. Permissions are checked on every DataStore operation; there are no escape hatches. Roles bundle authorities, authorities map to the eight primitives, and authority is scoped to an organization, a project, a branch, or a path. This page is the reference for the role model, the authority flags, and how authority is granted and audited.

Roles

A typical deployment defines four roles. The names are configurable per organization; the shape is consistent.

RoleReadWriteSolveApproveDeleteConfigure
ViewerYesNoNoNoNoNo
DesignerYesYesYesNoNoNo
ReviewerYesYesYesYesNoNo
AdminYesYesYesYesYesYes
  • Viewer. Read-only access to designated projects. No Write, no Run, no Solve.
  • Designer. Read and write within assigned projects and may invoke Solve. Cannot approve published baselines.
  • Reviewer. All Designer authority plus the ability to approve a design as baseline. Cannot delete projects.
  • Admin. Full read, write, delete, and configuration. Manages roles, members, and approvals.

Authority flags

Every operation carries an authority flag. These map directly onto the primitives Jax acts through, so a role governs the agent exactly as it governs a person.

AuthorityGrantsPrimitive
readLoad a DataStore file or query feed dataRead, Glob, Grep
writeCreate or modify a DataStore fileWrite, Edit
deleteRemove a file or branchDelete
runInvoke a deterministic computationRun
solveInvoke a solver familySolve
approvePromote a design to baseline
sharePublish a project externally

The engine evaluates (role, authority, target) on every call. A target can be scoped to an organization, a project, a branch, or a specific path, so authority is never broader than the work requires.

Project versus org authority

Authority lives at two levels, and the narrower one wins. Org-level roles set the ceiling; project-level grants refine it.

  • Org authority governs membership, the Skill library, data connections, and which projects a member can see at all.
  • Project authority governs what a member can do inside a specific project — a Designer on one project can be a Viewer on another.
  • Branch and path scope narrows further still, so a grant can permit writes on one spatial branch without touching Main.

Shadow mode

A new role or rule can run in shadow mode before it is enforced. Shadow records every decision the engine would have made without changing application behavior, so reviewers audit the diff and promote when satisfied. This makes it safe to tighten permissions on a live deployment without risking a lockout.

Approval queues

Sensitive operations — promoting a baseline, sharing a project, deleting a branch — can be configured to enter an approval queue. The actor sees their request as pending; an approver receives it for review. Every approval is logged with the reviewer's identity, the decision, and the rationale.

Subagent deny propagation

Jax can spawn subagents for parallel work. A subagent inherits the deny set of its parent — it cannot acquire authority the user does not have. This closes the obvious hole: an agent cannot delegate around a permission boundary by handing work to a child.

The agent is never a privilege-escalation path. Jax and its subagents act strictly within the authority of the person who invoked them.

Audit

Every permission decision is logged to the organization audit stream — actor, authority, target, decision, timestamp. The stream is queryable from the workspace and exportable for compliance review, so access control and the audit trail reinforce each other.

Where to go next

  • Authentication and access — organizations, members, and SSO.
  • API — how scopes will map onto API keys (in preview).
  • Security — isolation, tenancy, and audit.
  • Jax — the agent these authorities also govern.
Permissions & roles