security-canon/research/260920-mode-of-authority-v0.1.md

Mode of Authority Canon

Version: 0.1
Status: Research Draft
Short term: Auth Mode
Concept: Mode of Authority

---

1. Purpose

The Mode of Authority Canon provides a compact vocabulary for reasoning about authority in information systems.

It is intended to improve discussion and design of:

• identity and access management,
• authorization,
• privileged access,
• administration,
• operations,
• software construction and deployment,
• multi-tenant systems,
• federated infrastructures,
• security boundaries,
• emergency access,
• delegation,
• impersonation,
• auditability,
• human, workload and agentic identities.

The canon addresses a question that conventional permission and role models do not answer directly:

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

This relationship is called the actor's Mode of Authority, abbreviated Auth Mode.

---

2. Core Definition

2.1 Mode of Authority

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.

Examples include:

• using a system,
• observing it,
• operating it,
• administering it,
• governing its authority regime,
• constructing future versions of it,
• establishing or recovering its fundamental authority boundary.

An Auth Mode does not itself define individual permissions.

---

3. Distinction from Access Mode

The term access mode is commonly used for operations such as:

• read,
• write,
• execute,
• create,
• delete.

The canon therefore distinguishes:

Access Mode / Access Operation

Describes:

What operation may be performed on a resource?

Examples:

read
write
execute
delete
assign
approve

Mode of Authority / Auth Mode

Describes:

In what relationship to the system is the actor exercising authority?

Examples:

USE
OBSERVE
OPERATE
ADMINISTER
GOVERN
CONSTRUCT
SOVEREIGN

The two dimensions are orthogonal.

For example:

read + USE

may mean reading a customer's document.

Whereas:

read + OBSERVE

may mean reading telemetry about the document service.

---

4. Access Situation

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

Conceptually:

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

Not every implementation needs to materialize every dimension.

The model exists primarily to support precise reasoning.

---

5. Fundamental Principles

A1 — Authority is scope-relative

There is no meaningful authority without a scope.

Examples:

ADMINISTER @ tenant/acme
ADMINISTER @ kubernetes/namespace/foo
SOVEREIGN @ database/postgres
GOVERN @ cloud-organization

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.

For example:

• an auditor may OBSERVE information hidden from ordinary administrators,
• a developer may CONSTRUCT future production behavior while having no production access,
• a governor may constrain administrators without being able to perform their operational tasks.

Therefore:

USE < ADMINISTER < SOVEREIGN

must not be treated as the semantic model.

Auth Modes classify kind of authority, not simply amount of authority.

---

A3 — Auditability is independent of Auth Mode

A mode does not determine whether actions can be audited.

Instead, auditability depends on the Evidence Boundary.

The central question is:

Can the actor being observed also alter, suppress, bypass or invalidate the evidence used to observe that actor?

Examples include:

target-system-audited
independently-audited
substrate-audited
outside-target-audit
can-alter-audit-configuration
can-alter-audit-evidence

Sovereign authority therefore does not necessarily mean unaudited authority.

---

A4 — Federation does not imply authorization

Federation primarily establishes trusted assertions between independent authority realms.

A remote realm may assert:

This actor is Alice.
Alice belongs to group Researcher.

The receiving realm independently decides:

What may Alice do here?

Therefore:

Federation conveys trusted claims. It does not intrinsically convey authorization or sovereignty.

---

A5 — Sovereignty is relative, not absolute

There need not be a universal root or "God account".

Instead there can be independent sovereign authorities such as:

SOVEREIGN @ identity-realm
SOVEREIGN @ database
SOVEREIGN @ cluster
SOVEREIGN @ cloud-account
SOVEREIGN @ platform

A higher or underlying authority may dominate another scope without thereby becoming universally sovereign.

---

6. Canonical Auth Modes

Version 0.1 defines seven fundamental Modes of Authority.

USE
OBSERVE
OPERATE
ADMINISTER
GOVERN
CONSTRUCT
SOVEREIGN

---

7. USE

Intent

Exercise the system for its designated domain purpose.

USE concerns the value the system exists to provide.

Examples:

• sending a message,
• editing a document,
• placing an order,
• executing a business process,
• querying application data,
• consuming an API,
• creating a customer record.

Typical principal types include:

human
application
service
agent

Example:

alice
  USE @ crm/customer-management

USE does not imply low privilege.

A business user may legitimately perform highly consequential actions while still operating entirely in USE mode.

---

8. OBSERVE

