Listen to this article
Jump to a section
In this article
Executive Summary
A security review hands back a list of findings. Each one is scored on its own, given a severity and assigned to the team that owns the affected system. Three Low findings go to three teams, each team accepts or schedules its fix, and the report is closed. That process works when the systems are separate. An AI agent joins them by design: it reads content from outside, it holds access to internal data, and it can act. When the agent touches all three, one Low finding in each area becomes a single path from an attacker’s email to your confidential files. FIRST, which maintains the CVSS standard, has long said that chained vulnerabilities should be scored as a chain. OWASP’s guidance for AI applications sets out the controls that break such chains: least privilege, approval for consequential actions, and adversarial testing of the whole system. The missing piece in most organisations is governance. Every finding has an owner. The path usually has none.
4
separate filter bypasses chained in EchoLeak, the zero-click Microsoft 365 Copilot flaw that Microsoft rated Critical at 9.3
0
code flaws in the GitHub MCP server behind Invariant Labs’ private-repository leak; the path came from configuration and permissions
3
conditions that make an AI agent exploitable together: private data, untrusted content and a way to send data out
~$2,000
per full Windows privilege-escalation chain built by an AI model from public patches, Anthropic, June 2026
Core conclusions
- Severity is scored per finding and ownership is assigned per asset. An AI agent connects assets, so the real risk sits in the path between findings, where nobody is accountable for it.
- Score the chain as well as the parts. FIRST’s CVSS user guide describes how: take the easiest entry point and the worst impact in the chain, and report the combined score next to the individual ones.
- Give every AI agent a named path owner, usually the business owner of the service, and break the chain with OWASP’s three controls: least privilege, approval for consequential actions, and adversarial testing of the full system after every material change.
The argument, in ten slides
Save it, or send it to whoever closes out security findings in your organisation.
Most security reports we have read in the last two years end the same way. A table lists the findings, a column gives each one a severity, and another column names the team that will fix it. Criticals get a deadline in days, Highs in weeks, and Lows go into the backlog or the risk register with a note that the business accepts them. What the table cannot show is how the rows relate to each other. That gap has always existed. AI agents make it much more expensive, because an agent’s job is to connect systems that the findings table treats as separate. This post walks through how three Low findings become one serious attack path, what FIRST and OWASP already say about it, and how we would change the governance so that someone owns the path.
How a findings report is built
A penetration test, an AI red-team exercise or an internal audit produces findings one at a time. Each finding describes a weakness in one component, and the scoring method rates it in isolation. CVSS, the scoring system most reports use, asks how the weakness is reached, what privileges are needed, whether a user must act, and what the impact would be if it were exploited. All four questions are about that one weakness.
Ownership follows the same logic. The finding is assigned to whoever owns the affected system: the identity team for an over-broad service account, the application team for a filtering gap, the business process owner for an approval threshold. Each owner judges the finding against their own system and their own budget. A Low finding on a system that is “internal only” or “behind a human review” is easy to defer, and usually the decision is a fair one when that finding is looked at by itself.
The weakness of this method is structural. Nothing in the process asks whether the Low finding in one team’s system makes the Low finding in another team’s system reachable. That question belongs to the attacker, who looks at the estate as a set of paths.
Three findings marked Low
Here is an illustrative case, a composite of the patterns in the published AI incidents described below. A company deploys an AI agent to handle its accounts payable inbox. The agent reads supplier emails and attachments, looks up purchase orders and contracts in the finance document library, drafts replies, and can send routine confirmations and update supplier records without a person approving each one. A security review before go-live returns three findings.
| Finding | Rating | Reason given for the rating | Owner |
|---|---|---|---|
| A. Inbound supplier emails and attachments reach the agent without any check for embedded instructions | Low | The agent only drafts and sends routine messages; a human handles anything unusual | AI product team |
| B. The agent’s service account can read the whole finance document library, not just purchase orders and contracts | Low | Internal access only; the account cannot be logged into from outside | Identity and access team |
| C. The agent can send outbound email to any address and attach documents for “routine confirmations” without approval | Low | Approval would slow the process; values involved are small | Finance operations |
An illustrative composite. The three findings mirror the conditions in the EchoLeak and GitHub MCP cases described below.
Each rating is defensible on its own. Finding A has limited impact if the agent cannot reach anything sensitive. Finding B cannot be reached by an outsider. Finding C sends small, routine messages. Now read the three together. An attacker sends the supplier inbox an invoice email with instructions hidden in the attachment (A). The agent follows them and pulls board papers and salary files from the finance library, which its account can read (B). It then sends them to the attacker’s address as a “routine confirmation” (C). No one logs in, no malware is installed, and every individual step is something the agent is permitted to do.
The three findings are, in fact, the three conditions Simon Willison called the “lethal trifecta” in June 2025: access to private data, exposure to untrusted content, and the ability to communicate externally. When one agent has all three, he wrote, an attacker can “easily trick it” into sending your data to them. A findings report scores each leg of the trifecta separately, and each leg on its own tends to come out as Low.
Two real chains
This pattern is already on the public record.
EchoLeak (CVE-2025-32711). In January 2025 researchers at Aim Security found a way to make Microsoft 365 Copilot leak internal data after receiving a single crafted email, with no click from the user. The exploit chained four bypasses. The email was worded to pass Microsoft’s classifier for prompt injection. Copilot was led to produce reference-style Markdown links, which the link-removal filter did not catch. Image references in the output were fetched automatically by the browser. And the fetch was routed through a Microsoft Teams preview service that the content security policy allowed. Each of those safeguards worked most of the time and would probably have rated low as a standalone gap. Together they gave a zero-click path from an outside email to Copilot’s view of the organisation’s files. Microsoft fixed it on the server side in May 2025, published the advisory in June, said there was no evidence of exploitation, and scored it 9.3, Critical. NIST’s own assessment of the same CVE came out at 7.5. Even the chained score depends on who does the scoring.
The GitHub MCP case. In May 2025 Invariant Labs showed that an AI coding agent connected to GitHub through the official MCP server could be hijacked by an issue posted on a public repository. When the developer asked the agent to look at open issues, the agent read the hidden instructions, pulled data from the developer’s private repositories and published it in a pull request on the public one. Invariant’s own wording is the important part for governance: “this is not a flaw in the GitHub MCP server code itself, but rather a fundamental architectural issue that must be addressed at the agent system level.” The credential could reach every repository, the public issue was untrusted content, and the agent could write in public. They also noted that while the client asks users to confirm each tool call by default, “many users already opt for an ‘Always Allow’ confirmation policy when using agents, and stop monitoring individual actions.”
In both cases there was no single severe bug for one team to fix. The severity came from the combination, and the combination ran across components owned by different people.
What FIRST says about chained vulnerabilities
FIRST, the Forum of Incident Response and Security Teams, maintains CVSS. Its user guide for CVSS version 4.0 has a section on vulnerability chaining, carried over from earlier versions. It opens by stating the limit of the standard plainly: “CVSS is designed to classify and rate individual vulnerabilities.” It then adds that the method should accommodate “situations where multiple vulnerabilities are exploited in the course of a single attack to compromise a host or application.”
The guidance on how to do this is short and usable:
| FIRST guidance | What it means in a findings report |
|---|---|
| Identify which vulnerabilities combine to form a chained attack | Someone has to look across findings, which means someone has to be responsible for doing it |
| List the distinct vulnerabilities and their individual scores next to the chained score | The report shows both views: three Lows, and the High or Critical they add up to |
| Combine scores by taking the least restrictive exploitability metrics and the most severe impact metrics | Score the chain on the easiest way in and the worst thing that can happen |
| Document classes of vulnerability, or specific CVEs and weaknesses, that are known to chain | Keep a list of finding types that should never be closed without checking their neighbours |
Source: FIRST, Common Vulnerability Scoring System version 4.0: User Guide, section on vulnerability chaining.
Apply that to the accounts payable agent. The easiest entry point is finding A: reachable over the network by anyone who can send an email, no privileges required, no user action needed. The worst impact is finding B: high confidentiality loss across the finance library. Finding C supplies the exit. Score the chain on A’s exploitability and B’s impact and it lands in the same range the public scores gave EchoLeak, which is High at least, and arguably Critical. Three Lows have become one finding that most organisations would want fixed within days.
The same three findings scored two ways
A. Untrusted content
Way inEasy: anyone who can send an email
ImpactLimited on its own
Low
Owner: AI product team
B. Private data
Way inHard: internal account only
ImpactHigh: whole finance library
Low
Owner: Identity and access team
C. External send
Way inHard: needs the agent to act
ImpactLow: small routine messages
Low
Owner: Finance operations
Chained severity: High
Way in from A, impact from B, exit through C. Path owner needed.
Scored as a chain, the way in comes from A and the impact from B, with C as the exit. The same three findings now rate High, and need one owner.
Method: FIRST, CVSS v4.0 User Guide, vulnerability chaining. The accounts payable case is illustrative.
None of this needs a new standard. The method has been in FIRST’s guidance for years. Most organisations simply do not run it, because their remediation process has no step at which anyone looks across findings.
Why AI agents make chaining the default
Chaining used to need two things that were scarce: an attacker skilled enough to see how separate weaknesses connect, and the time to build the path. AI has reduced both.
On the defence side of the system, the agent itself is the connector. A conventional application keeps a document library, an email gateway and an outbound mail server apart, and an attacker has to find a way from one to the next. An agent is built to move between them on request, and it takes its requests partly from content it reads. OWASP’s Top 10 for Agentic Applications, published in December 2025, names this directly in its list: goal hijack through malicious content (ASI01), tool misuse (ASI02), identity and privilege abuse (ASI03), and cascading failures (ASI08), where small errors spread across planning and execution.
On the attack side, building the chain has become cheap. In the post Maria and I wrote last week on risk registers and AI-assisted exploitation, we covered Anthropic’s June 2026 results: a model built eight full Windows privilege-escalation chains from public patches for about $2,000 each. A chain of Lows that once needed a patient specialist to spot is now within reach of anyone with an API account and a target list.
The result is that the gap in the findings table, which was always there, is now where much of the real risk sits.
What OWASP says breaks the chain
OWASP’s guidance for AI applications points to three controls. Each one removes a leg of the chain, and each needs an owner who can see the whole agent.
| Control | OWASP guidance | Which finding it breaks in our example |
|---|---|---|
| Least privilege | LLM06:2025 Excessive Agency: “minimize extension permissions” and “execute extensions in user’s context.” The agentic Top 10 extends this to “least agency” and per-agent, short-lived, narrowly scoped credentials (ASI03) | B. The agent reads purchase orders and contracts for the supplier in question, nothing else in the library |
| Approval for consequential actions | LLM06:2025: “require user approval” for high-impact actions before they run, with authorisation enforced in the downstream system | C. Any outbound message with an attachment, or to an address not already on the supplier record, needs a person to approve it |
| Adversarial testing | OWASP GenAI Red Teaming Guide, January 2025: testing that covers model evaluation, implementation testing, infrastructure assessment and runtime behaviour | A. Someone sends the agent crafted supplier emails and tests whether the path from inbox to outbound mail can be completed, end to end |
Sources: OWASP Top 10 for LLM Applications 2025 (LLM06); OWASP Top 10 for Agentic Applications 2026; OWASP GenAI Red Teaming Guide.
Two points about these controls are easy to miss.
First, approval controls fail by fatigue. Invariant’s “Always Allow” observation applies inside companies too. If the agent asks a person to approve forty routine messages a day, the person stops reading them, and the control exists on paper only. Approval should be tied to the class of action, such as data leaving the organisation, a new recipient or a change to bank details, and kept rare enough that people read each request properly. Value thresholds alone are the wrong test, because data theft has no invoice amount.
Second, adversarial testing has to cover the assembled system. A test of the model alone, or of each connector alone, reproduces the findings-table problem in a different form. OWASP’s guide is explicit that red teaming covers runtime behaviour and the infrastructure around the model as well as the model itself. The test that matters for the example above starts with an email from outside and ends with checking what left the building.
Who should own the attack path
The governance fix is to make one person accountable for the path, and to give them a process that forces the cross-finding question. We would make five changes.
- Name a path owner for every AI agent. This should be the business owner of the service the agent supports, not the security team and not the AI platform team. They answer for what the agent can reach and what it can do, across every system it touches. ISO/IEC 42001 already expects roles and responsibilities for AI systems to be defined; this is where that role has teeth.
- Keep a capability map for each agent. One page, maintained by the path owner, listing what untrusted content the agent reads, what data it can access and what actions it can take outside the organisation. Any agent with all three is flagged, and any change that adds one of them goes through change approval.
- Run a chain review before any finding is closed or accepted. For findings on agent-connected systems, the review asks which other open findings on the same agent’s map this one connects to. Where a chain exists, score it using FIRST’s method and record the chained score next to the individual ones.
- Make risk acceptance path-aware. A Low finding cannot be accepted by its asset owner alone if it forms part of a scored chain. The acceptance moves to the path owner, at the chained severity, with an expiry date to match.
- Retest the whole path after every material change. A new connector, a broader permission, a new model version or a relaxed approval threshold reopens the adversarial test. Agents change more often than the systems around them, and a chain can appear without anyone touching the systems where the findings sit.
Here is how the accounts payable entry looks before and after.
| Field | Before | After |
|---|---|---|
| Findings recorded | A, B and C as three separate Lows | A, B and C linked as one chain, chained severity High |
| Owners | AI product, identity and access, finance operations | Path owner: head of accounts payable; the three teams own the fixes |
| Risk acceptance | Each team accepts its own Low | No acceptance of any part while the chain stands; break at least one leg within 14 days |
| Controls | None beyond the existing design | Library access scoped to the supplier’s own records; approval on external sends with attachments; inbound content tagged as untrusted |
| Testing | Pre-launch review only | Red-team test of the full inbox-to-outbound path, repeated on every model, connector or permission change |
| Board reporting | Not reported (all Low) | Counted in the number of agents holding all three trifecta conditions |
An illustrative entry, based on the five changes above.
The last row is the one most boards will never see under the current process. A report full of Lows produces a dashboard full of green, and the one combination that matters does not appear.
Questions for the board
We would ask management for written answers to five questions:
- How many AI agents are in production or pilot, and who is the named owner of each one’s attack paths?
- How many of those agents read untrusted content, can access confidential data and can send data or take actions outside the organisation, all three at once?
- In the last year, how many Low or Medium findings on agent-connected systems were accepted without anyone checking whether they connect to other open findings?
- Which agent actions require human approval, how many approvals does each approver handle in a day, and how often is a request rejected?
- When was each agent last tested end to end by someone trying to break it, and what has changed in the agent since?
A rejection rate close to zero on question four is worth probing. It may mean the agent is well behaved. It may also mean nobody is reading.
Free tool
Agent Risk Assessment Matrix
Place each agent on an autonomy and consequence grid, see which ISO/IEC 42001-referenced controls apply, and print a register entry for it. A quick way to find the agents that hold all three conditions.
Evidence & Methodology
The incidents, standards and guidance come from their primary sources. The accounts payable case, the five governance changes and the sample register entry are our own, built from assurance work and the patterns in the published cases, and we have marked them.
| Claim | Source | Grade |
|---|---|---|
| CVSS rates individual vulnerabilities; chains should be scored on least restrictive exploitability and most severe impact | FIRST, CVSS v4.0 User Guide | Standard text |
| EchoLeak chained four bypasses; fixed server-side May 2025; no evidence of exploitation | Reddy and Gujral, arXiv, 2025, citing Aim Labs and Microsoft | Reported, researcher analysis |
| EchoLeak scored 9.3 by Microsoft and 7.5 by NIST | NIST National Vulnerability Database, CVE-2025-32711 | Registry record |
| GitHub MCP leak was an architectural issue, not a code flaw; users often choose “Always Allow” | Invariant Labs, 26 May 2025 | Demonstrated by researchers |
| The lethal trifecta: private data, untrusted content, external communication | Simon Willison, 16 June 2025 | Practitioner framework |
| Least privilege, user approval and user-context execution as mitigations | OWASP LLM06:2025 Excessive Agency | Industry guidance |
| Agentic risks ASI01 to ASI10, least agency, scoped credentials | OWASP Top 10 for Agentic Applications 2026 | Industry guidance |
| Red teaming across model, implementation, infrastructure and runtime | OWASP GenAI Red Teaming Guide, January 2025 | Industry guidance |
| Eight Windows privilege-escalation chains for about $2,000 each | Anthropic Frontier Red Team, 8 June 2026 | Measured, lab evaluation with safeguards off |
| The accounts payable case, the chained rating and the five changes | Our assessment | Our call |
Sources
- FIRST. (2025). Common Vulnerability Scoring System version 4.0: User Guide (v1.2). Forum of Incident Response and Security Teams.
- OWASP GenAI Security Project. (2024). LLM06:2025 Excessive Agency. OWASP Top 10 for LLM Applications 2025.
- OWASP GenAI Security Project. (2025, December 9). OWASP Top 10 for Agentic Applications for 2026.
- OWASP GenAI Security Project. (2025, January 22). GenAI Red Teaming Guide.
- Reddy, P., and Gujral, A. S. (2025). EchoLeak: The first real-world zero-click prompt injection exploit in a production LLM system. arXiv:2509.10540.
- National Institute of Standards and Technology. (2025, June 11). CVE-2025-32711. National Vulnerability Database.
- Invariant Labs. (2025, May 26). GitHub MCP exploited: Accessing private repositories via MCP.
- Willison, S. (2025, June 16). The lethal trifecta for AI agents: private data, untrusted content, and external communication.
- Xiao, W., et al. (2026, June 8). Measuring LLMs’ impact on N-day exploits. Anthropic Frontier Red Team.
The Vulnerability Didn't Change. The Attacker Did.
Why risk acceptances priced on attacker effort need rescoring now.
How to Test an AI Agent Before You Trust It With Real Work
What a pre-production test of an agent should cover.
What Stops a Rogue Agent You Never Catch
Limiting what an agent can reach when detection does not work.
An OpenAI Model Escaped Its Sandbox and Hacked Hugging Face
A real case of an AI system chaining steps across systems.
My thanks to Maria Singh, who co-wrote this post with me. The point that the findings had owners and the path did not is hers, and it is the one I expect boards will find hardest to answer.
If your organisation is putting AI agents into production and wants their attack paths mapped and owned before go-live, that review is where I usually start. My consulting work covers technology and AI risk governance for boards of regulated firms and public agencies.
Was this useful?
