AI Agent Tool Authorization Bypass: CoreBreak Patches for AWS, Google ADK, and Vercel

Direct answer: AI agent runtimes must not treat a tool-call-shaped message as proof that a model authorized the call. Recent vulnerabilities across AWS Bedrock AgentCore, Google ADK for Python, and Vercel AI SDK harnesses exposed different versions of the same design failure: untrusted input could reach tool dispatch or approval logic without a verifiable model event. Upgrade the affected packages, reject caller-authored function calls, bind execution to an exact model event and argument set, and keep sensitive tools behind a separate authorization layer.

Key takeaways

• This was not ordinary prompt injection. In several paths, the model did not run before the tool was dispatched.
• The affected products and fixes are different: Google ADK for Python 2.5.0+, @ai-sdk/harness-codex 1.0.29+, and @ai-sdk/harness-opencode 1.0.28+.
• Google’s public CVE record, CVE-2026-18236, covers continuation forgery in tool confirmations. ADK 2.5.0 also separately rejects user-authored function calls in resumable flows.
• Vercel’s GitHub advisory identifies CVE-2026-64650 for the Codex harness and a separate OpenCode advisory/CVE path; verify the package-to-CVE mapping against the advisory rather than copying a summary.
• AWS fixed its managed AgentCore path, but AWS documentation still tells developers to validate and sanitize messages before passing them to InvokeHarness.
• A system prompt is not an authorization boundary. The final control must sit at tool execution.

The architectural mistake: confusing shape with provenance

A normal agent loop looks like this:

The vulnerable pattern skipped the provenance check:

The important distinction is what the message looks like versus what authorized it. A JSON object with name, arguments, or function_call fields is data. It becomes an executable capability only after the runtime proves that the expected model, agent, session, user, tool policy, and argument set authorized that exact action.

What was confirmed across the three ecosystems?

The independent report from The Hacker News on August 6, 2026 describes a cross-platform vulnerability class called CoreBreak. The affected paths were not identical, and they did not have identical prerequisites:

The shared lesson is narrower than “AI agents are insecure”: the execution layer needs cryptographic, contextual, or stateful evidence of authorization instead of trusting an event’s shape.

Google ADK: patch both the confirmation and resumable paths

Google’s official google/adk-python v2.5.0 release lists two particularly important security fixes:

• Prevent continuation forgery in tool confirmation
• prevent model bypass in resumable mode by rejecting user-authored function calls

The first fix is tracked publicly as CVE-2026-18236. NVD describes the issue as a vulnerability in which an attacker who can manipulate or inject session-history events can forge a tool confirmation response. The original implementation did not sufficiently verify that the tool belonged to the executing agent, that confirmation was required, or that the confirmation’s name and arguments matched the original call.

Google’s patch adds those checks. The official commit verifies the original function-call ID, registered tool, confirmation requirement, tool name, and arguments before allowing the confirmation to proceed.

The second fix closes a different route: user-authored events containing function_call parts. The official commit rejects those messages with an error rather than allowing the user event to become a direct instruction to execute a registered tool.

Upgrade the dependency and rerun your agent tests:

1python -m pip install --upgrade 'google-adk>=2.5.0'
2python -m pip show google-adk
3pytest -q

Do not use CVE-2026-18236 as an umbrella label for every ADK issue mentioned in the report. The public NVD record covers continuation forgery; the resumable-mode rejection is a separate hardening change in the same release.

Vercel AI SDK harnesses: remove process identity as authorization

Vercel’s official GitHub advisory for the Codex harness describes a local sandbox-to-host authorization bypass in @ai-sdk/harness-codex versions through 1.0.28. The vulnerable relay trusted a process when its command line contained an allowed helper-script path. Untrusted code already executing in a Linux sandbox could satisfy that condition and request host-exposed tools, including operations involving secrets, deployments, or cloud APIs.

The fix removes the process-path fallback. The relay instead requires an exact, short-lived, one-time authorization matching the tool name and input observed in a model event.

Update both harness packages when they are present in your lockfile:

1npm install @ai-sdk/harness-codex@latest @ai-sdk/harness-opencode@latest
2npm ls @ai-sdk/harness-codex @ai-sdk/harness-opencode

