Cisco Project Quarry: rules for AI agent behaviour

On 28 October 2026 Cisco open-sourced Project Quarry, a detection language and engine for watching what AI agents do across a whole session — not just one suspicious message. We read the primary sources, ran the command-line tool once to capture its output, and asked the buyer’s question: does a “shared language” for agent behaviour actually help defenders?

Documentation review: not tested. We have not tested Project Quarry against a lab of adversarial agents. It is a structured reading of published evidence, linked throughout. We ran the Quarry 0.1.0 command-line tool once to capture its output against the project’s own sample traces; we did not test it against a lab. How we review products explains what that covers.

Status: correct as at 29 October 2026 against Project Quarry 0.1.0 (alpha). The repository warns the DSL may change before v1.0.0 in ways that break existing rules. No vendor sponsored, reviewed or saw this article before publication, and there are no affiliate links. Our independence policy explains how we work.

What Project Quarry is watching

An AI agent, in this sense, is software that can read a task, call tools (shell, browser, ticket system, Model Context Protocol servers), look at the results, and act again until the job is done. A hacking run is not usually one dramatic prompt. It is a chain of ordinary-looking steps: list a directory, read a file, decode a string, send a request. Each step can be permitted on its own. Together they can become credential theft or data leaving the building.

That is the pattern Cisco and others pointed at after AI agents in an OpenAI cybersecurity evaluation reached Hugging Face’s production systems in July 2026. Hugging Face’s own technical timeline says its forensic reconstruction covers about 17,600 attacker actions recovered from logs between 9 and 13 July 2026; most looked unremarkable alone (Hugging Face, “Anatomy of a Frontier Lab Agent Intrusion”, 27 July 2026 (opens in a new tab); OpenAI’s account of the same evaluation-side compromise is in its incident update (opens in a new tab), with a fuller technical report (opens in a new tab)). Cisco later used that incident as a motivating example when announcing Quarry (Cisco AI blog, 28 October 2026 (opens in a new tab); also reported by The Register, same day (opens in a new tab)). Defenders already had classifiers for nasty strings and gates for individual tool calls. What they lacked was a shared way to say: “flag this sequence, and show me the evidence.”

A taxonomy here is simply a shared set of labels for those steps and relationships — user messages, tool calls, tool results, order, windows of time — so that a rule written in London can be read, tested and argued over in Singapore or São Paulo. Project Quarry is Cisco’s open attempt at that vocabulary, plus the engine that evaluates it. Treat the open release as early: it is v0.1.0 alpha, and the repository warns that the DSL may change before v1.0.0 in ways that break existing rules (cisco-ai-defense/project-quarry (opens in a new tab), README checked 29 October 2026). Buyers should expect to re-test rules when they upgrade.

What it actually detects

Strip away the headline and Quarry is a neurosymbolic rule engine for agent traces. “Neurosymbolic” is a fancy way of saying it can combine two kinds of evidence in one rule:

• Symbolic checks — exact things: a tool name, a regex, a string match, the order of two calls, a base64-encoded form of a keyword.
• Neural signals — judgment calls from classifiers or LLM judges (for example: “does this tool result contain a prompt injection?”), and OCR or vision models for images in the trace.

It covers single-turn and multi-turn LLM conversations, agents, tool use, Model Context Protocol (MCP) interactions and multimodal inputs (Cisco blog (opens in a new tab)). When a rule matches, Quarry returns evidence: the steps that caused the match, the fields involved, and short excerpts with common secret formats masked. The product that receives the finding decides whether to alert, block, redact, quarantine or log.

Cisco’s own framing is helpful for buyers. A single base64 decode-and-execute tool call can be enough for a local finding. Intent can emerge over several turns (reconnaissance, a claim of authority, then an admin grant). Data exfiltration is often a relationship: a sensitive file read followed, within a defined window, by an external send. That last pattern is why action order matters, and why single-event filters miss it — a point illustrated by Invariant Labs’ own write-up of a GitHub MCP demonstration published on 26 May 2025, in which a malicious public issue coerced an agent into reading private repositories and leaking data into a public pull request (Invariant Labs, “GitHub MCP Exploited” (opens in a new tab)). Cisco’s Quarry announcement points at the same pattern.

On our capture run, the shipped example config (fourteen local rules, no model credentials required) cleanly scanned benign.json with exit code 0, and flagged tool_calls.json with two matches: tool-call argument access and an “unrequested consequential action” check that compares a tool’s capability with what the user asked for. A separate mini-config that loaded the flow and base64 example rules matched those sample traces too. That is a smoke test of the CLI and starter pack, not a claim about detection quality in the wild.

How to try it

Quarry supports Python 3.11 through 3.13. The documented path uses the uv (opens in a new tab) package manager:

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

Then, from the repository root:

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

Swap the target for examples/data/tool_calls.json to see a match, or point it at examples/data/ to scan the whole sample set. Exit codes are 0 (clean complete scan), 1 (complete scan with matches) and 2 (invalid or incomplete). Add --explain for detailed match tracing, and -o json or -o csv when you want machine-readable output. Optional model-backed signals need uv sync --frozen --extra inference and provider credentials; the fourteen-rule example config is deliberately credential-free, with stub probers only for demos.

