Cisco Project Quarry examine ce qu’un agent a fait sur l’ensemble d’une tâche

Un assistant lit un fichier. Plus tard, il envoie une requête web. Chaque action peut être permise, utile et parfaitement ordinaire. La question de sécurité est de savoir si la seconde a transporté des informations issues de la première vers un endroit où elles n’auraient jamais dû aller.

Cisco a présenté Project Quarry le 28 octobre 2026 comme un langage et un moteur open source de détection du comportement des agents. Au lieu de vérifier seulement un message isolé, il permet aux équipes de décrire des schémas couvrant les messages, les appels d’outils, les résultats et l’ordre des événements. Un signalement comprend des preuves aidant à expliquer quelle activité correspond à la règle. Article de lancement de Cisco

Pour les équipes intégrant des agents à l’assistance, à la programmation ou aux opérations, c’est un ajout concret aux outils de sécurité. Ce guide explique ce que Quarry peut apporter, comment commencer avec des exemples locaux et pourquoi détecter une séquence dangereuse n’est qu’une partie de son contrôle. Le framework public est actuellement en alpha ; un pilote doit donc aussi tenir compte des modifications de règles avant la version 1.0.0. README de Project Quarry, consulté le 2 novembre 2026

Un pare-feu Cisco ASA 5510 en 2010 ; matériel historique de sécurité réseau. Quarry est un logiciel de comportement d’agents, et non cet appareil. Photo : Jon 'ShakataGaNai' Davis, CC BY-SA 3.0 ; redimensionnée avec des marges. Source de l’image · Licence et informations sur l’image. Référence officielle du produit.

Une séquence peut expliquer ce qu’un événement isolé ne peut pas

Imaginez un agent d’assistance interne capable de lire une base de connaissances et d’ouvrir un ticket externe. Ces deux capacités ont des usages légitimes. Imaginez maintenant qu’une page non fiable lui demande de joindre un fichier de diagnostic interne à un ticket public sans rapport. Une règle recherchant uniquement la phrase « ignore les instructions précédentes » peut manquer une instruction plus indirecte. Une règle examinant seulement l’outil d’envoi autorisé peut manquer la raison pour laquelle ses arguments sont inappropriés.

La séquence apporte le contexte. Qu’a lu l’agent ? Quelle instruction a précédé l’envoi ? Quelles données figuraient dans les arguments ? Cette destination faisait-elle partie de la tâche de l’utilisateur ? Ces questions sont souvent plus faciles à examiner lorsque la trace structurée reste intacte.

Cisco présente Quarry comme une combinaison de contrôles exacts et de jugements facultatifs par modèle. Les contrôles exacts peuvent exprimer des noms d’outils, des champs, des chaînes et un ordre ; les contrôles fondés sur des modèles peuvent traiter les questions exigeant une interprétation. Le produit hôte décide ensuite de ce qu’un signalement doit déclencher, par exemple une alerte ou le blocage d’une action. Explication de Cisco, 28 octobre 2026

Notre avis : une bonne règle est une question rejouable sur le comportement. On doit pouvoir désigner les événements correspondants et discuter de la fidélité de la règle à la politique voulue. C’est plus utile qu’un avertissement rouge dont la seule explication est qu’un modèle n’a pas aimé la conversation.

Séquence suspecte illustrative : Quarry évalue la trace et renvoie des preuves ; l’application qui l’intègre est responsable de la réponse.

Quarry a sa place aux côtés des autorisations et des contrôles de contenu

L’autorisation détermine si un acteur donné peut effectuer une action donnée sur une ressource. Un classificateur de contenu demande si une entrée ou une sortie possède une propriété pertinente. Une détection à l’échelle de la trace demande comment plusieurs événements sont liés. Ces questions se recouvrent, mais aucune ne devient inutile parce qu’une autre dispose d’une démonstration convaincante.

Cisco cite Snort, YARA et Sigma comme précédents de langages de détection lisibles et partageables pour l’analyse des réseaux, des logiciels malveillants et des journaux. Quarry vise à apporter ce style de règle vérifiable à l’activité des agents. Motivation du lancement de Cisco L’analogie est utile comme objectif de conception ; elle ne rend pas un jeune projet alpha aussi mature que ces écosystèmes établis.

Reprenons l’exemple du fichier et de l’envoi. Une autorisation forte peut arrêter l’accès à un fichier interdit avant qu’une règle de comportement ne devienne pertinente. Un contrôle de contenu peut repérer une instruction suspecte dans un résultat d’outil. Une règle de séquence peut relier une lecture permise à un transfert inapproprié. Ensemble, ils couvrent davantage du parcours qu’un contrôle seul.

Une alerte a besoin de suffisamment de preuves pour permettre une action humaine

L’avantage d’un signalement fondé sur la trace est de pouvoir soutenir une prochaine étape précise. La personne qui l’examine doit savoir quels événements ont compté, quel champ correspond et quel contexte environnant change l’interprétation. L’objectif est un dossier explicable, plutôt qu’une liste croissante de scores de risque inexpliqués.

