Skip to main content
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. Disabling an account revokes access without orphaning its history.
  • Tokens — 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)

Two built-in roles: 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 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.