AWS Puts Hard Limits on AI Agents as the Amazon Google Security Race Tightens

AWS has placed enforceable limits around AI agents, despite the risk that attackers or poisoned data can manipulate their reasoning. The move sharpens the Amazon Google contest over which cloud can safely connect agents to valuable business systems.

Amazon Bedrock AgentCore Policy checks an agent’s requested tool actions before those actions reach the underlying service. A manipulated agent can still produce a dangerous request, but the request should fail when it conflicts with an external policy.

That distinction matters because prompt filters have never provided a complete security boundary. Models process instructions and untrusted data through the same probabilistic machinery. AWS now treats that model as an untrusted decision-maker rather than the final authority.

Google Cloud and Microsoft are following the same broader direction through their own identity, gateway, and information-flow controls. The emerging competition is no longer limited to model quality. Cloud providers must show that agents can act without inheriting unrestricted access to every connected system.

AWS Moves Authorization Outside the Agent

AWS is separating what an agent wants to do from what the infrastructure permits it to do.

Policy in Amazon Bedrock AgentCore creates a protective boundary around interactions between agents and tools. The service intercepts requests routed through an AgentCore Gateway, then evaluates each request before allowing the tool invocation.

An AgentCore Gateway connects agents with APIs, functions, and other tools through a managed interface. The policy engine sits beside that connection rather than inside the agent’s prompt or orchestration code.

This placement changes the security model. A system prompt might tell an agent never to retrieve restricted customer records. However, prompt injection can persuade the model to disregard that instruction or interpret it differently.

An external authorization engine does not need the model to agree. It evaluates the proposed action using explicit rules, authenticated identity, tool parameters, and available request context.

AWS uses Cedar, its open-source authorization language, to express those rules. A Cedar policy identifies the principal making a request, the requested action, the protected resource, and any required conditions.

The service follows default-deny semantics. An action receives no access unless a policy explicitly permits it. A matching prohibition also overrides any broader permission that might otherwise allow the request.

AWS explains these mechanics in its AgentCore policy guide. The guide says every routed agent request is evaluated before tool access is granted.

Developers can write Cedar directly or describe requirements in plain English. The natural-language authoring service translates those requirements into candidate Cedar policies.

AWS says the service validates generated policies against the gateway’s tool schema. It also checks for rules that appear overly permissive, overly restrictive, or impossible to satisfy.

That generation process does not make vague requirements safe. AWS warns that natural-language policies still need precise, unambiguous wording. Security teams must review the resulting Cedar rather than treating generated policy as unquestionable code.

The model that creates a policy is also separate from the mechanism that enforces it. Once deployed, the formal policy controls the authorization decision instead of asking another model for an opinion.

Consider an internal support agent with tools for reading accounts and issuing refunds. A company could permit every support representative to read assigned accounts while allowing only supervisors to approve larger refunds.

If an email contains malicious instructions demanding a refund, the agent might attempt the operation. The gateway can still reject it when the authenticated employee lacks the required role or the amount exceeds policy.

The denied request never needs to reach the payment system. That outcome is stronger than asking the agent to recognize every variation of a malicious instruction.

AgentCore Policy is generally available across 13 AWS regions, according to AWS release documentation. Centralized policies can apply consistently to multiple agents and tools connected through associated gateways.

CloudWatch integration records authorization decisions for monitoring and audits. Those records give security teams a clearer account of which actions agents requested, allowed, or denied.

The immediate change is therefore architectural, not cosmetic. AWS is placing a deterministic checkpoint between uncertain model behavior and consequential enterprise systems.

Why Prompt Injection Changes the Amazon Google Contest

The Amazon Google cloud contest now depends on containing compromised agents, not merely improving their answers.

AI agents become useful when they can retrieve private information, call APIs, send messages, or change records. Those same permissions determine the damage possible after manipulation.

Prompt injection inserts hostile instructions into content that a model processes. Direct injection comes from a user request, while indirect injection can hide inside websites, documents, emails, or tool responses.

An agent researching a supplier might encounter instructions embedded in a webpage. Those instructions could tell it to retrieve confidential files and send them through another connected tool.

A content filter might detect a familiar attack pattern. It might also miss an unusual phrasing, an encoded command, or a sequence distributed across several interactions.

The underlying problem extends beyond malicious prompts. A model can hallucinate an action, misunderstand a business rule, or combine individually acceptable tools into an unacceptable workflow.

