Cisco Project Quarry asks what an agent did across the whole task

An assistant reads a file. Later it sends a web request. Each action can be permitted, useful, and completely ordinary. The security question is whether the second action carried information from the first somewhere it should never have gone.

Cisco introduced Project Quarry on October 28, 2026 as an open-source detection language and engine for agent behavior. Instead of checking only an isolated message, it lets teams describe patterns across messages, tool calls, results, and event order. A finding includes evidence that helps explain which activity matched the rule. Cisco launch article

For teams moving agents into support, coding, or operational work, that is a concrete addition to the security toolbox. This guide explains what Quarry can contribute, how to begin with local examples, and why detecting a dangerous sequence is only one part of controlling it. The public framework is currently alpha, so a pilot should also account for rule changes before version 1.0.0. Project Quarry README, checked November 2, 2026

A Cisco ASA 5510 firewall in 2010; historical network-security hardware. Quarry is agent-behavior software, not this device. Photo: Jon 'ShakataGaNai' Davis, CC BY-SA 3.0; resized with margins. Image source · License and image notes. Official product reference.

A sequence can explain what a single event cannot

Imagine an internal support agent that can read a knowledge base and open an external issue. Both capabilities serve legitimate purposes. Now imagine an untrusted page tells it to attach an internal diagnostic file to an unrelated public issue. A rule looking only for the phrase “ignore previous instructions” may miss a more indirect instruction. A rule looking only at the permitted upload tool may miss why its arguments are inappropriate.

The sequence supplies context. What did the agent read? Which instruction preceded the upload? What data appeared in the arguments? Was that destination part of the user's task? These questions are often easier to investigate when the structured trace survives intact.

Cisco frames Quarry as combining exact checks with optional model judgments. Exact checks can express tool names, fields, strings, and order; model-backed checks can address questions requiring interpretation. The host product then decides what a finding should trigger, such as an alert or a blocked action. Cisco explanation, October 28, 2026

Our take: a good rule is a replayable question about behavior. It should be possible to point to the matched events and debate whether the rule expressed the intended policy. That is more useful than a red warning whose only explanation is that a model disliked the conversation.

An illustrative suspicious sequence: Quarry evaluates the trace and returns evidence; the integrating application owns the response.

Quarry belongs beside authorization and content checks

Authorization answers whether a particular actor may perform a particular action on a resource. A content classifier asks whether a piece of input or output has a relevant property. A trace-level detection asks how several events relate. Those questions overlap, but none becomes unnecessary because another has a convincing demo.

Cisco invokes Snort, YARA, and Sigma as precedents for readable, shareable detection languages in network, malware, and log analysis. Quarry aims to bring that style of inspectable rule to agent activity. Cisco's launch rationale The analogy is helpful as a design goal; it does not make a young alpha project as mature as those established ecosystems.

Consider the file-and-upload example again. Strong authorization can stop access to a forbidden file before a behavior rule matters. A content check can identify a suspicious instruction in a tool result. A sequence rule can connect a permitted read with an inappropriate transfer. Together, they address more of the path than any one check alone.

An alert needs enough evidence for a human to act

The benefit of a trace-based finding is that it can support a specific next step. A reviewer needs to know which events mattered, which field matched, and what surrounding context changes the interpretation. The goal is an explainable case, rather than a growing list of unexplained risk scores.

For an illustrative support workflow, a useful finding could connect an internal-document result with a subsequent send to an unapproved destination. The analyst can then ask whether the requested action authorized that transfer, whether the destination belongs to the customer, and whether the payload actually contains protected information. A broad rule that flags every file read followed by every network request would bury the interesting cases.

Precision depends on the application's vocabulary. “External” may mean outside the organization, outside an approved tenant, or simply outside one service. “Sensitive” may refer to a labeled document, a source field, or a classification result. Define those terms in the integration before writing a rule that depends on them.

The evidence itself also needs protection. A trace may contain exactly the file content or credential fragment that made the event risky. An alert useful to a security analyst may be inappropriate for a public error page. Plan access and redaction together with the rule, rather than adding them after the first incident.

Three workflows make the first pilot concrete

A first illustrative use is retrospective review of support-agent sessions. Start with a small authorized dataset containing both normal support activity and a synthetic example of an inappropriate transfer. Run the same rules across both. A good pilot shows that the team can explain a match and also explain why legitimate work remains clean.

A second use is an agent's handling of a stop condition. Suppose a task allows three attempts and requires escalation afterward. A trace can show whether the agent stopped, continued, or changed tools to pursue the same action indirectly. This is a useful policy question even when the content of every individual message is harmless.

A third is incident response. Once a team learns a newly relevant behavior pattern, it can ask whether earlier stored traces contain that pattern too. The value is faster, consistent searching across the history the organization is authorized to retain. The quality of that answer still depends on whether the earlier trace captured the fields and ordering the rule requires.

