AI Tooling RCE: The Sublimit Layer Underwriters Rarely Underwrite

Two remote-code-execution chains in AI development platforms disclosed this week — both at CVSS 9.9 — landed in the same underwriter inbox on the same Monday morning. The first, in an open-source LLM-orchestration platform, allows an unauthenticated remote attacker to inject arbitrary code by bypassing sandboxed input validation. The second, in the same platform’s Python-REPL sandbox, allows the same without authentication in a different code path. Both are CVSS 9.9. Both are rated CRITICAL. Both have the same fix version. And both affect tooling that enterprise security teams have not inventoried — because AI tooling sits in a procurement blind spot. For an underwriter, the question is not the CVE. The question is the layer of insurance coverage that breaks when an AI tool gets popped.

What happened

The platform in question is widely used in enterprise AI engineering. It runs Python, mounts an LLM behind a configurable agent runtime, and exposes a Python REPL that the LLM can call. The platform’s value is also its attack surface: a tool that lets an LLM execute arbitrary Python is a tool that lets an attacker — through prompt injection, malicious document, or hostile MCP — execute arbitrary Python too, with no human in the loop.

The disclosed chain has three steps. First, an unauthenticated endpoint accepts a JSON payload that is forwarded to the LLM. Second, the LLM is induced (via a prompt injection in a fetched document) to call the Python REPL with attacker-supplied input. Third, the REPL input validation has a known bypass; the attacker’s payload runs in the application context. The CVSS score is 9.9 because the chain requires no authentication, no user interaction, and no special privileges. The attack complexity is low. The impact is remote code execution on the host running the AI platform.

The companion disclosure, in the same platform’s PythonREPL sandbox implementation, is a bypass of the validation logic — the “sandbox” is not a sandbox. The attacker wins the same way: arbitrary code execution. CVSS 9.9. The vendor released a fixed version on the same day, but the underlying pattern — an LLM-orchestration tool with too-broad REPL access — is now a class of vulnerability, not a single bug.

The pattern is the story. The same shape — LLM tool wraps a dangerous primitive, the safety wrapper is sub-NetworkModel, the wrapper is the vulnerability — repeats across agentic AI platforms in 2026. Underwriters are getting the disclosed CVEs but not the underlying pattern.

Why this matters for insurance

The standard cyber insurance tower is built around a single insured: one environment, one set of controls, one signature, one set of sublimits. The pattern of AI-tool RCE breaks that model in three places.

First, the AI tool is usually out of scope. Most cyber submissions ask: “do you use an LLM?” The right question is “do you use an LLM-orchestration tool with REPL access, a Python sandbox, or a code-execution capability?” Tooling like the one above is in nearly every enterprise AI deployment by mid-2026, often purchased by engineering teams without security review. Submission questionnaires don’t capture it. The risk is real and unrepresented.

Second, the AI tool is on a different sublimit. Most cyber towers have separate sublimits for ransomware, social engineering, and sometimes funds-transfer fraud. The relevant sublimit for AI-tool RCE is the cyber-extortion sublimit (the REPL is used to deploy ransomware) and the contingent-business-interruption sublimit (the AI tool is typically used to automate workflows whose downtime is expensive). A claim where the AI tool is the entry point can hit both. Most towers don’t have the language to handle that combination. The $250K ceiling: LLMjacking sublimits for cyber brokers is a useful refresher on the mechanics.

Third, the AI tool is a third-party supplier. Most enterprise AI deployments are SaaS: the platform is hosted by a third party, and the AI tooling itself runs on infrastructure the insured doesn’t own. A compromise of the AI tool is a third-party compromise. The aggregation tail is the same shape as the Klue – Salesforce breach aggregation analysis and the healthcare billers analysis: one supplier, many insureds, one 30-day window. The carrier that has fifty insureds all using the same AI tool faces the same kind of correlated loss.

These three properties — out-of-scope, sublimit-mismatch, third-party aggregation — are why this class of vulnerability is harder to underwrite than the underlying CVSS suggests. The FAIR risk report tool captures the loss distribution. The question is whether the distribution is the one the underwriter is pricing, or the one the carrier is reserving against.

The AI tool layer, in business language

