
Sécurité d'exécution pour les agents IA : découvrez les agents, cartographiez leurs permissions et contrôlez ce qu'ils peuvent faire.
Les agents IA ne se contentent pas de suggérer du code. Ils exécutent des commandes shell, lisent des fichiers, appellent des services, modifient l'infrastructure et interagissent avec des systèmes de production.
Kontext place une politique locale entre les agents IA et les outils qu'ils appellent. Il observe les actions prises en charge, évalue la politique avant l'exécution des actions à conséquences, et consigne la décision et le résultat dans un registre d'autorisation.
Commencez en mode observation. Voyez ce que la politique bloquerait. Passez les périmètres pris en charge en mode application lorsque vous êtes prêt.
Les erreurs d'évaluation de politique, une politique non prête (manquante, corrompue ou expirée) et une identité non résolue autorisent l'appel d'outil, y compris en mode application, et restent visibles comme échecs dans le journal d'activité. Seuls les refus de politique aboutis et les approbations requises indisponibles bloquent. Lorsque le hook ne peut obtenir aucune décision, parce que le démon est arrêté, en cours de redémarrage, trop lent ou renvoie quelque chose d'illisible, l'appel d'outil n'est pas bloqué et Kontext ne renvoie aucune décision, de sorte que les paramètres d'autorisation propres à l'agent s'appliquent.
Kontext prend actuellement en charge Claude Code, Claude Cowork et Codex. La couverture exacte des événements et de l'application varie selon l'agent—voir la matrice de prise en charge des agents.
Les hooks Claude gérés reconnaissent les sessions Cowork avec des noms de répertoire de session complets ou abrégés, en préservant leur identité Cowork dans les enregistrements d'activité.
brew install kontext-security/tap/kontext
Créez un jeton d'installation dans le tableau de bord Kontext, puis exécutez :
kontext setup
Configuration :
Vérifiez l'installation :
kontext doctor
Continuez ensuite à utiliser Claude Code ou Codex normalement. Vous n'avez pas besoin de lancer l'agent via un wrapper séparé.
La configuration en libre-service prend actuellement en charge macOS. Les environnements gérés et cloud peuvent exécuter le même runtime local lorsqu'ils fournissent un contrat de hook pris en charge, un stockage et un cycle de vie de démon.
Sans politique de pré-action, une action d'agent s'exécute avant qu'une équipe de sécurité puisse examiner ses journaux :
agent requests an action
|
v
action executes
|
v
activity appears in a log
Avec Kontext :
agent requests an action
|
v
Kontext receives it through a supported hook
|
v
local policy evaluates the action
|
+---- allow ----------> action continues
|
+---- would deny -----> action continues and evidence is recorded
| (observe mode)
|
+---- deny -----------> action is stopped before execution
(enforce mode)
|
v
decision and outcome enter the authorization ledger
Cela crée un point de décision avant l'action, et pas seulement un enregistrement après celle-ci.
Bloquer toute action inconnue dès le premier jour crée du bruit et interrompt les développeurs. Autoriser indéfiniment toutes les actions réduit la politique à une simple surveillance passive.
Kontext sépare le déploiement en deux modes :
Le mode observation enregistre la décision de politique sans interrompre l'agent.
Utilisez-le pour répondre aux questions suivantes :
Le mode application renvoie un refus réel lorsqu'une politique déterministe correspond à un hook synchrone pré-action pris en charge.
Les politiques peuvent définir des limites autour d'actions telles que :
L'application est volontairement limitée aux surfaces d'événements où l'agent attend Kontext avant de poursuivre. Kontext ne prétend pas que recevoir un événement signifie pouvoir arrêter toutes les actions de cet agent.
Chaque événement pris en charge qui atteint Kontext peut contribuer à des preuves dans le registre d'autorisation local.
Un enregistrement peut inclure :
Kontext enregistre l'activité des outils et les preuves de décision. Il ne capture pas le raisonnement du modèle ni ne reconstruit l'historique complet de la conversation. Chaque prompt démarre un tour qui regroupe les actions et l'usage du modèle lié aux outils qui le suivent ; l'enregistrement du tour ne contient qu'un extrait de prompt expurgé et borné lorsque l'espace de travail capture les résumés ou les charges utiles complètes et que la classification par type de travail est activée, et uniquement la taille du prompt dans le cas contraire.
Les déploiements gérés peuvent exporter des enregistrements expurgés vers le tableau de bord Kontext pour un examen, une rétention et une investigation à l'échelle de l'organisation.