Espace dédié · Sécurité Agentic
Sécuriser des agents qui agissent
Un agent qui appelle des outils, lit des données et parle à d'autres services est une surface d'attaque mouvante. On y traite l'identité forte des workloads, le zero-trust entre agents, la rotation des secrets et la défense en profondeur — code à l'appui.
Autorisation : décider ce qu'un agent a le droit de faire
Les volets 1 et 2 ont prouvé qui est un agent et pour le compte de qui il agit. Reste la décision : a-t-il le droit ? On externalise la politique du code (séparation PEP/PDP, NIST 800-207), on l'écrit comme du code testable avec OPA & Rego, on l'applique sur le jeton de délégation du volet 2, et on impose le moindre privilège du chemin (atténuation), les obligations et le human-in-the-loop — avec un graphe LangGraph et du code de bout en bout, pas à pas.
On-behalf-of : déléguer l'identité dans une chaîne d'agents
Le volet 1 a prouvé qui est un agent. Reste une question que l'identité de workload ne tranche pas : pour le compte de qui agit-il ? Dans une chaîne superviseur → chercheur → outil, l'intention de l'utilisateur d'origine se perd à chaque saut. On la fait voyager : délégation vs usurpation, jeton porteur de la chaîne d'acteurs (claim act), token exchange (RFC 8693) ré-émis à chaque hop et ancré sur le SVID — avec un graphe LangGraph, py-jwt et du code de bout en bout.
Identité de workload : SPIFFE & SPIRE pour des agents zero-trust
Vos agents et vos services s'authentifient encore avec des clés d'API partagées ? On remplace ces secrets statiques par une identité cryptographique forte, à courte durée de vie et sans secret de bootstrap. Modèle SPIFFE (SPIFFE ID, SVID, trust domain), implémentation SPIRE (attestation de nœud et de workload), puis mTLS et JWT-SVID entre agents — avec py-spiffe, configs et CLI.