A new exploit called CoreBreak bypasses AI system prompts and model guardrails by attacking the orchestration middleware beneath them — where most enterprises have zero governance.
At Black Hat USA 2026, researchers demonstrated CoreBreak, a vulnerability in widely used AI development frameworks including AWS Bedrock AgentCore and the Vercel AI SDK. The exploit does something that should unsettle anyone who has been told their AI is "safe because we set strong guardrails": it bypasses system prompts and model-level guardrails entirely by attacking the orchestration layer that sits between your application and the model.
In other words, the defenses most teams have invested in — carefully written system prompts, refusal training, content filters baked into the model — do not help. The vulnerability lives one layer down, in the plumbing.
Why this breaks the mental model
For the last two years, AI safety conversations inside most enterprises have been model-centric. The questions were: Which model do we use? What's in the system prompt? Does it refuse harmful requests?
CoreBreak invalidates that framing for a whole class of risk. When an attacker can manipulate the orchestration middleware — the SDKs, agent frameworks, and routing logic that assemble prompts, tool calls, and context before they ever reach the model — the model's own guardrails never get a chance to fire. You can have the most safety-tuned foundation model on the market and still be exposed, because the exploit happens before the model sees a clean request.
This is the same lesson enterprises keep relearning the hard way. The LiteLLM gateway compromise exposed credentials across thousands of organizations through infrastructure nobody had inventoried. CoreBreak is the guardrail-bypass version of the same story: the risk lives in components you adopted for convenience and never treated as governed AI systems.
The governance blind spot: nobody owns the middleware
Ask your teams three questions and watch the silence:
- Which AI orchestration frameworks and SDKs are in production across our applications?
- Who is responsible for patching them when a vulnerability like CoreBreak is disclosed?
- Do our security reviews of AI systems actually evaluate the middleware, or do they stop at the model and the prompt?
For most organizations, the honest answers are we're not sure, unclear, and no. Orchestration layers get pulled in by developers as dependencies. They rarely appear in an AI systems inventory. They almost never have a named owner in the risk register. And because they aren't "the model," they fall outside the scope of model-focused governance programs.
That gap is exactly what CoreBreak exploits. Model-level defenses cannot help when the vulnerable component is the framework wiring the model into your product.
What compliance and risk leaders should do now
You do not need to be a security engineer to close this gap. You need to make sure the middleware layer is governed — inventoried, owned, assessed, and monitored — the same way you'd govern any other AI component.
- Inventory the plumbing, not just the models. Extend your AI systems inventory to include orchestration frameworks, agent SDKs, and gateways. If AWS Bedrock AgentCore, the Vercel AI SDK, LangChain, or similar tools are in production, they are AI systems and belong on the list with an assigned owner.
- Expand security reviews down the stack. Update your AI risk assessment template so it explicitly asks whether the review covered the orchestration and SDK layer — not only the model and system prompt. "Did we test the middleware?" should be an auditable question.
- Treat guardrails as defense-in-depth, never a single control. System prompts and model filters are one layer. Add input/output validation, tool-call authorization, and least-privilege scoping at the application layer so a bypassed prompt does not equal a full compromise.
- Wire framework CVEs into your patch cadence. CoreBreak affects popular frameworks that ship frequent updates. Someone must own tracking disclosures for those dependencies and driving remediation on a defined timeline.
- Constrain what agents can actually do. If a guardrail is bypassed, the blast radius is defined by the permissions and tools you granted. Minimize both. An agent that cannot reach production systems or sensitive data is a smaller problem when its prompt is defeated.
From incident to initiative
The pattern across CoreBreak, the LiteLLM leak, and the agentic sandbox escapes is consistent: the highest-impact AI risks increasingly live in infrastructure and orchestration, not in the model you chose. Governance programs built only around model selection and prompt engineering are measuring the wrong dimension.
This is precisely why maturity matters more than any single control. A program that scores well on inventory completeness, third-party and supply-chain assessment, and technical security review would have flagged the orchestration layer as an ungoverned surface long before Black Hat put a name to the exploit. A program that stops at the model would not.
CoreBreak is a reminder that "we set strong guardrails" is not a control statement — it's an assumption about where your risk lives. Confirm the assumption. Inventory the layer beneath the model, give it an owner, and turn the gap into a prioritized initiative before an attacker turns it into an incident.