Arrêtez les actions risquées des agents IA avant leur exécution

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 les 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 autorisent l'appel d'outil, y compris en mode application, et restent visibles comme échecs dans le journal d'activité. Les refus de politique aboutis et les approbations requises indisponibles bloquent toujours. Ce repli en cas d'erreur ne change pas le comportement lorsque le démon est indisponible ou que l'application n'a pas de politique utilisable.

• Décisions locales : l'évaluation de la politique se fait aux côtés de l'agent.
• Application avant action : les actions correspondantes peuvent être refusées aux points d'ancrage synchrones pris en charge.
• Aucune commande d'enveloppe : installez Kontext une fois et continuez à utiliser vos agents normalement.
• Preuves attribuables : conservez l'agent, la session, l'action, la décision de politique et le résultat.
• Déploiement géré : distribuez la politique et examinez les enregistrements expurgés à l'échelle d'une organisation.

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, préservant leur identité Cowork dans les enregistrements d'activité.

Démarrage rapide

Installer Kontext

brew install kontext-security/tap/kontext

Connecter ce Mac

Créez un jeton d'installation dans le tableau de bord Kontext, puis exécutez :

kontext setup

Configuration :

• stocke le jeton d'installation dans le trousseau de connexion macOS ;
• installe les hooks pour les agents pris en charge ;
• démarre le démon Kontext local ;
• connecte l'installation à votre organisation Kontext.

Vérifiez l'installation :

kontext doctor

Ensuite, continuez à utiliser Claude Code ou Codex normalement. Vous n'avez pas besoin de lancer l'agent via une enveloppe séparée.

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.

Qu'est-ce qui change après la configuration ?

Sans politique avant action, une action d'agent s'exécute avant qu'une équipe de sécurité puisse examiner ses journaux :

l'agent demande une action
        |
        v
l'action s'exécute
        |
        v
l'activité apparaît dans un journal

Avec Kontext :

l'agent demande une action
        |
        v
Kontext la reçoit via un hook pris en charge
        |
        v
la politique locale évalue l'action
        |
        +---- autoriser ----------> l'action continue
        |
        +---- refuserait -----> l'action continue et la preuve est enregistrée
        |                       (mode observation)
        |
        +---- refuser -----------> l'action est arrêtée avant exécution
                                (mode application)
        |
        v
la décision et le résultat entrent dans le registre d'autorisation

Cela crée un point de décision avant l'action, et pas seulement un enregistrement après celle-ci.

Observez d'abord. Appliquez quand vous êtes prêt.

Bloquer chaque action inconnue dès le premier jour crée du bruit et interrompt les développeurs. Autoriser chaque action indéfiniment laisse la politique comme une surveillance passive.

Kontext sépare le déploiement en deux modes :

Mode observation

Le mode observation enregistre la décision de politique sans interrompre l'agent.

Utilisez-le pour répondre à :

• Quels outils les agents appellent-ils ?
• Quelles actions la politique actuelle refuserait-elle ?
• Quels dépôts, fichiers et systèmes sont impliqués ?
• Où l'application interromprait-elle un travail légitime ?
• Quelles surfaces d'événements peuvent réellement arrêter l'action ?

Mode application

Le mode application renvoie un refus réel lorsqu'une politique déterministe correspond à un hook synchrone avant action pris en charge.

Les politiques peuvent définir des périmètres autour d'actions telles que :

• les commandes destructrices ;
• l'accès à des fichiers sensibles ;
• les opérations sur des systèmes de production ;
• l'accès aux identifiants ;
• les exports de données.

L'application est intentionnellement limitée aux surfaces d'événements où l'agent attend Kontext avant de continuer. Kontext ne prétend pas que recevoir un événement signifie pouvoir arrêter chaque action de cet agent.

Sachez ce qui s'est passé—et pourquoi

Chaque événement pris en charge qui atteint Kontext peut contribuer des preuves au registre d'autorisation local.

Un enregistrement peut inclure :

• l'agent et la session ;
• l'événement de cycle de vie ou d'outil ;
• le nom de l'outil et l'entrée disponible ;
• la décision de politique locale ;
• la politique responsable de cette décision ;
• le résultat d'action disponible ;
• les preuves expurgées pour examen ultérieur.

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 des conversations.

Les déploiements gérés peuvent exporter les enregistrements expurgés vers le tableau de bord Kontext pour examen, rétention et investigation à l'échelle de l'organisation.

La politique là où l'agent s'exécute

Le chemin de décision reste local :

Claude Code / Cowork / Codex
              |
              v
        hook pris en charge
              |
              v
     runtime Kontext local
              |
        +-----+------+
        |            |
        v            v
  décision de politique   registre local
        |
        v
 autoriser / refuserait / refuser

