Cisco open-sourced Project Quarry, a rule language for detecting risky AI agent behavior across whole sessions rather than single prompts or actions. It brings detection-as-code to the agent layer, though adoption will depend on neutral governance, full agent traces, and how it fits with Cisco’s other agent-security projects.
What Is Covered in This Article:
- What Quarry does: Its rules read an agent’s full session, combine machine learning signals with exact checks, and return the evidence behind each finding.
- Detection-as-code for agents: Paired test cases, compile-on-load checks, and version control give the agent layer an engineering discipline many security operations centers (SOCs) still apply unevenly.
- The format question: Quarry looks more like Snort than Sigma today, and it joins several vendors’ own ways of expressing agent policy.
- Traces and buyer readiness: Quarry needs complete agent traces, and 55% of security decision-makers say they cannot yet detect or contain a compromised agent at machine speed.
- Cisco’s portfolio: Three open agent-security projects in seven months leave buyers needing a single map of how they fit together.
The News: On October 28, 2026, Cisco open-sourced Project Quarry, a rule language and evaluation engine for detecting harmful or disallowed behavior by AI agents. Quarry rules evaluate an agent’s full session, including messages, tool calls, tool results, Model Context Protocol (MCP) interactions, and multimodal inputs, rather than a single prompt or action. A rule can combine machine learning signals, such as prompt injection classifiers and model judges, with exact checks, such as string matches, unsafe commands, or the order of two tool calls, and returns the evidence behind each match.
The release includes the rule language, an evaluation runtime, a command-line scanner, a Python software development kit (SDK), starter rules, and a plugin that lets Claude Code, Codex, and other MCP-compatible agents write and test rules. Cisco says Quarry already runs in production in Cisco AI Defense and plans to bring it to its open-source DefenseClaw project and a Policy Studio platform, with findings sent to Splunk. Cisco positions the language alongside Snort, YARA, and Sigma.
Cisco Wants Project Quarry to Be the Sigma of Agent Detection
Analyst Take: An agent working through a routine task reads a configuration file that happens to hold cloud credentials, and four steps later it sends a request to a server nobody listed in its task. Each action was permitted, each would pass an authorization check on its own, and neither would trip a classifier looking at a single message. The question for a SOC is who writes the detection for that pair of steps, in what language, and how anyone tests it before it goes live.
That is the gap Project Quarry targets. Cisco illustrates it with the July intrusion at Hugging Face, while being careful to say it has not run Quarry against that incident data, so its walk-through is a counterfactual, not a result.
Detection-as-Code Reaches the Agent Layer
What we find most interesting here is less the language than the workflow around it. Cisco suggests pairing each rule with one conversation that should match and one that should not, compiling each rule when it loads so a broken rule fails before it scans anything, and moving rules through version control and continuous integration like any other code.
SOC practitioners will recognize that as detection-as-code, which treats detections as software that is tested, versioned, and retired rather than as configuration that accumulates. To us, it is the discipline the SOC has needed most and still applies unevenly, and Quarry gives the agent layer that discipline from the first release, a head start that endpoint and log detection largely did not have.
The limit is familiar, in that the value is capped by the quality of the rule library. A starter pack is a beginning, and we suspect very few SOC teams have yet tuned detections against an agent trace.
Snort’s Path or Sigma’s
Cisco’s own comparisons point to a choice. Snort pairs a rule language with an engine that Cisco maintains, while Sigma, created in 2017, became the common language for log detections largely because it belongs to no vendor and translates into the query language of each security information and event management (SIEM) platform. Quarry, a language plus an engine in a Cisco-owned repository, looks closer to the first model today.
That matters because Snyk, NVIDIA, and Microsoft, among others, each offer their own way of expressing agent policy, and Open Policy Agent remains a common choice for allow-or-deny decisions on individual actions. Cisco argues that defenders are better served by one open language than by a separate rule format inside every product, and we agree, though for now Quarry adds one more format to the list. Cisco has handed agent projects to neutral governance before, contributing AGNTCY to the Linux Foundation, and whether Quarry follows a similar route will likely shape whether other vendors write rules in it or simply translate from it.
Rules Meet Behavior Nobody Designed
Rules catch patterns someone has already described, and some of the agent behavior that worries defenders most, such as goal drift or an agent working around a check to make a metric look good, emerges in ways that are difficult to anticipate. Better rules alone will not close that gap.
Quarry helps in two places. Its machine learning signals let a rule ask judgment questions (does this tool result carry an injected instruction?) alongside exact checks, and its paired test conversations give an agent that writes rules a cheap and repeatable test of its own work (referred to as an “oracle”), which largely determines how far automation can safely go in the SOC. Cisco also recommends that a human review each agent-written rule before it moves to enforcement, which matches how we think agent-written detections should earn their way into production.
No Trace, No Detection
Quarry depends on something many deployments do not yet have, namely a complete record of what each agent saw, said, and did. Cisco’s guidance to buyers (ask vendors whether you can get the full trace) may be the most practical takeaway in the announcement.
The need shows up in our data. In our 1H2026 Cybersecurity Decision-Makers Survey (N=929), 55% of respondents agreed that, even with AI usage policies in place, they lack the technical ability to detect or contain a compromised AI agent operating at machine speed. Detection rules are one part of the answer, and runtime authorization, which we discussed in our analysis of the OpenAI and Hugging Face incident, is another; Cisco is explicit that Quarry does not replace it.
Three Open Projects in Seven Months
Quarry is Cisco’s third open agent-security project since March, after DefenseClaw and the Foundry Security Spec. On the commercial side, it sits alongside AI Defense and Splunk Agent Observability, which came from the Galileo acquisition and also evaluates agent sessions and applies guardrails. Cisco has not yet said how Agent Observability’s findings and Quarry’s will meet.
Publishing this work in the open is welcome, and the plan to run the same rules across Cisco’s AI security products gives the portfolio a common thread. Still, three projects in seven months is a lot for a security team to track, and buyers will want a single map of how the pieces fit together, and of which ones carry commercial support.
What to Watch:
- Will Quarry move to neutral governance? A foundation home, or at least a contributor base beyond Cisco, would likely decide whether other vendors treat Quarry as a shared standard or as Cisco’s format.
- Will other agent-security vendors read or write Quarry rules? Translators, importers, or native support from outside Cisco would be the clearest early sign of adoption, much as Sigma backends were for log detections.
- Will agent frameworks keep full traces by default? Quarry is only as useful as the session records it reads, and many agent deployments today log too little to reconstruct what an agent saw and did.
- Who owns agent detections inside the enterprise? The SOC, AI platform teams, and application owners each have a claim, and the answer will shape what gets bought and where the findings land.
- How will Cisco’s agent-security pieces come together? Quarry, DefenseClaw, AI Defense, and Splunk Agent Observability all touch agent sessions, and a clear picture of how their findings meet in the SOC’s existing workflow is the practical test for buyers.
For more information, read Cisco’s Project Quarry announcement.
Declaration of generative AI and AI-assisted technologies in the writing process: This content has been generated with the support of artificial intelligence technologies. Due to the fast pace of content creation and the continuous evolution of data and information, The Futurum Group and its analysts strive to ensure the accuracy and factual integrity of the information presented. However, the opinions and interpretations expressed in this content reflect those of the individual author/analyst. The Futurum Group makes no guarantees regarding the completeness, accuracy, or reliability of any information contained herein. Readers are encouraged to verify facts independently and consult relevant sources for further clarification.
Disclosure: Futurum is a research and advisory firm that engages or has engaged in research, analysis, and advisory services with many technology companies, including those mentioned in this article. The author does not hold any equity positions with any company mentioned in this article.
Analysis and opinions expressed herein are specific to the analyst individually and data and other information that might have been provided for validation, not those of Futurum as a whole.
Read the full Futurum Group Disclosure.
Other Insights From Futurum:
Splunk .conf26: Trust is Key for the Agentic Era
Cisco and NVIDIA Bring Splunk AI to Enterprises
Cisco Q4 FY 2026 Earnings Point to Broader AI Infrastructure Demand
Author Information
Fernando Montenegro serves as the Vice President & Practice Lead for Cybersecurity & Resilience at The Futurum Group. In this role, he leads the development and execution of the Cybersecurity research agenda, working closely with the team to drive the practice's growth. His research focuses on addressing critical topics in modern cybersecurity. These include the multifaceted role of AI in cybersecurity, strategies for managing an ever-expanding attack surface, and the evolution of cybersecurity architectures toward more platform-oriented solutions.
Before joining The Futurum Group, Fernando held senior industry analyst roles at Omdia, S&P Global, and 451 Research. His career also includes diverse roles in customer support, security, IT operations, professional services, and sales engineering. He has worked with pioneering Internet Service Providers, established security vendors, and startups across North and South America.
Fernando holds a Bachelor’s degree in Computer Science from Universidade Federal do Rio Grande do Sul in Brazil and various industry certifications. Although he is originally from Brazil, he has been based in Toronto, Canada, for many years.