These scenarios should begin in observation mode. Retrospective findings reveal false positives without interrupting users, and they help estimate the investigation burden. A rule that looks persuasive on one synthetic trace may be too broad across everyday activity. Promotion to a live intervention should follow that learning, with a clearly owned response.

Start with the repository's local examples

The public repository uses Apache 2.0 licensing and provides Python and command-line interfaces. Its README currently lists Python 3.11 through 3.13 and a quick start based on uv. The example configuration selects 14 local rules; four semantic examples use deterministic keyword stubs explicitly intended for demonstrations and tests, rather than production decisions. Project Quarry README

The following procedure follows that published setup path. It is a starting point for a reader's own evaluation, not a claim that a deployment or live scan was performed for this article.

1. Use an isolated evaluation folder. Confirm the documented Python range and install uv through your organization's usual tool process. Keep the evaluation separate from production traces and credentials.

2. Obtain and prepare the project. Clone the official repository, enter its folder, and synchronize the pinned environment:

   BashRun in Terminal

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

3. Run the local benign example. Use the supplied configuration before adding a provider or sending any real conversation data:

   BashRun in Terminal

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

4. Inspect a matching example. Change the target to examples/data/tool_calls.json, then examine the rule and the evidence together. A match should be understandable from the events, rather than accepted because the command printed a warning.

5. Add one application-specific test pair. Create a synthetic violating trace and a near-miss legitimate trace with the same tool vocabulary. State the expected result before adjusting the rule.

6. Record the revision and result handling. The documented CLI convention is 0 for a complete clean scan, 1 for a complete match, and 2 for an invalid or incomplete scan. Preserve those distinctions in any wrapper.

The exit distinction has practical consequences. A scan that ran out of resources or received invalid input cannot be counted as a clean scan. Monitoring should make incomplete evaluations visible so the team knows whether it has a coverage gap.

Model-backed rules introduce another data boundary

Some policies need interpretation that exact matching cannot provide. A model may help assess whether a tool result attempts to redirect the agent or whether a requested action falls outside the task. Adding that judgment also adds latency, cost, provider behavior, and another possible source of error.

Quarry's model-inference documentation says a model operation can send selected messages, tool definitions, and policy text to its configured endpoint. It advises reviewing the provider's retention, logging, transport, and credentials. The documentation also describes scan deadlines and model-call budgets, with adapters expected to honor cancellation and timeouts. Quarry model-inference documentation, checked November 2, 2026

That makes the data path a design decision. A team can begin with local checks, then enable a model-backed rule only when the benefit justifies the additional processing. Before using sensitive traces, decide exactly which fields cross that boundary and who can approve the configuration. A security check should not quietly become an unexpected route for exporting the data it is meant to protect.

Keyword stubs are useful for predictable examples because they produce repeatable outcomes without a live provider. They cannot demonstrate the accuracy of a production semantic detector. Evaluate the actual configured model against labeled, relevant cases, including ordinary messages that resemble the risky ones. False positives and missed detections belong in the same review.

A production integration must own the incomplete case

The integration guide instructs applications to prepare and validate their selected rules before accepting traffic. It separates trusted policy and adapter inputs from untrusted conversations, and requires an authoritative scan status before acting on matches. Quarry integration guide, checked November 2, 2026

That contract matters most when something fails. A malformed conversation, timeout, unavailable model, or invalid rule should follow an explicit application policy. Depending on the operation, that policy could pause a consequential action, ask for review, or report that an observation was incomplete. Treating every error as “no finding” creates a silent gap.

A complete match, a complete clean result, and an incomplete evaluation have different meanings. The host must decide how each affects the user's workflow.

Version changes need the same clarity. The alpha warning means a future syntax change can require rule updates. Pin a revision for evaluation, keep representative traces, and rerun them before adopting an update. That gives the team a way to distinguish a changed policy from a changed engine.

Cisco's announcement discusses deployment within its broader AI Defense work, but the public engine's maturity should be judged on its own documented state. Planned integrations are future work. A production product using a component does not automatically provide a supported production integration for every reader's application.

Agent security needs a question people can revisit

Quarry's strongest idea is making a behavioral concern explicit enough to run again. A team can retain a rule, its version, the activity it matched, and the reason for changing it. That makes policy review more concrete than a debate over whether an agent generally seems safe.

The next question for a pilot is therefore practical: can a reviewer understand why a legitimate session passed, why a violating session matched, and what happens when the evaluation cannot finish? If those answers are clear, the team has a foundation for deciding where detection should influence action.

Sources

• Cisco: introducing Project Quarry, October 28, 2026.
• Project Quarry README, checked November 2, 2026.
• Quarry application-integration guide, checked November 2, 2026.
• Quarry model-inference guide, checked November 2, 2026. Scenarios are illustrative, and no installation or production trace scan is claimed here.

---

Keep the rule connected to its evidence

Telli.sh is one option for retaining authorized source material, evaluation notes, and the decisions behind an engineering change. Create a note workspace.