§9 Authorization

Packs declare effect class (§4). Runtimes decide who may cause that effect.

9.1 Principal#

1. Every exec, connect, install, and Sense delivery MUST be attributed to exactly one Principal.
2. The Principal MUST be established by the runtime from an authenticated session or credential. It MUST NOT be taken from the exec envelope.
3. Principal kinds are informative: human, service, agent, mothership.

9.2 Scope#

1. Tenant MUST come from the Principal's session. A runtime MUST NOT select the tenant from args.
2. Project MUST be resolved when the command's or trigger's land is brain. Absent project scope, the runtime MUST deny with privacy.land brain requires project_id.
3. For land brain, the runtime MUST verify project membership; tenant membership alone is insufficient.
4. Arguments such as --entity MAY refine Binding-scoped accounts within the resolved scope.

9.3 Separation#

Packs MUST NOT embed user allow-lists, roles, or credentials.

9.4 Capabilities#

A runtime MUST implement, at minimum, these five axes.

1. A runtime MAY scope a grant to a pack_id and further to specific verb_keys.
2. A multi-tenant runtime MUST NOT collapse verb.exec.read, verb.exec.write, and pack.connect into a single boolean.
3. pack.connect MUST be evaluated for connect commands regardless of any verb.exec.write grant.
4. A runtime MUST fail closed: absence of a matching grant is a denial.

9.5 Evaluation order#

Authorization runs inside the exec pipeline, in the order of §6.3:

1. Resolve pack, activation, and Policy entry                       (§6.3 steps 1 to 3)
2. Authenticate Principal; resolve Tenant (+ Project if land = brain) (step 4)
3. Assert capability for pack_id (+ verb_key)                        (step 5)
4. Enforce confirm                                                   (step 6)
5. Mint Binding, fail closed                                         (step 7)
6. Execute Adapter                                                   (step 8)
7. Audit                                                             (step 9)

A runtime MUST NOT reorder these steps such that an Adapter could run before a denial would have been produced. Every Invoker (an agent, an API, a UI, a person at a terminal) reaches a command through this order, and a runtime MUST NOT give an Invoker a path to a verb_key that skips a step.

Informative. RFC 0006 (draft) adds access modes, allow, ask and deny rules, and approvals at step 4.

9.6 Audit#

The reference runtime writes one line per decision to audit.jsonl; see Access.

1. Every write MUST be recorded with: Principal + Tenant (+ Project) + Binding identity + pack_id + verb_key + operation.
2. Every read SHOULD be recorded with the same tuple.
3. Every denial SHOULD be recorded with its reason.
4. Binding identity and Principal MUST be distinct fields.

9.7 Denial reasons#

Denials MUST be returned as ok: false result envelopes. The error string SHOULD begin with denied: for grant and scope denials and SHOULD name the missing capability.

9.8 Cross-mode execution#

A runtime MUST refuse a command whose Binding mode is mothership when the Principal is not an operator, unless an explicit elevation grant is present. This applies regardless of how the operator binary became reachable.

9.9 Out of scope#

Informative. Role table schemas, row-level security, IdP integration, session formats, and host paths are adopter profiles. The protocol fixes only the axes, the order, and the tuple.