security-canon/infospace/vocabulary/mode-of-authority/auth-modes.yaml

id: sec-authority:AuthModeCatalog
title: SecurityCanon Auth Mode Catalog
type: catalog
namespace: sec-authority
version: 0.2.0
status: draft
source: infospace/vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md
notation: "MODE @ SCOPE"
non_ordered: true
non_ordered_note: >-
  Auth Modes classify the kind of authority, not its magnitude. This list is not
  a privilege ladder and must not be compared ordinally.

auth_modes:
  - id: USE
    intent: Exercise the system for its designated domain purpose.
    question: How do I obtain the value this system exists to provide?
    typical_actions: [send a message, edit a document, place an order, query application data, consume an API]
    boundary: >-
      USE does not imply low privilege. A business user may perform highly
      consequential actions entirely within USE.
    contrast:
      OBSERVE: reading a customer invoice is USE; reading latency metrics for the invoice service is OBSERVE

  - id: OBSERVE
    intent: Establish knowledge about the system, its behavior or its state.
    question: What is this system doing?
    typical_actions: [read logs, view metrics, inspect traces, read audit records, examine security events]
    boundary: >-
      Distinct from ordinary read access. The access operation may be identical;
      the relationship to the system differs.
    contrast:
      USE: understanding the system rather than obtaining its domain value

  - id: OPERATE
    intent: >-
      Maintain or change the operational state of an instantiated system while
      preserving its intended definition.
    question: How do I keep this instantiated system functioning?
    typical_actions: [start, stop, restart, scale, fail over, restore, drain a node, terminate a stuck process]
    boundary: Changes running state, not definition.
    contrast:
      ADMINISTER: restarting a database is OPERATE; changing its authentication configuration is ADMINISTER

  - id: ADMINISTER
    intent: Configure resources and delegated authority within an established governance regime.
    question: How do I configure this system within existing rules?
    typical_actions: [configure resources, create users, assign roles, manage groups, provision resources, delegate bounded authority]
    boundary: >-
      Operates inside rules established elsewhere. Broad discretion does not
      include redefining the constraints on that discretion.
    contrast:
      GOVERN: assigning application roles is ADMINISTER; deciding which roles administrators may assign is GOVERN

  - id: GOVERN
    intent: Define the rules under which authority may be exercised.
    question: What rules constrain how authority may be exercised?
    typical_actions: [set policy ceilings, define delegation rules, set separation-of-duty requirements, decide allowed identity providers]
    boundary: Authority over authority.
    test: Can this actor decide what another administrator is allowed to decide?
    contrast:
      CONSTRUCT: GOVERN decides the constraint; CONSTRUCT changes the artifact that must satisfy it

  - id: CONSTRUCT
    intent: Change definitions or artifacts from which system behavior is produced.
    question: How do I change what future incarnations of this system can be?
    typical_objects: [source code, infrastructure-as-code, build definitions, container images, schemas, policy-as-code, CI/CD pipelines]
    boundary: >-
      Authority over the possible future system, not necessarily over the
      running instance. Substantial CONSTRUCT authority may coexist with no
      production runtime authority.
    contrast:
      ADMINISTER: ADMINISTER changes the instantiated system; CONSTRUCT changes definitions capable of producing systems

  - id: SOVEREIGN
    intent: Establish, recover, replace or bypass the normal authority regime of a scope.
    question: How is the authority regime itself established, recovered or replaced?
    typical_situations: [initial bootstrap, establishing trust roots, root-account recovery, rebuilding the control plane, restoring authority after catastrophic failure]
    boundary: >-
      Sovereign relative to a defined scope and authority boundary, never
      all-powerful everywhere. SOVEREIGN @ database does not imply SOVEREIGN @ host.
    see_also: Evidence Boundary — sovereign authority is not necessarily unaudited

not_auth_modes:
  - {term: AUDIT, expressed_as: "OBSERVE @ evidence"}
  - {term: BACKUP, expressed_as: "OPERATE @ backup-system"}
  - {term: DEVELOPER, expressed_as: "CONSTRUCT @ product"}
  - {term: SUPPORT, expressed_as: "USE or ADMINISTER with authority_context and relation=IMPERSONATED"}
  - {term: BREAK_GLASS, expressed_as: "any mode with activation=BREAK_GLASS"}
  - {term: FEDERATION, expressed_as: "any mode with provenance=FEDERATED"}
  - {term: AGENT, expressed_as: "any mode with principal_type=AGENT"}
  - {term: SUPERADMIN, expressed_as: "ADMINISTER or SOVEREIGN at a named scope"}
  - {term: ROOT, expressed_as: "SOVEREIGN @ host, or ADMINISTER @ scope — implementation-specific"}
  - {term: OWNER, expressed_as: "GOVERN or ADMINISTER at a named scope"}
  - {term: BILLING, expressed_as: "USE @ billing, or ADMINISTER @ billing"}
  - {term: AUTOMATION, expressed_as: "any mode with principal_type=WORKLOAD or CONTROLLER"}
  - {term: SECURITY, expressed_as: "ADMINISTER @ security-controls, or GOVERN @ security-controls"}