The Decision in One Sentence

Give an AI agent autonomy only for actions whose scope is clear, downside is bounded, results are observable and verifiable, and mistakes can be contained or recovered; keep human approval at the point where those conditions stop being true.

The Decision to Make

The question is not whether to use AI agents. It is narrower and more operational: for a specific workflow, which actions may the agent take without asking a human first?

The same agent might safely read a document, draft a response and update a reversible internal record, yet still require approval before sending an external message, changing access rights, deleting data, deploying to production or spending money.

This is therefore a permission-design decision, not a referendum on AI capability.

Why This Decision Matters

Agents create value by reducing handoffs and completing work, but the same ability to act creates a new failure surface. OpenAI’s current app-permission model explicitly distinguishes read actions, low-risk actions and broader write actions, and notes that actions such as sending messages, editing or deleting records, changing access settings, making purchases or sharing sensitive information may need additional review.

Anthropic reports a different but related problem: repeated approval prompts create approval fatigue. In its Claude Code work, the company says users approved 93% of permission prompts, which motivated a system that automates some low-risk permission decisions. But Anthropic’s own evaluation still found a 17% false-negative rate on a small set of real “overeager” dangerous actions and explicitly says the feature is not a substitute for careful human review on high-stakes infrastructure.

The decision problem is therefore not “human approval or no human approval.” It is how to put human judgment where it changes risk, while removing approvals that add friction without adding meaningful control.

Explain It Simply

Imagine a teenager helping in a family shop. At first, you let them count stock and write a shopping list. If they make a mistake, nothing has left the shop and you can correct it easily.

Later, you may let them reorder inexpensive items from an approved supplier within a fixed budget. But you would probably still want them to ask before transferring all the shop’s money, firing an employee or signing a long contract.

The teenager did not suddenly become less intelligent when the action became serious. The consequence changed.

AI agents should be treated the same way: more freedom where the damage is limited and recoverable; more human control where the consequences are large, unclear or difficult to reverse.

Evidence Map

• Observed / permissions: OpenAI documents permission modes ranging from always asking, to read-only access, to automatic approval of low-risk actions; it separately flags actions with external, sensitive or hard-to-reverse effects for additional review.
• Observed / approval fatigue: Anthropic reports that Claude Code users approved 93% of permission prompts, motivating an automated approval layer intended to reduce routine friction.
• Observed / residual risk: Anthropic’s March 2026 auto-mode evaluation reported a 17% false-negative rate on 52 real overeager actions after the full classifier pipeline. The company states that this mode is not a drop-in replacement for careful human review on high-stakes infrastructure.
• Observed / threat model: Anthropic identifies overeager behavior, honest mistakes and prompt injection as distinct ways an agent can take harmful actions even when it is trying to complete the user’s task.
• Observed / standards direction: NIST’s 2026 work on agent identity and authorization focuses on identification, authorization, auditing, non-repudiation and controls for prompt injection. NIST’s RFI analysis also found broad agreement among respondents that agent security requires adapting established cybersecurity practices.
• Observed / control architecture: OWASP’s Agent Control Standard argues that agents should be inspectable, traceable and instrumentable, with runtime controls over what they can access and do.
• Inference: the useful permission boundary is action-specific and consequence-specific, not model-specific.
• Uncertain: there is no universal public threshold that tells every organization when a workflow is safe enough for autonomous action; acceptable risk depends on the action, environment, assets, legal obligations and recovery capability.

The Real Options

1. Observe only. The agent may read, search, classify and analyze, but cannot change external state.
2. Recommend. The agent proposes the next action, but a human performs it.
3. Prepare and wait. The agent drafts the email, fills the form, stages the change or prepares the transaction; a human approves execution.
4. Act within bounded authority. The agent may execute predefined low-impact or reversible actions within explicit limits.
5. Act autonomously with exception escalation. The agent completes the workflow unless a boundary, anomaly or uncertainty condition triggers human review.

The mistake is to jump from option 1 directly to option 5 because the model “seems capable.” The useful path is progressive delegation backed by evidence.

Decision Criteria

For each action, evaluate six questions.

1. Consequence: if the action is wrong, who or what is affected?
2. Authorization clarity: is the user’s intent specific enough to cover this exact action and target?
3. Reversibility: can the action be undone without major cost or secondary damage?
4. Observability: will we know what the agent did, when, with which inputs and permissions?
5. Verification: can success be checked independently rather than assumed from the agent’s own narrative?
6. Recovery: if the action fails halfway, is there a tested path to contain, retry, roll back or escalate?

