Skip to content
Beveiligingsnieuws

Agent Tool-Call Bypass in AWS, Google, Vercel

agent-toolcall flaws

Security teams have identified a worrying design flaw that falls outside the usual “prompt injection” conversation. In several agent frameworks from AWS, Google, and Vercel, researchers found an `agent tool-call bypass` pattern where tool execution could proceed even when the model never ran a valid turn. Without that model step, safeguards like system prompts, content filters, and model-level guardrails do not get a chance to act.

While each vendor’s details differ, the shared theme is consistent: in the vulnerable paths, the execution layer treated tool-call-shaped data as sufficient authority. The result is that attackers may reach a dispatch or authorization flow using inputs crafted to look like legitimate tool instructions, but without a properly verified model response.

Why this matters: tool execution without a model turn

In a typical agent workflow, the software development kit sends the user request, system prompt, conversation context, and the list of available tools to the model. The model then decides whether to call a tool and returns structured information identifying the tool and the arguments. Only after that should the SDK execute the tool.

The risky behavior reported in these cases sits between “model output” and “tool execution.” The vulnerable implementations did not verify provenance for the tool call content—meaning they did not strongly confirm that the tool invocation was directly produced by an actual, authorized model turn.

Crucially, in some attack paths the model was skipped entirely. If the model does not run, any protections that depend on the model step cannot intervene.

Three separate ecosystems, one risky control gap

The researcher-reported issues are not identical and do not share the same prerequisites. In practice, each framework exposed a different way to reach the tool execution layer.

  • AWS: an authenticated remote request could submit a tool-use block positioned so the event loop could dispatch the tool directly.
  • Google: session or user-authored inputs could be manipulated to forge confirmation or inject function call parts that lead to execution.
  • Vercel: exploitation required untrusted code already running inside a Linux sandbox that could satisfy a process-based check to reach host-exposed tools.

Despite these differences, the underlying control theme converges: checks that bind tool execution to a verified model event were missing or incomplete.

AWS: Bedrock AgentCore InvokeHarness and the “skip model” path

AWS assigned CVE-2026-18830 (CVSS v4.0 score 8.6) to insufficient input validation in the Amazon Bedrock AgentCore harness.

According to the bulletin summary, an authenticated remote user could place a tool-use content block in the final message of an InvokeHarness request. The event loop could then dispatch the named tool without making the model perform an authorization step.

AWS stated this issue affected the managed InvokeHarness API before July 31, 2026. The fix added server-side validation designed to reject caller-supplied tool-use blocks before they reach the event loop. AWS said the mitigation was applied automatically and required no customer action.

However, the report also highlights that this managed-service fix does not automatically cover an analogous model-skipping behavior present in the open-source Strands Python code that researchers say AgentCore’s harness is built on.

In the upstream logic (as described by the researchers), a helper checks whether the latest message contains a tool-use marker. When that condition passes, the event loop sets the stop reason to tool_use, takes the latest message directly, and skips model execution. The researchers noted that repository code still contained this shortcut at least as of August 5, 2026.

A narrower branch above that shortcut restores a tool-use message saved before an interrupt. A pull request in April warned that externally injected toolUse blocks might reach execution without model invocation, but that proposed change was closed unmerged on June 19.

Importantly, the researchers stressed exposure depends on how a specific application is wired. If an application does not let untrusted callers submit structured conversation messages, alter stored history, or place tool-use content where the event loop consumes it, the attacker may gain nothing.

Google: ADK for Python confirmation forgery and resumable-mode bypass

Google’s report includes two related but distinct findings delivered in the ADK 2.5.0 release (shipped July 16, 2026).

The first issue is tracked as CVE-2026-18236 (CVSS v4.0 score 9.3) and affects ADK for Python versions prior to 2.5.0.

