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

---
id: sec-authority:ModeOfAuthority
title: SecurityCanon Mode of Authority
short_name: AUTH-MODE
type: model
standard_family: SecurityCanon
repository_context: security-canon
recommended_path: infospace/vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md
status: draft
version: 0.2.0
source_version: "0.1"
source_file: research/260920-mode-of-authority-v0.1.md
canonical_owner: SecurityCanonModeOfAuthority
namespace: sec-authority
classification: vocabulary
abstraction_layer: architecture
primary_cluster: authority
imports:
  - InfoTechCanonCore
  - InfoTechCanonAccessControlModel
  - InfoTechCanonIdentityModel
  - InfoTechCanonOrganizationModel
  - InfoTechCanonPurposesExtension
related:
  - InfoTechCanonCaringAccessGovernanceStandard
  - InfoTechCanonSecurityModel
owned_concepts:
  - AuthMode
  - AuthorityContext
  - AuthorityRealm
  - AuthorityProvenance
  - Activation
  - EvidenceBoundary
  - AccessSituation
decisions:
  - 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](../../../research/260920-mode-of-authority-v0.1.md),
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](../../../docs/adr-001-securitycanon-boundary.md), 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.

```text
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:

```text
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`](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](../../../decisions/decisions.md) and
§9.

## 7. Dimensions

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

```text
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`](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:

```text
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](../../../decisions/decisions.md) and the
> [implications note](../../../docs/260920-actor-subject-implications.md).

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](../../mappings/mode-of-authority-to-infotechcanon.md), 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.**

```text
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:

```text
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:

```text
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](../../../research/260920-mode-of-authority-v0.1.md) §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:

```text
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](../../../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.