Govern (GV) · Authorization

Authorization at the Domain charter layer

deterministic · Outside the model's reasoning

Who is allowed to put this agent into the world, under what authority, accountable to what policy, with what retirement criteria?

What this cell does

Per-class scope, inherits org hard prohibitions, adds domain-specific restrictions.

Artifacts (1)

checks.yamlview on GitHub

# ABOUTME: Machine-checkable definition of the Charter authorization / domain cell.
# ABOUTME: The audit prompts in this cell's README, expressed so a validator can score them.

cell:
  id: authorization.client-side
  concern: authorization
  layer: client-side
  authority: domain
  document: domain-charter
  owner: "Domain authority."
  question: "Does the domain charter define the per-class scope (which APIs, data classes, environments, destructive verbs are allowed), inherit org-wide hard prohibitions, and add domain-specific ones?"

mappings:
  csf: "GV.PO-01, GV.RR-03"
  ai_rmf: "GOVERN 1.2"
  iso42001: "A.6"
  eu_ai_act: "Art. 26"

checks:
  - id: GV-AZ-D-01
    description: "Permitted data classes are enumerated for the domain."
    type: min_items
    target: "scope.data_classes:1"
    document: domain-charter
    severity: blocking
    evidence: "Named classifications."
  - id: GV-AZ-D-02
    description: "The domain inherits the organisational hard prohibitions explicitly."
    type: required_field
    target: "scope.inherits_prohibitions_from"
    document: domain-charter
    severity: blocking
    evidence: "A reference to the org policy document."
  - id: GV-AZ-D-03
    description: "Domain-specific prohibitions are recorded, even when the list is empty by decision."
    type: field_present
    target: "scope.domain_prohibitions"
    document: domain-charter
    severity: advisory
    evidence: "An explicit empty list beats a missing key."

Cell notes

Charter, Authorization / Domain

Structural question. Does the domain charter define the per-class scope (which APIs, data classes, environments, destructive verbs are allowed), inherit org-wide hard prohibitions, and add domain-specific ones?

Owner. Domain authority.

Template fragment

§5 (Authorization) of ../../templates/domain-charter.md.

Audit prompts

- What scope does this domain authorize? Is it more restrictive than the org-wide ceiling?
- Are domain-specific prohibitions documented? Are they enforced at runtime?
- How does the domain change scope policy? Domain-lead-only, or with security-review co-sign?

Operational tie-in

The domain's scope envelope is the upper bound on every agent charter in the domain. An agent charter that requests scope outside the domain charter must be rejected at PR review.

Citation

NIST CSF 2.0 GV.PO-01; PR.AA-05 (charter dimension). NIST AI RMF GOVERN 1.4, MANAGE 2.4. ISO/IEC 42001 §A.6.2. EU AI Act Art. 14, Art. 15.

Crosswalk

NIST CSF 2 0	GV.PO-01, PR.AA-05
NIST AI RMF	GOVERN 1.4, MANAGE 2.4
ISO IEC 42001	§A.6.2
EU AI ACT	Art. 14, Art. 15

Cite this cell: https://agenticcovenants.com/govern/authorization/client-side/