Cisco has announced Project Quarry, an open-source rule language intended to detect AI agent attacks that are difficult to spot in isolated events because each individual action may appear harmless. The idea is to help security teams identify patterns of behaviour that only become risky when several steps are linked together.

For European businesses adopting AI agents, LLM-based assistants and workflow automation, this is a relevant signal. As companies connect AI systems to internal tools, documents, customer data and external services, security risks increasingly come from multi-step behaviour rather than a single obviously malicious command.

What happened

According to the reported announcement, Cisco has open sourced Project Quarry. It is described as a rule language designed to detect attacks involving AI agents where the threat emerges across a sequence of otherwise benign actions.

This matters because AI agents are often given access to multiple systems and can perform chained tasks such as retrieving information, calling APIs, updating records, sending messages or triggering workflows. In that kind of environment, a harmful outcome may not be visible at the level of one action alone.

The source report does not provide broader technical validation or independent performance results. What is confirmed is that Cisco has presented Quarry as an open-source approach for detecting this class of AI-related attack pattern.

Why it matters for European businesses

Many SMEs and digital teams are moving beyond basic chatbots and starting to test AI agents for internal support, marketing operations, e-commerce workflows, software development and customer service. These systems can increase efficiency, but they also expand the attack surface.

Traditional monitoring often focuses on single events: one login, one API call, one file access or one prompt. With AI agents, the risk may instead come from the combination of steps. For example, an agent could access information it is allowed to see, pass it into another tool, trigger an external action and create a harmful outcome without any single step looking clearly suspicious on its own.

For European organisations, that has practical implications in several areas:

• Data protection: multi-step AI behaviour could increase the risk of unintended exposure of personal or confidential data.
• Operational security: agents connected to SaaS tools, CRMs, knowledge bases or cloud systems may create new paths for misuse or manipulation.
• Governance: businesses need better visibility into what agents do across workflows, not just what they say in a chat interface.
• Compliance and assurance: regulated businesses may need clearer logging, monitoring and control over automated decision paths and system actions.

The open-source nature of the project may also be relevant for companies and service providers that want to evaluate detection approaches without depending entirely on a single proprietary vendor model.

Who may be affected

The development is most relevant for organisations that are already deploying or actively piloting AI agents with access to business systems.

• SMEs using automation: especially businesses linking AI tools to email, customer support, documents, finance or internal operations.
• E-commerce companies: where agents may interact with product data, customer communications, order workflows or marketing systems.
• IT and security teams: responsible for monitoring AI-enabled workflows, API activity and identity-based access across cloud environments.
• Digital agencies and software teams: building AI-enabled services or automations for clients.
• Regulated sectors: businesses handling sensitive personal, financial, legal or health-related information may face greater consequences if agent actions are not properly monitored.

What companies should consider

Businesses do not need to adopt a specific Cisco project to act on the underlying issue. The broader lesson is that AI security monitoring should account for sequences of actions, not only individual prompts or events.

• Map agent permissions: review which systems, files, APIs and workflows each AI agent can access or trigger.
• Log full action chains: keep records of tool use, external calls, retrieved data and downstream actions so teams can reconstruct how an outcome happened.
• Monitor for patterns, not just single events: detection rules should look for suspicious combinations of steps across time.
• Apply least-privilege access: limit agent permissions to the minimum required for the task.
• Test failure scenarios: simulate prompt injection, data exfiltration paths and unsafe tool use in controlled environments.
• Review third-party AI integrations: ask vendors how they monitor and secure multi-step agent behaviour.

For European businesses increasing their use of AI agents, the key takeaway is straightforward: security controls built for ordinary software workflows may not be enough when autonomous systems can take multiple low-risk actions that add up to a higher-risk outcome.