What the Composio incident actually shows
OWASP published the Top 10 for Agentic Applications six months ago. The Composio incident traverses four of those categories in a single chain. The framework called it. The question now is what defenses catch chained ASI attacks. Single-category controls clearly don't.
Quick reference — the Composio attack chain mapped to OWASP ASI
Use this as your working anchor for the entire post. Every paragraph below is built around this mapping.
| Step in attacker chain | OWASP ASI category | What Composio's bulletin said |
|---|---|---|
| 1. LLM-generated adversarial probing of API surface | ASI01 — Agent Goal Hijack (generation-side dynamic) | "brute-forcing many combinations of exploits using LLM generated attack patterns" |
| 2. Foothold inside an internal agentic monitoring tool | ASI02 — Tool Misuse & Exploitation | "gained a foothold in an internal agentic tool used to monitor our infrastructure" |
| 3. Registration of malicious tool definitions | ASI04 — Agentic Supply Chain Vulnerabilities | "registered malicious tool definitions inside our sandboxed execution environment" |
| 4. Arbitrary code execution in the sandbox | ASI05 — Unexpected Code Execution | "execute arbitrary code within our tool-execution sandbox" |
The most interesting thing about the Composio incident report isn't the breach itself. It's that the attack chain maps cleanly to four published OWASP ASI categories, in sequence. Six months after OWASP released the Top 10 for Agentic Applications 2026, we have probably the first major public incident that walks through ASI01, ASI02, ASI04, and ASI05 like a worked example.
Before going further, I want to be clear about something. Composio's public response to this incident has been one of the better ones I've read this year. Fast disclosure. Detailed technical bulletin. Published IOCs. Clear, evolving recommendations to customers. Their team is doing the hard, exhausting work of an incident response in public, and the industry is better for it. What follows is a technical reading of the chain they documented, because the chain itself, independent of which platform got hit, is the most important security signal published about agentic infrastructure this year.
Let me walk through the four ASI categories the chain traverses. The terminology is OWASP's; the observations about what each category looks like in the wild are mine.
ASI01 — Agent Goal Hijack, generated at machine speed
OWASP ASI01 covers cases where attackers redirect an agent's objectives by manipulating instructions, tool outputs, or external content. The framework anticipates this happening through crafted inputs. What Composio documented is the same category, but with a generation-side wrinkle that changes the threat model: the inputs were LLM-generated at scale. "Brute-forcing many combinations of exploits using LLM generated attack patterns," in Composio's words.
Traditional fuzzing generates inputs from grammars or mutations. LLM-generated probing generates inputs from intent. An attacker tells a model "find a way to make this agent reveal data it shouldn't," and the model produces hundreds of plausible, semantically coherent attack variants per minute. The defender's signal-to-noise problem changes completely.
ASI01's existing mitigation guidance, things like input validation, context filtering, and output guardrails, assumes a defender has time between attack variants to write detection logic. When the attacker can generate novel semantically-valid variants faster than any human team can ship rules, that assumption breaks. The category is right. The defensive cadence assumed in most ASI01 implementations is too slow.
ASI02 — Tool Misuse, through an internal monitoring agent
ASI02 covers agents misusing legitimate tools through prompt injection, misalignment, or unsafe delegation. The textbook example most discussions reach for is a customer-facing agent that gets jailbroken into making an unintended API call. The Composio case is more interesting because it hits ASI02 through an internal, second-line agent: "an internal agentic tool used to monitor our infrastructure and report connector failures."
This is the architectural pattern worth dwelling on. Internal monitoring agents, by design, have read access to almost everything. They're trusted by other systems. They sit inside the trust boundary. And in 2026 more of them are themselves agentic. They reason, decide, and act on what they observe. An agentic monitoring tool with broad read access is, from an attacker's perspective, the most attractive piece of infrastructure to compromise in a stack. It's the panopticon. And because it's internal-facing, it usually receives less hardening than customer-facing systems.
The Composio attacker didn't go through the front door. They went through the security camera. Every agentic platform should audit, this week, which of its internal agentic tools have privileged read access, and treat each one as a top-tier ASI02 target in its own threat model.
ASI04 — Agentic Supply Chain, registered from inside the perimeter
ASI04 covers malicious or tampered tools, descriptors, models, or agent personas that compromise execution. The framework anticipates supply-chain risk arriving from outside, like a poisoned model on Hugging Face, a tampered MCP server, or a compromised tool registry. The Composio chain hits ASI04 from a less-discussed direction: the attacker, having already established the ASI02 foothold, used it to register malicious tool definitions inside Composio's own sandboxed execution environment. The supply chain was breached from inside the perimeter.
This is worth attention. Once a malicious tool definition is registered, every downstream agent that queries the tool catalog will see it. The agent doesn't "know" the tool is malicious. To the agent, it's just another tool with a plausible description. Prompt injection isn't needed at runtime; the injection happened at registration time. The mitigation is closer to package signing and registry integrity than to prompt filtering.
Most ASI04 implementation guidance focuses on verifying tools at integration time. Sign the MCP server, verify the manifest, check provenance. That guidance is correct but it assumes the registration channel itself is trusted. The Composio chain shows what happens when an attacker reaches the registration channel. Worth thinking about whether your platform treats tool definition registration as a privileged operation requiring its own authentication boundary, or as a routine API call.
ASI05 — Unexpected Code Execution, achieved via legitimate sequences
ASI05 covers agents generating or executing attacker-controlled code. The classic threat model is direct: a prompt-injection attack tricks an agent into running an attacker's payload, the sandbox catches it, hardening holds. The Composio chain achieves ASI05 differently. The sandbox itself wasn't escaped through a kernel exploit or syscall abuse. It was escaped through the chained logic of an agent that had been induced, via the malicious tool definitions from step three, to perform actions that, in sequence, were equivalent to code execution.
This matters because the defenses are different. Traditional sandbox hardening (seccomp, gVisor, Firecracker) defends against syscall-level attacks. They don't defend against an agent performing entirely legal API calls in a sequence whose aggregate effect is escape. The defensive layer that catches this is not the sandbox itself. It's the policy engine sitting between the agent and the sandbox, evaluating whether the agent's intended action sequence is consistent with its authorized purpose.
Most agentic platforms don't have that policy engine. ASI05 mitigation guidance, where it exists, focuses on output filtering and runtime restrictions. The Composio chain suggests an additional layer is needed: sequence-level intent validation. That's a category of control the industry is barely starting to build.
What this chain tells us about agentic security maturity
Each of the four categories above has existing mitigation guidance. The Composio attacker walked through all four anyway. That's not a critique of OWASP. The framework is six months old and it correctly anticipated all four categories. It's a critique of how the industry has implemented controls so far: category by category, one mitigation at a time, with little testing of what happens when an attacker chains across categories.
Most current ASI implementations test ASI01 controls in isolation, ASI02 controls in isolation, and so on. Pentests look at each category as a separate engagement. Red teams typically focus on the highest-likelihood single-category attack. The Composio chain shows the gap: an attacker who is fluent in chaining categories will route around any single-category defense, and the controls that exist for each individual ASI risk don't compose. The defense surface isn't ten controls. It's the joint distribution of all ten.
It is tempting, for those of us working in AI security, to read an incident like this as a vindication of our category. "See, this is why our space matters." I want to resist that framing. Composio is not the cautionary tale. Composio is one of the few platforms in this space mature enough to have an incident, publish about it in this much technical detail, and continue operating. The cautionary tales are the platforms that get hit and don't disclose, or get hit and don't notice. There are more of those than there are Composios.
The real signal in this incident is about the attack surface of agentic infrastructure as a category. The four ASI steps above are not Composio-specific. They apply to every agentic tool platform, every MCP gateway, every agent orchestration framework, every internal agentic ops tool. Most have not been tested seriously against chained ASI attacks. The ones that have are quiet about it.
The open question, and I'd genuinely like to hear how others are thinking about it, is what continuous defensive posture looks like for agentic platforms in 2026. Single-category red teams won't be enough; the chain is the threat, not the link. Periodic pentests won't be enough; the attack surface changes faster than the project cadence. Bug bounties partially help but undersample the chained-action attacks that defined the Composio chain.
We're working on one approach to chained-ASI testing at Verno Labs. Other teams are working on different approaches. I'd genuinely value comparing notes. If you operate an agentic platform and you've been thinking hard about chained attacks across the ASI categories, reach out at pavlos@vernolabs.ai or via vernolabs.ai.
OWASP published the Top 10 for Agentic Applications six months ago. The Composio incident traverses four of those categories in a single chain. The framework called it. The question now is what defenses catch chained ASI attacks. Single-category controls clearly don't.
Quick reference — the Composio attack chain mapped to OWASP ASI
Use this as your working anchor for the entire post. Every paragraph below is built around this mapping.
| Step in attacker chain | OWASP ASI category | What Composio's bulletin said |
|---|---|---|
| 1. LLM-generated adversarial probing of API surface | ASI01 — Agent Goal Hijack (generation-side dynamic) | "brute-forcing many combinations of exploits using LLM generated attack patterns" |
| 2. Foothold inside an internal agentic monitoring tool | ASI02 — Tool Misuse & Exploitation | "gained a foothold in an internal agentic tool used to monitor our infrastructure" |
| 3. Registration of malicious tool definitions | ASI04 — Agentic Supply Chain Vulnerabilities | "registered malicious tool definitions inside our sandboxed execution environment" |
| 4. Arbitrary code execution in the sandbox | ASI05 — Unexpected Code Execution | "execute arbitrary code within our tool-execution sandbox" |
The most interesting thing about the Composio incident report isn't the breach itself. It's that the attack chain maps cleanly to four published OWASP ASI categories, in sequence. Six months after OWASP released the Top 10 for Agentic Applications 2026, we have probably the first major public incident that walks through ASI01, ASI02, ASI04, and ASI05 like a worked example.
Before going further, I want to be clear about something. Composio's public response to this incident has been one of the better ones I've read this year. Fast disclosure. Detailed technical bulletin. Published IOCs. Clear, evolving recommendations to customers. Their team is doing the hard, exhausting work of an incident response in public, and the industry is better for it. What follows is a technical reading of the chain they documented, because the chain itself, independent of which platform got hit, is the most important security signal published about agentic infrastructure this year.
Let me walk through the four ASI categories the chain traverses. The terminology is OWASP's; the observations about what each category looks like in the wild are mine.
ASI01 — Agent Goal Hijack, generated at machine speed
OWASP ASI01 covers cases where attackers redirect an agent's objectives by manipulating instructions, tool outputs, or external content. The framework anticipates this happening through crafted inputs. What Composio documented is the same category, but with a generation-side wrinkle that changes the threat model: the inputs were LLM-generated at scale. "Brute-forcing many combinations of exploits using LLM generated attack patterns," in Composio's words.
Traditional fuzzing generates inputs from grammars or mutations. LLM-generated probing generates inputs from intent. An attacker tells a model "find a way to make this agent reveal data it shouldn't," and the model produces hundreds of plausible, semantically coherent attack variants per minute. The defender's signal-to-noise problem changes completely.
ASI01's existing mitigation guidance, things like input validation, context filtering, and output guardrails, assumes a defender has time between attack variants to write detection logic. When the attacker can generate novel semantically-valid variants faster than any human team can ship rules, that assumption breaks. The category is right. The defensive cadence assumed in most ASI01 implementations is too slow.
ASI02 — Tool Misuse, through an internal monitoring agent
ASI02 covers agents misusing legitimate tools through prompt injection, misalignment, or unsafe delegation. The textbook example most discussions reach for is a customer-facing agent that gets jailbroken into making an unintended API call. The Composio case is more interesting because it hits ASI02 through an internal, second-line agent: "an internal agentic tool used to monitor our infrastructure and report connector failures."
This is the architectural pattern worth dwelling on. Internal monitoring agents, by design, have read access to almost everything. They're trusted by other systems. They sit inside the trust boundary. And in 2026 more of them are themselves agentic. They reason, decide, and act on what they observe. An agentic monitoring tool with broad read access is, from an attacker's perspective, the most attractive piece of infrastructure to compromise in a stack. It's the panopticon. And because it's internal-facing, it usually receives less hardening than customer-facing systems.
The Composio attacker didn't go through the front door. They went through the security camera. Every agentic platform should audit, this week, which of its internal agentic tools have privileged read access, and treat each one as a top-tier ASI02 target in its own threat model.
ASI04 — Agentic Supply Chain, registered from inside the perimeter
ASI04 covers malicious or tampered tools, descriptors, models, or agent personas that compromise execution. The framework anticipates supply-chain risk arriving from outside, like a poisoned model on Hugging Face, a tampered MCP server, or a compromised tool registry. The Composio chain hits ASI04 from a less-discussed direction: the attacker, having already established the ASI02 foothold, used it to register malicious tool definitions inside Composio's own sandboxed execution environment. The supply chain was breached from inside the perimeter.
This is worth attention. Once a malicious tool definition is registered, every downstream agent that queries the tool catalog will see it. The agent doesn't "know" the tool is malicious. To the agent, it's just another tool with a plausible description. Prompt injection isn't needed at runtime; the injection happened at registration time. The mitigation is closer to package signing and registry integrity than to prompt filtering.
Most ASI04 implementation guidance focuses on verifying tools at integration time. Sign the MCP server, verify the manifest, check provenance. That guidance is correct but it assumes the registration channel itself is trusted. The Composio chain shows what happens when an attacker reaches the registration channel. Worth thinking about whether your platform treats tool definition registration as a privileged operation requiring its own authentication boundary, or as a routine API call.
ASI05 — Unexpected Code Execution, achieved via legitimate sequences
ASI05 covers agents generating or executing attacker-controlled code. The classic threat model is direct: a prompt-injection attack tricks an agent into running an attacker's payload, the sandbox catches it, hardening holds. The Composio chain achieves ASI05 differently. The sandbox itself wasn't escaped through a kernel exploit or syscall abuse. It was escaped through the chained logic of an agent that had been induced, via the malicious tool definitions from step three, to perform actions that, in sequence, were equivalent to code execution.
This matters because the defenses are different. Traditional sandbox hardening (seccomp, gVisor, Firecracker) defends against syscall-level attacks. They don't defend against an agent performing entirely legal API calls in a sequence whose aggregate effect is escape. The defensive layer that catches this is not the sandbox itself. It's the policy engine sitting between the agent and the sandbox, evaluating whether the agent's intended action sequence is consistent with its authorized purpose.
Most agentic platforms don't have that policy engine. ASI05 mitigation guidance, where it exists, focuses on output filtering and runtime restrictions. The Composio chain suggests an additional layer is needed: sequence-level intent validation. That's a category of control the industry is barely starting to build.
What this chain tells us about agentic security maturity
Each of the four categories above has existing mitigation guidance. The Composio attacker walked through all four anyway. That's not a critique of OWASP. The framework is six months old and it correctly anticipated all four categories. It's a critique of how the industry has implemented controls so far: category by category, one mitigation at a time, with little testing of what happens when an attacker chains across categories.
Most current ASI implementations test ASI01 controls in isolation, ASI02 controls in isolation, and so on. Pentests look at each category as a separate engagement. Red teams typically focus on the highest-likelihood single-category attack. The Composio chain shows the gap: an attacker who is fluent in chaining categories will route around any single-category defense, and the controls that exist for each individual ASI risk don't compose. The defense surface isn't ten controls. It's the joint distribution of all ten.
It is tempting, for those of us working in AI security, to read an incident like this as a vindication of our category. "See, this is why our space matters." I want to resist that framing. Composio is not the cautionary tale. Composio is one of the few platforms in this space mature enough to have an incident, publish about it in this much technical detail, and continue operating. The cautionary tales are the platforms that get hit and don't disclose, or get hit and don't notice. There are more of those than there are Composios.
The real signal in this incident is about the attack surface of agentic infrastructure as a category. The four ASI steps above are not Composio-specific. They apply to every agentic tool platform, every MCP gateway, every agent orchestration framework, every internal agentic ops tool. Most have not been tested seriously against chained ASI attacks. The ones that have are quiet about it.
The open question, and I'd genuinely like to hear how others are thinking about it, is what continuous defensive posture looks like for agentic platforms in 2026. Single-category red teams won't be enough; the chain is the threat, not the link. Periodic pentests won't be enough; the attack surface changes faster than the project cadence. Bug bounties partially help but undersample the chained-action attacks that defined the Composio chain.
We're working on one approach to chained-ASI testing at Verno Labs. Other teams are working on different approaches. I'd genuinely value comparing notes. If you operate an agentic platform and you've been thinking hard about chained attacks across the ASI categories, reach out at pavlos@vernolabs.ai or via vernolabs.ai.