Bedrock AgentCore Security: AWS Bedrock Agent Security and Prompt Injection Controls
AgentCore gives you microVM isolation, agent identity and Cedar policy on the gateway. What it does not do, in AWS own words, is inspect what a prompt means or constrain how an agent behaves once it is inside.
Direct answer
Amazon Bedrock AgentCore is a well built platform. Every session runs in its own Firecracker microVM with no shared state and no shared filesystem, AgentCore Identity threads end user identity through the agent so downstream tools can use scoped credentials instead of a shared service account, and Cedar based policies on AgentCore Gateway can gate every tool call by who is calling, under which conditions and with which arguments. AgentCore Policy with Bedrock Guardrails reached general availability in June 2026. The part buyers miss is written plainly in the AWS shared responsibility model for the AgentCore harness. AWS lists input validation and prompt injection prevention as your responsibility, alongside session to user mapping enforcement, IAM access controls, and the security of commands executed in runtime sessions. AWS states the boundary directly: the harness validates the structure of the request it accepts, but it does not inspect the meaning of prompts, screen content, or enforce behavioral constraints on the agent. For non harness AgentCore Runtime deployments AWS is blunter still, writing that AgentCore Runtime provides no server side protection. Three of the six rows in the comparison table further down say the native AWS control is the right purchase and we are not the thing you need.
Try it live
Watch Agentshield block an attack in real time.
Pick a scenario and drive the inspection lane yourself. No signup needed.
Run a request
Runs the live engine on your text. Nothing is stored, no account needed.
Inspection lane
INSPECTINGPolicy trace
High-risk action held for approval
Audit trail
- § · → → →
The risk
The usual path onto AgentCore is a migration, not a greenfield build. Bedrock Agents became Bedrock Agents Classic and closed to new customers on 30 July 2026, so any team standing up an agent in a fresh AWS account now gets an AccessDeniedException on CreateAgent and lands on AgentCore whether or not they planned to. Migration is when blast radius quietly grows. Action groups that used to be a Lambda behind an OpenAPI schema become MCP tools behind AgentCore Gateway, reachable by anything that clears the gateway. Return of control becomes an inline function tool your own client code has to handle. Memory is on by default. Each of those steps is reasonable and each one passed review on its own, and at the end the agent can touch more systems than the thing it replaced, with an orchestration layer nobody has threat modeled yet.
How Agentshield handles it
Turn on the AWS controls first, because they are included with the service and nothing you buy afterward replaces them. Run the harness in VPC mode with the required interface endpoints rather than on the public network, use inbound OAuth with a JWT authorizer instead of SigV4 if you need per user credential scoping downstream, scope the execution role to specific inference profiles rather than the wildcard the sample policy ships with, put tools behind AgentCore Gateway so Cedar policy can gate them, and attach Bedrock Guardrails so model input and output get filtered. Then add the layer AWS tells you to build yourself. AWS recommends validating and sanitizing messages in your application layer before they reach InvokeHarness, stripping content block types and model configuration fields you do not want dispatched, and allowlisting skill sources. That is a security application you now own, maintain and audit. The alternative is to put those controls in the action path as configuration: a scoped identity per agent so a hijacked prompt cannot reach a tool the agent was never granted, a policy that denies an out of scope tool call before it executes rather than filtering the text that requested it, an approval gate on irreversible operations such as payments, deletions and production writes, and an append only record of attempted and blocked actions kept somewhere the agent host cannot rewrite. AgentCore governs the runtime and the gateway. The second layer governs the action.
The controls
The controls that secure the agents your teams run on Amazon Bedrock AgentCore, and the tools those agents call.
Is Amazon Bedrock AgentCore secure? What AWS covers in 2026
Yes, and it is worth being precise about why, because most writing on this topic is vague in exactly the places procurement cares about. AgentCore inherits the AWS security model rather than inventing a new one, so controls your team already knows how to operate mostly apply. The table lists the native controls that matter for an agent workload and what each one actually does.
| Control | What it does | Where it sits |
|---|---|---|
| Firecracker microVM session isolation | Every session runs in its own microVM in AgentCore Runtime, with no shared state and no shared filesystem between sessions | Compute |
| AgentCore Identity and inbound OAuth | Requires callers to present a valid JWT from a configured identity provider, and threads end user identity through the agent so downstream tools can call APIs with scoped user credentials instead of a shared service account | Identity |
| AgentCore Policy on Gateway | Cedar based policies gate every tool call: who can call which tool, under which conditions, with which arguments. Generally available with Bedrock Guardrails support since June 2026 | Tool authorization |
| Bedrock Guardrails | Filters model input and output for harmful content, sensitive data and jailbreak patterns. Guardrails configured on the model still apply when that model is invoked through AgentCore | Model input and output |
| VPC mode and PrivateLink | Runs harness sessions inside your VPC for private access to internal resources, with interface endpoints for ECR and Bedrock runtime and an optional private path to your identity provider | Network |
That is a real security stack, and a team that turns all of it on is ahead of most agent deployments we see. Two things are worth flagging before you treat it as complete. First, the sample execution role policy AWS publishes allows bedrock:InvokeModel against arn:aws:bedrock:*::foundation-model/*, which is every foundation model in every region. AWS says so in a note and tells you to scope it down to specific inference profiles for production. Plenty of teams never come back to that note. Second, all of the above governs who may call a tool. None of it governs whether the model should have decided to call that tool after reading a hostile web page.
Bedrock Agents Classic maintenance mode: what changed on July 30, 2026
If you are researching AgentCore security right now, there is a decent chance you did not choose AgentCore so much as arrive at it. AWS moved Bedrock Agents, launched in November 2023, into maintenance mode under the name Bedrock Agents Classic. Here is what that means in practice, taken from the AWS maintenance mode documentation rather than from commentary about it.
| Question | What AWS documents |
|---|---|
| Do existing agents stop working? | No. Existing agents continue to function and the full API surface stays available. Only CreateAgent and InvokeInlineAgent are restricted, and only for accounts with no prior usage. |
| Who is affected? | Accounts with Bedrock Agents activity in the past 12 months are allowlisted automatically. This is per account, so a new account in an existing organization is not covered. |
| What happens if you are not allowlisted? | CreateAgent returns AccessDeniedException, HTTP 403, with a message saying Bedrock Agents is in maintenance mode. |
| Can you request an exception? | No. AWS states there is no exception process. |
| Is there a migration deadline? | No deadline and no announced end of life. But the model catalog is frozen as of 30 July 2026, so models released after that date are only reachable through AgentCore. |
The frozen model catalog is the part that actually forces the decision. An agent stuck on Classic keeps working indefinitely and keeps running the models it could run in July 2026, which in this field is a short shelf life. AWS recommends migrating and ships an amazon-bedrock skill in the agent toolkit for AWS that inspects your existing agent, checks migration eligibility, maps each component to its harness equivalent and drives the AgentCore CLI. AWS notes the skill never modifies your source agent and pauses for approval before deploying.
Security review is the step teams skip during a migration, because a migration feels like a like for like move. It is not. AWS documents several capability changes that matter for risk. Stage specific prompt overrides for pre-processing, knowledge base response generation and post-processing are not directly replicated, so any guardrail you had implemented as a post-processing prompt no longer exists in that form. The built in AMAZON.UserInput tool that handled reprompting becomes an inline function tool your client code has to implement, which means the human in the loop pause is now code you own. Multi-agent collaboration is described by AWS as limited, with routing mode not straightforward today. Every one of those is a control that silently changes hands during migration.
What the AWS shared responsibility model puts on you
This is the section worth reading twice, because AWS is unusually direct about it and the wording rarely makes it into third party summaries. The AgentCore harness security documentation splits duties explicitly. AWS handles infrastructure and microVM isolation at the hardware level, OS kernel patching, language runtime patching, the managed harness runtime code including validation of the request structure InvokeHarness accepts, network infrastructure security, and service availability.
Your side of the line is longer, and it is the interesting half.
| Your documented responsibility | What it means at 2am |
|---|---|
| Input validation and prompt injection prevention, including validating all InvokeHarness input | Nothing in the platform decides whether an instruction reaching the model is legitimate. That judgment is yours to implement. |
| Session to user mapping enforcement | Tying a session to a real human is your code, which is what makes an audit trail meaningful later. |
| IAM access controls and resource policies | Least privilege on the execution role, not the wildcard in the sample policy. |
| Security of commands executed in runtime sessions | The microVM contains the blast, it does not decide whether the command should run. |
| Skill and instruction sources | Ensuring the S3 buckets, Git repositories and URLs your skills come from contain trusted content. |
AWS then states the trust boundary in one sentence that is worth quoting exactly, because it describes the gap better than any vendor could: the harness validates the structure of the request it accepts, but it does not inspect the meaning of prompts, screen content, or enforce behavioral constraints on the agent.
For deployments that are not using the managed harness, AWS goes further. It writes that for AgentCore Runtime deployments, AgentCore Runtime provides no server side protection, and that your agent entrypoint must validate that the prompt field is a string and reject or strip toolUse content blocks before passing input to the agent framework. If you deployed a LangChain or Strands agent onto AgentCore Runtime directly, which is the common path for teams migrating an existing codebase, that sentence is about you.
AWS is not being evasive here. It is describing a platform boundary honestly, the same way Microsoft does in the Foundry responsibility matrix. The mistake is on the buyer side: reading "AgentCore handles identity and observability" in a launch blog and concluding that agent behavior is handled too.
Three documented gaps in Bedrock AgentCore security worth knowing before you ship
These are not vulnerabilities and they are not criticisms. All three are documented by AWS in the same pages linked throughout this article, which is exactly why they are worth planning around rather than discovering.
SigV4 does not carry per user identity downstream. When callers authenticate with SigV4, meaning ordinary AWS IAM credentials, the harness does not propagate per user identity into downstream tool calls. The user scoped OAuth token storage and on behalf of token exchange in AgentCore Identity Token Vault are only available on the inbound OAuth path with a Bearer JWT. AWS says SigV4 support for per user identity is planned for a future release. If your design assumed IAM auth would give you per user scoping at the tool, it will not today, and every downstream call will look like the same service principal in your logs.
Model configuration parameters pass through unvalidated. The model field in InvokeHarness accepts additionalParams for Bedrock, OpenAI and LiteLLM configurations, and AWS states the harness does not validate, filter, or restrict these parameters. A caller who can set them can redirect requests to an arbitrary endpoint using the LiteLLM Bedrock runtime endpoint parameter, override HTTP headers including Authorization through OpenAI extra headers, attempt IAM role assumption via the LiteLLM role name parameter, and change the target model, region or provider entirely. AWS mitigations are all things you build: strip or allowlist the model field, validate or remove additionalParams and apiBase, and deny sts:AssumeRole on the execution role if you do not need role switching.
Skills are treated as trusted input. Skills are bundles of markdown and scripts the harness fetches from S3 or Git at invocation time and injects into agent context. AWS writes that the harness treats all skill content as trusted input and does not validate, sanitize, or inspect the content or source of skills. Skills can also be overridden per InvokeHarness call, so if your application forwards caller supplied input, a caller can point the harness at their own skill source containing arbitrary instructions. This is indirect prompt injection with a supply chain shape, and the fix AWS suggests is to strip the skills field from caller supplied requests or allowlist permitted S3 prefixes.
The thread running through all three is the same: the platform gives you the primitives and hands you the policy. That is a reasonable place for a cloud provider to draw the line. It just means the line is where your work starts, not where it ends.
Bedrock AgentCore security tools compared: what to buy and what you already have
Most comparison tables in this category are written so the vendor wins every row. That is not useful when you are the one signing the purchase order, so this one marks the rows where the AWS native control is the right answer and we are not. Three of six go to AWS.
| What you need | Best answer | Why |
|---|---|---|
| Session isolation and sandboxed execution | AWS native | Firecracker microVM per session with no shared filesystem is a hardware level boundary. Nothing you install above it improves on that, and you already pay for it. |
| Agent identity, OAuth token exchange, credential vaulting | AWS native | AgentCore Identity with inbound OAuth and Token Vault is purpose built for this and integrates with your existing identity provider. Buy this from AWS, configure the JWT authorizer, and skip the third party layer. |
| Coarse tool authorization by caller and arguments | AWS native | Cedar policy on AgentCore Gateway already answers who can call which tool with which arguments. If your requirement stops there, it is solved. |
| Deciding whether the model should have called that tool at all | Agentshield | AWS states the harness does not inspect the meaning of prompts or enforce behavioral constraints. Injection that arrives inside legitimate tool output passes a Cedar policy cleanly, because the caller and arguments are valid. This needs inspection in the action path. |
| Human approval gate on irreversible actions | Agentshield | AgentCore gives you return of control as an inline function tool, which is a mechanism, not a control. The approval workflow, its routing, its timeout behavior and its record are an application you build and maintain. |
| Immutable record of attempted and blocked actions across platforms | Agentshield | AgentCore tracing is genuinely good observability, and AWS notes correlation identifiers are used for observability only and never for authorization decisions. An audit trail of what was denied, spanning agents that do not all live on AWS, is a different artifact. |
The honest summary: if every agent you run lives on AgentCore and your risk model is unauthorized callers, configure AWS properly and stop. If your risk model is a legitimate agent doing an illegitimate thing because something it read told it to, or if half your fleet runs somewhere other than AWS, the action layer is the piece that is missing. That question is worth answering before the migration, not after, because the migration is when the tool surface expands.
FAQ
Common questions about bedrock agentcore security.
Is Amazon Bedrock AgentCore secure?
Yes, as a platform. Every session runs in an isolated Firecracker microVM with no shared state or filesystem, AgentCore Identity supports inbound OAuth with JWT and per user credential scoping downstream, Cedar policies on AgentCore Gateway gate tool calls by caller and arguments, and Bedrock Guardrails filter model input and output. Security of an agent workload also depends on controls AWS assigns to you, chiefly prompt injection prevention and input validation.
What does the AWS shared responsibility model say about AgentCore?
AWS takes infrastructure and microVM isolation, kernel and runtime patching, the managed harness runtime code, network infrastructure and availability. You take agent code security, IAM access controls, security of commands executed in runtime sessions, session to user mapping, skill and instruction sources, and input validation and prompt injection prevention. AWS states the harness does not inspect the meaning of prompts or enforce behavioral constraints on the agent.
Are Bedrock Agents being deprecated?
Not deprecated, but in maintenance mode. Amazon Bedrock Agents is now Bedrock Agents Classic and closed to new customers on 30 July 2026. Existing agents keep working, all APIs stay available, and AWS has announced no end of life date. Only CreateAgent and InvokeInlineAgent are restricted, and only for accounts with no Bedrock Agents activity in the previous 12 months.
Do I have to migrate from Bedrock Agents to AgentCore?
There is no deadline, but there is pressure. The Bedrock Agents Classic model catalog is frozen as of 30 July 2026, so any foundation model released after that date is only available through AgentCore, and AWS has said no new features are planned for Classic. Most teams migrate for the model catalog rather than for a shutdown notice.
Does AgentCore protect against prompt injection?
Partly. Bedrock Guardrails filter model input and output, and AgentCore Policy can gate tool calls. AWS lists prompt injection prevention as a customer responsibility and writes that the harness does not inspect the meaning of prompts or enforce behavioral constraints. For non harness AgentCore Runtime deployments AWS states plainly that Runtime provides no server side protection.
What is the difference between Bedrock Agents Classic and AgentCore?
AgentCore is a re-architecture rather than a rename. Classic was a single managed orchestration loop with action groups and knowledge bases attached declaratively. AgentCore separates runtime, gateway, identity, memory and observability into primitives, exposes tools as MCP through the gateway, and runs any framework including Strands, LangChain, the OpenAI Agents SDK and the Claude Agent SDK.
How long does it take to migrate to AgentCore?
AWS says straightforward agents built from a model, action groups and a knowledge base take hours using the CLI import or harness setup, with most effort going into reviewing generated code and redeploying action groups behind AgentCore Gateway. Agents with custom orchestrators or multi-agent collaboration require significant code work, because AWS describes multi-agent routing support as limited today.
Does AgentCore support human in the loop approval?
It provides the mechanism, not the control. Inline function tools give you a return of control pattern where the agent pauses and returns a tool use block to your client code, which handles the interaction and sends a result back. The approval workflow itself, including who approves, what happens on timeout and what gets recorded, is an application you build and maintain.
Is AgentCore Policy the same as Bedrock Guardrails?
No, and they work at different layers. Bedrock Guardrails filter content in model input and output. AgentCore Policy uses Cedar to authorize tool calls at the gateway based on who is calling, under what conditions and with which arguments. AgentCore Policy gained Guardrails support in June 2026, so they can be combined, but neither evaluates whether the reasoning that produced a call was manipulated.
Do I still need third party security if I use AgentCore Gateway policies?
It depends on your risk model. If the threat is an unauthorized caller reaching a tool, Cedar policy on the gateway handles it and you are done. If the threat is an authorized agent making a valid looking call because content it processed told it to, a policy that checks caller and arguments passes that call cleanly, and you need inspection and approval in the action path instead.
More use cases