Bloquer les actions des agents IA sur le poste

Application

Les autres se contentent d’observer.

ZYBE refuse l’action avant qu’elle ne s’exécute.

Un appel d’outil qu’un agent IA s’apprête à faire est jugé sur le poste, au moment même où l’agent vérifie avant d’agir, selon vos règles. Si une règle dit non, la commande ne démarre pas, le fichier ne s’ouvre pas, le serveur ne répond pas. Le modèle apprend pourquoi, et qu’il ne doit pas essayer autrement. Ni proxy, ni passerelle, ni trafic à inspecter : c’est l’agent qui applique la décision, ce qui explique qu’elle tienne hors ligne et sur tous les portables à la fois.

Comment ça marche, en schémas

Ce qui tient sur chaque agent

Ce qui est bloqué

Douze types d’actions, refusées sur le poste

Chacune est une règle. Réglez-la sur Report, Ask ou Block, par profil, par groupe de postes, par agent.

Où ça tient

Douze agents soumis aux règles, et les autres refusés d’office

Chaque agent doté d’un hook avant action exécute le hook de ZYBE. Les applications sans hook agissent via des serveurs MCP, qui passent par le shim de ZYBE. La console affiche un état parmi quatre par agent et par poste, calculé à partir des appels réellement reçus : Blocking, Recording, Seen, Silent, ou Not allowed pour un produit que l’entreprise a refusé.

Agent

Comment le refus lui parvient

Hook, dans les réglages gérés

Hook

Hook, géré sur les installations à l’échelle de la machine

Hook, plus la politique gérée

Hook, dans le fichier de hooks Gemini partagé

Hook shell dans sa configuration

Un plugin ZYBE dans sa passerelle

Ses serveurs MCP passent par le shim ZYBE

Leurs serveurs MCP passent par le shim

Refusé d’office : le poste lui retire le droit de s’exécuter

La dernière ligne n’a pas de hook, une règle ne peut donc pas juger chaque appel. L’entreprise décide si le produit est autorisé ou non, et le poste l’applique. La console ne compte jamais un agent comme bloqué simplement parce qu’un fichier est en place.

Dans les mots de l’agent

À quoi ressemble un refus

De vraies sessions, de vrais agents, à qui l’on demande d’installer un paquet que l’espace de travail avait confiné. Chacun s’est arrêté, a cité la raison et n’a pas réessayé.

Une menace ouverte dans la console : la sortie injectée, la commande qui a suivi, le résumé et la remédiation

La chaîne, dans la console : les instructions arrivées par une page récupérée, la commande suivante dans cette session, et la marche à suivre.

Le quatrième état

Not allowed : quand il n’y a pas de porte, le poste refuse l’application

Certaines applications agissent dans le cloud de leur éditeur ou sur le web, sans rien sur le portable devant quoi placer un hook. Pour celles-ci, l’entreprise décide si l’application est autorisée ou non, et le poste applique la réponse : il retire à l’application le droit de s’exécuter, la ferme si elle est ouverte, et rend ce droit dès que l’entreprise l’autorise à nouveau. Saisissez une fois le nom du produit dans Rules, et chaque poste le refuse dans la minute. Installé, refusé, et affiché Not allowed sur chaque poste. Personne d’autre ne fait cela sur le poste.

Rien ne sort

Jugé sur la machine, pas dans le cloud d’un tiers

La commande, le chemin, la page et le prompt sont lus sur le poste et jamais envoyés. Ce qui remonte à la console, c’est la règle déclenchée, la décision, l’agent et une empreinte. C’est la différence avec une passerelle qui inspecte votre trafic : ZYBE voit ce que fait l’agent, et vos conversations restent les vôtres.

Installer sur une machine

Ce qui quitte la machine