> ## Documentation Index
> Fetch the complete documentation index at: https://docs.try-airlock.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Governance

> Identity, access control, supervision, retention, and jurisdiction posture.

A system that watches access must itself be governable.

## Identity and accounts

Every event, flag, and console action resolves to
a **user account** in Airlock's own user table — deliberately built-in, with
no external IdP dependency to stand up before day one.

* **Accounts** — an admin creates users (email + password, bcrypt at rest)
  and sets roles in the [console](/dashboard#user-management). Disabling an
  account revokes access without orphaning its history.
* **Tokens** — [`airlock login`](/cli#airlock-login) exchanges credentials
  for an ingest-scoped API token; admins mint named tokens for external
  agent identities the same way. Tokens are hashed at rest, revocable, and
  show last use. Every ingest is attributed server-side to its token's user.
  A token cannot write anyone else's history, and ingest tokens cannot read.
* **Tamper visibility** — events carry a server-assigned `received_at` beside
  the client timestamp, so backdating is visible; ingest is insert-only, so
  history cannot be rewritten.

## Access control (see [Console](/dashboard))

Two built-in roles:

| Role      | Sees                                               |
| --------- | -------------------------------------------------- |
| **admin** | Every timeline, session, and flag; user management |
| **user**  | Their **own** activity, read-only                  |

The people whose agents are recorded read
their own record, scoped server-side on every query.

## Action gates

Observation is the default posture; enforcement concentrates where actions
are irreversible. When an agent's next step moves funds, ships code, or sends
data somewhere it cannot be recalled, a **gate wraps the action**: it
independently re-verifies what the proposed action claims — sources
re-fetched, values compared, thresholds and state checked — and emits
**allow** or **hold**. Only an allow lets the action's own backend run.

Three invariants bind every gate:

* **Deterministic grounds.** Every check is a comparison against a source, a
  number, or a status — all checks always run, so a hold carries its
  complete, specific reasons.
* **Model output can classify, never authorize.** Anything model-scored lands
  on the record as an advisory after the decision is final; it cannot create
  an allow or flip a hold.
* **No borrowed credentials.** A gate holds no keys to the system it fronts —
  it decides, and a separate backend acts. Every evaluation is appended to
  the audit record before that backend runs.

Above a configured impact threshold, an allow additionally requires a human
disposition.

## Review

Every [flag](/dashboard#the-flags-queue) carries an append-only review
trail — status (`open`, `acknowledged`, `resolved`), reviewer, and note — so
the program can answer which alerts were reviewed, by whom, and with what
outcome.

## What is stored

The store holds captured events, including transcript content and returned
tool results, in the Postgres you operate. Two things follow:

* **Scope it deliberately.** Transcript `raw` includes model reasoning with
  no length cap. If retaining that is not acceptable, the ingestion path is
  the place to drop it, before it is ever written.
* **Treat the store as sensitive.** It is a record of what your people and
  agents read. Back it up, restrict it to the accounts that need it, and put
  it in scope for your own incident response.

## Egress posture

* **No vendor telemetry.** Airlock phones nowhere home; license checks are
  offline.
* **The backend makes no outbound connections.** Events come *to* it. The
  CLI publishes, agents push, and nothing content-bearing leaves your
  deployment.