Authority Permission Binding¶

This document defines how an AI authority level binds to the permission kinds it grants.

It is the rule that keeps technical capability from being read as authority: an AI authority level grants only the permission kinds in its bundle, and consequential permissions are excluded from every default bundle.

The canonical bundle values are defined in accountable-authority-vocabulary. This document defines the binding rule, the exclusion of sensitive permissions, and the conformance requirements that apply when a surface role declares an AI authority level.

Binding rule¶

An ai_authority_level is a named policy bundle over permission-kind.

Each level names the exact set of permission kinds it permits.

REQ.APB.1: A surface role MUST declare exactly one ai_authority_level or one AI authority denial state.

REQ.APB.2: An AI authority level MUST NOT be read to grant any permission kind outside its declared bundle.

REQ.APB.3: A manifest MUST NOT interpret an AI authority level independently of its permission-kind binding.

Default authority levels¶

The following levels are assignable under default policy. None of their bundles contains a sensitive permission.

# ai-authority-level bundles (accountable-authority-vocabulary)
# Each level grants exactly the listed permission-kind values and no others.

[level.none]
status = "stable"
assignable = true
permits = []

[level.advisory]
status = "stable"
assignable = true
permits = ["observe", "propose"]

[level.drafting]
status = "stable"
assignable = true
permits = ["observe", "propose", "draft"]

[level.local_edit]
status = "stable"
assignable = true
permits = ["observe", "propose", "draft", "modify"]

[level.local_command]
status = "stable"
assignable = true
permits = ["observe", "propose", "draft", "modify", "execute"]

[level.network_tool]
status = "stable"
assignable = true
permits = ["observe", "propose", "draft", "modify", "execute", "network"]

[level.authenticated_tool]
status = "stable"
assignable = true
permits = ["observe", "propose", "draft", "modify", "execute", "network", "credential"]

Sensitive permissions¶

The following permission kinds are sensitive. They are excluded from every default AI authority level.

sensitive = [
  "approve",
  "merge",
  "release",
  "publish",
  "deploy",
  "bind",
  "revoke",
  "delegate",
]

REQ.APB.4: A default ai_authority_level MUST NOT grant a sensitive permission.

REQ.APB.5: Granting a sensitive permission to an AI actor requires an explicit per-surface rule that records the human review, reviewer authority, and supporting evidence that approved it.

REQ.APB.6: The revoke permission is further constrained. An AI actor may be granted protective_revoke only under narrow, logged, bounded, reversible, or reviewable safety and recovery rules. authoritative_revoke is denied by default.

Provisional authority levels¶

external_actuator and autonomous_binding are provisional.

They are reserved for future profiles. They reserve names for authority patterns that require separate testbeds before they can become assignable levels.

These levels are not assignable under default policy and do not imply validated authority semantics in v0.

[level.external_actuator]
status = "provisional"
assignable = false
permits = []

[level.autonomous_binding]
status = "provisional"
assignable = false
permits = []

REQ.APB.7: A provisional level MUST NOT be assigned except by an explicit per-surface override that records human review, reviewer authority, and supporting evidence.

REQ.APB.8: A provisional level retains status = "provisional" until it has a validated testbed.

Provisional levels are reserved for future profiles. They are not assignable under default policy and do not imply validated authority semantics in v0.

none and prohibited are different¶

none is the empty authority bundle. It grants no permissions and is the default floor of the assignable authority ladder. A more specific per-surface rule may, subject to review and evidence requirements, elevate a surface above none.

prohibited is not an authority bundle. It is a denial state that bars AI participation on the surface. It cannot be elevated by an override.

REQ.APB.9: A per-surface rule that attempts to grant any AI permission on a prohibited surface is a conformance violation.

REQ.APB.10: The authority manifest .accountability/surfaces.toml MUST declare its own AI authority as prohibited, not none, because none is elevable and prohibited is not.

Multi-role resolution¶

A surface may carry several roles, each with its own declared AI authority level or denial state.

The effective AI authority for a surface is the most restrictive applicable authority across its roles.

When authority levels are defined as permission bundles, tools SHOULD compute the effective authority as the intersection of the applicable role bundles.

REQ.APB.11: If any role on a surface declares prohibited, the effective AI authority for the covered surface scope is prohibited.

REQ.APB.12: A tool MUST preserve which role introduced each authority limit.

REQ.APB.13: A tool MUST NOT collapse multiple role-specific AI authority limits into an untyped surface-level approval.

Permission kinds outside the default ladder¶

audit is a non-sensitive permission kind that no default AI authority level grants.

A surface-specific rule MAY grant audit when the rule explicitly declares:

• the surface and role covered;
• the review required for audit participation;
• the evidence required for audit participation;
• whether audit participation is read-only, report-generating, or evidence-producing.

Granting audit MUST NOT imply permission to approve, merge, release, publish, deploy, bind, revoke, or delegate.

AI participation vs AI authority¶

AI participation is the full allowed involvement spectrum, including observation, suggestion, drafting, review assistance, and tool-mediated action.

AI authority is the subset of participation that permits capability-bearing action against a protected surface.

AI systems may assist review, but may not satisfy human review authority.