Les entreprises déploient progressivement des agents d’intelligence artificielle capables de consulter des documents, d’interroger des bases, de déclencher des workflows ou d’agir dans des applications métiers. Cette autonomie crée un problème concret : un droit d’accès acceptable pour une personne n’est pas nécessairement acceptable pour un agent qui peut enchaîner des centaines d’actions en quelques secondes.
Le 27 juillet 2026, Google a présenté « Beyond Zero », un modèle de sécurité qui prolonge les principes du zero trust jusqu’à l’autorisation de chaque action sur chaque ressource. Ce n’est ni un produit prêt à acheter ni une norme universelle. C’est une proposition d’architecture, issue des travaux internes d’Alphabet, qui mérite l’attention des DSI, RSSI et responsables de plateformes IA.
La question n’est plus seulement : « Cet utilisateur ou cet agent a-t-il le droit d’entrer dans l’application ? » Elle devient : « A-t-il le droit d’effectuer cette action précise, sur cette ressource précise, dans ce contexte précis, à cet instant ? »
Pourquoi le zero trust classique ne suffit plus toujours
Le zero trust a déjà fait évoluer la sécurité d’entreprise : ne plus considérer le réseau interne comme automatiquement fiable, vérifier l’identité, l’état du terminal et le contexte, puis limiter les accès.
Mais de nombreux environnements conservent encore des permissions très larges. Un compte autorisé à utiliser un outil obtient parfois, par commodité, un accès étendu à ses fonctions ou à ses données. Pour un salarié, les limites humaines freinent le volume d’actions. Pour un agent automatisé, cette barrière disparaît.
Un agent qui reçoit un objectif mal formulé, interprète une instruction externe ou rencontre une injection de prompt peut exploiter ses autorisations à une vitesse et à une échelle très supérieures. La sécurité doit donc suivre la granularité et la rapidité de l’automatisation.
Les cinq principes proposés par Google
Google présente cinq axes pour son modèle Beyond Zero.
1. Autoriser une action sur une ressource, pas simplement un outil
L’autorisation doit porter sur l’opération exacte. Lire une fiche client, exporter mille fiches, modifier une adresse ou déclencher un remboursement ne présentent pas le même risque, même si toutes ces actions appartiennent au même CRM.
Pour une entreprise, cela implique de cartographier les opérations réellement sensibles. Un rôle générique « utilisateur du CRM » devient insuffisant lorsqu’un agent peut enchaîner lecture, comparaison, extraction et mise à jour.
2. Combiner règles stables et contrôles dynamiques
Les politiques statiques restent nécessaires : un agent du support ne doit pas accéder à la paie. Mais elles doivent être complétées par des décisions dynamiques lorsque le contexte change.
Une demande inhabituelle, un volume anormal, une ressource très sensible ou un enchaînement d’actions risqué peut exiger une authentification supplémentaire, une validation humaine ou un blocage temporaire.
L’enjeu est d’éviter deux extrêmes : des règles tellement rigides qu’elles paralysent les usages, ou une décision entièrement dynamique impossible à auditer.
3. Enrichir automatiquement le contexte
Une décision d’autorisation devient plus fiable si elle connaît la mission de l’utilisateur, l’objectif de l’agent, le type de donnée, l’action demandée et les protections disponibles.
Cette contextualisation suppose cependant des données de qualité. Si les classifications documentaires sont absentes, les propriétaires de données inconnus ou les finalités mal décrites, le moteur d’autorisation ne peut pas inventer un contexte fiable.
Avant d’acheter une nouvelle couche de sécurité, l’entreprise doit donc vérifier la qualité de son inventaire : identités, ressources, propriétaires, niveaux de sensibilité et journaux d’activité.
4. Déclencher des investigations automatiques
Beyond Zero prévoit que certains signaux puissent lancer immédiatement une investigation automatisée. L’objectif n’est pas d’attendre qu’une équipe de sécurité remarque manuellement une série d’événements dispersés.
Pour être utile, cette automatisation doit produire une preuve exploitable : événement déclencheur, action analysée, données concernées, décision prise et condition de retour à la normale.
Un système qui bloque sans expliquer crée des contournements. Un système qui explique sans pouvoir contenir laisse le risque progresser.
5. Contester ou contenir une action à la demande
Le modèle prévoit des mécanismes de challenge et de confinement. Une action peut être suspendue jusqu’à l’obtention d’un signal supplémentaire : validation du propriétaire de la donnée, confirmation de l’utilisateur, preuve d’intégrité ou réduction du périmètre.
Pour les agents IA, cette capacité est essentielle. L’entreprise doit pouvoir arrêter une séquence en cours, révoquer un jeton, réduire les permissions ou imposer une validation humaine sans désactiver toute la plateforme.
Six questions à poser avant un pilote
Une DSI qui teste un agent connecté à des outils métiers peut utiliser cette grille :
- Quelles actions exactes l’agent peut-il effectuer ?
- Sur quelles ressources et pour quelle finalité ?
- Les droits sont-ils différents entre lecture, export, modification et suppression ?
- Quel contexte déclenche une validation humaine ?
- Comment une action suspecte est-elle contenue en temps réel ?
- Quel journal permet de reconstituer la décision après l’incident ?
Si les réponses se limitent à « l’agent utilise le compte de l’utilisateur », le dispositif est probablement trop grossier.
Ce qu’il faut demander aux fournisseurs
Les éditeurs de plateformes d’agents devront démontrer davantage que la présence d’un contrôle d’accès traditionnel.
Demandez si les autorisations fonctionnent de la même manière dans l’interface, par API et via MCP. Vérifiez si chaque outil exposé à l’agent possède un périmètre minimal. Exigez des journaux qui distinguent l’intention, l’identité humaine, l’identité technique, l’action et la ressource.
Il faut également tester la révocation. Une permission retirée doit cesser de fonctionner immédiatement, y compris pour une session ou un workflow déjà lancé.
Enfin, ne confondez pas contrôle et promesse marketing. Google indique que l’adoption de ce type d’autorisation continue reste encore précoce et annonce d’autres publications techniques. La démarche est intéressante, mais elle doit être évaluée sur des scénarios métiers réels, des preuves d’audit et des tests de confinement.
Une évolution de gouvernance, pas seulement de technologie
Passer d’un accès à l’application à une autorisation par action impose un travail collectif. Les métiers doivent décrire les opérations critiques. Les propriétaires de données doivent fixer les conditions d’usage. La sécurité doit définir les signaux de risque. Les équipes de plateforme doivent rendre ces décisions exécutables et observables.
Le bénéfice potentiel est important : donner aux agents uniquement les capacités nécessaires, au moment nécessaire, avec une possibilité de challenge et d’arrêt. Mais ce bénéfice dépend moins d’un slogan que de la précision des politiques et de la qualité des preuves.
CTA : choisissez un agent pilote et documentez dès aujourd’hui ses six réponses d’autorisation avant de lui ouvrir un nouvel outil métier.
Source principale : Google Security Blog — Going Beyond Zero: A New Paradigm for Enterprise Security, publié le 27 juillet 2026 et vérifié le 30 juillet 2026.
Illustration générée avec Picsart SANA-Sprint pour cet article.
