CoreBreak: AWS, Google and Vercel agents ran tools without the model
Five agent-runtime flaws allowed forged tool calls or approvals to bypass LLM inference. We explain why the model cannot serve as an authorisation layer.
- AUTHOR
- Karol Rapacz / CEO of Breachroad · OSCP · PNPT
- PUBLISHED
- 6 August 2026
- READING TIME
- 13 min read
- TOPIC
- AI Security
Research presented as CoreBreak disclosed five vulnerabilities in agent infrastructure from AWS, Google and Vercel. Depending on the path, an attacker could supply a message shaped like model output, forge a tool approval or resume a session with a prepared function call. The runtime executed the action even though no model had proposed it.
This changes how teams should think about guardrails. A system prompt, content filter and model refusal do not matter if the execution layer accepts a correctly shaped object without cryptographic or stateful proof of its origin.
Three variants of one class
In Amazon Bedrock AgentCore, the InvokeHarness endpoint accepted a tool-use block in a final message supplied by an authenticated caller. CVE-2026-18830 describes insufficient input validation. A server-side fix rejects those blocks, but deployments using the underlying framework directly should examine their message history and dispatcher independently.
In Google ADK, the researchers found weaknesses in binding an approval to the exact tool and arguments, and in resuming a flow. Approval cannot be a generic “yes” stored in conversation history. It must cover one operation, principal, resource, parameter set and execution instance.
In Vercel’s harness, code already running in a sandbox could exploit a trust mechanism to invoke host-side tools. The fix included signed one-time approvals bound to an observed model event. That is the right direction: evidence of a decision is created outside untrusted context and cannot be reconstructed from content alone.
A secure tool gateway
The model is a planner, not a security principal. A tool should receive the user and agent identity, tenant, permitted scope, parameter hash, run identifier, expiry and the result of an independent policy decision. The runtime must validate this structure without asking the model whether it is valid.
An approval should be consumed after execution. Replaying a message, retrying after a timeout or resuming an old session must not repeat a payment, deletion or secret read. Idempotency helps with failure handling but does not replace authorisation.
What teams should do
- Update SDKs, managed runtimes and adapters to vendor-fixed versions, including copied or forked code.
- Diagram the path from message ingestion to tool dispatch and mark where authorisation is created.
- Reject tool calls originating directly from user input, memory, resume history or a sandbox.
- Bind approval to tool name, complete arguments, resource, principal, tenant and a short expiry.
- Use a one-time nonce and signature or MAC, with approval state stored outside the LLM context.
- Alert on tool execution without a preceding inference event and policy-engine decision.
- Add replay, argument substitution, tenant swapping, resume and forged message roles to regression tests.
A gateway should issue capabilities, not forward an entire session
Instead of giving an agent a durable cloud token, the tool layer can issue a single-use capability for one action: a named resource, method, data limit and short time window. The gateway validates parameters again after canonicalisation so that the model cannot change the target through alternate encoding, a redirect or an alias resolving to another object.
The decisions “the model proposes” and “the system authorises” must remain separate. A tool schema validates types, a policy engine evaluates identity and data classification, and the executor accepts no extra fields beyond the signed decision. Irreversible operations need a human approval step that displays the final expanded destination after aliases and redirects are resolved. Audit logs should retain a prompt hash, policy version, arguments before and after canonicalisation and the external API result.
Facts and conclusions
The CoreBreak session in the Black Hat schedule and vendor advisories confirm five findings and fixes for most components. There is no report of mass exploitation of these paths in production.
Breachroad’s conclusion is that authorisation must be deterministic and enforced at the tool boundary. An AI and LLM security audit should trace the complete execution protocol, while team security training teaches the separation of intelligence from authority.