For a non-technical reader, the AI tool layer is the same risk shape as a payment processor at a retail insured. The retail insured doesn’t write code for the payment processor; the processor runs on someone else’s infrastructure. A breach at the processor produces a many-claim event. The cyber insurance market priced this risk correctly from the early 2010s — payment processors became a well-understood aggregation lever, and carriers incorporated processor concentration into renewal questions.

The AI tool layer is the same shape, but the underwriting profession has not yet caught up. Most renewal questionnaires still ask “do you use SaaS?” The right question is “do you use a SaaS that runs a Python REPL behind an LLM?” The set of SaaS vendors that answer yes to the second question is large and growing. The set of underwriters that ask the second question is still small.

What the AI tool layer needs in underwriting terms is the same thing the payment processor needed a decade ago: a vendor concentration schedule, a recent-incident disclosure, an attestation of the vendor’s security posture, and a re-underwriting of the relevant sublimits when the vendor score changes. The underwriters who do this systematically will price the AI-tool RCE cycle correctly. The ones who don’t will see the loss curve decouple from the rate curve — the same dynamic that AM Best and S&P flagged in the broader market.

For brokers: the conversation is no longer “do you use AI” — it is “which AI tooling do you use, who runs it, and what privileges does it have on the host.” Document the answer in writing. The carriers that win the next renewal cycle will be the ones that can answer the AI-tool concentration question accurately.

Implications for coverage and underwriting

The AI-tool RCE pattern forces four renewal-cycle questions that most submissions are not yet asking.

First, AI-tooling inventory and concentration. Map the insured’s AI tooling footprint before quoting: which platforms, which versions, which versions are patched, which have known disclosed CVEs with available fixes. The carrier’s panel of approved AI tools is not yet standard; underwriters should ask for the insured’s own list.

Second, sublimits for the AI-tool RCE class. The CVSS 9.9 + REPL access + enterprise penetration pattern produces a ransomware-adjacent loss with a contingent-business-interruption overlay. Re-underwrite the sublimit against the AI tool’s vendor-side incident history, not just the insured’s own controls.

Third, vendor-side incident attribution. When the AI tool vendor discloses a breach, the carrier’s exposure is correlated across the insured book. The 30-day window between vendor disclosure and insured notification is the carrier’s tail window. Renewal questions should establish which vendor disclosures the insured monitors, and which the insured does not.

Fourth, the AI-tool sublimit insurance, if it exists. Some carriers now offer a sublimit specifically for AI-tool incidents. The pricing is novel and the loss data is thin. Underwriters should ask whether the carrier has a separate AI-tool sublimit and whether the insured’s exposure is allocated to it.

Actionable recommendations

• Underwriters: at Q3/Q4 2026 renewal, ask the insured’s AI tooling inventory explicitly. Specifically: which LLM-orchestration platforms, which Python REPL tools, which code-execution surfaces. Map the answers against the disclosed CVEs in the [OpenCTI snapshot]((none yet)) stream. The book that has the same AI tool across multiple insureds is the book with the aggregation tail.
• Brokers: walk the client through the AI-tooling story explicitly. The conversation is no longer “do you use AI” — it is “which AI tooling do you use, who runs it, and what privileges does it have on the host.” Document the answer in writing. The carriers that win the next renewal cycle will be the ones that can answer the AI-tool concentration question accurately.
• Insured CISOs and risk engineers: treat the AI tool as a first-class control surface. Inventory the tools, fix the disclosed CVEs, monitor the vendor’s CVE stream, and segment the AI tool’s network access. The tool that runs the LLM is also the tool that runs the attacker’s code.
• Risk managers at carriers: build a tier of “AI-tool-allowed” vendors with concentration caps. The same way payment processors became a known tier, AI-tooling vendors will become a known tier over the next 24 months. The carriers that get ahead of the curve on the underwriting side will price this cycle correctly.

Takeaway

The CVSS 9.9 in the AI tooling itself is the wrong level to read the risk at. The right level is the layer underneath — the in-app REPL, the unguarded prompt-to-code path, the AI tool that the rest of the insured’s stack trusts. For underwriters, the right question is not “do you use AI” but “which AI tooling do you use, and what does it have access to.” The carrier that prices the AI-tool RCE cycle correctly will out-perform the carrier that prices the CVSS 9.9 alone — for the same reason the carrier that priced payment-processor concentration correctly out-performed the carrier that priced retail breach likelihood alone.