An action with low consequence, narrow scope and strong rollback can support more autonomy than an action with ambiguous authorization and irreversible external effects, even if both use the same model.

The Trade-offs

More approvals can reduce unreviewed harmful actions, but they also add delay, attention cost and approval fatigue. Fewer approvals improve flow, but they transfer more trust to software controls and expose the organization to mistakes that may not be noticed in time.

Broad permissions make an agent more versatile, but increase blast radius. Narrow permissions constrain damage, but may create more handoffs and configuration work.

Automatic classifiers and policy engines can replace some routine human checks, but they introduce their own false positives and false negatives. The right comparison is therefore not “human versus AI.” It is the full cost and residual risk of each control architecture.

Minimum Proof Before More Autonomy

Do not promote a workflow to the next autonomy level because a demo worked once. Require evidence from the actual workflow.

• The task boundary is explicit and testable.
• The agent uses the minimum permissions required.
• Normal and adversarial cases have been exercised in a safe environment.
• Actions are logged with enough context to reconstruct what happened.
• Success is verified by an external check, rule, system state or human sample — not only by the agent saying it succeeded.
• Rollback or containment has been tested, not merely documented.
• Exception conditions are defined and actually route to a human.
• Observed error and recovery patterns remain within a pre-agreed tolerance appropriate to the workflow.

The exact threshold is context-specific. The discipline is not.

Sidy’s Synthesis — The Earned Autonomy Ladder

My synthesis is that autonomy should be treated as something a workflow earns through evidence, not something a model receives because it is powerful.

Observe → Recommend → Prepare → Act with approval → Act within bounds → Act autonomously with exception escalation

Each rung transfers more execution authority from the human to the system. The promotion rule is simple: move up only when the current rung produces enough evidence that the next rung’s additional risk is understood, bounded and recoverable.

The deeper point is that autonomy belongs to the workflow, not to the model. The same model may deserve high autonomy in one narrow, reversible process and almost none in another process involving money, public communication, shared infrastructure or irreversible commitments.

Autonomy should be earned by evidence, not granted by capability.

The Decision Rule

Use autonomous execution when scope is explicit, permissions are narrow, consequences are bounded, outputs are independently verifiable, and failure is reversible or recoverable.

Use human approval when the target is ambiguous, the action creates external commitments, the blast radius is large, rights are broad, sensitive data may move, or reversal is costly.

Use human execution when the action is both high-impact and difficult to verify or recover, unless a stronger control architecture has been demonstrated in that exact environment.

This is not a permanent classification. Evidence, tooling, controls and consequences change; the decision should be reopened when they do.

What Would Change the Decision?

• A new model, harness or tool changes the observed failure profile.
• The agent receives broader permissions or access to more sensitive systems.
• The workflow moves from a sandbox to shared or production infrastructure.
• The action becomes harder to reverse or begins affecting customers, employees, money or public commitments.
• Monitoring, verification or rollback becomes materially stronger.
• Error, exception or recovery data show that the present autonomy level is either too risky or unnecessarily restrictive.
• A security incident, prompt-injection path or trust-boundary change alters the threat model.

Build From This

• Action Registry: list every agent action and classify its consequence, reversibility and target system.
• Permission Envelope: define the minimum data, tools, accounts and write rights required for each workflow.
• Human Gate Matrix: specify which action classes always require approval and which may be auto-approved under conditions.
• Evidence Contract: define what proof must accompany a completed action before the workflow can close.
• Autonomy Promotion Review: periodically decide whether a workflow has earned the next rung of the ladder.
• Exception Escalator: route ambiguity, repeated denial, abnormal state or recovery failure to a named human owner.
• Rollback Drill: test that critical agent actions can actually be undone or contained.

Remember This

1. Agent autonomy is a workflow property, not a model property.
2. Approval fatigue is real; more prompts do not automatically mean more safety.
3. Irreversible, ambiguous and externally consequential actions deserve stronger human gates.
4. Verification and recovery matter as much as permission.
5. Autonomy should expand through accumulated evidence, not confidence or novelty.

La décision en une phrase