Intent

Establish knowledge about the system, its behavior or its state.

OBSERVE is concerned with understanding the system rather than obtaining its ordinary domain value.

Examples:

• reading logs,
• viewing metrics,
• inspecting traces,
• querying health information,
• reading audit records,
• examining security events,
• viewing configuration for diagnostic purposes.

Example:

sre
  OBSERVE @ production/platform

OBSERVE is distinct from ordinary read access.

Compare:

read customer invoice
→ USE

with:

read latency metrics for invoice service
→ OBSERVE

The access operation is read in both cases.

The Auth Mode differs.

---

9. OPERATE

Intent

Maintain or change the operational state of an instantiated system while preserving its intended definition.

Typical actions include:

• start,
• stop,
• restart,
• scale,
• fail over,
• restore,
• trigger backup,
• rotate an operational instance,
• drain a node,
• restart a workload,
• terminate a stuck process.

Example:

ops-agent
  OPERATE @ production/database

OPERATE answers:

How do we keep this system functioning?

It is distinct from ADMINISTER.

For example:

restart database
→ OPERATE

whereas:

change database authentication configuration
→ ADMINISTER

---

10. ADMINISTER

Intent

Configure resources and delegated authority within an established governance regime.

Typical actions include:

• configure resources,
• create users,
• assign roles,
• manage groups,
• create projects,
• change settings,
• provision resources,
• delegate bounded authority.

Example:

tenant-admin
  ADMINISTER @ tenant/acme

ADMINISTER operates inside rules established elsewhere.

An administrator may have broad discretion without being allowed to redefine the constraints governing that discretion.

---

11. GOVERN

Intent

Define the rules under which authority may be exercised.

GOVERN is authority over authority.

Typical concerns include:

• policy ceilings,
• organizational constraints,
• delegation rules,
• security requirements,
• allowed identity providers,
• tenant boundaries,
• trust policy,
• separation-of-duty requirements,
• requirements for privileged activation.

Example:

security-governor
  GOVERN @ organization

A useful distinguishing question is:

Can this actor decide what another administrator is allowed to decide?

If yes, the activity is likely GOVERN rather than ADMINISTER.

Example:

Administrator:
  assign application roles

Governor:
  determine which roles administrators may assign

---

12. CONSTRUCT

Intent

Change definitions or artifacts from which system behavior is produced.

CONSTRUCT covers authority over the possible future system rather than necessarily over its current running instance.

Typical objects include:

• source code,
• infrastructure-as-code,
• build definitions,
• container images,
• database migrations,
• schemas,
• firmware,
• policy-as-code,
• deployment templates,
• release artifacts,
• CI/CD pipelines.

Example:

coding-agent
  CONSTRUCT @ product/payment-service

A principal may have substantial CONSTRUCT authority while having no production runtime authority.

This distinction is particularly important for:

• software supply-chain security,
• CI/CD,
• infrastructure automation,
• agentic software development.

A useful distinction is:

ADMINISTER
    changes the instantiated system

CONSTRUCT
    changes definitions capable of producing systems

---

13. SOVEREIGN

Intent

Establish, recover, replace or bypass the normal authority regime of a scope.

SOVEREIGN authority exists at or beyond the authority boundary being governed.

Typical situations include:

• initial bootstrap,
• establishing trust roots,
• root-account recovery,
• rebuilding the control plane,
• replacing authentication infrastructure,
• restoring authority after catastrophic failure,
• resetting governance mechanisms,
• overriding mechanisms that normally constrain administrators.

Example:

recovery-principal
  SOVEREIGN @ identity-realm

SOVEREIGN does not mean:

all-powerful everywhere

It means:

sovereign relative to a defined scope and authority boundary.

Therefore:

SOVEREIGN @ database

does not necessarily imply:

SOVEREIGN @ host

and:

SOVEREIGN @ tenant

does not imply:

SOVEREIGN @ platform

---

14. Root

root is treated as an implementation-specific manifestation of sovereign or highly privileged authority rather than as a canonical Auth Mode.

Depending on the system:

root

may mean:

• SOVEREIGN,
• ADMINISTER with extremely broad permissions,
• OPERATE + ADMINISTER,
• or authority inherited from an underlying substrate.

Therefore the canon prefers explicit descriptions such as:

SOVEREIGN @ host
SOVEREIGN @ account
ADMINISTER @ cluster

over the ambiguous statement:

has root

---

15. Scope