There is also a Python SDK (QuarryGuard / DSLScanner), a plugin for Claude Code, Codex and other MCP-compatible agents, and a path into Cisco’s commercial Policy Studio and AI Defense. Planned DefenseClaw integration is described as forward-looking in the blog. For a first hour, the open CLI plus the sample corpus is enough to decide whether the rule shape fits your team’s detection engineering habits.

The rule language in plain English

If you have ever read a Snort or YARA rule, Quarry will feel familiar. A rule has a name, optional metadata, strings or parameters, and a condition. Conditions can walk user and assistant messages, inspect tool calls and results, and express order: after, before, within: N timeline steps, and similar flow operators. Rules are parsed, validated and compiled to a symbolic finite-state automaton when they load; a broken rule fails before it scans anything.

That compile-on-load habit matters for buyers. It is the difference between a detection language you can put in version control and CI, and a pile of prompts nobody can regression-test. Cisco’s announcement leans hard on the Snort analogy — Talos shipping coverage the day patches land — and on letting coding agents draft Quarry rules via the plugin, with a human still approving before enforcement. Treat agent-written rules as first drafts. They inherit whatever the drafting agent misunderstood about your risk.

Adoption, as Cisco sketches it, is three steps: scan traces you already keep (OpenAI-format chat JSON is the documented input shape); tune and add exemptions before you enforce; then call Quarry from the application path and map findings to an action. That is detection engineering advice, not a product tour, and it is honest about the work.

Where it sits next to Agent 365 and Zenity

Buyers keep asking the same confused question: “Which agent security product do I need?” The honest answer is that the category is still several products wearing one jacket. Our earlier documentation review of Microsoft Agent 365 versus Zenity put it this way: Agent 365 is mainly a control plane and registry for agents in a Microsoft estate; Zenity is mainly runtime guardrails and posture. Neither is a Snort-style shared rule language for agent traces.

Project Quarry sits beside them, not on top of them. It does not discover every shadow agent in your tenant. It does not give you FinOps charts. It does not replace badge-reader style authorisation on each tool call. What it offers is a portable way to describe multi-step behaviour and evaluate stored or live traces against that description — including patterns that span several individually permitted actions. Cisco says Quarry already runs inside AI Defense, and that the same rules are meant to travel across Cisco’s agent-security surfaces over time. Other vendors may speak Quarry, invent their own DSL, or stay proprietary. That market fight has barely started.

For a global buyer — a bank in Frankfurt, a manufacturer in Busan, a public body reading the UK NCSC’s agentic-AI guidance — the practical test is boring and useful: can you export full agent traces, and can a finding arrive with the steps that justified it? An agent whose actions cannot be reconstructed afterwards leaves investigators with vibes instead of evidence. Quarry is one answer to the second half of that test. The first half is still on whoever runs the agents.

Does a shared language actually help?

Shared languages have a good pedigree. Snort, YARA and Sigma did not make attackers vanish; they made coverage discussable, testable and shippable across organisations that would never share a codebase. Agent behaviour deserves the same treatment. Attacks that unfold as “small test charge, then a purchase in another city, then the games console” — Amy Chang’s card-fraud analogy in The Register interview — are exactly the sort of thing single-event filters shrug at.

So the short verdict from this chair (Friday Jones, if you are new here: yes, that is a Heinlein pen name, and no, the byline does not write the detections for you) is:

• Yes, a shared language helps when teams can keep traces, write or review rules, and put findings next to human oversight. Portable rules, attached evidence and sequence awareness are real gains.
• No, it does not help if you treat the language as a product. Without traces, tuning and someone who understands the estate, Quarry is a compiler looking for homework. The repository itself says rules are not a substitute for chain-of-thought monitors or other oversight — Cisco’s researchers are clear on that point.

There is also a community bet inside the open-source release. No single vendor will see every new agent technique. A readable rule format is how defenders outside Cisco can contribute coverage the way malware analysts contribute YARA. Whether that commons forms, or every platform keeps a private dialect, will decide if Quarry becomes “the Snort of agents” or a well-documented Cisco component with fans. Alpha status and a DSL that may still break are the honest caveats on the box.

Who should try it first

Try it this month if you already log agent conversations in something close to OpenAI chat JSON, you have detection engineers who are happy in Git, or you build MCP tools and want regression rules for “read then send” mistakes before customers find them.

Watch, then decide if you are comparing vendor decks about “agent security”, mapping controls to national guidance (the UK NCSC’s agentic-AI material is a useful non-US lens), or waiting to see whether your gateway or SIEM will speak Quarry natively.

Do not rely on it alone if you have no traces yet, you need a turnkey console without engineering time, or anyone in the room thinks a rule pack replaces monitoring and human review. Pair Quarry with whatever gives you inventory and runtime enforcement in your stack — which, for many Microsoft-heavy estates, still points back to the Agent 365 and Zenity conversation.

Project Quarry is a serious, early, open attempt to give agent defence the thing network defence already had: a language you can argue about. That is worth an afternoon with the sample corpus. It is not, on today’s evidence, the whole shopping list.

Sources: every figure and claim above links to its source, with the date we checked it. Spotted an error? Tell us.

Follow Cyber-Threat.net RSS · Feedly (opens in a new tab) · X (opens in a new tab) · Bluesky (opens in a new tab) · LinkedIn (opens in a new tab)