How to Secure AI Agents Against Tool-Call Bypass: CoreBreak and the Dispatch-Layer Problem

CoreBreak made ‘agent security’ an execution-layer problem, not a model problem

CoreBreak is a dispatch-layer vulnerability pattern presented at Black Hat USA 2026 that should change how we scope AI agent security reviews: the highest-impact failures can occur when the tool dispatcher executes a tool call without a legitimate model turn. Our central claim is simple and arguable: when the dispatch layer treats tool calls as trusted data structures, model-level guardrails become structurally irrelevant, so the right engineering response is to move trust and authorization to the plumbing that triggers execution.

Quick Answer: how to prevent AI agents from executing tools via dispatch-layer bypass

CoreBreak-style bypasses happen when an agent framework accepts something shaped like a model tool call and forwards it to a tool runner without proving it originated from an actual model completion within a valid session. In that world, system prompts, refusal policies, and content filters are not ‘weak’; they are simply bypassed.

To harden an agent this quarter, we recommend designing tool execution as a privileged path with explicit provenance verification and authorization checks at the dispatch boundary. Practically, that means your dispatcher must reject any tool-call payload that cannot be tied to a verified model turn, and your sensitive tools must re-check approval and argument integrity instead of trusting session history alone.

Why CoreBreak is not prompt injection: the model never gets a vote

CoreBreak matters because it is categorically different from prompt injection. Prompt injection targets the model’s judgment by manipulating context; CoreBreak targets the infrastructure by bypassing the model entirely. The input signal here is that dispatch layers in Amazon Bedrock AgentCore, Google Agent Development Kit (ADK), and Vercel AI SDK harness packages can be coerced into executing tools without a legitimate model authorization when they accept tool-call-formatted data without validating provenance.

This should change engineering practice: when a tool is executed, your primary security question is no longer ‘did the model intend this,’ but ‘what component had authority to cause execution, and how did it validate that authority.’ That is an execution-contract question, not a prompting question.

The uncomfortable implication is that adding more policy to the system prompt can become negative work: it increases confidence while the real control plane sits elsewhere. If we keep auditing only prompts and model outputs, we will miss the path where the model output is never produced.

The plumbing layer that everyone ships and nobody threat-models

Agent frameworks tend to accumulate a dispatch layer that feels like glue code: an event loop, a session history store, and a ‘tool router’ that decides when to call an external function. CoreBreak highlights what happens when that glue becomes a security boundary by accident. In AWS Bedrock AgentCore, the research describes a case where an authenticated remote caller could inject a tool-use content block into the final message of an InvokeHarness API request, and the event loop dispatched the tool without model authorization.

In Google ADK for Python, the described flaw allowed manipulation or injection of events into an agent session history to forge human-approval confirmation for sensitive tools, where the confirmation processor failed to verify tool ownership or argument matches. And in Vercel AI SDK harness packages, a process-path check trusted any process whose command line contained an approved helper script path, allowing malicious code in a Linux sandbox to satisfy the check. These are not ‘LLM vulnerabilities’; they are dispatch and validation failures.

Inspection-execution gaps are becoming the recurring failure mode in agent stacks

CoreBreak is part of a broader class of problems the input calls an inspection-execution gap: a system ‘inspects’ something (a prompt, a model output, a confirmation step) but ‘executes’ somewhere else under weaker guarantees. The related CSA GuardFall research (June 30, 2026) is cited as finding shell injection bypasses in AI coding agents, with 10 of 11 tested agents vulnerable, reinforcing that the brittle boundary is often the step that turns ‘text’ into ‘action.’

We should read that as an engineering pattern, not as a vendor-specific incident. Any architecture that logs and moderates model I/O but treats tool invocation as a downstream implementation detail is setting itself up for a blind spot. When execution can be triggered by crafted events, session history mutations, or path-check tricks, the control layer and the action layer are no longer coupled.

What breaks in your architecture when tool calls are just data