On peut laisser un agent IA agir sans validation préalable lorsque le périmètre est clair, les conséquences restent bornées, les résultats sont observables et vérifiables, et les erreurs peuvent être contenues ou corrigées ; la validation humaine doit revenir dès que l’une de ces conditions cesse d’être satisfaite.

La décision à prendre

La question n’est pas de savoir s’il faut ou non utiliser des agents IA. Elle est plus précise : dans un processus donné, quelles actions l’agent peut-il exécuter sans demander d’abord l’accord d’un humain ?

Un même agent peut très bien lire un document, préparer une réponse ou mettre à jour un enregistrement interne réversible, tout en devant demander une validation avant d’envoyer un message externe, de modifier des droits d’accès, de supprimer des données, de déployer en production ou d’engager une dépense.

Il s’agit donc d’une décision de conception des permissions, pas d’un vote pour ou contre les capacités de l’IA.

Pourquoi cette décision compte

Les agents créent de la valeur lorsqu’ils réduisent les passages de relais et mènent réellement une tâche à son terme. Mais cette capacité d’action ouvre aussi une nouvelle surface d’échec. Le système actuel de permissions des applications d’OpenAI distingue explicitement la lecture, les actions à faible risque et des actions plus larges d’écriture ; il signale notamment que l’envoi de messages, la modification ou la suppression d’enregistrements, les changements de droits, les achats ou le partage d’informations sensibles peuvent nécessiter un contrôle supplémentaire.

Anthropic met en lumière un autre problème : lorsque les demandes de validation deviennent trop nombreuses, l’attention humaine se dégrade. Dans ses travaux sur Claude Code, l’entreprise indique que 93 % des demandes de permission étaient acceptées, ce qui l’a conduite à automatiser certaines décisions jugées peu risquées. Mais sa propre évaluation fait encore apparaître 17 % de faux négatifs sur un petit ensemble d’actions réelles dangereuses et « trop zélées » ; Anthropic précise d’ailleurs que ce mécanisme ne remplace pas une revue humaine attentive sur les infrastructures à fort enjeu.

La vraie décision n’oppose donc pas « validation humaine » et « absence de validation ». Elle consiste à placer le jugement humain là où il change réellement le niveau de risque, tout en supprimant les validations qui créent de la friction sans créer de contrôle utile.

L’expliquer simplement

Imaginez un adolescent qui aide dans la boutique familiale. Au début, on peut le laisser compter le stock et préparer une liste d’achats. S’il se trompe, rien n’a encore quitté la boutique et l’erreur se corrige facilement.

Avec l’expérience, on peut l’autoriser à recommander des produits peu coûteux auprès d’un fournisseur déjà approuvé, dans une limite budgétaire précise. Mais on lui demandera probablement encore de consulter un adulte avant de transférer toute la trésorerie, de licencier quelqu’un ou de signer un contrat de longue durée.

L’adolescent n’est pas devenu moins intelligent au moment où l’action devient sérieuse. Ce sont les conséquences qui ont changé.

Un agent IA doit être traité de la même manière : davantage de liberté lorsque les dommages possibles sont limités et réparables ; davantage de contrôle humain lorsque les conséquences sont importantes, ambiguës ou difficiles à annuler.

Carte des preuves

• Observé / permissions : OpenAI documente plusieurs niveaux allant de la demande systématique de validation à la lecture sans confirmation, puis à l’autorisation automatique de certaines actions à faible risque ; les actions ayant des effets externes, sensibles ou difficiles à annuler font l’objet d’un contrôle distinct.
• Observé / fatigue de validation : Anthropic indique que les utilisateurs de Claude Code acceptaient 93 % des demandes de permission, ce qui a motivé la création d’une couche d’approbation automatisée pour réduire les interruptions routinières.
• Observé / risque résiduel : dans son évaluation de mars 2026, Anthropic rapporte un taux de faux négatifs de 17 % sur 52 actions réelles jugées « trop zélées » après passage dans l’ensemble du mécanisme de classification. L’entreprise précise que ce mode ne remplace pas une revue humaine rigoureuse dans les environnements à fort enjeu.
• Observé / modèle de menace : Anthropic distingue notamment le zèle excessif, les erreurs honnêtes et les injections de prompt comme des causes différentes pouvant conduire un agent à une action dangereuse alors même qu’il cherche à atteindre l’objectif demandé.
• Observé / orientation des standards : les travaux 2026 du NIST sur l’identité et l’autorisation des agents portent sur l’identification, l’autorisation, l’audit, la non-répudiation et les contrôles contre l’injection de prompt. L’analyse par le NIST de sa consultation publique fait également ressortir un large accord sur la nécessité d’adapter les pratiques classiques de cybersécurité aux agents.
• Observé / architecture de contrôle : l’Agent Control Standard de l’OWASP défend des agents inspectables, traçables et instrumentables, avec des contrôles d’exécution sur ce qu’ils peuvent consulter et modifier.
• Interprétation : la bonne frontière de permission dépend de l’action et de ses conséquences, pas seulement du modèle utilisé.
• Incertitude : aucun seuil public universel ne permet de dire qu’un processus est « assez sûr » pour une autonomie complète ; le niveau acceptable dépend de l’action, de l’environnement, des actifs concernés, des obligations applicables et de la capacité de reprise.

