Cisco Project Quarry fragt, was ein Agent während der gesamten Aufgabe getan hat

Ein Assistent liest eine Datei. Später sendet er eine Webanfrage. Beide Aktionen können erlaubt, nützlich und völlig gewöhnlich sein. Die Sicherheitsfrage lautet, ob die zweite Aktion Informationen aus der ersten an einen Ort gebracht hat, an den sie niemals hätten gelangen dürfen.

Cisco stellte Project Quarry am 28. Oktober 2026 als quelloffene Erkennungssprache und Engine für Agentenverhalten vor. Statt nur eine isolierte Nachricht zu prüfen, können Teams Muster über Nachrichten, Werkzeugaufrufe, Ergebnisse und Ereignisreihenfolgen hinweg beschreiben. Ein Befund enthält Belege, die erklären helfen, welche Aktivität zur Regel passte. Startartikel von Cisco

Für Teams, die Agenten in Support, Programmierung oder operative Arbeit einführen, ist das eine konkrete Ergänzung des Sicherheitswerkzeugkastens. Dieser Leitfaden erklärt, was Quarry beitragen kann, wie der Einstieg mit lokalen Beispielen gelingt und warum die Erkennung einer gefährlichen Abfolge nur ein Teil ihrer Kontrolle ist. Das öffentliche Framework befindet sich derzeit im Alpha-Stadium; ein Pilotversuch sollte deshalb auch Regeländerungen vor Version 1.0.0 berücksichtigen. README von Project Quarry, geprüft am 2. November 2026

Eine Cisco-ASA-5510-Firewall im Jahr 2010; historische Netzwerksicherheitshardware. Quarry ist Software für Agentenverhalten, nicht dieses Gerät. Foto: Jon 'ShakataGaNai' Davis, CC BY-SA 3.0; mit Rändern skaliert. Bildquelle · Lizenz und Bildhinweise. Offizielle Produktreferenz.

Eine Abfolge kann erklären, was ein einzelnes Ereignis nicht erklärt

Stellen Sie sich einen internen Supportagenten vor, der eine Wissensdatenbank lesen und ein externes Issue eröffnen kann. Beide Fähigkeiten dienen legitimen Zwecken. Nun weist ihn eine nicht vertrauenswürdige Seite an, eine interne Diagnosedatei an ein sachfremdes öffentliches Issue anzuhängen. Eine Regel, die nur nach „Ignoriere vorherige Anweisungen“ sucht, könnte eine indirektere Anweisung übersehen. Eine Regel, die nur das erlaubte Upload-Werkzeug betrachtet, könnte übersehen, warum dessen Argumente unangemessen sind.

Die Abfolge liefert Kontext. Was hat der Agent gelesen? Welche Anweisung ging dem Upload voraus? Welche Daten erschienen in den Argumenten? War dieses Ziel Teil der Nutzeraufgabe? Diese Fragen lassen sich häufig leichter untersuchen, wenn die strukturierte Aufzeichnung vollständig erhalten bleibt.

Cisco beschreibt Quarry als Verbindung exakter Prüfungen mit optionalen Modellurteilen. Exakte Prüfungen können Werkzeugnamen, Felder, Zeichenfolgen und Reihenfolge ausdrücken; modellgestützte Prüfungen können Fragen behandeln, die Interpretation erfordern. Das einbindende Produkt entscheidet dann, was ein Befund auslösen soll, etwa einen Alarm oder eine blockierte Aktion. Cisco-Erklärung, 28. Oktober 2026

Unsere Einschätzung: Eine gute Regel ist eine erneut ausführbare Frage zum Verhalten. Es sollte möglich sein, auf die passenden Ereignisse zu zeigen und darüber zu diskutieren, ob die Regel die beabsichtigte Richtlinie ausdrückt. Das ist nützlicher als eine rote Warnung, deren einzige Erklärung lautet, dass einem Modell das Gespräch missfallen hat.

Eine beispielhafte verdächtige Abfolge: Quarry bewertet die Aufzeichnung und liefert Belege; die integrierende Anwendung verantwortet die Reaktion.

Quarry gehört neben Autorisierung und Inhaltsprüfungen

Autorisierung beantwortet, ob ein bestimmter Akteur eine bestimmte Aktion an einer Ressource ausführen darf. Ein Inhaltsklassifikator fragt, ob eine Eingabe oder Ausgabe eine relevante Eigenschaft besitzt. Eine Erkennung auf Aufzeichnungsebene fragt, wie mehrere Ereignisse zusammenhängen. Diese Fragen überschneiden sich, doch keine wird überflüssig, weil eine andere eine überzeugende Demo hat.

