Que fait Sécurité Zero-Trust Agentique ?
Architecture de sécurité cryptographique pour les systèmes d'agents IA autonomes. Cette compétence couvre l'intersection de l'ingénierie de sécurité traditionnelle et des défis uniques des agents qui planifient, persistent, délèguent et exécutent des tâches à travers les frontières de confiance.
Principe fondamental : Ne jamais faire confiance, toujours vérifier — appliqué à chaque message agent-à-agent, chaque compétence chargée, chaque outil invoqué et chaque résultat retourné.
Points de Décision
1. Niveau de Menace → Stratégie de Vérification
Évaluation du Niveau de Menace :
├── PUBLIC (agents internet, compétences inconnues)
│ ├── Actions : mTLS complet + JWS + jetons de capacité + sandbox WASM
│ ├── Audit : Chaque action enregistrée avec preuve Merkle
│ └── TTL : Durée de vie max de 5 min pour les capacités
├── INTERNE (cluster d'agents de confiance)
│ ├── Actions : mTLS + JWS + capacités (TTL plus long)
│ ├── Audit : Journalisation agrégée avec publication quotidienne de la racine
│ └── TTL : Durée de vie max de 1 h pour les capacités
└── DEV/TEST (localhost, développement)
├── Actions : mTLS optionnel + capacités de base
├── Audit : Journaux de fichiers locaux (pas d'arbre de Merkle)
└── TTL : Durée de vie max de 24 h pour les capacités
2. Requête d'Agent → Vérification de Capacité → Logique d'Octroi/Refus
Traitement d'une Requête d'Agent Entrante :
├── 1. Vérifier la chaîne de certificats mTLS
│ ├── Signature CA valide ? → Continuer
│ └── Invalide/expirée ? → REJETER immédiatement
├── 2. Analyser l'enveloppe du message JWS
│ ├── Signature valide + non expirée ? → Continuer
│ ├── Rejeu détecté (cache jti) ? → REJETER
│ └── Signature invalide ? → REJETER + enregistrer l'événement de sécurité
├── 3. Vérifier les capacités requises
│ ├── L'agent détient exactement la capacité ? → ACCORDER
│ ├── L'agent détient une capacité plus large ? → ATTÉNUER + ACCORDER
│ ├── Capacité expirée ? → REJETER + forcer le renouvellement
│ └── Aucune capacité correspondante ? → REJETER + suggérer un octroi minimal
└── 4. Exécuter avec les contraintes du sandbox
├── Compétences WASM : Limites CPU/mémoire appliquées
├── Opérations sur fichiers : Validation du chemin par rapport aux capacités
└── Appels réseau : Validation de la destination par rapport aux capacités
3. Chaîne de Délégation → Décision de Profondeur de Confiance
Demande de Délégation de Capacité :
├── Capacité parente délégable=true ?
│ ├── Oui → Vérifier la profondeur restante
│ │ ├── Profondeur > 0 → Autoriser avec profondeur-1
│ │ └── Profondeur = 0 → REJETER (délégation maximale atteinte)
│ └── Non → REJETER (non délégable)
├── Actions demandées ⊆ actions parentes ?
│ ├── Oui → Autoriser le sous-ensemble
│ └── Non → REJETER (impossible d'augmenter les privilèges)
└── Frontière de confiance franchie ?
├── Même domaine d'orchestrateur → Autoriser
└── Domaine différent → Nécessiter capacité explicite inter-domaines
Modes de Défaillance
1. Fuite d'Autorité Ambiante
Détection : grep -r "process.env" agent_code/ montre un accès aux variables d'environnement sans vérification de capacité
Symptôme : L'agent accède à des ressources pour lesquelles il ne devrait pas avoir d'autorisations
Correctif : Remplacer par des jetons de capacité explicites limités aux ressources exactes nécessaires
2. Attaque par Rejeu de Message
Détection : Plusieurs entrées de journal d'audit avec un jti (ID de message) identique ou des horodatages dans la fenêtre de rejeu
Symptôme : L'agent reçoit et traite la même commande plusieurs fois
Correctif : Implémenter un cache de déduplication jti avec un TTL correspondant à l'expiration du message
3. Escalade de Capacité par Délégation
Détection : La capacité fille a plus d'actions que la capacité parente, ou la profondeur de délégation dépasse le maximum configuré Symptôme : Les sous-agents obtiennent plus de privilèges que prévu par leur délégateur parent Correctif : Appliquer l'invariant d'atténuation : capacités filles ⊆ capacités parentes au moment de la délégation
4. Évasion de Sandbox par Épuisement des Ressources
Détection : Utilisation CPU de l'agent >95 % pendant >30 secondes, ou utilisation mémoire approchant les limites du sandbox Symptôme : L'agent tente des boucles infinies ou une allocation mémoire excessive pour sortir des contraintes Correctif : Tuer brutalement le processus de l'agent aux limites de ressources, implémenter une métrologie d'exécution basée sur le carburant
5. Acceptation de Certificat TOFU
Détection : L'agent accepte un certificat sans vérification CA lors de la première connexion Symptôme : Les attaques de type homme-du-milieu réussissent en présentant un certificat quelconque Correctif : Pré-positionner tous les certificats d'agent, maintenir un magasin de confiance explicite, rejeter les CA inconnues
Exemples Concrets
Exemple 1 : Pipeline de Signature de Messages Multi-Agents
Scénario : L'agent de recherche doit transmettre une analyse à l'agent de génération de code, puis à l'agent de révision.
Phase de Configuration :
// L'orchestrateur émet des capacités
const researchCap = mint.mint('fs:/tmp/research/**', ['read','write'], 'agent-research-001');
const codegenCap = mint.mint('fs:/workspace/src/**', ['read','write'], 'agent-codegen-001');
const reviewCap = mint.mint('fs:/workspace/**', ['read'], 'agent-review-001');
Flux de Messages :
-
Research → Codegen : L'agent de recherche crée un message signé JWS :
Header : {alg: 'EdDSA', kid: 'agent-research-001/v1'} Payload : { iss: 'agent-research-001', sub: 'agent-codegen-001', dag_id: 'proj-alpha-v1', action: 'task', body: {analysis: "API needs OAuth2 flow", output_path: "/tmp/research/api_analysis.json"} } -
Vérification par Codegen : L'agent Codegen reçoit le message :
- Vérifie la signature JWS par rapport à la clé publique de l'agent de recherche
- Vérifie le TTL du message (non expiré)
- Valide que le jti n'est pas dans le cache de rejeu
- Confirme que le dag_id correspond au contexte d'exécution actuel
- Détection experte : Vérifie que l'agent de recherche avait la capacité pour le output_path
-
Codegen → Review : Codegen crée un résultat signé :
{ "iss": "agent-codegen-001", "sub": "agent-review-001", "action": "result", "body": {"generated_files": ["/workspace/src/auth.ts"], "confidence": 0.87} }
Erreur novice : Ignorerait la protection anti-rejeu jti, permettant un traitement en double. Aperçu expert : La piste d'audit montre une chaîne de messages complète avec une preuve cryptographique de possession.
Exemple 2 : Émission d'un Jeton de Capacité avec Atténuation
Scénario : L'agent principal doit déléguer l'analyse de fichiers à un sous-agent spécialisé, mais restreindre l'accès aux répertoires sensibles.
Octroi Initial :
// L'orchestrateur accorde un accès large au système de fichiers
const mainCap = mint.mint('fs:/project/**', ['read','write','execute'], 'agent-main', {
delegatable: true,
maxDepth: 2,
ttlSeconds: 3600
});
Arbre de Décision d'Atténuation :
L'agent principal évalue la demande de délégation :
├── Le sous-agent demande : fs:/project/src/** [read]
│ ├── /project/src/** ⊂ /project/** ? OUI
│ ├── [read] ⊂ [read,write,execute] ? OUI
│ ├── Profondeur de délégation 2 > 0 ? OUI
│ └── ACCORDER : Créer une capacité atténuée
├── Le sous-agent demande : fs:/project/secrets/** [read]
│ ├── Le chemin contient "secrets" → Violation de la politique de sécurité
│ └── REJETER : Exclusion de chemin sensible
└── Le sous-agent demande : fs:/etc/passwd [read]
├── /etc/passwd ⊂ /project/** ? NON
└── REJETER : En dehors du périmètre autorisé
Capacité Atténuée Générée :
const subCap = mint.attenuate(mainCap, 'agent-analyzer-001', ['read']);
// Résultat : fs:/project/src/** [read] delegatable=true maxDepth=1 ttl=3600s
Erreur novice : Accorderait la capacité parente complète sans restriction. Aperçu expert : L'atténuation applique « ne jamais augmenter les privilèges » au niveau cryptographique.
Exemple 3 : Détection de Violation de Politique Sandbox avec Analyse de Compromis
Scénario : L'agent de génération de code tente d'accéder au réseau pendant l'exécution, en violation de la politique du sandbox.
Configuration du Sandbox :
const codegenSandbox = {
fileRead: ['/workspace/src/**', '/workspace/package.json'],
fileWrite: ['/workspace/src/**'],
netConnect: false, // PAS d'accès réseau
maxExecutionMs: 300000,
maxMemoryMb: 512
};
Flux de Détection de Violation :
-
Action de l'Agent : Codegen tente
fetch('https://api.github.com/repos/...') -
Interception du Sandbox : Le runtime WASM intercepte l'appel système pour socket réseau
-
Vérification de la Politique :
netConnect: false→ VIOLATION DÉTECTÉE -
Analyse de Compromis :
Compromis Sécurité vs Fonctionnalité : ├── STRICT (actuel) : Bloquer le réseau, terminer l'agent │ ├── Pour : Surface d'attaque réseau nulle │ ├── Contre : Impossible de récupérer les dépendances/documentations externes │ └── Décision : APPLIQUER (environnement sécurité d'abord) ├── MODÉRÉ : Autoriser des domaines spécifiques sur liste blanche │ ├── Pour : Fonctionnel pour les API connues et fiables │ ├── Contre : Risques d'empoisonnement DNS, de prise de contrôle de sous-domaine │ └── Décision : Envisager uniquement pour les environnements de développement └── PERMISSIF : Journaliser mais autoriser ├── Pour : Fonctionnalité complète préservée ├── Contre : L'agent peut exfiltrer des données, télécharger des malwares └── Décision : REJETER (viole le modèle zero-trust) -
Réponse : Terminer l'agent, enregistrer l'événement de sécurité :
{ "event": "sandbox_violation", "agent_id": "agent-codegen-001", "violation_type": "unauthorized_network_access", "attempted_url": "api.github.com", "policy_matched": "netConnect: false", "action_taken": "terminate_agent" }
Erreur novice : Autoriserait l'accès réseau « juste pour cette fois » ou ne détecterait pas la violation. Aperçu expert : Les violations de sandbox indiquent une compromission potentielle ou une dérive du modèle — toujours appliquer strictement.
Barrières de Qualité
- Chaque agent a une identité cryptographique unique (paire de clés Ed25519 + certificat)
- Tous les canaux agent-à-agent utilisent TLS mutuel avec vérification de certificat
- Tous les messages portent des signatures JWS avec un TTL <5 min et une protection anti-rejeu jti
- Les jetons de capacité suivent le modèle ocap (pas d'autorité ambiante nulle part)
- La délégation de capacité préserve l'invariant d'atténuation (privilèges enfant ⊆ parent)
- La piste d'audit utilise un arbre de Merkle à ajout seul avec des racines publiées
- Toute exécution de compétence se produit dans un sandbox WASM ou conteneur
- Les limites de ressources sont appliquées (CPU, mémoire, temps d'exécution, réseau)
- Les paquets de compétences sont adressés par contenu et signés par l'auteur
- Aucun agent n'accepte de compétences/entrées non signées ou non vérifiées
- La rotation des certificats est automatisée avec une durée de vie de certificat <24 h
- Le cache de détection de rejeu est opérationnel avec un TTL correspondant à l'expiration du message
- Toutes les violations de sécurité sont journalisées avec l'horodatage + l'identité de l'agent + l'action entreprise
LIMITES DE NON-APPLICATION
Cette compétence NE DOIT PAS être utilisée pour :
- L'analyse de vulnérabilité au niveau applicatif → Utiliser
security-auditorà la place - La configuration du pare-feu réseau/WAF → Utiliser
infrastructure-engineerà la place - La documentation de conformité SOC2/HIPAA → Utiliser les processus de conformité organisationnels
- La défense contre les injections de prompt → Utiliser la compétence
prompt-engineerà la place - La limitation de débit ou la protection anti-DDoS → Utiliser la configuration de la passerelle API
- La sécurité de l'orchestration de conteneurs → Utiliser la compétence
devops-automatorà la place
Limites de délégation :
- Pour les problèmes de sécurité au niveau du code →
security-auditor - Pour le durcissement de l'infrastructure →
infrastructure-engineer - Pour les pratiques de codage sécurisé →
software-engineer - Pour la réponse aux incidents →
security-incident-response