OWASP describes this condition as excessive agency. The risk appears when an LLM receives enough functionality or permission to cause harmful effects after unexpected output.

Authorization limits the resulting blast radius. The system assumes that an agent will eventually make a bad decision, then prevents that decision from becoming an unrestricted action.

That approach resembles established cloud security practices. Applications should receive only the permissions required for a task, while sensitive operations should face additional checks.

Agents complicate this principle because they select tools dynamically. They can also chain many calls together, carry context between steps, and operate for longer periods without direct supervision.

A static service account with broad permissions can therefore become a serious liability. The agent effectively gains every capability attached to that credential, regardless of the user or task involved.

AWS can connect AgentCore requests to OAuth users or AWS Identity and Access Management entities. Policies can then consider the identity behind a request rather than relying only on the agent’s shared service role.

Google faces the same issue as it expands Gemini-based agents and Model Context Protocol connections. MCP is a standard interface that lets models discover and invoke external tools.

Google’s MCP security guidance recommends deny policies for production access, narrowly scoped permissions, input sanitization, and monitoring. It also warns that security can otherwise depend entirely on agent programming.

This convergence is important. Amazon Google competition has often centered on model availability, infrastructure, data platforms, and developer tooling. Agent authorization is becoming another major buying criterion.

Enterprise customers rarely deploy an agent as an isolated chatbot. They want agents connected to databases, code repositories, support platforms, cloud consoles, and internal knowledge stores.

Every connection creates both utility and exposure. A cloud provider that makes the connection easy but the authorization weak shifts the operational risk back to the customer.

AWS is positioning AgentCore Policy as a reusable enforcement layer across frameworks and models. Developers can use AgentCore with agents built through several popular orchestration frameworks.

That openness lets AWS argue that security policy should remain stable even when a company changes its model. An organization might replace one foundation model without rewriting every permission rule.

Google can make a similar case through its cloud identity controls, Model Armor, and resource-level permissions. Its advantage is proximity to Google Workspace, Gemini, and an extensive data platform.

Microsoft adds pressure through Entra identity, Copilot, and its agent development stack. The market is becoming a three-way contest over who controls the boundary between AI reasoning and enterprise execution.

For buyers, the relevant Amazon Google question is not which model always refuses a malicious prompt. No vendor can credibly promise perfect refusal across every input and tool combination.

The better question is what happens after the refusal fails. A secure platform should limit the tools, records, parameters, destinations, and action sequences available to the compromised agent.

Amazon Google Security Strategies Meet at the Tool Boundary

AWS, Google, and Microsoft are converging on deterministic enforcement, but they organize that enforcement differently.

AWS places AgentCore Policy directly in the gateway path. Every covered agent-to-tool request reaches the policy engine before the requested invocation proceeds.

Cedar gives AWS a formal language that teams can inspect, validate, and analyze. AWS has used Cedar concepts beyond agents, which helps connect agent authorization with established application-security practices.

The company’s security researchers make a blunt assumption about the model itself. Their Cedar security analysis says organizations should treat an LLM as an untrusted actor within a defense-in-depth design.

That does not mean the model is malicious. It means the authorization system cannot depend on predictable model behavior, because the model is probabilistic and susceptible to manipulated context.

Google’s published guidance currently emphasizes layered controls around MCP servers and Google Cloud resources. Those controls include deny policies, narrow credentials, separate test environments, sanitized inputs, and restricted production access.

Google also recommends stopping read-write tools from reaching production resources unless the workflow requires them. Recovery features remain important because even an authorized action can produce an unwanted result.

The practical difference can appear in developer experience. AWS offers a dedicated AgentCore policy engine with Cedar-backed evaluation at its managed gateway.

Google can draw on mature Cloud IAM and product-specific policies. However, developers still need to ensure that every relevant tool path actually passes through the intended control.

That caveat applies to AWS as well. AgentCore Policy governs traffic routed through an associated AgentCore Gateway. An agent with another execution path might bypass that particular checkpoint.

For example, a policy could block an S3 operation through a managed MCP tool. The restriction would not automatically cover a separate shell tool that can issue an equivalent command.

Architecture reviews must therefore enumerate capabilities, not merely named tools. Security teams need to ask whether an agent can reach the same resource through an SDK, command line, browser, function, or secondary agent.

Microsoft is developing another variation through information-flow control. Its FIDES middleware labels content by integrity and confidentiality, then carries those labels through tool calls.