Cisco nennt Snort, YARA und Sigma als Vorbilder für lesbare, teilbare Erkennungssprachen in Netzwerk-, Schadsoftware- und Protokollanalysen. Quarry soll diese Art prüfbarer Regeln auf Agentenaktivitäten übertragen. Ciscos Begründung zum Start Als Entwurfsziel ist die Analogie hilfreich; sie macht ein junges Alpha-Projekt nicht so ausgereift wie diese etablierten Ökosysteme.

Betrachten wir erneut das Datei-und-Upload-Beispiel. Eine starke Autorisierung kann den Zugriff auf eine verbotene Datei verhindern, bevor eine Verhaltensregel relevant wird. Eine Inhaltsprüfung kann eine verdächtige Anweisung in einem Werkzeugergebnis erkennen. Eine Sequenzregel kann einen erlaubten Lesezugriff mit einer unangemessenen Übertragung verbinden. Gemeinsam decken sie mehr des Weges ab als jede einzelne Prüfung allein.

Ein Alarm braucht genügend Belege, damit ein Mensch handeln kann

Der Vorteil eines auf der Aufzeichnung beruhenden Befunds besteht darin, dass er einen konkreten nächsten Schritt stützen kann. Ein Prüfer muss wissen, welche Ereignisse entscheidend waren, welches Feld passte und welcher umgebende Kontext die Interpretation verändert. Ziel ist ein erklärbarer Fall statt einer wachsenden Liste unerklärter Risikowerte.

In einem beispielhaften Supportablauf könnte ein nützlicher Befund ein Ergebnis aus einem internen Dokument mit einem späteren Versand an ein nicht freigegebenes Ziel verbinden. Der Analyst kann dann fragen, ob die angeforderte Aktion diese Übertragung erlaubte, ob das Ziel dem Kunden gehört und ob die Nutzlast tatsächlich geschützte Informationen enthält. Eine breite Regel, die jeden Lesezugriff mit jeder folgenden Netzwerkanfrage markiert, würde die interessanten Fälle verdecken.

Präzision hängt vom Vokabular der Anwendung ab. „Extern“ kann außerhalb des Unternehmens, außerhalb eines freigegebenen Mandanten oder lediglich außerhalb eines Dienstes bedeuten. „Sensibel“ kann ein gekennzeichnetes Dokument, ein Quellfeld oder ein Klassifikationsergebnis meinen. Definieren Sie diese Begriffe in der Integration, bevor Sie eine davon abhängige Regel schreiben.

Auch die Belege selbst brauchen Schutz. Eine Aufzeichnung kann genau den Dateiinhalt oder Zugangsdatenbestandteil enthalten, der das Ereignis riskant machte. Ein für Sicherheitsanalysten nützlicher Alarm kann für eine öffentliche Fehlerseite ungeeignet sein. Planen Sie Zugriff und Schwärzung gemeinsam mit der Regel, statt sie nach dem ersten Vorfall anzufügen.

Drei Arbeitsabläufe machen den ersten Pilotversuch konkret

Eine erste beispielhafte Anwendung ist die nachträgliche Prüfung von Supportagentensitzungen. Beginnen Sie mit einem kleinen autorisierten Datensatz, der normale Supportaktivitäten und ein synthetisches Beispiel einer unangemessenen Übertragung enthält. Lassen Sie dieselben Regeln über beide laufen. Ein guter Pilot zeigt, dass das Team einen Treffer und zugleich das unauffällige Ergebnis legitimer Arbeit erklären kann.

Eine zweite Anwendung betrifft den Umgang eines Agenten mit einer Stoppbedingung. Angenommen, eine Aufgabe erlaubt drei Versuche und verlangt danach Eskalation. Eine Aufzeichnung kann zeigen, ob der Agent aufgehört, weitergemacht oder die Werkzeuge gewechselt hat, um dieselbe Aktion indirekt zu verfolgen. Dies ist eine nützliche Richtlinienfrage, selbst wenn der Inhalt jeder einzelnen Nachricht harmlos ist.

Eine dritte Anwendung ist die Vorfallreaktion. Sobald ein Team ein neu relevantes Verhaltensmuster erkennt, kann es fragen, ob frühere gespeicherte Aufzeichnungen dieses Muster ebenfalls enthalten. Der Wert besteht in schnellerer, konsistenter Suche in der Historie, die die Organisation aufbewahren darf. Die Qualität dieser Antwort hängt weiterhin davon ab, ob die frühere Aufzeichnung die von der Regel benötigten Felder und Reihenfolgen erfasst hat.

