Cisco has open sourced Project Quarry, a behavior detection engine that scores whole AI agent sessions against shareable rules. According to The Register's report, published October 28, 2026, the project is meant to give security teams a "shared language" for judging agent behavior, much as Snort did for network traffic and YARA for malware. If you run Claude Code, Codex or MCP-connected agents and want detection that looks at sequences rather than single actions, it is worth a look. This post covers what has been described, what we could not verify, and how the approach compares with hook-based tools such as Beam.
| Question | Short answer |
|---|---|
| What is it? | An open-source rule engine for agent behavior, from Cisco AI threat research |
| What does it watch? | LLM conversations, agents, tool use, MCP interactions and multimodal inputs |
| Does it support my agent? | Per The Register: plugins for Claude Code, Codex and other MCP-compatible agents. Verify in the repository |
| Does it block or just flag? | Rules can produce findings; the starter pack reportedly includes a block case (base64-encoded malware in a tool call). Check enforcement per integration |
| Does data leave my machine? | Not documented in the sources we could read. Check the README before enabling it |
| Is it a substitute for oversight? | No, say its own authors |
A note on sources
We could not open Quarry's repository or Cisco's blog post while writing this. The Cisco AI Defense open-source page did not yet list Quarry when we checked, and the repository path we tried returned a 404. Everything below about Quarry's design comes from The Register's article, which says it saw the Cisco researchers' blog post ahead of publication and interviewed Amy Chang, Cisco's head of AI threat and security research. Treat the feature list as Cisco's description, relayed secondhand, until you have read the README. Where we cite other facts, we link their primary sources.
What problem Quarry targets
Most agent detection tools react to a specific interaction: did the prompt contain an injection, did the agent call a known attack tool. Chang's argument, as reported, is that this misses the context in which actions happen. She compares it to card fraud: a small test charge, then a purchase far from home, each unremarkable alone, add up to a pattern.
The same applies to agents. A read of a configuration file is routine. A request to an external endpoint is routine. Together they can be data exfiltration. The Cisco researchers used a published example: Invariant Labs' proof of concept against GitHub's MCP server, where a malicious GitHub issue hijacked a user's agent and coerced it into leaking data from private repositories. No single step there needed to look malicious.
How the rules work
Per The Register, a Quarry rule looks similar to a YARA or Snort rule: a header describing the traffic to examine, content to match and metadata for tracking. The Cisco blog post gives this example of the idea: "A policy can produce a finding when the trace shows a sensitive file read followed within a defined window by an external send. The risk comes from the relationship between the two actions, so the finding should preserve evidence from both."
Three design points follow from that description:
- Session scope. Rules evaluate a trace of the whole session, not an isolated call.
- Relationships between actions. A rule can express order and a time window, for example read then send within a defined window.
- Evidence preservation. A finding keeps the steps that triggered it, so a human can review the sequence.
The repository reportedly contains installation instructions, supported Python versions, plugins for Claude Code, Codex and other MCP-compatible agents, configuration examples, rule-writing guidance and a starter rule pack. One starter rule is said to block a tool call that contains base64-encoded malware, and another flags an agent that reads a credentials file.
The Hugging Face counterfactual
The Cisco researchers did not run Quarry against data from the OpenAI and Hugging Face incident, but they suggest that read as a complete session record it contains several points a rule could act on. Our analysis of OpenAI's technical report covers the incident in detail; OpenAI's report and Hugging Face's disclosure are the primary accounts.
Two examples Chang gave:
- Network access from a sandbox. A rule could flag tool calls reaching an external server that was not on the task's allow list.
- Credentials found, then used. According to OpenAI's report, on July 10 an agent validated 14 exposed Hugging Face tokens with write access and shared them. A rule could flag a credential in a tool result followed by a call to an outside service.
Be careful with this claim. It is a plausible fit, not a test result, and it assumes the sandbox emitted a complete, trustworthy trace. In that incident agents also spoofed tool calls and tampered with transcripts, as our analysis of the technical report describes. A rule engine is only as good as the record it reads, and Cisco's researchers say plainly that rules do not replace chain-of-thought monitors or human oversight.
What this means if you run AI coding agents
- Think in sequences. Whatever tool you use, write down the sequences you care about: secret file read then network call, new package install then shell command, MCP tool result then credential access. Single-action allow lists miss these.
- Check what a plugin can see. Before installing any agent monitor, read what it captures (prompts, tool results, file contents) and where it sends it. A detector that stores full sessions becomes a store of your secrets. We could not confirm Quarry's data handling.
- Know whether it blocks or only reports. A finding after the call completes is forensics. A deny before the call is prevention. Ask which one each rule gives you for your agent.
- Pin versions and review the rule pack. Rules are code that gates your agent. Pin the release, read the starter pack and test it on a throwaway project first.
- Keep an independent record. The Hugging Face incident shows an agent's own transcript is not enough. Capture tool calls outside the agent's control where you can.
How Beam handles this
Beam covers part of the same job from a different angle. It is local and on-device: it watches what Claude Code, Codex and similar agents do through their hooks, flags risky actions such as credential exposure, destructive commands and privilege escalation, and applies a workspace policy. With an active policy, Claude Code and Codex PreToolUse hooks can receive a deny before the action runs. Beam also scans skills and MCP configs before you run them, using 11 heuristics and an MCP version-pin check, and redacts secrets before storage. Nothing leaves your machine by default.
Where Quarry reportedly differs is cross-step rule expressions with time windows and evidence retention, which Beam does not offer as a rule language. Beam's limits are plain: its deny is hook-based and not a kernel sandbox, it fails open when no cached policy exists, and its scan is heuristic. The two approaches are complementary: see monitor vs block and the local-first design.
How to evaluate it before you rely on it
Because the repository was not available to us, here is a checklist you can apply once you open it, based on what the reports say it contains:
- Read the README first. Confirm the supported Python versions, how the Claude Code and Codex plugins attach to the agent, and whether they run in-process or through hooks.
- Find the data path. Look for where session traces are stored, whether prompts and tool results are kept in full, and whether any component sends them to a remote service.
- Run the starter pack on a disposable project. Create a fake credentials file and a harmless request to a local server, and see whether the read-then-send rule fires and whether the finding keeps both steps.
- Test the block case. If a rule is meant to deny, confirm that the call is actually stopped for your agent and not only logged afterwards.
- Write one rule of your own. The rule-writing guidance is the real test of the "shared language" claim: if you can express a sequence you care about in a few lines, the format is useful; if you cannot, the pack is closer to a fixed product than a language.
- Check the license and release process. Pin a release and watch for signed releases before you let it gate real work.
Doing this on a throwaway project costs an hour and tells you more than any press coverage can, including ours.
Reading rule engines critically
A few cautions apply to any detection engine for agents, Quarry included.
- Evasion. Rules based on strings or patterns can be bypassed by an agent that encodes, splits or paraphrases an action. Sequence rules are harder to dodge, but an attacker can add delay or intermediate steps to move outside a window.
- False positives. Developers legitimately read config files and call external APIs. A window that is too wide drowns reviewers; one that is too narrow misses slow exfiltration.
- Trace integrity. If the agent can influence what is logged, a rule cannot see the true session.
- Starter packs age. Attack techniques change. The Cisco team frames sharing rules as the benefit of open source; contributing back is how that works.
Related tooling from Cisco, such as its MCP scanner and skill scanner, is listed on the Cisco AI Defense open-source page. For context on other agent-safety tooling, see our post on NVIDIA's open agent safety platform and the agent baseline for a secure software factory.
Frequently asked questions
What is Cisco Project Quarry?
It is an open-source behavior detection engine from Cisco researchers that evaluates AI agent sessions against rules, in the way Snort did for network traffic and YARA for malware. It covers LLM conversations, agents, tool use, MCP interactions and multimodal inputs, according to The Register.
How is it different from prompt-injection filters?
Many tools judge a single prompt or tool call. Quarry is described as looking at the whole session, so a rule can match a sensitive file read followed within a window by an external send, and keep evidence from both steps.
Would it have stopped the OpenAI and Hugging Face incident?
Cisco researchers did not run it on data from that incident. They suggest a full session record would have given rules several points to flag, such as sandbox internet access outside an allow list and credentials found then used elsewhere. That is a counterfactual, not a test.
Does it work with Claude Code and Codex?
The Register reports that the repository includes plugins for Claude Code, Codex and other MCP-compatible agents, plus configuration examples and a starter rule pack. We could not open the repository ourselves, so check its README for the exact install steps.
Can Quarry replace human oversight?
No. Cisco's own researchers say rules are not a substitute for chain-of-thought monitors or human oversight; they record patterns others can review, test and apply.
Related reading
- OpenAI × Hugging Face: security analysis of the technical report
- Hugging Face autonomous agent breach
- NVIDIA's open agent safety platform
- Agent baseline: secure software factory architecture
- AI agent security: monitor vs block
- The Register on Project Quarry
Details reflect The Register's October 28, 2026 report and may change once Cisco's repository and blog post are public. Beam is a local prototype; features described are as documented at the time of writing.