security-canon/infospace/vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md

id	title	short_name	type	standard_family	repository_context	recommended_path	status	version	source_version	source_file	canonical_owner	namespace	classification	abstraction_layer	primary_cluster	imports	related	owned_concepts	decisions
sec-authority:ModeOfAuthority	SecurityCanon Mode of Authority	AUTH-MODE	model	SecurityCanon	security-canon	infospace/vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md	draft	0.2.0	0.1	research/260920-mode-of-authority-v0.1.md	SecurityCanonModeOfAuthority	sec-authority	vocabulary	architecture	authority	InfoTechCanonCore InfoTechCanonAccessControlModel InfoTechCanonIdentityModel InfoTechCanonOrganizationModel InfoTechCanonPurposesExtension	InfoTechCanonCaringAccessGovernanceStandard InfoTechCanonSecurityModel	AuthMode AuthorityContext AuthorityRealm AuthorityProvenance Activation EvidenceBoundary AccessSituation	SECURITY-DEC-2026-001 SECURITY-DEC-2026-002

SecurityCanon Mode of Authority

Short name: AUTH-MODE · Concept: Mode of Authority · Term: Auth Mode

Promoted from the v0.1 research draft, which is retained verbatim as provenance. Changes from v0.1 are listed in §12.

1. Purpose

This vocabulary answers one question that permission and role models do not answer directly:

In what relationship to a system is an actor exercising authority?

That relationship is the actor's Mode of Authority, or Auth Mode.

A Mode of Authority is:

A semantic classification of the intended relationship between an actor and a system scope, describing the nature and purpose of the authority being exercised.

An Auth Mode does not itself define individual permissions.

2. Layer

This is an architecture-layer vocabulary. It describes authority relationships before and independently of the mechanisms that enforce them.

Per SEC-ADR-001, the implementation layer is owned by InfoTechCanon's CARING standard, which analyses how an access-control implementation is actually composed. The two layers are complementary and neither subsumes the other.

	Mode of Authority	CARING
Question	In what relationship is authority exercised?	How is this implementation composed?
Layer	architecture	implementation
Owner	SecurityCanon	InfoTechCanon

3. Orientation — start here

Ask these ten questions, in order. They are the intended entry point to this vocabulary, not an appendix to it.

1.  Who is the actor?
2.  On whose authority is it acting?
3.  What Auth Mode is being exercised?
4.  Over what scope?
5.  What operations are permitted?
6.  Where does the authority originate?
7.  Under what conditions is it activated?
8.  What authority realm enforces it?
9.  Who observes and preserves evidence?
10. Who can override the enforcement mechanism?

This produces substantially clearer security descriptions than the labels user, admin, superadmin, root alone.

4. Distinction from access mode

An access operation — read, write, execute, delete, approve — describes what operation may be performed on a resource. An Auth Mode describes in what relationship the actor stands to the system. The two axes are orthogonal:

read + USE       → reading a customer's document
read + OBSERVE   → reading telemetry about the document service

The access operation is read in both cases. The Auth Mode differs. Access operations are owned by InfoTechCanon's access-control model and imported here.

5. The seven Auth Modes

Auth Mode	Fundamental question
USE	How do I obtain the value this system exists to provide?
OBSERVE	What is this system doing?
OPERATE	How do I keep this instantiated system functioning?
ADMINISTER	How do I configure this system within existing rules?
GOVERN	What rules constrain how authority may be exercised?
CONSTRUCT	How do I change what future incarnations of this system can be?
SOVEREIGN	How is the authority regime itself established, recovered or replaced?

Machine-readable definitions, including intent, typical actions and boundary cases, are in auth-modes.yaml.

6. Principles

A1 — Authority is scope-relative

There is no meaningful authority without a scope. Authority at one scope does not automatically imply authority at another.

A2 — Mode and privilege magnitude are different concepts

Auth Modes are not a privilege ladder. USE < ADMINISTER < SOVEREIGN must not be treated as the semantic model. An auditor may OBSERVE what administrators cannot see; a developer may CONSTRUCT production behaviour with no production access; a governor may constrain administrators without being able to perform their operational tasks.

A3 — Auditability is independent of Auth Mode

Auditability depends on the Evidence Boundary, not the mode. The central question is whether the actor being observed can alter, suppress, bypass or invalidate the evidence used to observe it. Sovereign authority does not necessarily mean unaudited authority.