Most agent frameworks create a representation of a tool call and pass it across boundaries: from API gateway to agent runtime, from runtime to dispatch loop, from dispatch loop to tool runner, then back into a transcript. CoreBreak’s dominant signal is that some stacks treated the representation itself as authority. If the dispatcher accepts ‘tool-call-formatted’ payloads without verifying provenance, an attacker can skip the model and still reach the tool runner.

That breaks a common engineering assumption: that ‘the model is the policy engine.’ Even when teams implement human approvals, content filters, or structured tool schemas, those controls typically live in the model turn or immediately after it. CoreBreak shows that, in some implementations, a caller can create a condition equivalent to ‘the model already asked for this tool,’ and the system believes it.

From an operational perspective, this changes how we think about logging and monitoring. If your detection is based on model prompts and model outputs, a bypass that never invokes the model will look like normal tool activity or will be invisible. The input explicitly warns that detection cannot rely on model I/O logs alone and requires deep visibility into dispatch and authorization layers.

Event loops and session histories should be treated as untrusted inputs

The Google ADK case is a particularly sharp example of why ‘agent memory’ is not inherently trustworthy. When a confirmation processor fails to verify tool ownership or argument matches, the transcript becomes a medium for forging approvals. In many systems, session history is both the audit trail and the input to future decisions, which makes it a high-value target if mutations are possible.

At Plavno, we treat event streams and conversation histories as data that must be validated at read time, not as a ground truth. The attacker’s goal in a CoreBreak-style scenario is not necessarily to make the model say something; it is to make the orchestrator believe something already happened. If the system’s state machine can be advanced by injected events, the attack surface becomes the state transitions themselves.

• Tool execution without a matching model completion: Your system can show a tool run while no model turn exists that produced the corresponding tool call.
• Approvals recorded as transcript artifacts: Human approval appears as a message or event in history, rather than as a separately verified authorization decision.
• Dispatch accepts ‘tool-call-shaped’ payloads: Requests can carry blocks that the runtime treats as if the model emitted them.
• Path or process checks used as security controls: Execution is permitted because a process ‘looks like’ an approved helper based on command line text.

A pragmatic stance: treat every tool like a privileged API, not an LLM feature

The practical response is not to abandon agents; it is to stop treating tool invocation as a conversational byproduct. When an agent calls a tool, it is performing a privileged action in your environment: it may touch customer data, trigger financial workflows, or execute code paths with real side effects. CoreBreak is a reminder that we should secure that action with the same rigor we apply to any production API.

This stance changes design reviews. Instead of asking whether your system prompt is strong enough, ask whether your dispatcher enforces that the only way to invoke a tool is through a verified model turn within a session whose integrity you can defend. If you cannot prove that, then your ‘guardrails’ are more like UI suggestions than enforcement.

Provenance, not prompt policy, is the control point

The input explicitly notes that CoreBreak occurs when the system assumes any tool-call-formatted data must have been generated by the model, and that the right detection requires tying every tool execution cryptographically or logically to a verified model turn. We cannot invent implementation specifics here, but we can draw the architectural line: tool execution should require evidence that the model produced that call in the right context, and that any ‘human approval’ cannot be forged via event injection.

In practice, we recommend thinking in terms of a chain of custody. A model completion is produced by a specific provider API (such as AWS Bedrock AgentCore or a self-hosted ADK runtime), at a specific time, for a specific session, and it yields a specific tool name and arguments. If any component later tries to execute a tool call without a verifiable link back to that completion, the dispatcher should treat it as untrusted input and reject or quarantine it.

1. Define what counts as a legitimate model turn in your stack, including where it is produced and how it is identified in logs.

2. Map the full path from model output to tool runner, and mark every boundary where tool-call data can be injected or mutated.

3. Move ‘allow/deny’ decisions to the dispatch boundary, so the tool runner cannot be reached by tool-call-shaped payloads alone.

4. Separate approvals from transcripts, so a forged history event cannot impersonate a human confirmation.

5. Instrument tool execution as a first-class security event, so you can detect tool runs that lack a verified authorization chain.

