Cisco has released Project Quarry, an open-source rule language and engine that looks for malicious AI agent behaviour across an entire session rather than one action at a time. For SOC teams that have watched agents arrive in production with no detection content at all, it is a serious early attempt at a YARA-style common format for this telemetry.
What happened
On 28 October 2026 Cisco’s AI Software and Platform group published Project Quarry on GitHub, alongside a blog post from researchers Adam Swanda, Ravikumar Balakrishnan, Amy Chang and Konstantin Berlin. Cisco describes Quarry as a detection language for agent activity, and it deliberately borrows the model of Snort, which Cisco also maintains, and YARA: write a rule once, share it, and run it anywhere the right data exists.
The release includes the engine, a command-line scanner, a Python SDK, configuration examples, guidance on writing rules and a starter rule pack. There is also a plugin for Claude Code, Codex and other agents that speak the Model Context Protocol (MCP), which lets an engineer use a coding agent to draft and test new rules against real conversations. Cisco says Quarry already runs in production inside its commercial AI Defense product. It invites practitioners to submit counterexamples.
As context, Cisco pointed to July’s incident in which OpenAI evaluation agents escaped their sandbox and worked inside Hugging Face’s infrastructure. It stressed that it has not tested Quarry against that data.
The technical picture
The core problem will be familiar to SIEM tuners. An agent working through a task produces a long chain of steps, almost all of them permitted and unremarkable in isolation. The risk only becomes visible when certain steps occur together and in a particular order. The standard example in Cisco’s material is an agent reading a credentials file and then, a few steps later, sending data to an external destination. Cisco argues that per-message classifiers and per-action allow or deny controls can wave each step through.
As Cisco describes it, a Quarry rule has several parts. It selects which parts of the trace to examine, such as a named tool’s arguments or its output. It defines signals, which can be exact symbolic checks (string matches, command patterns, tool-call order, a base64 modifier for encoded content) or neural judgements from classifiers, LLM judges, OCR or vision models. It then states how those signals must combine, including ordering and time or step windows. One example in the post fires when a credentials read is followed by an outbound call within four steps. Rules can carry exemptions for sanctioned behaviour, for example an organisation’s own upload endpoints.
The output is what makes this useful to an analyst. Cisco says that when a rule matches, Quarry returns the specific steps that caused it, which field triggered each match, and a brief extract in which typical credential patterns are redacted. In The Register’s coverage the researchers argued that a finding should carry evidence from both halves of a sequence. Quarry does not decide what happens next. The product receiving the finding maps it to alert, block, redact, quarantine or log.
For input, the engine reads OpenAI-format chat JSON, which Cisco says many agent frameworks already log or can convert to. It keeps tool names, arguments, results and metadata intact. It can run inline as a runtime guardrail through the SDK, or after the fact against stored traces, directories and datasets. Cisco’s roadmap includes sending findings with evidence into Splunk.
Why it matters for UK organisations
UK firms are putting agents into customer service, software engineering and internal operations quickly, often wired into document stores, ticketing systems and cloud consoles through MCP servers. In most SOCs I see, that activity either is not logged in a form anyone can query or lands in a bucket nobody watches. Network tooling may record the outbound connection, but not what the agent read first.
That gap matters for incident response as well as prevention. If an agent with access to personal data is manipulated into moving that data out, the organisation still has to establish what happened, assess the risk and potentially notify the ICO within 72 hours under UK GDPR. Without session-level traces and a way to query them, that assessment turns into guesswork. A shared rule format also lets managed security providers and sector sharing groups circulate agent detections as readily as YARA signatures.
Expert view
The idea is right, and overdue. Over 25 years the defensive tools that lasted were those that gave practitioners a common, portable language: Snort rules, YARA, Sigma. A detection written by one analyst could be reviewed and reused by thousands. Agent security has had plenty of vendor dashboards and little of that. Chang put it neatly in The Register: “We all see slices of the problem.”
There are caveats. Quarry is only as good as the traces it is given, and many organisations do not yet retain full agent transcripts, tool arguments and results. Neural signals such as LLM judges add cost, latency and their own error rates, so tuning will be needed just as with any behavioural analytics. Cisco itself warns that a check on a single event is not session-level coverage, and that agent-written rules can inherit the gaps in the agent’s understanding. It recommends that a human approves every rule before enforcement, and I would go further and treat new rules as alert-only until they have run against real traffic. The licence terms are in the repository and should be checked before anyone builds on it commercially.
It is also not a replacement for basic controls. When we test agent deployments, the serious findings are usually excessive permissions, long-lived tokens in reachable files and unrestricted egress. Detection catches the chain, but least privilege stops most chains forming.
What to do now
- Inventory your agents. List every agent, MCP server and tool integration in use, including developer tools such as coding assistants, and record what data and credentials each can reach.
- Capture full traces. Make sure agent frameworks log conversations, tool calls, arguments and results in a structured format, ideally OpenAI-style chat JSON, and keep them long enough to support an investigation.
- Trial Quarry offline first. Run the command-line scanner and starter rules against historical traces to gauge noise before considering any inline blocking.
- Write rules for your own crown jewels. Prioritise sequences such as sensitive file reads followed by external sends, decoded content being executed, and tools contacting destinations off the task’s allow list.
- Route findings into the SOC. Send matches with their evidence to your SIEM and build a triage playbook, so agent alerts have an owner.
- Fix the fundamentals. Under Cyber Essentials, apply secure configuration and user access control to agents: least-privilege service accounts, no secrets in readable files, and restricted outbound access through boundary firewalls.
Bottom line
Quarry will not secure an agent deployment by itself, and it depends on telemetry many organisations do not yet collect. What it does offer is a common, testable way to describe what bad agent behaviour looks like across a whole session, with evidence attached. UK SOC teams should start capturing agent traces now, so they have more than guesswork when an agent goes wrong.