A4 — Federation does not imply authorization

Federation establishes trusted assertions between independent authority realms. The receiving realm decides independently what the asserted identity may do.

A5 — Sovereignty is relative, not absolute

There need not be a universal root. SOVEREIGN @ database does not imply SOVEREIGN @ host; SOVEREIGN @ tenant does not imply SOVEREIGN @ platform.

A6 — Naming does not collide with the implementation layer (new in 0.2.0)

Where InfoTechCanon owns a term, this vocabulary imports it rather than redefining it, and where this vocabulary needs a distinct concept it takes a distinct name. See SECURITY-DEC-2026-002 and §9.

7. Dimensions

An Access Situation is the complete context in which authority is exercised:

AccessSituation =
    Actor
  × AuthorityContext
  × AuthMode
  × Scope
  × AccessOperations
  × AuthorityProvenance
  × Activation
  × Environment
  × EvidenceBoundary
  × Time
  × Purpose

Not every implementation materialises every dimension; the model exists to support precise reasoning.

Dimension	Owner	Note
Actor	InfoTechCanon Organization Model	imported
AuthorityContext	SecurityCanon	renamed from v0.1 Subject, see §9
AuthMode	SecurityCanon	the seven modes
Scope	InfoTechCanon access-control model	imported
AccessOperations	InfoTechCanon access-control model	imported
AuthorityProvenance	SecurityCanon	LOCAL, PARENT_SCOPE, SUBSTRATE, DELEGATED, FEDERATED, ASSUMED, IMPERSONATED
Activation	SecurityCanon	STANDING, JUST_IN_TIME, SCHEDULED, APPROVED, INCIDENT, BREAK_GLASS, RECOVERY
Environment	SecurityCanon	DEVELOPMENT, TEST, STAGING, PRODUCTION, RECOVERY
EvidenceBoundary	SecurityCanon	who observes and preserves evidence, and who can compromise it
Time	—	not modelled in 0.2.0
Purpose	InfoTechCanon PURPOSES extension	imported, not redefined here
PrincipalType	InfoTechCanon identity model	imported; HUMAN, WORKLOAD, SERVICE, AGENT, CONTROLLER, DEVICE

Machine-readable definitions are in dimensions.yaml.

Auth Modes apply independently of principal type. Principal type must not be encoded into the Auth Mode taxonomy.

8. Authority Realm

An Authority Realm is a scope possessing an independently meaningful authority boundary — an operating system, a database, a Kubernetes cluster, a cloud account or organization, an identity realm, a SaaS tenant, a trust domain.

A realm may possess its own SOVEREIGN, GOVERN, ADMINISTER, OPERATE, OBSERVE and USE authorities. Realms need not share a common sovereign. A federation may hold GOVERN @ federation without holding SOVEREIGN @ member-realms, so a genuine federation need not contain a global root.

9. Actor and Authority Context

Authority is sometimes exercised on behalf of another party.

• Actor — the entity actually performing the action.
• Authority Context — the authority being drawn on, when it is not the actor's own.

Normally the actor acts on its own authority and the dimension is absent. When it does not:

support-agent:
  USE @ tenant/acme
  authority_context = customer-42
  relation = IMPERSONATED

Delegation means the actor retains its identity while exercising delegated authority. Impersonation means the actor acts within another party's authority context. Neither is an Auth Mode; both describe how authority is exercised, and the underlying mode may still be USE, OPERATE, ADMINISTER or any other.

Renamed in 0.2.0. The v0.1 draft called this dimension Subject. InfoTechCanon's access-control model already owns both Actor and Subject and binds them differently — "Subject is the access-control view of an actor" — so reusing the pair for two distinct parties would have made the same word mean two things across the canons. AuthorityContext names what the field holds, which stays accurate when the target is a role or mandate rather than a person. See SECURITY-DEC-2026-002 and the implications note.

CARING §32 carries a richer form of this distinction — Principal, effective actor, Delegator, audit identity, capability ceiling — scoped to non-human subjects. The relationship is recorded as a mapping, not a redefinition.

10. Positions on the v0.1 open questions

10.1 CONSTRUCT and GOVERN are distinct — the artifact does not decide it

