Security & governance
Permissions, audit, isolation
Nexma is built so you can let an autonomous agent act on live infrastructure with confidence. Every action — human or agent — is permissioned, versioned, and replayable, and the platform runs inside your security boundary on the deployment you choose.
Core concepts
Security in Nexma is not a layer bolted on top; it falls out of the architecture. Because the DataStore is the single source of truth and the agent acts only through eight generic primitives, there are exactly eight kinds of action to govern, and one place where state changes.
- Unified permissioning. Access is governed once, against the world model, and applies to every surface — map, tables, API, mobile, and Jax alike.
- Everything is versioned. Every write is a commit. Nothing is overwritten in place, so the before-state always exists.
- Scoped agent action. Jax can only do what the eight primitives allow, bounded by the permissions of the project and workflow it runs in. Every agent action is logged and reversible.
- Tenant isolation. Organizations and projects are isolated, and agent runs operate in scoped contexts so concurrent work doesn't collide or leak.
Permissions and roles
Access control integrates with your existing identity provider rather than inventing a parallel one.
- Identity. Connect your SSO so users and roles come from your directory.
- Roles and access control. Authenticated users get role-based access to projects and resources; see Authentication and the permissions reference.
- Agent scoping. Workflows in the AgentEngine carry their own permissions, bounding exactly what each run can read and write.
- Human-in-the-loop. Insert approval gates so a person signs off before an agent commits a change to the live world.
Audit trail
Because the DataStore is versioned, the audit trail is not a separate logging system — it is the store's own history.
| Property | What it gives you |
|---|---|
| Versioned writes | Every change is a commit with author, time, and content |
| Point-in-time replay | Reconstruct the exact state of the world at any past moment |
| Full run history | Replay any agent run end-to-end — every tool call, read, and write |
| Reversibility | Any change can be inspected, diffed, and rolled back |
| Lineage and provenance | Trace any value back to the source and the decision that set it |
Who changed what, when, and why is captured automatically across every human and agent action — for compliance, debugging, and trust. There is no path that mutates the world without leaving a record.
How it works
A change flows through the same governed path whether a person or Jax makes it.
1 Actor (user or Jax)
2 │
3 ▼
4 Permission check ── denied ──▶ rejected, logged
5 │ allowed
6 ▼
7 Versioned write to DataStore ──▶ commit (who · what · when · why)
8 │
9 ▼
10 Surfaces re-render · audit history updated · reversibleThere is one write path, so there is one place to enforce policy and one place to audit. Optional approval gates sit on that path for changes that require sign-off.
Deployment, isolation, and secrets
- Your boundary. Deploy in managed cloud, your VPC, on-premise, or fully air-gapped — the same platform, inside the security perimeter you require. See Supported platforms.
- Network isolation. Run within strict boundaries, including environments with no outbound connectivity. The Agent Computer's solvers run locally so disconnected operation loses no capability.
- Data residency. Choose the region or network where data lives; opaque SaaS residency guarantees are replaced by a deployment you control.
- Secrets. Connector credentials and keys are handled by the integration layer and are never written into DataStore files. Application code and secrets live outside the world model by design.
Where to go next
- Set up access: Authentication and the permissions reference.
- Govern agent runs: AgentEngine and Automations.
- Choose your security boundary: Supported platforms.
- Understand the versioned foundation: Branches and DataStore-first architecture.