CoreBreak: the AI agent flaws where the model never ran

Governance Watch — our take on the news a compliance owner actually has to answer for.

Most of what you have been told about AI risk assumes the model is the dangerous part. This month's disclosure is about the machinery around the model: on three of the industry's most reputable agent platforms, researchers showed an attacker could make an agent's tools fire — send the message, call the cloud API, look up the secret — without the AI ever being consulted. All three vendors patched quickly and well. What's left on your desk is a genuinely better question to ask every AI vendor you oversee.

What happened

At Black Hat USA 2026, researchers Hedi Ingber and Aviyam Ivgi presented a cross-platform attack pattern they call CoreBreak, affecting agent infrastructure from AWS, Google, and Vercel.

The plain-language version requires one piece of vocabulary. An AI agent has two halves: a model that decides, and a runtime that acts. The runtime holds the "tools" — the actual ability to send an email, query a database, call a cloud API. In the intended flow, the runtime asks the model what to do, the model answers "call this tool with these inputs," and the runtime executes that answer. CoreBreak is what happens when the runtime skips the checking part: each vulnerable platform accepted data that was merely shaped like a model's tool request — arriving in a user message, a session history file, or a process name — and executed it as if the model had asked.

The three paths, one sentence each. On AWS, an authenticated caller could append a tool-request block to the end of an ordinary API request, and the runtime dispatched the tool directly — no model involved. On Google's ADK, an attacker who could inject events into an agent's session history could forge the human approval on a tool the developer had flagged as sensitive — the confirmation processor never checked that the tool belonged to that agent, that it actually required approval, or that the name and inputs matched the original request. On Vercel, malicious code already running inside the agent's sandbox could name itself after an approved helper script, pass the identity check, and invoke tools on the host — including secret lookups and cloud API calls.

One nuance worth filing: AWS fixed its managed service automatically — customers had to do nothing. Its open-source Strands agent code got documentation instead of a patch, with guidance that developers must build message history only from controlled sources. Whether "this is fixed" applies to a given product depends on which layer that product is built on.

Why it matters

The researchers' one-liner is the whole story: "Any safeguard implemented only in a system prompt or model response disappears when a caller can reach the dispatch path without a legitimate model turn."

Note what this is not. It is not prompt injection — nobody tricked the AI into doing something bad. In several of these paths the model never ran at all, which means the system prompt, the content filters, and every model-level guardrail never got a chance to object. The AI equivalent of bypassing the security guard by walking in through the loading dock.

That distinction matters to you because "our AI has guardrails" is the sentence at the center of nearly every AI vendor's security story right now. This disclosure sorts that sentence into two very different claims. Guardrails that live in the model's instructions are promises the software asks the AI to keep — and they are conditional on the AI being in the loop. Guardrails enforced at the moment of execution — the runtime independently verifying the model actually asked for this, with these inputs, this turn — hold even when the loop is subverted. All three vendors' fixes are the second kind: AWS now rejects caller-supplied tool requests server-side, Google now verifies ownership, approval, and matching inputs, and Vercel replaced its process-name check with exact, short-lived, one-time authorizations tied to observed model events.

And these are not obscure stacks. Bedrock AgentCore, Google's ADK, and Vercel's AI SDK are precisely the reputable, name-brand infrastructure your AI vendors are building agents on — often the very names offered as reassurance in a diligence call. The patches inherited from those platforms are real. So is the question they hand you.

What it means for you

If you're a credit union or community bank — nothing new is mandated by this, and no examiner will say the word CoreBreak. But your vendor due diligence program already covers material technology vendors, and an AI vendor whose agent can act on your members' data is exactly that — the argument is MCP servers as third-party vendors, and it applies to agent platforms wholesale. What this disclosure adds is a concrete, answerable question for the questionnaire (below) — and proportionality still applies, as NCUA's operative guidance has always said (07-CU-13 / SL 07-01). A chat-only tool with no ability to act needs less of this scrutiny than an agent holding credentials to your core systems.

If you're an RIA or broker-dealer — Reg S-P's amended safeguards rule (17 CFR 248.30(a)(5)) requires ongoing oversight of service providers, and its incident-response provisions run on a 72-hour provider-to-firm breach-notice clock. Here is the uncomfortable pairing: a CoreBreak-style dispatch is an unauthorized action that, on an unpatched and poorly instrumented stack, may produce a log that looks like the AI simply used a tool. Your 72-hour clock only helps if the vendor can detect the thing that starts it. "Would an action your agent took without model authorization show up in your monitoring?" is now a fair diligence question with a knowable answer.

