# Paliers de risque

> Règle **non négociable**. Conditionne le sursis du cycle "need review".
> Le LLM **ne doit jamais** pouvoir reclasser un asset privilégié en réversible.

## Les deux paliers

### `reversible` — réversible / lecture seule
- Effet nul ou trivialement annulable, pas d'accès aux secrets, pas de mutation
  d'infra.
- **7 jours de sursis PROVISOIRE autorisés** (exécutable pendant la fenêtre).
- Exemples : lister workflows n8n, lire l'état d'un conteneur, lister stacks,
  inspecter (read-only), récupérer des logs.

### `privileged` — privilégié / destructeur
- **Aucun sursis** : l'asset est **BLOQUÉ** jusqu'à review explicite.
- Exemples : déploiement Portainer (stack/conteneur), montage de volume hôte,
  accès à des secrets, suppression, exec dans un conteneur, modification réseau,
  écriture/activation de workflow n8n, toute écriture sur l'infra.

## Classification
- Le palier est **déterminé par la nature de l'opération**, pas déclaré par le LLM.
- En cas de doute → **`privileged`** (fail-safe).
- La classification vit dans le code (table de correspondance outil/opération →
  palier), versionnée et testée. Voir `orchestrator/src/gatekeeper/`.

## Invariant testé (anti-escalade)
- Un asset `privileged` **ne peut jamais** être réécrit en `reversible` par
  l'agent. Tout changement de palier est une opération hors-agent (humain + commit).
- Ceci fait l'objet d'un test dédié (`gatekeeper.test.ts`) : tentative de
  reclassement → rejet.

## Phase 1 (lecture seule)
En Phase 1, **seuls les outils `reversible` (read-only) sont exposés** au LLM.
Les outils mutants/`privileged` ne sont même pas branchés. Le gatekeeper et la
classification sont posés comme interfaces, prêts pour la Phase 2.