La plupart des discussions sur les accès privilégiés imaginent encore une personne : un administrateur qui se connecte, effectue l'action à risque, puis se déconnecte. De plus en plus souvent, c'est un service qui effectue cette action à risque — un robot de déploiement, un exécuteur de compilation, un agent d'IA exécutant du code généré — et il ne se déconnecte jamais de lui-même.
La solution n'est pas un mot de passe plus robuste sur ce compte de service. C'est l'élimination complète du privilège permanent. Dans l'une de nos propres réalisations, du code non fiable devait s'exécuter dans un bac à sable avec accès réseau — mais « l'accès réseau » est justement la capacité qui transforme un bogue en voie d'exfiltration. La réponse a été une politique de sortie refusée par défaut : rien ne quitte le bac à sable à moins qu'une règle ne l'autorise explicitement, et la liste des règles reste volontairement courte.
La partie inconfortable de ce travail n'est généralement pas la conception, c'est le déploiement : une politique de refus par défaut brisera quelque chose dès le premier jour, parce qu'un appel légitime reposait discrètement sur la porte ouverte. Il faut traiter cela comme le constat d'audit qu'il est réellement, autoriser le chemin précis, puis avancer. L'alternative — laisser la porte ouverte parce que la fermer pourrait tout casser — est précisément la façon dont le privilège permanent s'accumule au départ.
Le moindre privilège n'est pas un document de politique. C'est tout ce qu'un identifiant peut encore faire à 3 h du matin, quand personne ne surveille.