AccuKnox : voir et contrôler la surface d’exécution de l’IA

La surface d’un système agentique ne se limite pas au modèle. Un environnement peut contenir des modèles, datasets, agents, pipelines, endpoints, serveurs MCP et workloads répartis entre plusieurs clouds ou infrastructures privées.

AccuKnox organise ses capacités AI Security en étapes successives : découverte, posture, validation, protection runtime et réponse.^[2]

AI Security Posture Management

AccuKnox documente une capacité AI-SPM destinée à construire un inventaire consolidé des actifs IA de l’environnement : modèles, agents, datasets et pipelines. L’éditeur présente cette découverte comme agentless et applicable aux environnements cloud et on-premises, avec pour objectif d’identifier les actifs ou usages IA non approuvés et d’en centraliser la visibilité.^[2][1]

Shadow AI : la découverte avant le contrôle

Un actif IA inconnu ne peut être ni rattaché à un propriétaire, ni évalué, ni intégré à une politique. Dans l’approche AccuKnox, la découverte identifie les usages non approuvés avant de qualifier leur exposition et leur criticité. Le cas d’usage découvrir le Shadow AI détaille ce qu’un inventaire doit contenir.

La documentation AccuKnox décrit une protection des agents au runtime fondée sur eBPF et les Linux Security Modules, qui impose des contrôles sans modifier le code de l’agent. Les exemples portent sur ce qu’un workload exploite directement : processus, fichiers, réseau, outils, API ou connexions déclenchées par l’agent. Elle indique aussi que des appels d’outils non autorisés peuvent être bloqués avant exécution.^[2]

Pourquoi descendre jusqu’au runtime

Un agent qui génère ou exécute du code devient un processus informatique classique : il ouvre des fichiers, lance des sous-processus, établit des connexions. Les contrôles runtime appliquent des restrictions au niveau de l’environnement d’exécution, indépendamment des instructions données au modèle.

Le workload n’est qu’une partie du problème : l’agent choisit aussi des outils et construit leurs paramètres. La documentation AccuKnox présente un contrôle de moindre privilège sur les outils, qui refuse un appel avant son exécution.^[2]

Il s’agit d’une politique d’usage des outils appliquée au runtime, pas d’un moteur d’autorisation métier fine. Le cas d’usage sécuriser MCP décrit les autres points de contrôle d’un tool call.

AccuKnox documente des contrôles sur les artefacts IA eux-mêmes. Pour les modèles, l’analyse de plusieurs formats afin de rechercher notamment des risques de supply chain et de désérialisation. Pour les datasets, la recherche de données sensibles, PII ou PHI, avant leur utilisation dans les pipelines.^[2] Voir aussi protéger modèles et datasets.

Plusieurs agents qui partagent une clé API ou un compte de service deviennent difficiles à distinguer et à auditer. La fonction AI Identity Security décrite par AccuKnox utilise SPIFFE pour attribuer une identité propre à chaque agent, avec une attestation cryptographique destinée à réduire le risque d’usurpation.^[2]

AccuKnox documente une couche de guardrails et de prompt firewall : détection d’attaques par prompt, suivi stateful des conversations, masquage en temps réel de certaines données sensibles avant envoi au modèle.^[2] C’est une protection complémentaire des contrôles précédents.

AI-DR est la couche de détection et réponse de l’offre AI Security. La documentation indique une ingestion continue de logs provenant notamment d’AWS, Azure et GCP, et un enrichissement des incidents avec du contexte exploitable pour la réponse. Elle cite des intégrations de routage d’incidents vers Jira, ServiceNow, Slack et PagerDuty.^[2] Leur disponibilité peut varier selon le module et le mode de déploiement.

AccuKnox documente un red teaming automatisé qui soumet modèles et applications IA à des scénarios adversariaux : jailbreaks, prompt injection, techniques d’encodage, avec un mapping vers OWASP et MITRE ATLAS. Les tests peuvent être déclenchés lors des changements de modèle. La documentation annonce plus de 150 probes adversariales automatisées.^[2] Méthode et livrables attendus : red teaming des agents IA.

La couche AI-GRC relie les findings à des référentiels : OWASP, MITRE ATLAS, NIST AI RMF, EU AI Act. Les supports décrivent aussi une traçabilité par requête destinée à l’audit.^[2] Ces mappings et traces peuvent contribuer à documenter certains contrôles ou exigences ; ils ne rendent pas un système conforme.

Gouvernance métier des habilitations

Décider qui doit obtenir durablement un droit reste une problématique distincte de la protection runtime.

Fine-grained business authorization

Un contrôle de processus ou de réseau ne détermine pas nécessairement si tel utilisateur peut approuver cette commande ou exporter ce dossier client dans ce contexte.

Conception de l’agent

Les contrôles de sécurité ne corrigent pas une architecture agentique mal définie.

Qualité des données

Scanner un dataset ne remplace pas la gouvernance fonctionnelle de ses données.

Risk ownership

Un finding technique doit encore être rattaché à une criticité et à un propriétaire métier.

La documentation AI Security indique une couverture des environnements suivants :^[2]

• Public Cloud
• Private Cloud
• Fully Air-Gapped Cloud
• Edge / IoT

Aucune capture réelle n’a encore été fournie. Chaque écran ajouté sera accompagné d’une légende factuelle décrivant ce qu’il montre.