Every Auth Mode must be interpreted relative to a Scope.

Scopes frequently form hierarchies:

platform
└── organization
    └── tenant
        └── project
            └── resource

But a scope model may also form a graph.

Examples include:

• trust domains,
• federations,
• cross-account relationships,
• shared infrastructure,
• dependency relationships.

A scope describes:

Where does this authority apply?

Examples:

USE @ tenant/acme
ADMINISTER @ namespace/payments
GOVERN @ organization/example
SOVEREIGN @ cluster/prod-1

---

16. Authority Realms

An Authority Realm is a scope possessing an independently meaningful authority boundary.

Examples may include:

• operating system,
• database,
• Kubernetes cluster,
• cloud account,
• cloud organization,
• identity realm,
• SaaS tenant,
• trust domain.

A realm may possess its own:

SOVEREIGN
GOVERN
ADMINISTER
OPERATE
OBSERVE
USE

authorities.

Realms need not share a common sovereign.

---

17. Central Governance

A centrally governed infrastructure commonly resembles:

Platform
└── Organization
    ├── Tenant A
    ├── Tenant B
    └── Tenant C

Authority may propagate downward through governance.

For example:

GOVERN @ platform
GOVERN @ organization
ADMINISTER @ tenant
USE @ application

A central platform may possess cross-scope sovereign capabilities.

This should nevertheless be stated explicitly rather than assumed.

---

18. Federation

Federation connects independently administered authority realms.

Conceptually:

Realm A ──trust──> Realm B
Realm C ──trust──> Realm B

Trust relationships need not be symmetric.

For example:

A trusts B

does not imply:

B trusts A

A federation may have:

GOVERN @ federation

without possessing:

SOVEREIGN @ member-realms

A genuine federation therefore need not contain a global root.

---

19. Actor and Subject

Authority sometimes involves one entity acting on behalf of another.

The canon therefore distinguishes:

Actor

The entity actually performing the action.

Subject

The identity or authority context on whose behalf the action is performed.

Normally:

actor = subject

But not always.

Example:

actor   = support-agent
subject = customer-123

This distinction is important for:

• delegation,
• impersonation,
• automation,
• service accounts,
• agents,
• token exchange.

---

20. Delegation and Impersonation

These are not Auth Modes.

They describe how authority is exercised.

Delegation

The actor retains its identity while exercising delegated authority.

actor   = deployment-agent
subject = release-authority
relation = delegated

Impersonation

The actor acts using another subject's authority context.

actor   = support-agent
subject = customer
relation = impersonated

The underlying Auth Mode may still be:

USE
ADMINISTER
OPERATE

etc.

---

21. Activation

Activation describes when and under what conditions authority becomes exercisable.

Examples include:

STANDING
JUST_IN_TIME
SCHEDULED
APPROVED
INCIDENT
BREAK_GLASS
RECOVERY

Activation is orthogonal to Auth Mode.

Examples:

ADMINISTER
activation=JUST_IN_TIME

OPERATE
activation=INCIDENT

SOVEREIGN
activation=BREAK_GLASS

Therefore break-glass is not an Auth Mode.

---

22. Authority Provenance

Authority Provenance describes where authority originates.

Candidate values include:

LOCAL
PARENT_SCOPE
SUBSTRATE
DELEGATED
FEDERATED
ASSUMED
IMPERSONATED

Example:

alice
  USE @ application/project-x
  provenance=FEDERATED

The application may trust Alice's identity from another realm while making its own authorization decision locally.

---

23. Principal Type

Auth Modes apply independently of principal type.

Candidate principal types include:

HUMAN
WORKLOAD
SERVICE
AGENT
CONTROLLER
DEVICE

Examples:

human
  ADMINISTER @ tenant

service
  USE @ database

agent
  CONSTRUCT @ repository

controller
  OPERATE @ cluster

Principal type therefore must not be encoded into the Auth Mode taxonomy.

---

24. Environment

Authority often differs by environment.

Candidate values include:

DEVELOPMENT
TEST
STAGING
PRODUCTION
RECOVERY

For example:

alice
  SOVEREIGN @ development/environment

does not imply:

alice
  SOVEREIGN @ production/environment

This is especially important for CONSTRUCT authority.

---

25. Evidence Boundary

The Evidence Boundary identifies which system is responsible for observing and preserving evidence of authority use.

An authority may be:

target-audited
external-audited
substrate-audited
multi-party-audited
outside-audit-boundary

Additional questions include:

Can the actor disable logging?

Can the actor modify historical evidence?

Can the actor change the audit destination?

Can the actor compromise the authority observing it?

Audit guarantees must therefore always be interpreted relative to an authority boundary.

---

26. Compact Notation

A minimal notation can use:

MODE @ SCOPE

Examples:

USE @ tenant/acme

OBSERVE @ platform/prod

OPERATE @ cluster/prod-1

ADMINISTER @ tenant/acme

GOVERN @ organization/example

CONSTRUCT @ product/payment-api

SOVEREIGN @ identity-realm

Modifiers can be appended:

alice:
  ADMINISTER @ tenant/acme
  activation=JIT
  duration=2h

Example involving federation:

bob:
  USE @ realm-b/project-x
  identity=realm-a/bob
  provenance=FEDERATED

Example involving impersonation:

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

Example involving emergency recovery:

recovery-principal:
  SOVEREIGN @ identity-realm
  activation=BREAK_GLASS
  evidence=EXTERNAL

---

27. Non-Canonical Candidate Modes

The following concepts should currently not become fundamental Auth Modes:

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

They can currently be represented more precisely through combinations of:

Auth Mode
+ Scope
+ Principal Type
+ Activation
+ Purpose
+ Provenance
+ Operations

Examples:

auditor
→ OBSERVE @ evidence

backup operator
→ OPERATE @ backup-system

developer
→ CONSTRUCT @ product

security administrator
→ ADMINISTER @ security-controls

security policy owner
→ GOVERN @ security-controls

---

28. Canonical Auth Mode Summary

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?

---

29. Design Heuristic

When analyzing an authority situation, ask in order:

1. Who is the actor?

2. On whose behalf 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 labels such as:

user
admin
superadmin
root

alone.

---

30. Research Hypothesis

Version 0.1 proposes that the seven canonical Auth Modes are sufficient to describe most authority relationships found in contemporary information systems:

USE
OBSERVE
OPERATE
ADMINISTER
GOVERN
CONSTRUCT
SOVEREIGN

without requiring platform-specific modes.

The hypothesis should be tested against representative systems including:

• Unix/Linux,
• databases,
• Kubernetes,
• cloud IAM,
• identity platforms,
• secrets management,
• SaaS multi-tenancy,
• software-development platforms,
• CI/CD systems,
• federated identity,
• workload identity,
• agentic systems.

A new canonical Auth Mode should only be introduced if a recurring authority relationship cannot be represented cleanly by:

existing Auth Mode
+ scope
+ operation
+ provenance
+ activation
+ purpose

---

31. Open Research Questions

Version 0.1 deliberately leaves several questions open.

Q1 — Are seven modes sufficient?

The canon must be stress-tested against concrete platforms and pathological authority situations.

Q2 — Is CONSTRUCT always distinct from GOVERN?

Policy-as-code and executable governance mechanisms may blur the distinction.

Q3 — How should substrate authority be represented?

Examples include:

hypervisor over VM
cloud provider over tenant
host root over container
hardware operator over software

Q4 — Can sovereignty itself be decomposed?

Potential distinctions include:

bootstrap sovereignty
recovery sovereignty
cryptographic sovereignty
substrate sovereignty

These may be dimensions rather than modes.

Q5 — How should mutually constraining sovereigns be modeled?

Examples include:

• threshold cryptography,
• multi-party approval,
• HSM governance,
• jointly controlled federations.

Q6 — How should autonomous agents change the model?

An agent may simultaneously possess:

CONSTRUCT
OPERATE
ADMINISTER

authority and may potentially modify mechanisms affecting its own future authority.

Q7 — Can Auth Mode become a machine-readable authorization attribute?

For example:

auth_mode = "operate"
scope = "cluster/prod"
activation = "incident"

could become input to ABAC or policy engines.

---

32. Version 0.1 Position

The Mode of Authority Canon starts from one central observation:

Permissions describe what an actor can do.
Modes of Authority describe what kind of relationship allows the actor to do it.

This distinction provides a semantic layer between architectural intent and concrete authorization mechanisms.

The initial canonical vocabulary is:

USE
OBSERVE
OPERATE
ADMINISTER
GOVERN
CONSTRUCT
SOVEREIGN

All are:

• scope-relative,
• independent of principal type,
• independent of access operation,
• independent of activation mechanism,
• independent of auditability,
• applicable to centralized and federated systems.

This constitutes the Mode of Authority Canon v0.1.