Un service hébergé n'a pas besoin de répondre à chaque appel d'outil.

Les déploiements gérés ajoutent la configuration d'organisation, le déploiement de politique, l'export d'enregistrements, l'identité et la rétention. Ils ne déplacent pas le chemin de décision synchrone hors de l'environnement de l'agent.

Agents pris en charge

« Pris en charge » signifie plus que d'accepter un événement. Kontext documente quels événements il reçoit, quels événements peuvent bloquer, et comment chaque intégration est installée.

Voir la matrice de prise en charge des agents pour le comportement exact, la portée du déploiement et les lacunes connues. C'est la source faisant autorité pour la couverture de l'application.

Kontext et les bacs à sable résolvent des problèmes différents

Un bac à sable de processus demande :

À quels fichiers, destinations réseau, identifiants et ressources du système d'exploitation ce processus peut-il accéder ?

Kontext demande :

Quel agent tente quelle action, quelle politique s'applique, l'action doit-elle se poursuivre, et quelle preuve atteste la décision ?

Les bacs à sable du noyau sont de solides frontières de confinement. Kontext fournit une politique sémantique et une attribution aux hooks d'agent et d'outil pris en charge.

Ils sont complémentaires :

Kontext
  décide si l'action est autorisée
              |
              v
bac à sable
  contraint ce à quoi le processus peut physiquement accéder

Kontext ne prétend pas à une isolation au niveau du noyau. Utilisez un bac à sable approprié lorsque le modèle de menace exige un confinement du processus, du système de fichiers ou du réseau.

Pourquoi ne pas simplement collecter les journaux des agents ?

Les journaux vous disent ce qu'un agent a signalé après un événement.

Kontext crée une décision d'autorisation avant que les actions à conséquences prises en charge ne s'exécutent, puis relie cette décision au résultat disponible.

Cette distinction compte lors de :

• le déploiement de politique ;
• l'investigation d'incidents ;
• l'examen des accès à la production ;
• la gestion des exceptions des développeurs ;
• l'examen de conformité et d'audit.

Le résultat n'est pas seulement « l'agent a appelé un outil ». C'est la preuve de ce qui a été demandé, quelle politique s'est appliquée, si cela a été autorisé, et ce qui s'est passé ensuite.

Exécutez Kontext dans toute votre organisation

Les déploiements gérés ajoutent :

• une politique déterministe gérée de manière centralisée ;
• l'identité d'entreprise et les contrôles d'organisation ;
• le déploiement de l'observation à l'application ;
• la prise en charge du déploiement géré d'agents et de cloud ;
• l'export de preuves expurgées ;
• la rétention d'audit ;
• la surveillance de la santé du déploiement et de l'arriéré ;
• l'intégration des équipes de sécurité et de plateforme.

Pour la planification du déploiement et l'intégration de l'organisation, contactez [email protected] ou planifiez une conversation.

Diagnostiquer une installation

kontext doctor

doctor vérifie :

• les hooks d'agent installés ;
• la santé et la version du démon ;
• la santé de l'export géré ;
• l'arriéré d'export en attente.

Il se termine avec un code non nul lorsqu'une installation configurée est en mauvaise santé.

Lorsqu'un démon en libre-service est obsolète :

kontext doctor --fix

Faites tourner le jeton d'installation en relançant la configuration :

kontext setup

Supprimez l'installation en libre-service :

kontext setup --uninstall

Traitement des données

• Les décisions de politique se prennent localement.
• L'activité des outils et les preuves de décision sont stockées localement.
• Les valeurs sensibles sont expurgées avant le stockage local et l'export géré.
• Kontext ne stocke pas le raisonnement du modèle ni l'historique complet des conversations.
• Les déploiements gérés peuvent exporter les enregistrements expurgés vers le tableau de bord de l'organisation.

Voir la documentation Guard pour le runtime et la frontière des données.

Développement

go build -o bin/kontext ./cmd/kontext
go test ./...
go test -race ./...
go vet ./...

Communauté

• Lisez SUPPORT.md pour les canaux de support.
• Lisez CONTRIBUTING.md avant d'ouvrir une contribution.
• Signalez les vulnérabilités via notre Politique de sécurité.
• Kontext est publié sous la licence MIT.

Rapport d'autorité

kontext report affiche les agents découverts et l'autorité exactement tels que le cloud les a acceptés en dernier. Utilisez kontext report --json pour la charge utile brute. Avant le premier envoi réussi, il ne rapporte aucune donnée.

Définissez KONTEXT_AUTHORITY_SCAN=off dans l'environnement du démon pour désactiver la collecte et la transmission d'autorité sur ce Mac.