The advisory lists the Codex package’s patched version as 1.0.29. The independent report identifies the OpenCode package’s patched version as 1.0.28. Use the advisory and package metadata as the source of truth for the exact package you deploy, and commit the lockfile update.

The operational implication is bigger than this one fallback: process names, helper paths, environment variables, and local ports are not authorization tokens. They can identify a process, but they do not prove which model event authorized a particular tool name and argument set.

AWS AgentCore: sanitize the boundary even after the managed fix

The Hacker News report says AWS fixed the managed AgentCore InvokeHarness path by rejecting caller-supplied tool-use blocks before they reach the event loop. AWS says the managed mitigation was applied automatically.

That does not remove application-level responsibility. AWS’s AgentCore security documentation tells applications that expose the harness to users or integrations they do not fully trust to validate and sanitize messages before passing them to InvokeHarness. The documented concern includes stripping content-block types or model-configuration fields that the application does not intend to dispatch.

Treat inbound agent messages as an API boundary:

1const ALLOWED_BLOCK_TYPES = new Set(["text", "image"]);
2
3export function sanitizeUserContent(input: unknown) {
4  if (!Array.isArray(input)) throw new Error("content must be an array");
5
6  return input.map((block) => {
7    if (!block || typeof block !== "object") {
8      throw new Error("invalid content block");
9    }
10
11    const value = block as Record<string, unknown>;
12    const type = value.type;
13    if (typeof type !== "string" || !ALLOWED_BLOCK_TYPES.has(type)) {
14      throw new Error(`content block type is not allowed: ${String(type)}`);
15    }
16
17    if (type === "text" && typeof value.text !== "string") {
18      throw new Error("text block must contain text");
19    }
20
21    return type === "text"
22      ? { type: "text", text: value.text }
23      : { type: "image", source: value.source };
24  });
25}

This is an application allowlist, not a replacement for AWS’s service-side controls. Keep it close to the trust boundary, test it with malformed structured content, and do not forward arbitrary model configuration from a caller.

A production authorization invariant

Every tool execution should satisfy an invariant like this:

1allow(toolCall) only if:
2  authenticated principal is allowed for this session
3  AND toolCall.event_id exists in trusted model output
4  AND event.session_id == current session
5  AND event.agent_id == executing agent
6  AND event.tool_name == requested tool
7  AND canonical(event.arguments) == canonical(requested arguments)
8  AND current policy allows the action
9  AND any required human approval matches the same event
10  AND the authorization has not expired or been consumed

A TypeScript policy boundary can make that contract explicit:

1type AuthorizedCall = {
2  eventId: string;
3  sessionId: string;
4  agentId: string;
5  toolName: string;
6  args: Record<string, unknown>;
7  expiresAt: number;
8};
9
10function canonical(value: unknown): string {
11  return JSON.stringify(value, Object.keys(value as object).sort());
12}
13
14export function assertAuthorized(
15  requested: { eventId: string; sessionId: string; agentId: string; toolName: string; args: Record<string, unknown> },
16  grant: AuthorizedCall,
17) {
18  if (grant.expiresAt <= Date.now()) throw new Error("authorization expired");
19  if (requested.eventId !== grant.eventId) throw new Error("event mismatch");
20  if (requested.sessionId !== grant.sessionId) throw new Error("session mismatch");
21  if (requested.agentId !== grant.agentId) throw new Error("agent mismatch");
22  if (requested.toolName !== grant.toolName) throw new Error("tool mismatch");
23  if (canonical(requested.args) !== canonical(grant.args)) {
24    throw new Error("argument mismatch");
25  }
26}

In production, use a canonicalization method that handles nested objects and arrays deterministically; the short example is intentionally compact. Make grants single-use, record the decision, and avoid logging secrets or complete sensitive arguments.

Why prompt defenses are not enough

Prompt injection attempts to influence a model’s decision. These failures target an earlier or adjacent trust boundary: a runtime that receives structured content and assumes that it came from a model-authorized turn.

That means the usual defenses are insufficient on their own:

• A stronger model cannot approve a call it never saw.
• A system prompt cannot constrain a dispatch path that bypasses inference.
• A content filter cannot inspect a request rejected or skipped before model execution.
• A human approval UI is ineffective if the approval is not bound to the original tool ID, name, and arguments.

