Le pouvoir caché (et les dangers) des agents IA pour coder

En 2024, les agents IA changent la donne pour les devs. Tu décris une fonctionnalité. L'agent scanne ton code, modifie les fichiers, lance les tests et pushe les commits. Tout ça pendant que tu bois ton café. C'est révolutionnaire.

Mais voilà le hic : la plupart des devs ignorent ce qui se passe vraiment sous le capot.

Quand l'agent exécute une commande shell, lit un fichier ou accède à des configs, il opère avec tes droits utilisateur, dans ton filesystem, via tes credentials. Il voit tes clés SSH, tes tokens AWS, tes variables d'environnement. Toi, tu vois juste l'interface chat sympa. Le reste ? Une boîte noire.

Un scénario concret (et flippant)

Imagine : tu demandes à ton agent de refactoriser un module d'auth foireux. Il lit les sources, améliore le code, lance les tests. Mais là, à cause d'une dépendance malveillante, d'une injection de prompt ou d'un raisonnement buggé, il tente de lire ~/.ssh/known_hosts. Puis d'écrire dans ~/.aws/credentials/.

Tu t'en rends compte ? Sûrement pas avant le carnage.

C'est le front de la sécu qu'on discute trop peu. D'où l'urgence d'un monitoring runtime pour les agents IA.

Prempti : Falco appliqué à ton agent de code

La communauté open-source s'active. En greffant des outils de sécu runtime existants – comme le moteur Falco, référence du threat detection – sur les appels d'outils des agents IA, on obtient un truc puissant : visibilité structurée et application de règles au moment où l'agent agit.

Le principe :

Avant tout appel d'outil (lecture fichier, écriture, commande bash, etc.), Prempti l'intercepte. La requête passe par Falco, qui la juge selon tes policies. Falco rend son verdict :

• Allow : l'action passe
• Deny : bloquée, avec explication à l'agent
• Ask : tu valides ou refuses en direct

Pas de modules kernel. Pas de root. Pas de containers. Ça tourne en service user-space léger, intégré au pipeline des tool calls de l'agent.

L'agent ne se fait pas juste bloquer : il reçoit une explication claire. Ça remonte vers toi, pour une sécu transparente.

Deux modes : observer, puis verrouiller

Prempti propose deux modes malins :

Mode monitor : tu observes tout sans bloquer. Lance-le sur quelques sessions, analyse le comportement réel de l'agent, affine tes règles, gagne en confiance.

Mode guardrails (par défaut) : applique les verdicts. Bloque, demande ton avis, ou laisse passer.

Toggle facile :

premptictl mode monitor      # observation pure
premptictl mode guardrails   # verdicts appliqués
premptictl logs              # logs en live

C'est comme ça qu'on fait du bon tooling sécu : observer d'abord, enforcer ensuite.

Écrire des policies : intuitif si tu connais Falco

Si tu as déjà touché aux règles Falco, les policies pour agents te paraîtront familières. Exemple : une règle qui bloque un vecteur d'attaque basique, le pipe direct vers un shell (classique pour les injections de prompt) :

- rule: Deny pipe to shell
  desc: Block piping content to shell interpreters
  condition: >
    tool.name = "Bash"
    and (tool.input_command contains "| sh"
         or tool.input_command contains "| bash"
         or tool.input_command contains "| zsh")
  output: >
    Falco blocked piping to a shell interpreter (%tool.input_command)
  priority: CRITICAL
  source: coding_agent