Cas d’usage · Runtime

Contrôler ce que le workload de l’agent peut réellement exécuter

Même si les prompts et les permissions sont correctement encadrés, l’agent reste un workload informatique. Il lance du code, ouvre des fichiers, utilise des credentials et établit des connexions réseau.

Les surfaces d’exécution

  • Process execution
  • Filesystem
  • Credentials
  • Network
  • Generated code
  • Containers
  • Host
  • External services

Runtime controls

Schéma de principe, pas l’architecture complète d’un produit. En amont : code, modèle et dépendances. Au centre : l’agent ou le workload. Surfaces observées : processus, fichiers, réseau, API, outils et MCP. Réponses : observer, détecter, bloquer, puis isoler et tracer.

Runtime controls. Schéma de principe des surfaces observées et des réponses possibles.

Un agent de développement exécute un script qu’il a généré

L’agent écrit un script pour transformer des fichiers, puis l’exécute dans son environnement. Le script hérite de tout ce que le workload peut faire : lire les fichiers montés, utiliser les variables d’environnement contenant des credentials, ouvrir des connexions sortantes.

Isoler l’exécution
Exécuter le code généré dans un environnement séparé du workload principal.
Limiter les fichiers
N’exposer que les répertoires nécessaires, en lecture seule quand c’est possible.
Restreindre les processus
Interdire les binaires non prévus : shells, outils réseau, gestionnaires de paquets.
Limiter l’egress
Autoriser uniquement les destinations réseau nécessaires.
Protéger les credentials
Ne pas laisser de secrets lisibles par le code généré.
Détecter
Repérer les comportements qui s’écartent du profil attendu.
Interrompre
Pouvoir arrêter ou isoler le workload.

Ce que ces contrôles ne règlent pas

  • La sécurité runtime ne décide pas si une action métier est légitime : un appel réseau techniquement sain peut être une opération non autorisée.
  • Un profil d’exécution trop permissif laisse passer ce qu’il devait bloquer ; il doit être construit à partir du comportement réel.

Technologies mobilisables

Les contrôles runtime relèvent ici d’une capacité spécialisée.

AccuKnox

Runtime security

La documentation AccuKnox décrit notamment :[1]

  • sandboxing runtime
  • eBPF / LSM
  • process isolation
  • filesystem protection
  • network segmentation
  • credential security
  • execution control
  • sandboxing de code généré

Voir la page AccuKnox

Contenus associés

Sources

Sources vérifiées le

  1. [1]

    Documentation éditeur

    AccuKnox

    AI Security Posture Management for LLMs & Agents (lien externe, nouvel onglet)

    Documentation publique AccuKnox présentant les capacités de sécurité IA, dont inventaire, Shadow AI, sécurité agentique, runtime, modèles, datasets et red teaming.

    Vérifié le

Évaluer l’isolation de vos agents en exécution

Nous pouvons partir d’un agent existant ou d’un projet en conception pour identifier les ressources, actions et contrôles concernés.

Nous contacter