Cisco has released Project Quarry, an open-source rule language and engine for finding patterns in an agent’s recorded actions. An agent is a model running a multi-step task with tools. Quarry can connect messages, tool arguments, results and event order into one finding with supporting evidence.

The October 28 announcement, by Adam Swanda, Ravikumar Balakrishnan, Amy Chang and Konstantin Berlin, describes the intended workflow. The repository provides a Python implementation under Apache 2.0, with Python 3.11–3.13 support.

Evidence status: a published tool and vendor-described detection method. The repository calls Quarry alpha and warns that its rule syntax may change before version 1.0.0. The announcement does not supply an independently measured detection or false-positive rate.

A permitted action can become suspicious in sequence

Reading a configuration file may be legitimate. Sending an external request may also be legitimate. A rule can flag a sensitive-file read followed by an outbound send within a defined number of steps.

That pattern identifies a relationship worth investigating. It does not, by itself, prove the outgoing request contained the file or that the user prohibited it. Benign uploads and authorized integrations need representative examples and carefully reviewed exceptions.

Quarry combines exact checks on text, fields and event order with optional model judgments, such as classifying a tool result as a prompt injection. Prompt injection means untrusted content trying to redirect the agent’s instructions. A model-derived signal remains a judgment, even when an exact rule combines it with other evidence.

Cisco uses the OpenAI–Hugging Face intrusion to illustrate possible rules. It explicitly says it has not run Quarry against that incident’s data. Those proposed detections are counterfactual examples, not validated evidence that Quarry would have prevented the intrusion.

An incomplete scan is not a clean result

The repository distinguishes three command-line outcomes:

  • 0: a complete scan with no match.
  • 1: a complete scan with a match.
  • 2: an invalid or incomplete scan.

An integration that collapses every non-match into “safe” would lose that distinction. Even a complete clean scan means only that the supplied rules found no match in the supplied data.

The application-integration guide requires an authoritative result before acting. It says QuarryGuard raises on incomplete scans. Lower-level scanner integrations must check status themselves. Rule validation and compilation should happen before accepting traffic; a failed policy generation should block that generation’s deployment.

These are documented integration requirements, not a guarantee that every application using the library handles errors correctly.

The detector has its own trust and privacy boundaries

The same guide separates trusted policies and configuration from untrusted conversations and model responses. Rules, adapters, model endpoints and compiled-policy bytes need controlled permissions and provenance. Letting retrieved content rewrite the detector’s policy would cross that boundary.

Trace quality also limits coverage. Quarry accepts OpenAI-shaped conversation JSON, and its message documentation preserves tool calls and results. A single event cannot establish a multi-step sequence whose earlier actions were never supplied.

The guide warns that validation errors can contain attacker-controlled field names, roles and tool-call identifiers. Keep conversation content and those diagnostics out of public logs, metrics and client responses without appropriate redaction. Optional model adapters also define a network boundary: review where trace data goes before enabling them.

The example configuration includes deterministic keyword stubs for some semantic rules. The README explicitly limits those stubs to examples and tests. Their sample behavior is not a production classifier’s measured performance.

Evaluate on stored traces before choosing enforcement

Cisco recommends starting with existing traces, reviewing matches, and pairing rules with both matching and benign examples. Tune on representative workflows before mapping findings to blocking or other runtime actions.

Keep authorization, operating-system isolation and restricted credentials alongside detection. Quarry produces findings; the host application decides what to do with them. A useful evaluation checks missed sequences, legitimate activity wrongly flagged, missing history and incomplete scans separately.

Caveat: Cisco sells AI-security products and positions Quarry within that product strategy. Its historical attack examples illustrate intended coverage, while real-world effectiveness remains unverified by the reviewed material.