Managed services won’t save self-hosted teams from the patch-and-prove workload

One subtle but operationally critical point in the input is the split between managed and self-hosted responsibility. AWS deployed a fix automatically before July 31, 2026 for CVE-2026-18830 in Bedrock AgentCore’s InvokeHarness API. That reduces exposure for customers who rely on that managed path, but it does not eliminate the architectural lesson: you still need to know whether your surrounding components can accept forged tool-call artifacts.

By contrast, Google ADK for Python required a fix released in ADK version 2.5.0 on July 16, 2026, which self-hosted operators must apply manually. Vercel’s fixes landed July 20, 2026 in versions 1.0.29 and 1.0.28 for the affected harness packages. That is the reality for many teams: you are your own security operations for agent plumbing, and ‘we use a reputable framework’ is not a control.

What the CVEs imply about your update process

CoreBreak’s cross-platform nature should push teams to stop treating agent dependencies as frontend-like packages that can drift. If your runtime includes an agent SDK, a harness package, or a confirmation processor, those components can become execution gateways. The key operational question is whether you can rapidly determine which version is deployed where, and whether the fix was applied.

We also see a monitoring gap: when a vulnerability allows tool dispatch without model authorization, traditional ‘LLM safety’ dashboards will not alert you. Even if you have immaculate prompt logs, they are not an execution log. Your patch process and your observability stack need to treat the dispatcher and tool runner as part of the security perimeter.

The business impact is not ‘bad answers,’ it is unauthorized actions with valid credentials

When an AI agent fails at the model layer, businesses typically get incorrect responses, reputational risk, or increased support load. When an AI agent fails at the dispatch layer, the failure mode shifts toward unauthorized actions in otherwise legitimate workflows. The AWS case explicitly involves an authenticated remote caller; the Vercel case describes malicious code in a Linux sandbox satisfying a trusted path check; the Google case involves forging approval confirmations in history.

That is why CoreBreak is a board-level risk packaged as an engineering detail. It is easier to accept hallucinations than to accept unapproved tool execution, because tools are where agents touch systems of record: ticketing, CRM, billing, internal admin panels, and code execution environments. Even when the attacker needs authentication, the blast radius can be large because the agent’s tools often run with broad permissions to be ‘useful.’

If you need to validate this risk beyond code review, a targeted cybersecurity and penetration testing engagement can focus specifically on dispatch-layer injection paths and authorization binding.

How we evaluate exposure this quarter without boiling the ocean

At Plavno, we start with a brutally specific question: can anything other than a verified model turn cause a tool to execute. This question is narrower than ‘are we safe from prompt injection,’ and that is the point. It forces the review to follow the execution path through the dispatch layer, confirmation processor, and tool runner.

For teams who want help structuring this assessment, we typically position it as an applied architecture review rather than a model selection exercise. That is also where targeted AI consulting tends to pay off: you are not buying theory, you are buying a clear mapping from your current orchestration stack to specific control points that can be tested and enforced.

Log what matters: tool authorization events, not model tokens

The input makes a direct claim that detection cannot rely on model I/O logs alone and requires deep visibility into dispatch and authorization layers. That implies a concrete logging priority: your primary security event is ‘tool X executed with arguments Y under session Z,’ paired with the evidence that it was authorized by a verified model turn and, when relevant, by a verified human approval.

In practice, teams often have rich LLM telemetry and weak tool telemetry. They can replay prompts but cannot reconstruct why a payment was initiated, why a document was exfiltrated, or why an internal admin action occurred. If you flip that, investigations become tractable: you can ask whether a tool execution has a corresponding model completion, whether the session history was mutated, and whether a confirmation processor’s decision can be replayed deterministically.

Where CoreBreak-style bypass becomes a real breach in production systems

The fastest way to underestimate CoreBreak is to think only about chatbots. The affected components in the input are agent runtimes and harness packages, which are used specifically to wire models to tools. That means the risk manifests where your agent integrates with business systems.