Diese Szenarien sollten im Beobachtungsmodus beginnen. Nachträgliche Befunde zeigen Fehlalarme, ohne Nutzer zu unterbrechen, und helfen, den Untersuchungsaufwand abzuschätzen. Eine auf einer synthetischen Aufzeichnung überzeugende Regel kann im Alltag zu breit sein. Der Übergang zu einem Live-Eingriff sollte auf diesen Erkenntnissen beruhen und eine klar verantwortete Reaktion haben.

Beginnen Sie mit den lokalen Beispielen des Repositorys

Das öffentliche Repository steht unter Apache 2.0 und bietet Python- und Kommandozeilenschnittstellen. Sein README nennt derzeit Python 3.11 bis 3.13 und einen auf uv basierenden Schnelleinstieg. Die Beispielkonfiguration wählt 14 lokale Regeln; vier semantische Beispiele verwenden deterministische Schlüsselwort-Stubs, die ausdrücklich für Demonstrationen und Tests statt für Produktiventscheidungen vorgesehen sind. README von Project Quarry

Das folgende Verfahren folgt diesem veröffentlichten Einrichtungsweg. Es ist ein Ausgangspunkt für eine eigene Bewertung durch Leser, keine Behauptung, für diesen Artikel sei eine Bereitstellung oder ein Live-Scan durchgeführt worden.

1. Verwenden Sie einen isolierten Bewertungsordner. Bestätigen Sie den dokumentierten Python-Bereich und installieren Sie uv über den üblichen Werkzeugprozess Ihrer Organisation. Halten Sie die Bewertung von produktiven Aufzeichnungen und Zugangsdaten getrennt.

2. Besorgen Sie das Projekt und bereiten Sie es vor. Klonen Sie das offizielle Repository, wechseln Sie in seinen Ordner und synchronisieren Sie die festgelegte Umgebung:

   BashIn Terminal ausführen

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

3. Führen Sie das lokale unbedenkliche Beispiel aus. Verwenden Sie die mitgelieferte Konfiguration, bevor Sie einen Anbieter hinzufügen oder echte Gesprächsdaten senden:

   BashIn Terminal ausführen

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

4. Untersuchen Sie ein Beispiel mit Treffer. Ändern Sie das Ziel zu examples/data/tool_calls.json und betrachten Sie Regel und Belege gemeinsam. Ein Treffer sollte anhand der Ereignisse verständlich sein, statt akzeptiert zu werden, weil der Befehl eine Warnung ausgegeben hat.

5. Ergänzen Sie ein anwendungsspezifisches Testpaar. Erstellen Sie eine synthetische regelverletzende Aufzeichnung und eine ähnliche legitime Aufzeichnung mit demselben Werkzeugvokabular. Legen Sie das erwartete Ergebnis fest, bevor Sie die Regel anpassen.

6. Erfassen Sie Revision und Ergebnisbehandlung. Die dokumentierte CLI-Konvention lautet 0 für einen vollständigen sauberen Scan, 1 für einen vollständigen Treffer und 2 für einen ungültigen oder unvollständigen Scan. Erhalten Sie diese Unterschiede in jeder umgebenden Software.

Die Unterscheidung der Rückgabecodes hat praktische Folgen. Ein Scan, dem Ressourcen ausgingen oder der ungültige Eingaben erhielt, kann nicht als sauberer Scan gezählt werden. Die Überwachung sollte unvollständige Bewertungen sichtbar machen, damit das Team weiß, ob eine Abdeckungslücke besteht.

Modellgestützte Regeln schaffen eine weitere Datengrenze

Manche Richtlinien benötigen Interpretation, die exakte Vergleiche nicht leisten können. Ein Modell kann helfen zu bewerten, ob ein Werkzeugergebnis den Agenten umzulenken versucht oder eine angeforderte Aktion außerhalb der Aufgabe liegt. Dieses Urteil fügt zugleich Latenz, Kosten, Anbieterverhalten und eine weitere mögliche Fehlerquelle hinzu.

Quarrys Dokumentation zur Modellinferenz erklärt, dass eine Modelloperation ausgewählte Nachrichten, Werkzeugdefinitionen und Richtlinientext an ihren konfigurierten Endpunkt senden kann. Sie empfiehlt, Aufbewahrung, Protokollierung, Transport und Zugangsdaten des Anbieters zu prüfen. Die Dokumentation beschreibt außerdem Scan-Fristen und Budgets für Modellaufrufe; von Adaptern wird erwartet, Abbruch und Zeitüberschreitungen zu beachten. Quarry-Dokumentation zur Modellinferenz, geprüft am 2. November 2026

Damit wird der Datenweg zu einer Entwurfsentscheidung. Ein Team kann mit lokalen Prüfungen beginnen und eine modellgestützte Regel erst dann aktivieren, wenn der Nutzen die zusätzliche Verarbeitung rechtfertigt. Entscheiden Sie vor der Verwendung sensibler Aufzeichnungen genau, welche Felder diese Grenze überschreiten und wer die Konfiguration freigeben darf. Eine Sicherheitsprüfung sollte nicht unbemerkt zu einem unerwarteten Exportweg für die Daten werden, die sie schützen soll.

