Between late 2024 and early 2025, security researchers disclosed vulnerabilities in AWS Bedrock, Google's Agent Development Kit, and Vercel's AI SDK. These flaws allowed attackers to trigger tool execution without the AI model authorizing the action. Although the vendors have patched these issues, the incident highlights a critical architectural weakness in how agent systems enforce authorization boundaries.
What Happened
Attackers bypassed the AI model entirely and directly invoked tools available in the agent framework. AWS's Bedrock AgentCore failed to validate that tool invocation requests originated from the model's decision-making process. Google's ADK for Python had session management weaknesses that let attackers craft requests appearing to come from legitimate agent sessions. Vercel's AI SDK contained a local sandbox escape, allowing unauthorized tool calls from the host environment.
The common issue: these frameworks assumed the model would act as the authorization gatekeeper but didn't enforce that assumption at the tool execution layer.
Timeline
Late 2024: Researchers identify authorization bypass patterns across multiple agent frameworks.
January 2025: AWS assigns CVE-2026-18830 to the Bedrock AgentCore vulnerability with a CVSS v4.0 score of 8.6.
February 2025: Google releases ADK for Python version 2.5.0 with fixes.
February 2025: Vercel patches AI SDK Codex (version 1.0.29) and OpenCode (version 1.0.28).
All three vendors deployed patches before public disclosure, but the gap between initial deployment and widespread adoption of fixed versions left teams running older versions exposed.
Which Controls Failed or Were Missing
Input validation at the tool execution boundary. AWS's AgentCore accepted tool invocation requests without verifying they came from the model's output. This failure to validate trust boundaries meant the framework trusted anything calling the tool interface without enforcing that trust.
Session integrity checks. Google's ADK didn't maintain cryptographic binding between the model's decision to invoke a tool and the actual invocation request. Attackers who could observe or predict session tokens could craft their own tool execution requests.
Sandbox enforcement. Vercel's SDK ran tools in a local sandbox but didn't prevent the sandbox from making unauthorized calls back to the host. The isolation boundary existed in theory but wasn't enforced at runtime.
Least privilege for tool access. All three platforms gave the tool execution layer broad permissions, assuming the model would limit which tools got called. When that assumption broke, the tools themselves had excessive capabilities.
What the Standards Require
OWASP ASVS v4.0.3 Requirement 4.1.3 mandates that access control decisions cannot be tampered with and must be enforced at a trusted location. The agent frameworks violated this by allowing tool invocation requests from untrusted sources. Your authorization logic must reside in a component that attackers cannot bypass or impersonate.
NIST 800-53 Rev 5 Control AC-3 (Access Enforcement) requires systems to enforce approved authorizations for logical access. The model's decision to invoke a tool is an authorization decision, but these frameworks didn't enforce that decision at the execution point. You need a verifiable chain from the authorization decision to the action.
ISO/IEC 27001:2022 Control 8.3 (Information Access Restriction) requires restricting access to information and system functions based on business requirements. The tool execution layer must independently verify that the request meets the access policy, not just assume upstream components handled it.
PCI DSS v4.0.1 Requirement 6.4.3 (for teams handling payment data) requires custom code to prevent common coding vulnerabilities. These authorization bypasses fall under broken access control, one of the vulnerabilities this requirement addresses.
Lessons and Action Items for Your Team
Implement cryptographic request binding. When your model decides to invoke a tool, generate a signed token that includes the tool name, parameters, and a nonce. Your tool execution layer must validate this signature before running anything. Don't rely on session cookies or bearer tokens that an attacker can replay.
Enforce least privilege at the tool layer. Each tool should run with only the permissions it needs for its specific function. If your database query tool only reads from two tables, restrict it to those tables in the database permissions, not just in the model's prompt. When an authorization bypass happens, you want the blast radius minimized.
Audit your agent framework's architecture. Map out where authorization decisions happen and where they're enforced. If you see a gap between "the model chose this action" and "the system executed this action," you have the same vulnerability these vendors had. Add enforcement at the execution boundary.
Update to patched versions immediately. If you're running AWS Bedrock agents, Google ADK for Python below 2.5.0, or Vercel AI SDK Codex below 1.0.29, you're vulnerable. These aren't theoretical risks; the attack patterns are now public.
Log tool invocations with full context. Your logs should capture not just what tool was called, but what model session authorized it, what parameters were passed, and whether the authorization token validated. When you're investigating an incident, you need to distinguish between legitimate model decisions and injected requests.
Test your authorization boundaries. Write tests that attempt to invoke tools without going through the model. If your tests succeed, your controls failed. This should be part of your standard security testing for any agent system.
The shared responsibility model matters here. AWS, Google, and Vercel fixed their frameworks, but you still own the decision to deploy those fixes and to architect your agent systems with defense in depth. Don't assume the model is your security boundary. Enforce authorization where the action happens.
