Offre

Limiter ce que l’environnement d’exécution peut réellement faire

Un agent reste un workload informatique. Lorsqu’il génère du code, ouvre un fichier, lance un processus ou contacte un service externe, ces effets peuvent être observés et limités indépendamment du raisonnement du modèle.

Quand nous appeler

  • Votre agent de code exécute les scripts qu’il génère.
  • Des agents tournent dans des conteneurs qui ont accès à des credentials cloud.
  • Aucune restriction d’egress n’existe sur les workloads d’agents.
  • Vous voulez pouvoir confiner un agent sans modifier son code.

Les surfaces travaillées

  • Process
  • Filesystem
  • Network
  • Credentials
  • Containers
  • Generated code
  • External endpoints

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.

Un exemple

Blocage d’une connexion sortante

Agent de code, script généré, exécution, requête réseau sortante, destination bloquée.

Le contrôle intervient au niveau de l’environnement d’exécution : il n’a pas besoin que le modèle renonce à l’appel.

Ce que nous travaillons

Segmentation des capacités
Séparer ce dont chaque workload a besoin.
Isolation
Exécuter le code généré à part.
Politiques process / file / network
Définir ce qui est permis au runtime.
Restrictions d’egress
Limiter les destinations joignables.
Protection des credentials
Retirer les secrets inutiles de l’environnement.
Journalisation
Tracer les événements runtime utiles.
Réponse et confinement
Pouvoir isoler ou arrêter un workload.
Observe → alert → block
Passer progressivement en mode bloquant lorsque c’est pertinent.
Limitation
La sécurité runtime ne remplace pas l’autorisation métier. Un appel peut être techniquement sûr et néanmoins ne pas être autorisé au regard de la mission de l’agent.

Technologies mobilisables

AccuKnox peut être mobilisé pour les contrôles runtime documentés, notamment une protection des agents fondée sur eBPF et les Linux Security Modules, sans modification du code de l’agent.[1] Détail : fonctionnement d’AccuKnox.

Le problème en profondeur : contrôler ce que le workload exécute.

Contenus associés

Sources

  1. [1]

    Documentation éditeurDocument non public

    AccuKnox

    Zero Trust AI Security - Build to Runtime

    Support AccuKnox non public couvrant AI-SPM, AI-DR, AI Red Teaming, AI Guardrails, Agentic AI Security, AI Identity Security, Model & Dataset Security et AI-GRC.

Examiner vos workloads d’agents

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

Évaluer mon runtime