Skip to content

iii — Roles and Permissions

A run only touches what its caller is allowed to touch.

Every resource call goes through a proxy that holds the credentials and checks the call against the grants issued for that run; the container never sees a secret. Everything the run did is recorded.

governance — one prompt, two requesters

The same prompt, “Summarize this week’s admissions on ward 3.”, is run for two people. In both runs the task sends the identical query for ward 3’s admissions and the identical request for its scans. The proxy applies each person’s grant. u_ellis, the ward’s attending, is scoped to ward 3 and receives all 36 admissions and 12 scans. u_rhodes, a research fellow, is scoped to ward 3 with research consent and receives 12 admissions; the other 24 are never sent, and the scans request is denied because u_rhodes holds no grant for it. Every decision is written to the audit log.

run as u_ellis · u_rhodes0 decisions loggedTrace
live run — financial auditrun_events

█

One table, four uses.

  • Status, the audit trail, approval, and crash recovery all read from this one table, so they always agree.

  • If the executor is killed mid-run, it rebuilds each run's state from the log and finishes the work.

  • A task can gate on human approval. The pending decision persists, so the run survives a restart and continues when someone signs off.