Approbations et contrôle humain

Cette page décrit le circuit d'approbation de la Navin Platform (l'humain dans la boucle) : qui demande, qui approuve, comment le quorum et l'expiration s'appliquent, comment un run d'agent attend une décision, et chaque règle de quatre yeux trouvée dans le code. Code : services/control-plane/src/eai/domains/approvals, migration sql/postgres/V041.

English version: en/approvals.md

Cycle de vie d'une approbation

État	Signification
pending	En attente de décisions
approved	Le nombre d'approbations atteint le quorum
rejected	Un approbateur a rejeté
expired	expires_at dépassé sans décision finale
cancelled	Annulée par POST /v1/approvals/{approval_id}/cancel

• Demande : POST /v1/approvals (rôles tenant_admin, developer, agent, security_officer, finops) avec l'action, la ressource, une raison, un quorum de 1 à 10, des approver_roles et une durée expires_in_seconds. Durée par défaut : EAI_APPROVAL_TTL_SECONDS (86400 s). Une clé d'idempotence évite les doublons.
• Lecture : GET /v1/approvals, GET /v1/approvals/{approval_id} (membres du tenant).
• Décision : POST /v1/approvals/{approval_id}/decide avec approve ou reject et un commentaire. Rôles admis : les approver_roles de la demande, sinon tenant_admin, security_officer, developer, business_owner.
• Expiration : le job approvals du worker (EAI_WORKER_APPROVAL_EXPIRY_INTERVAL_SECONDS) passe les demandes échues à expired ; une demande lue après son échéance l'est aussi.

Séparation des tâches

Le service eai.domains.approvals.service refuse qu'une même personne demande et approuve :

• le demandeur, l'utilisateur pour le compte duquel agit l'agent (on_behalf_of) et chaque excluded_approvers de la demande ne décident jamais : 403 separation_of_duties, refus audité (approval.decide deny) ;
• un approbateur ne décide qu'une fois : 409 already_decided ; le quorum ne compte que des personnes distinctes ;
• une demande close répond 409 approval_closed ;
• une action qui exige une approbation vérifie son état (require_approved) : 403 approval_required tant qu'elle n'est pas approved.

Approbation d'un run d'agent

1. Le manifeste de l'agent liste ses actions sensibles dans autonomy.human_approval_for (motifs tool:<nom>, agent:<nom>, model:<nom> ou nom seul).
2. Une étape tool_call, subagent, model_call ou act qui correspond, sans approval_id, est enregistrée pending et une approbation run.<type> est ouverte ; un agent peut aussi demander une étape approval avec son propre quorum (run.approval).
3. Le run passe à waiting_approval.
4. À la décision, le run reprend (running, raison approval_granted) ou échoue (failed, raison approval_rejected ou approval_expired).
5. Une étape rejouée avec un approval_id n'est acceptée que si l'approbation est approved pour ce run.

La politique OPA peut aussi imposer une approbation par une obligation approval (authentication-authorization.md), et le SOC peut imposer la réaction REQUIRE_APPROVAL.

Promotions contrôlées

Passer une ressource à approved ou active ouvre une approbation promotion (eai.domains.approvals.promotion). Une fois approuvée, la plateforme vérifie la classification du risque (un système à haut risque exige une évaluation de risque approuvée), lance les suites d'évaluation bloquantes de la cible et n'applique le statut que si tout passe. Les retraits (deprecated, retired, blocked, suspended, restricted) restent immédiats et audités. Une version de modèle passe par POST /v1/models/{model_id}/versions/{version}/approval.

Chemin de changement

Chaque changement d'un prompt, d'un skill, d'un connecteur, d'une règle, d'un modèle, d'une politique, d'un outil, d'un agent ou d'un pack suit les étapes draft, test, security_review, business_approval, staging, production, monitoring (sql/postgres/V192, GET /v1/marketplace/changes, POST /v1/marketplace/changes/{change_id}/advance).

Passage	Condition
security_review vers business_approval	Approbation change.security_review par un responsable sécurité
business_approval vers staging	Approbation change.business_approval par un administrateur du tenant
staging vers production	Tests de fumée de préproduction réussis, puis approbation change.production de deux personnes

L'auteur n'approuve jamais ; chaque transition est gardée dans history et auditée.

Règles des quatre yeux

Circuit	Règle	Code ou route
Accès d'urgence	Deux approbateurs distincts (security_officer ou tenant_admin), jamais le demandeur ni le bénéficiaire	POST /v1/break-glass
Mandat d'agent planifié	Approuvé par une autre personne que le demandeur	POST /v1/mandates
Reprise après kill switch	Deux responsables SOC distincts, différents du demandeur, puis ré-autorisation	POST /v1/soc/recoveries/{recovery_id}/approve
Ordre de confinement	EMERGENCY_LOCKDOWN et SUSPEND_TENANT toujours, ordre manuel au-delà d'un rayon d'impact de 25 : seconde personne	POST /v1/soc/orders/{order_id}/approve
Levée d'une conservation légale d'audit	Deux approbateurs distincts, chacun avec une raison (409 audit_hold_same_approver)	POST /v1/evidence/holds/{hold_id}/release
Exception de risque	L'approbateur nommé n'est pas l'auteur (409 separation_of_duties)	POST /v1/risk/exceptions
Restauration de sauvegarde	Deux approbateurs autres que le demandeur (règle du Navin Manager)	POST /v1/platform-manager/backup/restores/{plan_id}/approve
Exercice de reprise	Approbation dans le Navin Manager, refus de l'auto-approbation	POST /v1/platform-manager/dr/exercises/{exercise_id}/approve
Mise en production d'un changement	Approbation change.production de deux personnes	POST /v1/marketplace/changes/{change_id}/advance

Preuves

• Chaque création, décision, refus, annulation et expiration est un événement d'audit (actions approval.*, envoyées au SIEM par défaut avec EAI_SIEM_FORWARD_ACTIONS).
• Les décisions individuelles sont dans eai.approval_decisions (approbateur, décision, commentaire).
• Les événements d'audit écrits sous un contexte d'identité vérifié portent approvals.approval_ids (identity-context-delegation.md).
• Le contrôle EAI-HUM-01 du catalogue de risque (« Human oversight and approvals for sensitive actions ») a pour source de preuve approvals (risk-compliance.md).