In real deployments, we see these dispatch layers sitting behind API gateways, inside serverless functions, or embedded in internal automation services. If a tool call can be forged, the attacker’s goal will be to choose the tool that produces an irreversible side effect: changing data, initiating workflows, or accessing protected resources. Even if the vulnerability requires authentication, the attacker may leverage compromised credentials or lower-privileged accounts to reach higher-impact agent tools.

• Customer support automation: An attacker targets tools that update account records or issue credits, because the agent was granted broad CRM permissions for efficiency.
• AI coding agents and CI assistants: Tool runners that execute shell-like actions become high risk when inspection-execution gaps resemble those cited in GuardFall.
• HR and internal admin agents: Approval workflows become the target when ‘confirmation’ can be forged through session history injection as described for Google ADK.
• Sandboxed compute or plugin environments: Path or process checks can be abused in environments similar to the Vercel Linux sandbox scenario described in the advisory.

The hard part of ‘binding execution to a model turn’ is organizational, not conceptual

It is conceptually straightforward to say ‘tie each tool execution to a verified model turn,’ and the input explicitly recommends cryptographic or logical binding. The hard part is that agent stacks are multi-component: gateway, runtime, session store, tool router, tool runner, and downstream systems. Each boundary is owned by different teams, deployed on different cadences, and monitored in different places.

This is where many organizations regress into prompt tweaks because prompts are owned by one team and ship quickly. CoreBreak is a forcing function to coordinate across platform engineering, security engineering, and application teams. Without that coordination, you will patch one component and still leave a bypass path through another integration, or you will log model I/O while ignoring the dispatcher that actually triggers tools.

Why cryptographic binding is hard in practice

The input frames binding as cryptographic or logical, which is a useful nuance. Cryptographic approaches can be stronger, but they require careful key management and consistent propagation across services. Logical binding can be easier to retrofit, but it must be designed so that attackers cannot forge the same evidence by manipulating session histories, injecting events, or replaying requests.

The CoreBreak signal is that attackers exploit assumptions, not just missing encryption. If a system assumes provenance because a payload is formatted correctly, no signature scheme matters unless the dispatcher actually verifies it and refuses execution otherwise.

Plavno’s perspective: build agents as execution contracts, not conversational apps

When we deliver agent systems, we treat ‘tool execution’ as a contract between components: the dispatcher must be able to prove why it executed a tool, and the tool runner must be able to prove it was allowed to run. That is how we avoid the trap CoreBreak exposes, where the model becomes a narrative layer while the real authority sits in poorly validated glue.

This philosophy directly shapes how we scope AI agents development: we prioritize dispatch integrity, approval integrity, and tool permissioning alongside the model layer, because those are the surfaces that survive model upgrades and prompt refactors.

Resourcing the fix: outstaffing works when you already own the architecture

If you have an existing agent stack and need to close dispatch-layer gaps quickly, the work is usually surgical but cross-cutting: dependency upgrades (such as moving to Google ADK 2.5.0 where applicable), runtime instrumentation, and authorization redesign at the dispatcher boundary. Teams with strong internal platform ownership often succeed by adding experienced engineers through outstaffing to accelerate audits and refactors without reorganizing product roadmaps.

If, instead, the agent program is still forming and the architecture is unstable, we see better outcomes when the agent platform is built with these execution contracts from day one, because retrofits tend to expose hidden coupling between session histories, approvals, and tool routers.

The closing insight: stop auditing what the model said and start enforcing what the system did

CoreBreak’s dominant lesson is that agent security collapses at orchestration boundaries. If your system can execute a tool without a legitimate model turn, you do not have a ‘guardrail problem’; you have an authority problem. Fixing it requires moving controls into the dispatch and authorization layers that actually trigger execution, and treating transcripts, events, and tool-call-shaped payloads as untrusted until proven otherwise.

Author: Plavno team. Last updated: August 2026.

Summarize this blog post with AI

Chat GPT Perplexity Claude Gemini