On Wednesday at Black Hat USA in Las Vegas, two researchers from a company called Stealth walked up to the stage and explained a problem that's going to matter to every team building anything with AI agents.
They called it CoreBreak. The short version: in Amazon Bedrock AgentCore, Google's Agent Development Kit for Python, and the Vercel AI SDK harness packages, attackers could trigger an agent's tools without the model ever running. Your system prompt never fires. Your content filters never check. Your safety rules never apply. The tools just execute.
Three major platforms. All patched now. But the finding points at something most people building AI products haven't internalized yet.
How agents are supposed to work
When you build an AI agent, the flow goes like this: a user sends a request, the model reads it along with your system prompt and the list of available tools, the model decides whether to call a tool, and then the SDK executes that call.
The safety logic lives in the model turn. You write rules in the system prompt: "only access records for the requesting user," "never run destructive commands," "don't expose API keys." The assumption is that the model enforces those rules before any tool runs.
CoreBreak showed that assumption was wrong across three major platforms. The vulnerable paths didn't verify that a tool call actually came from a legitimate model turn. The runtime received data shaped like a model-generated tool call and treated it as authoritative. An attacker could craft something that looked like a tool call, inject it into the right place in the flow, and get it executed without ever going through the model.
Researchers Hedi Ingber and Aviyam Ivgi put it plainly in their talk: in several of the demonstrated attack paths, "the model never ran at all."
What was actually affected
These aren't three identical bugs. The attack conditions differed by platform:
Amazon Bedrock AgentCore (CVE-2026-18830, CVSS 8.6): An authenticated attacker with access to the InvokeHarness API could deliver a forged tool-use block directly to the agent's event loop, bypassing the model entirely. AWS has applied a server-side fix automatically — no action required from customers using the managed service.
Google's Agent Development Kit for Python: The vulnerable paths required attacker-controlled session events or function calls authored by the user themselves. Fixed in ADK 2.5.0.
Vercel AI SDK harness packages: Specifically @ai-sdk/harness-codex and @ai-sdk/harness-opencode, the harness wrappers used with popular open-source coding agents. Required untrusted code already running inside the sandbox. Both patched — @ai-sdk/harness-codex@1.0.29 and @ai-sdk/harness-opencode@1.0.28 — on July 10, but many teams haven't updated.
Why this matters to a 10-30 person org
Most teams building internal AI tools — a document Q&A system, an intake processor, an automated research assistant — spend their security thinking on the model layer. Write a careful system prompt. Add guardrails. Test that the AI won't do the things you told it not to do.
CoreBreak is a reminder that model-level rules are only as strong as the infrastructure that enforces them. If an attacker can reach the tool execution layer without going through the model, every rule in your prompt is irrelevant. The guardrails never ran.
Think about what your AI agents actually have access to. A typical setup for a 15-person org might include: read/write access to your CRM, the ability to send emails or Slack messages, database queries, maybe API calls to billing or project management tools. Now imagine every one of those capabilities triggering with no model-level check whatsoever. That's the blast radius.
The conditions required for CoreBreak differ by platform — Vercel's flaw specifically needed code already running inside the sandbox — so this isn't "anyone on the internet can own your Bedrock agent." But the security model most teams are operating under, which is "the system prompt is the security boundary," is wrong. That's the actual finding.
What to do this week
If you're using any of the three affected platforms:
AWS Bedrock AgentCore: Server-side fix is already applied for the managed service. Check the security bulletin for CVE-2026-18830 and confirm you're on the managed path, not a self-hosted fork.
Google ADK: Update to version 2.5.0 or later. Check your requirements.txt or pyproject.toml for the google-adk package version and update if you're behind.
Vercel AI SDK harness: Run npm update @ai-sdk/harness-codex @ai-sdk/harness-opencode and verify you're on 1.0.29+ and 1.0.28+ respectively. These fixes shipped over a month ago. If you deployed the harness packages and haven't updated since, you haven't pulled the fix.
Beyond the specific patches: take 30 minutes this week to audit what tools your AI agents actually have registered — not what you intended when you built it, but what's actually wired up now. Then ask: if an attacker bypassed the model entirely and called each of these tools directly, what could they do? That's your real attack surface.
If the answer is "read all customer records," "send outbound email as a staff member," or "query the database without filters," your tool execution layer needs its own authorization logic — not just the model prompt.
The pattern
CoreBreak is the third major AI agent attack class disclosed at Black Hat this week, alongside PleaseFix (prompt injection through AI browser context) and autonomous attack campaigns that completed full data exfiltration without human involvement. Each one targets a different layer of the AI stack. The consistent finding: teams secured the layer they can see — the model, the prompt — and left the layer underneath it wide open.
That gap is where the attacks are going. And it's closing faster than most orgs are moving.
We help small teams figure out where these assumptions live in their specific setup and close them without turning the AI off. If you've got agents running against real data and you want a second pair of eyes on the authorization model, reach out.