Microsoft’s FIDES security model can prevent untrusted content from influencing a sensitive operation. It can also restrict private data from flowing toward a public destination.

This approach handles a weakness in single-action authorization. A database lookup might be permitted, and sending an email might also be permitted. The dangerous behavior appears when private query results flow into an external email.

AWS has been extending its policies toward session-aware evaluation. Temporal controls can examine an agent’s recent actions rather than judging every request as an isolated event.

That direction matters because attackers can divide a harmful objective across several legitimate-looking steps. A sequence can reveal risk that no individual action exposes.

An agent might first read a confidential portfolio, then calculate a summary, and finally attempt an external transmission. Each tool call can appear valid without the trajectory connecting them.

For customers comparing Amazon Google security designs, coverage matters more than terminology. A formal policy language provides little protection when high-risk execution routes remain outside enforcement.

Identity propagation also matters. The policy engine needs reliable knowledge about the user, workload, resource, action, and relevant business context.

A generic “agent” identity is insufficient when the agent serves many employees. It can grant every user the agent’s maximum permission set and erase the accountability that normal access controls provide.

Organizations should preserve the human or workload identity behind each delegated request. They should also assign the agent its own constrained identity rather than hiding it inside a shared credential.

That separation helps answer two different questions. The first asks whether the user can request the action. The second asks whether this agent can perform that action through this specific tool.

Central policy also reduces inconsistency between teams. Without it, each developer may implement authorization inside prompts, custom middleware, or individual tool handlers.

Those scattered checks become difficult to audit. They also drift as agents gain new tools, models, and workflow branches.

A shared gateway cannot replace every resource-level permission. It can provide a consistent point where organizations apply policy before agent intent reaches downstream services.

The Policy Is Only as Strong as Its Coverage

AgentCore Policy reduces risk, but it does not prove that an AWS-hosted agent is safe.

The service controls requests that pass through its configured gateway and policy engine. It cannot govern tools, credentials, or network routes that developers leave outside that boundary.

This creates a coverage problem. A security team might believe it has blocked a dangerous action while an alternate tool offers another route to the same resource.

Broad IAM permissions can worsen that gap. If an agent’s runtime role can call services directly, gateway restrictions must be paired with resource policies that block unauthorized paths.

Policy design also remains difficult. Natural-language authoring lowers the syntax barrier, but it does not resolve vague business requirements or missing security assumptions.

“Allow analysts to view appropriate reports” is not a precise authorization rule. The organization must define which analysts, reports, classifications, regions, clients, and operational conditions count as appropriate.

Generated Cedar requires review, testing, and change control. Teams should test expected approvals, expected denials, malformed requests, missing context, and deliberately adversarial parameter combinations.

A policy that denies everything causes operational failure. A rule that quietly permits everything creates the opposite problem. Both outcomes can appear syntactically valid.

Developers also need to consider authorization context supplied by the agent. Security-sensitive attributes should come from trusted identity tokens, resource metadata, or controlled infrastructure.

The model should not be allowed to declare that a transaction is low risk or that a document is public. Those claims need verification outside the model’s reasoning process.

Audit logs introduce another obligation. Recording every decision helps investigations, but teams must actively monitor the records and preserve useful context.

A denied action can indicate a successful security control. Repeated denials might also reveal a compromised workflow, a policy error, or an agent continuously retrying a forbidden objective.

Allowed actions deserve attention too. An attacker can abuse permissions that are individually legitimate, especially when policies do not consider session history or data movement.

Human approval remains useful for irreversible or high-impact operations. However, an approval screen can fail when the agent supplies a misleading description of the requested action.

The interface should present trusted details from the actual tool request. Reviewers need the destination, resource, parameters, data classification, and expected effect.

Security teams must also defend the policy administration plane. An agent should not be able to edit its own rules, associate a weaker policy engine, or obtain credentials with broader access.

Separation of duties helps here. Developers can propose policy changes, while security owners review and deploy changes through controlled workflows.

The same discipline applies to internal knowledge systems. Teams building a searchable knowledge base should preserve document permissions before exposing that content to an agent.

Retrieval should filter records according to the requesting user’s authorization. The model should receive only the subset of information that the user could access directly.

This design prevents a critical failure mode. Even a successfully manipulated model cannot reveal information that never entered its accessible context.

Organizations should avoid placing all confidence in prompt-injection detection. Detection adds useful defense, but unfamiliar attacks and benign-looking instructions can evade classifiers.

