> ## Documentation Index
> Fetch the complete documentation index at: https://nativeharness.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Your users

> Actors, permissions, sessions and approvals — the multi-user model, and how one user's agent is kept away from another's.

The design assumption that separates nativeharness from a terminal coding agent: **the person
the agent works for is not the person running the harness.** Your users are many, they do not
trust each other, and they must not be able to reach each other's work.

## Actors

An actor is a string: whatever identifies a principal in *your* system. A user id, a service
account, a tenant. The harness never sees a password, a session cookie or an email; it sees an
opaque name and enforces what that name may do.

## Permissions

A workspace names who may work in it, where, and how:

```ts theme={null}
permissions: [
  { actor: "user-42",  scope: "/",     mode: "commit"  },
  { actor: "user-7",   scope: "/docs", mode: "commit"  },
  { actor: "reviewer", scope: "/",     mode: "discard" },
]
```

| Field   | Effect                                                                              |
| ------- | ----------------------------------------------------------------------------------- |
| `actor` | who                                                                                 |
| `scope` | the subtree they may commit into; a command that writes outside it is not committed |
| `mode`  | a **ceiling**: a `discard` actor cannot open a `commit` session                     |

An actor not in the list cannot run a command at all. `BashTool` checks this on every
execution, before a sandbox is even acquired.

## Sessions

A session is one actor's conversation in one workspace, in one mode:

```ts theme={null}
const session = await store.createSession(workspaceId, { actor: "user-42", mode: "commit" });
```

Turns belong to sessions, and events are scoped to them, so a stream for one session never
carries another's. A session can be closed, and a new one started in the same workspace, with
the files exactly where the last one left them.

## Isolation

Each command runs in a sandbox hydrated from *that* workspace. There is no path from one
sandbox to another workspace's files, and the provider refuses a path that tries to leave the
workspace rather than normalising it. The agent will not run a model's commands on a provider
that does not isolate.

## Approvals

The approval policy reviews a command's **effects** — the files it changed, the connectors it
called — after the command ran in its sandbox and before anything is committed:

```ts theme={null}
const policy: ApprovalPolicy = {
  review(effects, context) {
    if (effects.files.deleted.length > 20) return "ask";
    if (effects.connector_calls.some((c) => c.tool === "delete_repo")) return "deny";
    return "allow";
  },
};
new BashTool({ store, sandbox, events, approval: policy });
```

`ask` ends the turn `needs_continuation` and emits `approval_required` with the effects. Your
UI shows them to a person; their decision comes back through `agent.resume()`, and it is
recorded with who decided. The effects are staged at review time, so a decision can take a
day and still commit cleanly.

The policy's job is *your* rules — a plan tier, a repository's protection level, a customer's
settings. The harness enforces isolation and scope before the policy runs and does not ask it
about them.

## Questions

A model can call `ask_user`. That, too, ends the turn `needs_continuation`, with the questions
in the event; the answers come back through `resume`. Nothing blocks waiting.

## Per-user integrations

A connector is attached to a workspace with a reference to a credential that belongs to an
actor. The credential never enters the sandbox: a per-command token does, and the gateway
swaps it for the real credential on the way out. See [Connectors](/concepts/how-it-works).

## What is yours

Authentication, user records, billing, quotas, which user gets which plan's sandbox size —
all yours, above the harness. The harness's job is that once you have decided an actor may do
something, that is exactly and only what they can do.