ADK allows developers to flag certain sensitive tools as requiring confirmation. In the vulnerable path, if an attacker could manipulate or inject events into an agent’s session history, they could forge an approval and cause unauthorized tool execution. The added checks in the fix ensure the confirmation is verified against the correct executing agent, confirms that the tool actually required confirmation, and matches the tool name and arguments recorded in the session.

The second fix in the same release targets resumable-mode flows. The researchers described that resumable-mode accepted user-authored events containing function_call parts in a way that could be interpreted as instructions to run registered tools—effectively enabling a bypass where the system avoids relying on the LLM output.

Google’s patch rejected function calls in user-authored messages to prevent that model-skipping behavior. The public record for the CVE mentioned above focuses on the continuation-forgery path, while the resumable-mode bypass is treated separately in release documentation.

Vercel: sandbox-to-host authorization bypass in AI SDK harnesses

Vercel’s findings focus on packages used by Codex and OpenCode coding agents via harness relays. Two CVEs were reported, each tied to a different package and version range.

  • CVE-2026-64650 affects @ai-sdk/harness-codex through version 1.0.28 (CVSS v4.0 score 6.3).
  • CVE-2026-64651 affects @ai-sdk/harness-opencode through version 1.0.27 (CVSS v4.0 score 6.3).

In these vulnerable cases, the harness relay trusted a process condition based on the command line containing a path of an approved helper script. Researchers reported that malicious code already running inside the sandbox could satisfy that check and invoke host-exposed tools, including secret lookups, deployment operations, and cloud API calls—without a corresponding model-authorized event.

This is a different threat shape than the AWS remote request issue. Vercel’s exploitation scenario required Linux, an active harness session with at least one host-provided tool, and untrusted code already executing in the sandbox (for example, a malicious dependency or lifecycle hook).

Vercel removed the process-path fallback. The patched relay accepts tool execution only when it matches an exact, short-lived one-time authorization tied to the observed model event data—so the tool invocation cannot be driven solely by the structure of incoming requests.

Not prompt injection—and why that distinction matters

Although the symptoms may sound familiar (tool misuse), the researchers emphasized this is not prompt injection. There is no probabilistic model output to “trick,” and there is no expectation that a stronger model could resist the attack.

Instead, the model never reaches the point where it could enforce its own guardrails. The vulnerable logic allows the system to interpret tool-call-shaped inputs as authorization, effectively skipping the model turn altogether or weakening its binding to tool execution.

What defenders can do now

As of the report, advisories and CVE records indicate fixes, but they do not definitively answer whether the issues were exploited against live deployments before patches landed. Researchers said they provided proof-of-concept code to the affected vendors privately and did not publish it.

Even so, the remedies converge on the same engineering principle: treat incoming tool invocation instructions as untrusted until execution-time verification ties them to a legitimate model event.

  • Patch affected packages: upgrade Google ADK for Python to 2.5.0 or later; upgrade @ai-sdk/harness-codex to 1.0.29 or later; and upgrade @ai-sdk/harness-opencode to 1.0.28 or later.
  • Reject caller-authored tool calls: treat conversation history, resumable events, confirmation responses, and structured tool-use blocks as untrusted input when they cross an external boundary.
  • Authorize at execution time: bind each tool invocation to the exact model event, including tool name, arguments, session context, and the authorization state that produced it.
  • Reduce inherited authority: give each agent only the minimum tools, cloud roles, credentials, and write permissions needed for its task.

Bottom line

The documented agent tool-call bypass pattern highlights a fundamental risk in agent systems: if the execution layer trusts tool-call-shaped data without proving it came from a verified model turn, guardrails can fail to run. Across AWS, Google, and Vercel, fixes focus on stronger checks and tighter binding between model outputs and tool invocation authorization.

If you run agents in production, review your tool execution pipeline, ensure you’ve applied the relevant version upgrades, and verify that tool calls cannot be triggered solely by caller-controlled message structures.

Source: https://thehackernews.com/2026/08/aws-google-and-vercel-patch-agent-flaws.html