ARCANA/GOVERNANCE~/arcana/governance/risk.md
03
RISK CLASSES
Four levels, four intent requirements
Severity decides how much proof a request owes before it may execute. The ladder runs from read-only inspection to actions that can move the outside world.
[ CRITICAL ]git push · deploy · policy modification · external consequential sendExact explicit approval plus all other controls
[ HIGH ]Process execution, deletion, sensitive mutationActive contract criterion and exact capability
[ MODERATE ]Ordinary writes, bounded executionDirect user request or explicit approval, per policy
[ LOW ]Read-only inspectionOptional binding — still subject to workspace & provenance policy
# 03 · Risk Classes > Four levels, four intent requirements. ## Overview Not every action owes the same proof. Reading a file is not pushing to a remote. Every AuthorizationRequest carries a **riskClass**, and that class sets the minimum controls that must be satisfied before the PEP will act. The class is assigned by policy and tool configuration — never chosen by the model. ## The ladder ### CRITICAL — irreversible, externally consequential Examples: `git push`, deploy pipelines, policy modification, sending data to an external service, publishing, rotating credentials. Requirement: **exact explicit approval plus all other controls** — a valid capability, an active intent binding, clean provenance, and a human-approved request hash whose approval is claimed atomically at execution time. ### HIGH — destructive or sensitive mutation Examples: process execution, file deletion, database writes, modifying CI configuration, installing packages. Requirement: **active contract criterion AND exact capability**. The action must be demanded by the current objective, and the agent must hold a grant covering precisely this action/resource pair. ### MODERATE — ordinary writes Examples: creating/editing project files, bounded script execution, local commits. Requirement: direct user request or explicit approval, depending on policy. ### LOW — read-only inspection Examples: reading files, searching code, listing directories, analysis. Requirement: optional intent binding — but still fully subject to workspace containment and provenance policy. LOW is *less* proof, never *less* containment. ## Design rules 1. **The model cannot downgrade its own risk class.** Reframing a deletion as "cleanup" changes nothing; the class comes from policy. 2. **Classes compose with approvals.** CRITICAL actions require approval even when every other control passes. 3. **Unknown risk fails closed.** A tool without an assigned class is treated as HIGH until policy says otherwise. ## Related - Previous: [PDP ⇄ PEP Split](/governance/pdp-pep.md) - Next: [Intent–Action Binding](/governance/intent.md)