AWS supports Bedrock Guardrails at the policy layer for evaluating gateway inputs and outputs. That feature complements Cedar enforcement rather than replacing it.

The difference is straightforward. A guardrail estimates whether content looks dangerous, while authorization decides whether a requested operation is permitted.

Probabilistic detection and deterministic enforcement solve different problems. Combining them narrows the attack surface without pretending that either layer catches every failure.

The Amazon Google security race will reward vendors that make these layers difficult to bypass. Marketing claims about safe agents matter less than demonstrable enforcement coverage.

Customers should test those claims with red-team exercises that involve indirect injection, compromised tools, alternate execution routes, and multi-step data movement.

They should also verify failure behavior. A denied tool call must stop the protected operation without exposing sensitive details through errors or fallback paths.

AWS has established a stronger default pattern by placing policy outside agent code. The remaining question is whether customers will configure the surrounding identities and routes with equal care.

What Enterprise Buyers Should Watch Next

The next phase will test policy coverage, session awareness, and portability across competing agent platforms.

The first signal is how quickly customers adopt temporal policies. Single-request rules work well for clear restrictions, but many agent attacks emerge through sequences of authorized actions.

Temporal evaluation can detect that an agent read sensitive data before attempting an external transfer. It can also require additional approval after a particular sequence of operations.

The difficult part involves state and interpretation. Systems must track enough history to recognize dangerous trajectories without blocking ordinary workflows or adding excessive latency.

Buyers should look for public technical documentation describing exactly how much session history is evaluated. They should also ask how state is isolated between users, agents, and concurrent tasks.

The second signal is how Google and Microsoft expose equivalent controls through their managed agent platforms. All three providers recognize that prompt instructions alone cannot protect connected systems.

Google’s response will matter because Gemini agents can sit close to Workspace content, cloud data, and developer infrastructure. Strong resource permissions already exist, but agent-specific composition remains essential.

Microsoft can combine Entra identity with Copilot, Agent Framework, and information-flow labels. Its advantage will depend on consistent enforcement across Microsoft and third-party tools.

The Amazon Google comparison should focus on end-to-end paths. Buyers need evidence that policy follows an action from user identity through agent reasoning, gateway execution, and final resource access.

The third signal is independent security testing. Vendor documentation describes intended behavior, while red teams reveal missing routes, confused identities, unsafe defaults, and unexpected tool combinations.

Tests should include a malicious webpage, poisoned support ticket, compromised MCP response, and hostile document inside an approved repository. Each source can carry indirect instructions into an agent’s context.

Researchers should also test whether agents can transform forbidden requests into technically different actions. A blocked export might become a browser upload, shell command, encoded message, or request to another agent.

Results will determine whether external policy produces meaningful containment or only another configuration layer. The strongest evidence will come from attacks that change model behavior but still fail to cross authorization boundaries.

Enterprises do not need to wait for those results before improving their architecture. They can begin by inventorying every agent, tool, credential, data source, and outbound destination.

Each tool should receive the narrowest possible action scope. Read-only access should remain separate from modification, deletion, external sharing, or financial execution.

Teams should remove standing credentials when short-lived delegation can work. They should preserve user identity across tool calls and log both attempted and completed operations.

High-impact actions should require trustworthy approval context. Security teams should regularly test alternate paths to protected resources rather than validating only the intended gateway route.

For the Amazon Google cloud decision, model benchmarks are no longer enough. Buyers should compare default-deny behavior, identity propagation, policy analysis, audit detail, session controls, and enforcement coverage.

They should also ask how policies survive model and framework changes. Authorization tied tightly to one agent implementation becomes expensive to maintain and easier to bypass during migrations.

AWS has made a clear architectural bet. It assumes agent reasoning will remain manipulable, then limits the consequences through deterministic controls outside the agent.

That assumption is more credible than promising perfect model obedience. It accepts that mistakes and attacks will occur while preserving a separate authority over tools and data.

The approach still depends on disciplined configuration. A narrow gateway policy cannot compensate for an overprivileged runtime, an unmanaged shell, or data retrieved before authorization filtering.

Enterprise teams should now test one concrete workflow from beginning to end. Manipulate the agent, observe its requested actions, and confirm that protected operations fail at an external boundary.

That test provides a practical standard for Amazon Google and every other agent platform: the model can be fooled, but the infrastructure must still say no.