AI Extensions, November 7: Quarry and the meaning of an incomplete scan

A file read followed by an HTTP request can mean something different from the same calls in the reverse order. That is the useful starting point for Cisco's Project Quarry: rules over an agent conversation can inspect event sequences rather than judge every message alone.

Today's selection is a source review of the open-source alpha and its agent plugin, checked on November 7, 2026. I read the repository, documentation, example configuration and license. I did not install the package, connect a model, scan private conversations or reproduce Cisco's incident analysis. The latest main-branch commit was dated November 3. Activity is a maintenance signal, not a quality score.

The extension is a route into a detector

The plugin documentation describes five read-only tools: reference search, rule compilation, decision trees, decision-flow counts and scans of explicit conversation JSON. The plugin exposes the installed Quarry engine through MCP to coding-agent hosts. Its scan tool does not itself read files or saved sessions. The host may have separate file access, so this is a tool contract, not a promise that an entire agent session is isolated.

The documented setup uses the repository as one installation unit and a locked uv launch configuration. The README lists Python 3.11 through 3.13. No separate provider credential is needed for the local examples. Adding a semantic model changes that boundary: the application registers an adapter, whose endpoint can receive selected conversation data. Review that path before handing it a real trace.

The repository's actual LICENSE is Apache 2.0. Redistribution comes with its notice and license conditions, and the software carries no warranty under the license. The README labels the DSL alpha and warns it may change before 1.0. Pin a reviewed revision for a trial; do not treat today's rule syntax as a permanent interface.

What the rule engine evaluates

According to How Quarry works, selected rules are parsed, validated and compiled into deterministic finite automata when loaded. The scanner builds a finite event trace from the supplied conversation. An assistant message with a tool call contributes both a message event and a tool-call event. Event positions therefore need not equal message-array indexes.

Local checks can inspect tool names, argument values, text and counts. Optional model checks turn scores or categories into predicates used by the same rule logic. The automaton follows a deterministic path given the predicate results; an external model can still produce different results on different calls. "Deterministic" does not remove uncertainty introduced by a model.

The docs' read-then-send example checks a sensitive path read before an HTTP request to a specified host. A match proves that stated pattern on the supplied trace. It does not prove that the request contained the file's bytes. To support that stronger claim, the rule must compare or capture relevant values, and the recording must include them. Unrecorded activity remains outside the scanner's view.

Preserve the third outcome

The result contract deserves as much attention as the rule syntax. The README gives the CLI three exit outcomes: 0 for a complete scan without matches, 1 for a complete scan with matches, and 2 for invalid input or an incomplete scan. A timeout, evaluation error or malformed input cannot be folded into "nothing found."

The application integration guide tells callers of DSLScanner to check status before using matches. QuarryGuard performs that status check before returning. This original wrapper sketch follows that documented order; it has not been run and is not an enforcement implementation.

def classify_supplied_trace(scanner, conversation):
    result = scanner.scan_data(conversation)
    result.raise_for_status()  # invalid/incomplete must not become clean
    return "matched" if result.rule_matches else "complete_clean"

# The host must handle scan errors explicitly.
# Neither return value authorizes a tool call or a data disclosure.

A host could pause a proposed operation after a match or scan failure, but that requires a separate action boundary. A detector run after an HTTP request cannot retroactively stop that request. A clean scan cannot grant the user permission that an agent never had.

Witnesses help explain a match, within limits

Quarry can return supporting events when explanations are enabled. The docs call that a witness. For some rules, the engine removes events and reruns the rule to find a smaller supporting set. Work limits can leave extra events, and another supporting set may exist. The result is one explanation, not necessarily the shortest or a complete account of the incident.

A shortened witness also changes visual adjacency. For spacing-sensitive rules, inspect original event positions. An absence or "all messages" condition may need the whole relevant set; a static condition can match with an empty witness. Empty evidence is not automatically a failed scan.

The engine masks some recognized secret patterns and truncates excerpts. That is not a safe-sharing guarantee. Witnesses, validation errors and model requests may still contain sensitive conversation material. The integration guide specifically warns against forwarding raw diagnostics to public telemetry. Keep explanations behind the same access rules as the traces they describe.

A trial I would run before a production decision

Start with invented data. Define one narrow rule, compile it, and keep a matching read-then-request fixture beside a reverse-order fixture. Add a benign request to an unrelated host, malformed arguments and an intentionally over-limit input. Record the rule revision, complete status, matches and original event positions. These are proposed cases, not reported Quarry results.

Reviewed rule -> compile/admit resources -> candidate scanner
Invented trace -> validate -> evaluate -> complete clean / complete match
                                 |
                           invalid or incomplete
                                 |
                         separate host error policy

The configuration guide describes input, deadline, compiler and model-call limits. Keep them enabled for untrusted input. A rejected large trace is a failed scan, not a shortened conversation silently declared clean. Authenticate stored compiled policies before loading them, and separate reviewed rules/configuration from untrusted conversation data.

One trap is easy to miss: the example configuration has fourteen rule files and explicitly opts into keyword stubs for four semantic examples. Its comment says not to use those stubs for production decisions. A credential-free demo of the plumbing is not a measurement of a model's ability to detect attacks.

My take

Quarry is worth a bounded source-level trial when a team needs inspectable sequence rules and explanations over recorded agent activity. Its alpha status, adapter boundary and completion contract should stay visible in that trial. Cisco's announcement discusses an incident as a counterfactual analysis, not a reproduced scan of the incident's original data. I would not turn that into a detection-rate claim.

The practical adoption question is whether a reviewed rule, the available trace and the host's response together support a specific decision. A repository badge, a successful compilation or an attractive witness cannot answer that on its own.