How to get ahead of it

1. Ask which agent frameworks your AI vendors build on. One questionnaire line: "Which agent framework or SDK does your product use (for example Bedrock AgentCore, Google ADK, Vercel AI SDK), and were you affected by the July 2026 CoreBreak advisories?" Affected versions and fix dates are all public — a vendor who can't answer in a week is telling you something. (This slots straight into the AI vendor due diligence questions you're already asking.)
2. Ask where the guardrails actually live. The single best question this disclosure gives you: "If a request reached your tool-execution layer without a legitimate model turn, what rejects it?" You are not grading the engineering; you are listening for whether the answer describes enforcement at execution time or a well-written system prompt. Vendors who have thought about it answer fast.
3. Ask what the record would show. "What log exists of the tools your agent invoked, and does it capture whether the model authorized each invocation?" This is the same evidence thread we pulled in MCP's 2026 spec change — the trail your file depends on is assembled by your vendor's engineering choices.
4. Sort your AI vendors into "can act" and "can only talk." Every question above applies to agents with tools, not chatbots. If you don't currently know which of your AI vendors hold credentials and take actions, that inventory is the first deliverable — and it's a scoping exercise, not a project.

What to watch out for

• "We're built on AWS / Google, so this is handled" is half an answer. The managed AWS service was fixed automatically; the open-source layers were not, and library fixes only help vendors who shipped the update. The follow-up is which layer, which version, when.
• "This wasn't prompt injection" cuts both ways. True — and it also means patching CoreBreak does nothing about prompt injection, which remains open on every platform. These are two different doors into the same room. A vendor who treats one patch cycle as a security posture is reading the news, not managing risk.
• Don't let a CVSS score do your thinking. The critical-rated Google flaw required access to session history; the medium-rated Vercel flaws required code already running in a sandbox — but sandboxed, semi-trusted code is exactly what coding agents run all day. Your exposure depends on the vendor's architecture and what their agent can reach, not the number.
• "Our model has guardrails" answers a different question than the one you asked. Model behavior and runtime authorization are separate layers. A vendor can be state-of-the-art on one and silent on the other. Keep asking about the second until you get an execution-time answer.

Where we stand

We spent this piece telling you to put hard questions to your AI vendors. We are one, so here are our own answers — checked against what is actually running, not what we intended.

One of the three affected us. NobleCloak's agent runtime is built on Google's ADK for Python, and we were running an affected version when the advisories published. We upgraded to a patched release and confirmed it on August 10 by reading the version out of the running process — not by checking what our manifest declared. We use neither Bedrock AgentCore nor the affected Vercel harness packages.

How that happened is worth more to you than the disclosure itself. Our dependency file permitted a patched version the whole time; our lockfile pinned one that predated the fix by two minor releases. The lockfile is what ships. So when you ask a vendor whether they were affected, the answer you want isn't what their requirements file allows — it's what's running in production, and how they know.

As for where our guardrails live: authorization happens server-side at the moment of execution. Every tool call is checked against the caller's verified identity and permissions before dispatch, independent of anything the model was told — and the policy is per-actor, not a global switch. The same tool can require human approval for one user, run freely for a trusted agent, and be denied outright for a role, per customer. Our orchestration layer also rebuilds agent messages from plain text rather than forwarding caller-supplied structure, so a caller-authored tool request has no vessel to travel in.

And the limit, named plainly, because that's the deal: our own human-approval gates are not yet bound to the specific tool call they approved — the same class of gap Google just patched. We found it by turning this disclosure's questions on ourselves, and the fix is designed and in progress, not shipped. Prompt injection, likewise, is a different door, and it remains open on every platform — including ours.

The bottom line

Three of the most sophisticated engineering organizations in the world shipped agent infrastructure with the same missing check — literally the same: all four CVEs carry the same weakness classification, incorrect authorization. And all three fixed it the same way: authorize the action at the moment of execution, and treat anything merely shaped like an instruction as untrusted. That convergence is the lesson, and it compresses into one test you can now apply to any AI vendor — including us: ask where the guardrails live, and don't accept a system prompt as the answer.

Knowing which of your AI vendors even have tool-armed agents — before asking any of the questions above — is inventory, and producing that inventory is what a Discover scan does. Request your Discover scan — we run it with you.

Related: MCP servers as third-party vendors · The agent identity problem · MCP rewrites itself · A2A — when your vendors' AIs start talking