CoreBreak proves agent guardrails must live outside the agent

CoreBreak proves agent guardrails must live outside the agent

AWS, Google, and Vercel all shipped the same agent security flaw

August 31, 2026
Last modified on
TL;DR Takeaways:
No items found.
Learn more at Redpanda University

At Black Hat 2026, researchers Aviyam Ivgi and Hedi Ingber showed one structural flaw running through three of the largest agent stacks: AWS Bedrock AgentCore with the Strands SDK, Google's Agent Development Kit, and Vercel's AI SDK harness. They named that flaw CoreBreak. AWS patched CVE-2026-18830 (CVSS 8.6), Google patched CVE-2026-18236 (CVSS 9.3, critical), and Vercel patched CVE-2026-64650 and CVE-2026-64651. All three vendors had put enforcement where the agent could reach it.

The guardrails the industry relies on are all wrapped around the model: system prompts, content filters, refusal training. If you bypass the model, you bypass all of them. CoreBreak showed two ways to do exactly that:

  1. Feed the harness a message history whose latest message already contains a tool call, and the tool runs with attacker-chosen arguments while the model and every guardrail wrapped around it never fires.
  2. Forge an "approved" confirmation event in that same history, and the human-in-the-loop step approves an action no human saw. The approval mechanism itself became the attack vector.

The emergency fixes all converged on the same move: bind tool execution to state the attacker cannot author, and reject externally supplied tool calls and approvals. That's called out-of-band policy enforcement, or OBPE, and each vendor had to rebuild a piece of it under fire, one patch at a time.

We built the OBPE boundary before the breach

Redpanda's Agentic Data Plane ships OBPE for agents in production today. Every tool call crosses a typed boundary that sits outside the agent's reasoning, its prompt, and its message history. That boundary is where identity is bound, where the data owner's policy ceiling is enforced, and where approvals are resolved on a channel the agent cannot read or forge. Each approval ties to the exact request digest, the deciding principal, and the policy version, and resumes only the immutable held call. A forged tool call in the message history is not an authorization. A forged "confirmed: true" is not an approval. Skipping the model does not skip the boundary, because the boundary does not care whether the model ran.

This isn't the same thing as the CVE patches. The vendors' patches add provenance checks: verify a tool call came from a model turn, reject the rest. A boundary doesn't replace that check; it removes the prize for defeating it. A forged call that gets past provenance still meets the data owner's policy ceiling, so it can do at most what a legitimate call could, not whatever the execution role's full reach would allow. Approvals are the stronger case, in which an OBPE approval never reads from agent-supplied history at all, so the forged-confirmation trick has nothing to forge.

The architecture behind this wasn't reverse-engineered from the CVEs. In April, we published an O'Reilly Radar essay arguing that nobody had built HR for agents. In May, we put the formal architecture on the record in an SAO workshop paper at ACM CAIS. Our full research paper on OBPE then tested the same design question against a sibling attack class: not forged tool calls, but prompt-injected agents coaxed into leaking protected data and taking forbidden actions.

We ran 3,621 trials across four models (Claude Sonnet 4.6, Claude Haiku 4.5, GPT-5, and GPT-5 mini) to measure this directly. Agents guarded only by prompt rules failed in 57.6% of trials, leaking protected data, revealing protected values, or completing forbidden backend effects. The same agents behind the OBPE boundary failed in 0.2%.

We also tested the in-band alternative, in which a dedicated reviewer model reads the agent's output and blocks unsafe answers. On Sonnet, the reviewer still failed 58.6% of the time, because it reads text after the tools have already run. It can refuse an answer. It cannot un-read a record the agent has already absorbed, and it cannot undo a write that already landed. The boundary failed 0.0% of those same trials, finished more of the work (66.2% task fulfillment against the reviewer's 58.7%), and tripled safe, useful completion (63.0% against 19.7%). The reviewer made 930 extra model calls and did worse on both counts. The boundary spent none.

OBPE doesn't solve everything.3 But it closes the gaps in agentic governance that remain unsolved when LLMs are part of the solution, and it does so with the efficiency and determinism of classic software. A model guard is an inference call on every step, so its cost and latency scale with its capability. You cannot buy your way from probabilistic to deterministic. A policy decision is a typed evaluation against a written rule, and it gives you the same answer in microseconds with no tokens spent.

{{featured-resource}}

The verdict: CoreBreak is right

The researchers' own hardening list reads like our OBPE design goals. They called for rejecting caller-authored tool calls, authorizing at execution time, reducing inherited authority, and binding each tool invocation to the exact model event and authorization state that produced it. That is a specification for enforcement outside the agent. The industry's most effective red team and our own research group reached the same conclusion independently, which is either a coincidence or an answer.

The credential-theft path CoreBreak exposed is worth highlighting: injected instructions steered managed browser and code-interpreter tools into reading the execution role's cloud credentials and exfiltrating them. No policy engine changes a sandbox's networking, ours included. The lesson is what you hand an agent in the first place. A typed, mediated tool grant keeps the credential behind the boundary. A general compute environment with ambient cloud credentials puts it one HTTP request away from any injected instruction. Locks only work on doors that have them. And CoreBreak showed that much of the industry shipped buildings without doors.

The next question to ask

No company lets employees approve their own access requests from a document they wrote themselves. Agents shouldn't either, and CoreBreak is the argument for why that's not a philosophical position but an engineering requirement. The CVEs and the patches point in the same direction as the researchers' own hardening list: enforcement belongs at a boundary the agent cannot reach. We published the architecture before the disclosure, measured it against the attack class, and run it in production today.

If you are putting agents in front of real data, the question to ask of every stack you evaluate is whether your agent is governing itself. CoreBreak is what happens when the answer is “yes.” 

To see what “no” looks like, read our full research paper or skip ahead and see Redpanda’s Agentic Data Plane in action

No items found.

Related articles

View all posts
Kristin Crosier
,
,
&
May 12, 2026

5 predictions about agentic AI and analytics in 2026

What AI trends will shape analytics in the coming months?

Read more
Text Link
Travis Downs
,
Peter Corless
,
&
Mar 16, 2026

Redpanda pushes the envelope on NVIDIA Vera

Benchmark shows Vera provides 5.5x lower latencies and up to 73% higher throughputs than other leading CPU models

Read more
Text Link
Redpanda
,
,
&
Mar 4, 2026

Hello, Agent! A podcast on the agentic enterprise

Learn from the leaders actually shipping and scaling AI agents today

Read more
Text Link
PANDA MAIL

Stay in the loop

Subscribe to our VIP (very important panda) mailing list to pounce on the latest blogs, surprise announcements, and community events!
Opt out anytime.