Schlüsselwort-Stubs sind für vorhersehbare Beispiele nützlich, weil sie ohne aktiven Anbieter wiederholbare Ergebnisse erzeugen. Sie können nicht die Genauigkeit einer produktiven semantischen Erkennung demonstrieren. Bewerten Sie das tatsächlich konfigurierte Modell anhand gekennzeichneter, relevanter Fälle, einschließlich gewöhnlicher Nachrichten, die riskanten ähneln. Fehlalarme und übersehene Erkennungen gehören in dieselbe Prüfung.

Eine Produktivintegration muss den unvollständigen Fall verantworten

Der Integrationsleitfaden weist Anwendungen an, ihre ausgewählten Regeln vor der Annahme von Datenverkehr vorzubereiten und zu validieren. Er trennt vertrauenswürdige Richtlinien- und Adaptereingaben von nicht vertrauenswürdigen Gesprächen und verlangt einen maßgeblichen Scan-Status, bevor auf Treffer reagiert wird. Quarry-Integrationsleitfaden, geprüft am 2. November 2026

Dieser Vertrag zählt besonders dann, wenn etwas fehlschlägt. Ein fehlerhaft aufgebautes Gespräch, eine Zeitüberschreitung, ein nicht verfügbares Modell oder eine ungültige Regel sollten einer ausdrücklichen Anwendungsrichtlinie folgen. Je nach Operation könnte diese eine folgenreiche Aktion pausieren, um Prüfung bitten oder melden, dass eine Beobachtung unvollständig war. Jeden Fehler als „kein Befund“ zu behandeln, schafft eine stille Lücke.

Ein vollständiger Treffer, ein vollständiges sauberes Ergebnis und eine unvollständige Bewertung haben unterschiedliche Bedeutungen. Die einbindende Anwendung muss entscheiden, wie sich jeder Fall auf den Nutzerablauf auswirkt.

Versionsänderungen brauchen dieselbe Klarheit. Die Alpha-Warnung bedeutet, dass eine künftige Syntaxänderung Regelaktualisierungen erfordern kann. Fixieren Sie eine Revision für die Bewertung, bewahren Sie repräsentative Aufzeichnungen auf und führen Sie diese vor der Übernahme eines Updates erneut aus. So kann das Team eine geänderte Richtlinie von einer geänderten Engine unterscheiden.

Ciscos Ankündigung bespricht den Einsatz innerhalb seiner umfassenderen AI-Defense-Arbeit; die Reife der öffentlichen Engine sollte jedoch anhand ihres eigenen dokumentierten Zustands beurteilt werden. Geplante Integrationen sind künftige Arbeit. Ein produktives Produkt, das eine Komponente verwendet, liefert nicht automatisch eine unterstützte Produktivintegration für die Anwendung jedes Lesers.

Agentensicherheit braucht eine Frage, zu der Menschen zurückkehren können

Quarrys stärkste Idee ist, ein Verhaltensproblem so ausdrücklich zu formulieren, dass es erneut geprüft werden kann. Ein Team kann eine Regel, ihre Version, die passende Aktivität und den Änderungsgrund aufbewahren. Das macht die Richtlinienprüfung konkreter als eine Debatte darüber, ob ein Agent allgemein sicher wirkt.

Die nächste Frage für einen Pilotversuch ist deshalb praktisch: Kann ein Prüfer verstehen, warum eine legitime Sitzung bestanden hat, warum eine regelverletzende Sitzung einen Treffer erzeugte und was geschieht, wenn die Bewertung nicht abschließen kann? Sind diese Antworten klar, hat das Team eine Grundlage für die Entscheidung, wo Erkennung das Handeln beeinflussen sollte.

Quellen

• Cisco: Vorstellung von Project Quarry, 28. Oktober 2026.
• README von Project Quarry, geprüft am 2. November 2026.
• Leitfaden zur Anwendungsintegration von Quarry, geprüft am 2. November 2026.
• Leitfaden zur Modellinferenz von Quarry, geprüft am 2. November 2026. Die Szenarien dienen der Veranschaulichung; eine Installation oder ein Scan produktiver Aufzeichnungen wird hier nicht behauptet.

---

Verbinden Sie die Regel mit ihren Belegen

Telli.sh bietet eine Möglichkeit, autorisiertes Quellenmaterial, Bewertungsnotizen und die Entscheidungen hinter einer technischen Änderung aufzubewahren. Einen Notizbereich erstellen.