Dans un processus d’assistance illustratif, un signalement utile pourrait relier un résultat de document interne à un envoi ultérieur vers une destination non approuvée. L’analyste peut alors demander si l’action demandée autorisait ce transfert, si la destination appartient au client et si la charge contient réellement des informations protégées. Une règle large signalant chaque lecture de fichier suivie de chaque requête réseau noierait les cas intéressants.

La précision dépend du vocabulaire de l’application. « Externe » peut signifier hors de l’organisation, hors d’un locataire approuvé ou simplement hors d’un service. « Sensible » peut désigner un document étiqueté, un champ source ou un résultat de classification. Définissez ces termes dans l’intégration avant d’écrire une règle qui en dépend.

Les preuves elles-mêmes ont aussi besoin de protection. Une trace peut contenir précisément le contenu du fichier ou le fragment d’identifiant qui rendait l’événement risqué. Une alerte utile à un analyste de sécurité peut être inappropriée sur une page d’erreur publique. Prévoyez les accès et le masquage avec la règle, plutôt que de les ajouter après le premier incident.

Trois processus rendent le premier pilote concret

Un premier usage illustratif est l’examen rétrospectif des sessions d’agents d’assistance. Commencez par un petit jeu de données autorisé contenant des activités normales et un exemple synthétique de transfert inapproprié. Exécutez les mêmes règles sur les deux. Un bon pilote montre que l’équipe peut expliquer une correspondance et expliquer pourquoi le travail légitime ne déclenche rien.

Un deuxième usage concerne le respect d’une condition d’arrêt par l’agent. Supposons qu’une tâche autorise trois tentatives et exige ensuite une transmission. Une trace peut montrer si l’agent s’est arrêté, a continué ou a changé d’outil pour poursuivre indirectement la même action. C’est une question utile de politique, même si le contenu de chaque message individuel est inoffensif.

Un troisième concerne la réponse aux incidents. Lorsqu’une équipe découvre un nouveau schéma de comportement pertinent, elle peut demander si les traces précédemment stockées le contiennent aussi. La valeur est une recherche plus rapide et cohérente dans l’historique que l’organisation est autorisée à conserver. La qualité de la réponse dépend toujours de la présence dans les anciennes traces des champs et de l’ordre exigés par la règle.

Ces scénarios doivent commencer en mode observation. Les signalements rétrospectifs révèlent les faux positifs sans interrompre les utilisateurs et aident à estimer la charge d’investigation. Une règle convaincante sur une trace synthétique peut être trop large dans l’activité quotidienne. Le passage à une intervention en direct doit suivre cet apprentissage, avec une réponse dont la responsabilité est clairement attribuée.

Commencez par les exemples locaux du dépôt

Le dépôt public utilise la licence Apache 2.0 et fournit des interfaces Python et en ligne de commande. Son README indique actuellement Python 3.11 à 3.13 et un démarrage rapide fondé sur uv. La configuration d’exemple sélectionne 14 règles locales ; quatre exemples sémantiques utilisent des substituts déterministes à mots-clés explicitement destinés aux démonstrations et aux tests, plutôt qu’aux décisions en production. README de Project Quarry

La procédure suivante suit ce parcours publié. Elle constitue un point de départ pour l’évaluation du lecteur, sans prétendre qu’un déploiement ou une analyse en direct a été effectué pour cet article.

1. Utilisez un dossier d’évaluation isolé. Confirmez la plage Python documentée et installez uv par le processus habituel de votre organisation. Gardez l’évaluation séparée des traces et identifiants de production.

2. Obtenez et préparez le projet. Clonez le dépôt officiel, entrez dans son dossier et synchronisez l’environnement aux versions fixées :

   BashExécuter dans Terminal

   git clone https://github.com/cisco-ai-defense/project-quarry.git
   cd project-quarry
   uv sync --frozen
   

3. Exécutez l’exemple local bénin. Utilisez la configuration fournie avant d’ajouter un fournisseur ou d’envoyer des conversations réelles :

   BashExécuter dans Terminal

   uv run --frozen quarry scan --config examples/config.yaml --target examples/data/benign.json
   

4. Examinez un exemple correspondant à une règle. Remplacez la cible par examples/data/tool_calls.json, puis examinez la règle et les preuves ensemble. Une correspondance doit être compréhensible à partir des événements, plutôt qu’acceptée parce que la commande a affiché un avertissement.

5. Ajoutez une paire de tests propre à l’application. Créez une trace synthétique en violation et une trace légitime proche de la limite avec le même vocabulaire d’outils. Énoncez le résultat attendu avant d’ajuster la règle.

6. Consignez la révision et le traitement des résultats. La convention documentée de la CLI est 0 pour une analyse complète sans correspondance, 1 pour une analyse complète avec correspondance et 2 pour une analyse invalide ou incomplète. Préservez ces distinctions dans toute surcouche.