This is closely related to the threat model for MCP tool servers. MCP tool metadata and results are untrusted inputs, while the host remains responsible for consent and policy. It also complements the operational controls in NVIDIA NemoClaw’s agent sandbox release: sandboxing reduces blast radius, but it does not replace authorization at the tool boundary. Teams reviewing coding-agent integrations can also compare the broader AI agent stack architecture.

Verification checklist for teams

1. Inventory packages and services. Search lockfiles, container images, and deployed functions for ADK, AgentCore harness integrations, harness-codex, and harness-opencode.
2. Upgrade and pin. Use Google ADK 2.5.0+, Codex harness 1.0.29+, and OpenCode harness 1.0.28+ where applicable.
3. Reject forged shapes. Add tests for user-authored function_call, caller-supplied tool_use, forged confirmation, altered arguments, unknown tool names, and stale session events.
4. Bind authorization. Require event ID, session ID, agent identity, tool name, canonical arguments, policy result, and expiry to match.
5. Make grants single-use. A replayed approval should fail even if the payload is otherwise identical.
6. Minimize tools and credentials. Remove shell, deployment, secret lookup, and write-capable tools from agents that do not need them.
7. Test the untrusted-repository path. For coding agents, assume dependencies and lifecycle scripts can execute inside the sandbox.
8. Monitor denials. Log a safe decision record with package version, tool identifier, event ID hash, reason, and actor—not raw credentials or sensitive prompt content.

FAQ

Is CoreBreak the same as prompt injection?

No. Prompt injection tries to change what a model decides. The reported paths allowed tool execution or approval without a valid model-authorized event, so model-level defenses could be bypassed entirely.

Do all AI agents using AWS, Google, or Vercel have the same risk?

No. The products, versions, configurations, and attack prerequisites differ. The shared pattern is a missing provenance check at the execution or approval boundary, not a universal vulnerability in every deployment.

What should Google ADK users do first?

Upgrade google-adk to 2.5.0 or later, then test confirmation replay, altered arguments, unknown tools, and user-authored function calls in resumable flows.

What should Vercel AI SDK users do first?

Check whether @ai-sdk/harness-codex or @ai-sdk/harness-opencode is installed directly or transitively. Upgrade to the patched versions or later, regenerate the lockfile, and avoid running untrusted repositories with sensitive host tools exposed.

Does AWS’s managed fix eliminate application validation?

No. AWS’s documentation still directs applications to validate and sanitize messages before passing them into the harness when callers or integrations are not fully trusted.

Can sandboxing solve this problem?

Sandboxing helps contain a compromised process, but a sandbox-to-host relay still needs authorization. Use both isolation and exact, short-lived, event-bound tool grants.

Conclusion

The practical lesson from the 2026 agent-tool authorization flaws is simple: a tool call is not authorized because it looks like a tool call. The runtime must prove where it came from, who requested it, which model event produced it, what arguments were approved, and whether the current policy still allows it.

Patch the affected dependencies, reject caller-authored executable events, bind approvals to immutable call details, and keep sensitive capabilities behind a deterministic policy layer. If the model never receives a turn, it cannot be the security boundary.

Sources

• The Hacker News: AWS, Google, and Vercel Agent Flaws Let Attackers Trigger Tools Without Running the Model — independent reporting, August 6, 2026.
• Google ADK Python v2.5.0 release — official release notes and fixes, July 16, 2026.
• Google ADK continuation-forgery fix — official source commit.
• Google ADK resumable-mode model-bypass fix — official source commit.
• NVD: CVE-2026-18236 — U.S. National Vulnerability Database record.
• Vercel AI SDK Codex Harness advisory — official advisory, July 20, 2026.
• AWS AgentCore security and access controls — official AWS documentation on validating and sanitizing untrusted messages.

Visuals: original Mermaid diagrams by Essa Mamdani. Source links above provide the factual basis; diagrams are explanatory renderings, not vendor screenshots.

Related reading

• Nutanix MCP Server: A Safe Starting Point for AI-Driven Cloud Operations
• MCP 2026-07-28: Stateless Servers, Routing, and Migration
• Grok Bot: The 24/7 AI Employee Era