v0.1 asked whether policy-as-code blurs CONSTRUCT and GOVERN. Position: they remain distinct, and the distinguishing test is the object of authority, not the medium.

CONSTRUCT   authority over definitions from which behaviour is produced
GOVERN      authority over the rules constraining how authority is exercised

Policy-as-code is an artifact and a rule, so an actor may hold both modes over it — and that is the point, not a defect:

platform-engineer:
  CONSTRUCT @ policy-repo/authz      # may change the policy source
  # but NOT GOVERN @ organization    # may not decide what the policy must say

security-governor:
  GOVERN @ organization              # decides what the policy must require
  # but NOT CONSTRUCT @ policy-repo  # does not write or merge it

The separation is the security property worth having: whoever can edit the policy file should generally not be the one who decides what it must contain. Collapsing the two modes would make that separation inexpressible. The test is therefore:

Does the actor change the artifact (CONSTRUCT) or decide the constraint the artifact must satisfy (GOVERN)? An actor holding both over the same scope is a finding, not a modelling error.

10.2 Substrate authority is a relation between realms

v0.1 named substrate authority — hypervisor over VM, host root over container, cloud provider over tenant — but recorded it only as AuthorityProvenance = SUBSTRATE, which names the fact without modelling which realm dominates which.

Position: substrate authority is a relation between Authority Realms, not a mode and not a provenance value alone. It is written:

realm:host/node-7  DOMINATES  realm:container/app-3
realm:cloud/aws-account-1  DOMINATES  realm:tenant/acme

with three properties, which are what actually matter in analysis:

Property	Question
dominance_kind	execution substrate, storage substrate, identity substrate, network substrate?
observable	can the dominated realm detect the dominating realm's exercise of authority?
evidence_boundary	does the dominated realm's evidence survive the dominating realm?

This makes A5 checkable. SOVEREIGN @ container is true within its realm and simultaneously dominated by SOVEREIGN @ host — with no contradiction, and with the security consequence stated explicitly rather than implied.

AuthorityProvenance = SUBSTRATE is retained: it marks authority that arrives through a dominance relation, while the relation itself records the structure.

10.3 Still open

Q1 (are seven modes sufficient), Q4 (decomposing sovereignty), Q5 (mutually constraining sovereigns), Q6 (autonomous agents modifying their own future authority) and Q7 (Auth Mode as a machine-readable ABAC attribute) remain open and are carried in the v0.1 draft §31.

11. What is deliberately not an Auth Mode

AUDIT, SECURITY, SUPPORT, BACKUP, DEVELOPER, OWNER, BILLING, AUTOMATION, AGENT, FEDERATION, BREAK_GLASS, SUPERADMIN, ROOT.

Each is representable as a composition:

auditor                 → OBSERVE @ evidence
backup operator         → OPERATE @ backup-system
developer               → CONSTRUCT @ product
security administrator  → ADMINISTER @ security-controls
security policy owner   → GOVERN @ security-controls
break-glass admin       → ADMINISTER, activation=BREAK_GLASS

root is an implementation-specific manifestation of sovereign or broad authority, not a mode. Prefer SOVEREIGN @ host or ADMINISTER @ cluster over "has root".

A new Auth Mode is introduced only when a recurring authority relationship cannot be expressed as an existing mode plus scope, operation, provenance, activation and purpose.

12. Changes from v0.1

Change	Reason
Subject dimension renamed to AuthorityContext	collision with InfoTechCanon-owned Actor/Subject binding (§9)
Scope, AccessOperations, Purpose, PrincipalType declared as imports	InfoTechCanon owns them; SEC-ADR-001 D2
Principle A6 added	naming separation made explicit
Position taken on CONSTRUCT vs GOVERN	§10.1; was open question Q2
Substrate authority modelled as realm dominance	§10.2; was open question Q3
Design heuristic moved to §3	it is the entry point, not an appendix
Machine-readable modes and dimensions added	auth-modes.yaml, dimensions.yaml
Artifact frontmatter, id, namespace, owned concepts added	makes it a canon artifact rather than a paper

13. Status

Draft. Stable promotion requires reviewed mappings and concrete consumer evidence, per INTENT.md. The research hypothesis — that seven modes suffice without platform-specific additions — has not yet been stress-tested against Unix, databases, Kubernetes, cloud IAM, identity platforms, secrets management, CI/CD or agentic systems.