La distinction des codes de sortie a des conséquences pratiques. Une analyse à court de ressources ou recevant une entrée invalide ne peut pas être comptée comme une analyse sans problème. La surveillance doit rendre les évaluations incomplètes visibles pour que l’équipe sache si sa couverture présente une lacune.

Les règles fondées sur des modèles introduisent une autre frontière de données

Certaines politiques exigent une interprétation que la correspondance exacte ne peut pas fournir. Un modèle peut aider à déterminer si un résultat d’outil tente de détourner l’agent ou si une action demandée dépasse la tâche. Ajouter ce jugement ajoute aussi de la latence, du coût, le comportement d’un fournisseur et une autre source possible d’erreur.

La documentation d’inférence de Quarry indique qu’une opération de modèle peut envoyer des messages sélectionnés, des définitions d’outils et du texte de politique à son point d’accès configuré. Elle conseille d’examiner la conservation, la journalisation, le transport et les identifiants du fournisseur. Elle décrit aussi les échéances d’analyse et les budgets d’appels aux modèles, les adaptateurs étant censés respecter les annulations et délais. Documentation d’inférence de modèles de Quarry, consultée le 2 novembre 2026

Le parcours des données devient donc une décision de conception. Une équipe peut commencer avec des contrôles locaux, puis activer une règle fondée sur un modèle seulement si le bénéfice justifie le traitement supplémentaire. Avant d’utiliser des traces sensibles, décidez exactement quels champs franchissent cette frontière et qui peut approuver la configuration. Un contrôle de sécurité ne doit pas devenir silencieusement un parcours inattendu d’exportation des données qu’il est censé protéger.

Les substituts à mots-clés sont utiles pour des exemples prévisibles, car ils produisent des résultats reproductibles sans fournisseur actif. Ils ne peuvent pas démontrer l’exactitude d’un détecteur sémantique de production. Évaluez le modèle effectivement configuré sur des cas étiquetés et pertinents, notamment des messages ordinaires ressemblant aux messages risqués. Les faux positifs et les détections manquées appartiennent à la même revue.

Une intégration de production doit prendre en charge le cas incomplet

Le guide d’intégration demande aux applications de préparer et valider leurs règles sélectionnées avant d’accepter du trafic. Il sépare les politiques et entrées d’adaptateurs fiables des conversations non fiables et exige un statut d’analyse faisant autorité avant d’agir sur les correspondances. Guide d’intégration de Quarry, consulté le 2 novembre 2026

Ce contrat compte surtout lorsqu’un élément échoue. Une conversation mal formée, un délai dépassé, un modèle indisponible ou une règle invalide doivent suivre une politique applicative explicite. Selon l’opération, celle-ci peut suspendre une action lourde de conséquences, demander une vérification ou signaler qu’une observation est incomplète. Traiter chaque erreur comme une « absence de signalement » crée une lacune silencieuse.

Une correspondance complète, un résultat complet sans correspondance et une évaluation incomplète ont des sens différents. L’hôte doit décider de l’effet de chacun sur le processus de l’utilisateur.

Les changements de version exigent la même clarté. L’avertissement alpha signifie qu’un changement futur de syntaxe peut exiger des mises à jour des règles. Fixez une révision pour l’évaluation, conservez des traces représentatives et rejouez-les avant d’adopter une mise à jour. L’équipe peut ainsi distinguer une politique modifiée d’un moteur modifié.

L’annonce de Cisco évoque le déploiement dans ses travaux plus larges AI Defense, mais la maturité du moteur public doit être jugée sur son propre état documenté. Les intégrations prévues sont des travaux futurs. Un produit de production utilisant un composant ne fournit pas automatiquement une intégration de production prise en charge pour l’application de chaque lecteur.

La sécurité des agents a besoin d’une question que l’on peut réexaminer

L’idée la plus forte de Quarry consiste à rendre une préoccupation de comportement assez explicite pour l’exécuter à nouveau. Une équipe peut conserver une règle, sa version, l’activité correspondante et la raison de sa modification. Cela rend la revue des politiques plus concrète qu’un débat sur l’impression générale de sûreté d’un agent.

La prochaine question d’un pilote est donc pratique : une personne peut-elle comprendre pourquoi une session légitime n’a rien déclenché, pourquoi une session en violation a correspondu et ce qui se passe lorsque l’évaluation ne peut pas terminer ? Si ces réponses sont claires, l’équipe possède une base pour décider où la détection doit influencer l’action.

Sources

• Cisco : présentation de Project Quarry, 28 octobre 2026.
• README de Project Quarry, consulté le 2 novembre 2026.
• Guide d’intégration applicative de Quarry, consulté le 2 novembre 2026.
• Guide d’inférence de modèles de Quarry, consulté le 2 novembre 2026. Les scénarios sont illustratifs et aucune installation ni analyse de traces de production n’est revendiquée ici.

---

Reliez la règle à ses preuves

Telli.sh est une possibilité pour conserver des sources autorisées, des notes d’évaluation et les décisions à l’appui d’une modification technique. Créer un espace de notes.