An agent reads a file. Then it sends a web request. Each action might be allowed. The security question is whether the second action sends away something the first action should have kept private.

That gap between a permitted step and a dangerous sequence is the premise of Project Quarry, which Cisco announced and open sourced on October 28. The project gives defenders a language for describing patterns across an agent's conversation and actions. Its most useful promise is not that another detector can say "unsafe." It is that a finding can point to the connected steps that made it unsafe.

The trace is the unit of investigation

Cisco describes Quarry as a policy and evaluation layer over messages, tool calls, results and session context. Rules can combine exact checks, such as a string match or the order of two calls, with configured machine-learning signals. Those signals can include a classifier's score or a model's judgment.

The distinction matters because an attack need not arrive as one obviously malicious request. A suspicious instruction in a retrieved page, a later file read and an external send may each look different when examined alone. A rule that connects them can ask a more useful question: did the agent cross a boundary over the course of its work?

According to Cisco, matching rules return evidence, including the relevant steps, matched fields and short excerpts, with common secret formats masked. That can make a finding easier to investigate than an unexplained risk score. It does not prove that every sensitive value will be recognized or hidden.

Detection still needs somewhere to act

Cisco explicitly says Quarry does not replace fine-grained authorization. It also separates a finding from what a receiving product does with it, such as alerting, blocking or redacting. That is an important limit to preserve when reading the launch.

A rule finding a dangerous sequence after a completed session is useful for an investigation. The same rule evaluated before an external send could support prevention, but only if the surrounding application actually pauses the action and enforces the result. A detection engine is not, by itself, a universal stop button.

The Register's launch coverage describes Cisco's ambition as a shared language for evaluating agent behavior. Shared rules could give teams something concrete to review and compare. Whether two installations reach the same verdict will still depend on the rules, inputs and configured signals they use.

Read the alpha label before the examples

The public repository calls Quarry alpha and warns that its rule-language syntax may change before version 1.0.0. It lists Python 3.11 through 3.13 support and an Apache 2.0 license. This is a released project to evaluate, not a claim of stable interfaces or proven production coverage.

The quick-start examples carry an especially useful warning. Four semantic rules in the example configuration use deterministic keyword stubs, enabled explicitly for examples and tests. The repository says these are not for production decisions. A demonstration that matches a sample conversation should not be presented as a measured result for a real detector.

The repository also distinguishes a complete clean scan, a complete match and an invalid or incomplete scan through different command-line exit codes. Operators should preserve that third state. "The check did not finish" is not another spelling of "nothing was found."

Different layers answer different questions

Another October 28 announcement illustrates the distinction. GitHub's code scanning for AI applications is entering public preview to flag risky agent code paths in pull requests, including paths where untrusted content reaches a model with tools or data access. GitHub says it requires a GitHub Advanced Security license and is not available on GitHub Enterprise Server at this time.

That is a check on application code before it ships. Quarry evaluates recorded or live interactions. Authorization decides whether a particular action may proceed. These layers can complement each other, but one does not certify the others.

For a Quarry evaluation, start with a bounded set of traces whose expected outcomes are known. Include benign workflows that resemble attacks, incomplete records and sequences that should be stopped. Check whether the evidence explains the verdict and whether a failed scan reaches a safe handling path. Before connecting enforcement, decide what can be blocked, who reviews uncertain matches and how the workflow recovers.

The useful change is to stop treating a tool call as the whole story. A step can be permitted while the sequence is wrong. Detecting that sequence is progress. Permission to act, and the mechanism that stops an action, remain separate jobs.

Reporting note: This article analyzes public announcements, documentation and launch coverage. GigSoul has not tested Quarry or GitHub's preview. Product behavior is attributed to the published sources, not independently measured.