Les vraies options

1. Observer seulement. L’agent peut lire, rechercher, classer et analyser, sans modifier l’état d’un système externe.
2. Recommander. L’agent propose l’action suivante, mais c’est l’humain qui l’exécute.
3. Préparer puis attendre. L’agent rédige le message, remplit le formulaire, prépare la modification ou la transaction ; l’exécution reste soumise à validation.
4. Agir dans un mandat borné. L’agent peut exécuter des actions prédéfinies, à faible impact ou réversibles, dans des limites explicites.
5. Agir de façon autonome avec escalade des exceptions. L’agent mène le processus jusqu’au bout, sauf lorsqu’une limite, une anomalie ou une incertitude déclenche une revue humaine.

L’erreur consiste à passer directement de la première option à la cinquième parce que le modèle « paraît capable ». La bonne trajectoire est une délégation progressive, soutenue par des preuves.

Critères de décision

Pour chaque action, six questions doivent être examinées.

1. Conséquence : si l’action est mauvaise, qui ou quoi en subit les effets ?
2. Clarté de l’autorisation : l’intention de l’utilisateur couvre-t-elle précisément cette action et cette cible ?
3. Réversibilité : peut-on annuler l’action sans coût majeur ni dommage secondaire ?
4. Observabilité : saura-t-on ce que l’agent a fait, quand, avec quelles données et quels droits ?
5. Vérification : peut-on contrôler le résultat indépendamment du récit produit par l’agent lui-même ?
6. Reprise : si l’action échoue à mi-chemin, existe-t-il une procédure testée pour contenir, recommencer, annuler ou escalader ?

Une action à faible conséquence, au périmètre étroit et facilement réversible peut supporter davantage d’autonomie qu’une action autorisée de façon ambiguë et produisant des effets externes irréversibles — même si le modèle utilisé est identique.

Les arbitrages

Multiplier les validations peut réduire le nombre d’actions dommageables non relues, mais augmente les délais, le coût d’attention et la fatigue de validation. Réduire les validations fluidifie l’exécution, mais transfère davantage de confiance vers les contrôles logiciels et augmente le risque qu’une erreur ne soit détectée qu’après coup.

Des permissions larges rendent l’agent plus polyvalent, mais agrandissent le rayon d’impact. Des permissions étroites limitent les dégâts possibles, au prix de davantage de configuration et parfois de passages de relais.

Les classificateurs et moteurs de politiques automatiques peuvent remplacer une partie des contrôles humains routiniers, mais ils introduisent leurs propres faux positifs et faux négatifs. La bonne comparaison n’oppose donc pas « humain » et « IA » : elle porte sur le coût total et le risque résiduel de chaque architecture de contrôle.

La preuve minimale avant d’élargir l’autonomie

Un processus ne doit pas passer au niveau d’autonomie supérieur simplement parce qu’une démonstration a fonctionné une fois. Il faut des preuves issues du processus réel.

• Le périmètre de la tâche est explicite et testable.
• L’agent ne possède que les droits strictement nécessaires.
• Les cas normaux et les cas adverses ont été testés dans un environnement sûr.
• Les actions sont journalisées avec assez de contexte pour reconstruire ce qui s’est passé.
• Le succès est vérifié par un contrôle externe, une règle, l’état réel du système ou un échantillonnage humain — pas seulement par l’affirmation de l’agent.
• La procédure d’annulation ou de confinement a été testée, pas seulement écrite.
• Les conditions d’exception sont définies et déclenchent réellement une escalade vers un humain.
• Les erreurs observées et les reprises restent dans une tolérance fixée à l’avance et adaptée au processus.

Le seuil précis dépend du contexte. La discipline, elle, reste la même.

Synthèse de Sidy — L’échelle d’autonomie acquise

Ma synthèse est la suivante : l’autonomie doit être considérée comme quelque chose qu’un processus acquiert par la preuve, et non comme un droit accordé à un modèle parce qu’il est puissant.

Observer → Recommander → Préparer → Agir avec validation → Agir dans un périmètre borné → Agir de façon autonome avec escalade des exceptions

Chaque niveau transfère une part supplémentaire de l’autorité d’exécution de l’humain vers le système. La règle de progression est simple : on ne monte d’un niveau que lorsque le niveau actuel a produit suffisamment de preuves pour que le risque supplémentaire soit compris, borné et récupérable.

Le point le plus important est que l’autonomie appartient au processus, pas au modèle. Un même modèle peut mériter beaucoup d’autonomie dans une tâche étroite et réversible, et presque aucune dans un processus qui engage de l’argent, une communication publique, une infrastructure partagée ou un engagement difficile à annuler.

L’autonomie se mérite par la preuve ; elle ne se déduit pas de la capacité technique.

La règle de décision

Autoriser l’exécution autonome lorsque le périmètre est explicite, les droits sont étroits, les conséquences restent limitées, les résultats sont vérifiables indépendamment et les erreurs sont réversibles ou récupérables.

Maintenir une validation humaine lorsque la cible est ambiguë, que l’action crée un engagement externe, que le rayon d’impact est important, que les droits sont larges, que des données sensibles peuvent circuler ou que l’annulation serait coûteuse.

Conserver l’exécution humaine lorsque l’action est à la fois fortement engageante et difficile à vérifier ou à réparer, sauf si une architecture de contrôle plus robuste a déjà fait ses preuves dans cet environnement précis.

Cette classification n’est jamais définitive. Les preuves, les outils, les contrôles et les conséquences évoluent ; la décision doit être rouverte lorsqu’ils changent.

Qu’est-ce qui ferait changer la décision ?

• Un nouveau modèle, harnais d’exécution ou outil modifie le profil réel des erreurs.
• L’agent reçoit des droits plus larges ou l’accès à des systèmes plus sensibles.
• Le processus quitte un environnement isolé pour une infrastructure partagée ou de production.
• L’action devient plus difficile à annuler ou commence à engager des clients, des salariés, de l’argent ou une communication publique.
• La supervision, la vérification ou les mécanismes de retour arrière s’améliorent fortement.
• Les données d’erreur, d’exception ou de reprise montrent que le niveau d’autonomie actuel est soit trop risqué, soit inutilement restrictif.
• Un incident de sécurité, une nouvelle voie d’injection de prompt ou une modification des frontières de confiance change le modèle de menace.

Ce qu’on peut bâtir à partir de là

• Registre des actions : recenser chaque action possible de l’agent et qualifier ses conséquences, sa réversibilité et le système touché.
• Enveloppe de permissions : définir le minimum de données, d’outils, de comptes et de droits d’écriture nécessaires pour chaque processus.
• Matrice des validations humaines : préciser les classes d’actions qui exigent toujours une validation et celles qui peuvent être autorisées automatiquement sous conditions.
• Contrat de preuve : définir les éléments qui doivent accompagner une action terminée avant de considérer le processus comme clos.
• Revue de progression d’autonomie : réexaminer périodiquement si un processus a réellement mérité le niveau supérieur de l’échelle.
• Escalade des exceptions : envoyer l’ambiguïté, les refus répétés, les états anormaux ou les échecs de reprise vers un responsable humain clairement identifié.
• Exercice de retour arrière : tester concrètement que les actions critiques peuvent être annulées ou contenues.

À retenir

1. L’autonomie d’un agent est une propriété du processus, pas du modèle.
2. La fatigue de validation existe ; multiplier les demandes d’accord ne crée pas automatiquement plus de sécurité.
3. Les actions irréversibles, ambiguës ou fortement engageantes à l’extérieur méritent des garde-fous humains plus stricts.
4. La vérification et la capacité de reprise comptent autant que la permission initiale.
5. L’autonomie doit progresser grâce aux preuves accumulées, pas grâce à l’impression de confiance ou à l’effet de nouveauté.