Last updated: November 6, 2026
How secure is Amazon Bedrock AgentCore for enterprise AI agents? AgentCore gives AWS builders strong primitives, including microVM session isolation, managed credentials and deterministic policy on tool calls. In 2026 it also showed where the model ends: researchers found a DNS channel in Code Interpreter's Sandbox mode, and two SDK command-injection CVEs were patched. Under shared responsibility, session mapping, IAM roles, policy design and prompt-level threats stay with you.
TL;DR: Key Takeaways
- Verdict: AgentCore is a strong fit for AWS-native agent builds, and teams running agents across clouds and on-premises usually add 1 independent control point such as TrustGate (Agent Gateway).
- BeyondTrust Phantom Labs reported in March 2026 that Sandbox mode allowed public DNS queries, and says AWS remediated DNS tunneling on April 15, 2026.
- 2 AWS bulletins cover command injection in the SDK's install_packages() helper: 2026-044-AWS (June 17) and 2026-065-AWS (July 23). Upgrade to bedrock-agentcore 1.18.1 or later.
- AWS states that AgentCore does not enforce session-to-user mappings, and sessions can run up to 8 hours.
- Guardrail scores in Policy come in 6 steps from 0 to 1.0 and are non-deterministic, unlike policy decisions.
At a glance: AgentCore security controls and owners
Quick Answer
Is AgentCore secure enough for enterprise AI agents?
AgentCore provides solid infrastructure security on AWS, including a dedicated microVM per session, managed credentials and deterministic policy on Gateway tool calls. Under the shared responsibility model you still own session-to-user mapping, IAM roles, policy content, SDK versions and prompt-level threats. Enterprises running agents in more than one environment usually add an independent security layer.
| Service | What it does | Built-in security function | What you still own |
|---|---|---|---|
| Runtime | Serverless runtime for agents and tools | A dedicated microVM per session, sanitized after use | Session-to-user mapping, execution role, input validation |
| Gateway | Managed AI gateway for tools, agents and models | Inbound and outbound auth, credential storage | Target hardening and interceptor code |
| Policy | Rules for every tool call routed through Gateway | Deterministic permit and forbid decisions | Writing, testing and maintaining policies |
| Identity | Managed agent identity and credentials | SigV4, OAuth 2.0 flows and API keys | Provider setup and token scopes |
| Code Interpreter | Sandboxed code execution for agents | Sandbox, Public and VPC network modes | Network mode, execution role, SDK version |
| Memory | Short-term and long-term agent memory | Encryption for stored memory | What agents may write and read back |
How we compared
On November 6, 2026 we re-read the Amazon Bedrock AgentCore Developer Guide pages on Runtime, Gateway, interceptors, Policy and Code Interpreter, plus two AWS security bulletins and two BeyondTrust Phantom Labs write-ups. We did not deploy AgentCore. These pages are cited by title, without links, under our policy on external vendor links.
What changed in AgentCore security in 2026
Three events shaped AgentCore security in 2026: a DNS finding in Code Interpreter's Sandbox mode, two command-injection CVEs in the Python SDK, and new AWS controls for Runtime and Policy. AWS fixed or documented each one. All of them sit on the customer side of the shared responsibility line.
| Date (2026) | Event | Source | Your action |
|---|---|---|---|
| March 16 | Sandbox mode allowed public DNS queries; remediated April 15 | BeyondTrust Phantom Labs | Inventory network modes |
| June 17 | CVE-2026-12530, fixed in SDK 1.6.1 | AWS bulletin 2026-044-AWS | Upgrade the SDK |
| June 30 | MMDSv2 required on Runtime | AWS Runtime documentation | Check every runtime |
| July 23 | CVE-2026-16796, fixed in SDK 1.18.1 | AWS bulletin 2026-065-AWS | Upgrade to 1.18.1 or later |
The Sandbox DNS finding
On March 16, 2026, BeyondTrust Phantom Labs showed that Code Interpreter in Sandbox network mode could still send public DNS queries. An attacker with code execution inside the interpreter could use that channel for command and control or to move data out.
According to BeyondTrust, AWS first scored the report CVSS 7.5, treated it as intended behavior and updated its documentation. BeyondTrust's April 22 update says AWS remediated DNS tunneling on April 15, 2026. AWS's current documentation lists three network modes: Sandbox (limited access to AWS services such as Amazon S3), Public and VPC. For sensitive work, BeyondTrust recommends VPC mode with Route 53 Resolver DNS Firewall.
The SDK command-injection CVEs
AWS published 2 bulletins for the open-source bedrock-agentcore Python SDK. CVE-2026-12530 (2026-044-AWS, June 17) affects versions 1.1.3 up to but not including 1.6.1. The install_packages() helper used an incomplete blocklist on package names, so crafted arguments such as pip's --index-url and -r flags got through.
CVE-2026-16796 (2026-065-AWS, July 23) affects every version before 1.18.1. According to AWS, it could let a remotely authenticated user run arbitrary commands inside the interpreter sandbox. BeyondTrust, which published its write-up on September 28, lists both CVEs at CVSS 3.1 7.3 and CVSS 4.0 8.4. AWS handled both through coordinated disclosure, and the fix is the upgrade. Its workaround is to keep user-supplied and model-generated strings out of install_packages().
The impact depends on what the interpreter can reach. BeyondTrust notes that a role attached to the interpreter exposes its credentials to code running inside it, and that CloudTrail records for InvokeCodeInterpreter carry no request parameters, so commands show up only in Observability logs. Our guide to MCP audit logging covers what a useful record contains.
Which AgentCore controls AWS runs and which you own
AWS secures the infrastructure that runs AgentCore, and you secure what you build on it. AWS documentation (2026) describes security as a shared responsibility, split into security of the cloud and security in the cloud. Agents add new items to your side of that split.
AgentCore is not one product. The overview lists 13 services, and each configuration is a security decision on your side of the split.
One line in the overview deserves review by data governance teams. According to AWS (2026), AgentCore may use and store your content to improve your service experience, and AWS says such improvements are for your use and not for other customers. Regulated teams should check that against their data rules.
Runtime sessions: strong isolation, with gaps you own
AgentCore Runtime gives each session its own microVM, with isolated compute, memory and filesystem. When the session ends, AWS terminates the microVM and sanitizes memory. That is strong isolation between sessions. The gaps sit around it: who owns a session, what the code inside can read, and who can call the runtime directly.
The Runtime sessions page is explicit. In AWS's words, "AgentCore does not enforce session-to-user mappings", so your client backend must keep the relationship between users and session IDs. AWS advises session IDs of at least 33 characters. Sessions last up to 8 hours on microVMs and up to 14 days on Instances.
The Runtime security best practices page adds four points you should read closely.
- Any code inside the microVM can read the execution role's credentials through the metadata service. AWS requires MMDSv2 on runtimes from June 30, 2026.
- The execution role the CLI creates by default permits invoking all foundation models in the account. AWS says to review it before production.
- InvokeAgentRuntimeForUser and its user-id header are not verified against an identity provider. AWS recommends JWT authentication.
- Filesystem permissions are not enforced inside the microVM, and user-supplied toolUse blocks can make some frameworks run a tool without model evaluation.
AWS also says to front Runtime with Gateway so that policies, guardrails and interceptors apply. They protect only traffic that flows through the gateway, so restrict direct invocation.
A practical checklist for Runtime:
- Generate session IDs server-side from a cryptographically secure source, never from user input.
- Bind each session ID to an authenticated user in your own datastore and check it on every call.
- Scope the execution role to the models, tables and buckets the agent needs, and block direct invocation.
- Log session creation and reuse, and alert on one session ID appearing under two identities.
Gateway, Policy and interceptors: deterministic rules on tool calls
AgentCore Policy evaluates every tool call that passes through an AgentCore Gateway against rules you define, before the agent can use the tool. That makes it a strong authorization control. It only sees traffic routed through Gateway, and rule quality is your job.
Policies can be written in Cedar, in Dogwood, which AWS describes as compatible with Cedar, or in natural language, where automated reasoning checks flag policies that are overly permissive, overly restrictive or impossible to satisfy. Temporal policies are scoped to a session, such as required approvals or budgets, and decisions are logged to CloudWatch.
The biggest change is that guardrails are now a documented part of Policy. Backed by Amazon Bedrock Guardrails, they cover content filtering, prompt attacks (jailbreak, prompt injection and prompt leakage) and sensitive information. According to AWS, scores come in six steps from 0 to 1.0, and the default threshold for prompt attacks is 0.4.
AWS separates the two kinds of decision: guardrail scores are non-deterministic, while policy decisions are deterministic. A LOG_ONLY mode lets you test before you enforce. One detail deserves a test: if no JSONPath resolves, evaluation fails closed, but a mistyped path next to working ones fails silently.
Regional availability also matters. As of November 6, 2026, the guardrails-in-policies page lists seven Regions, including London and Stockholm, but not Frankfurt, Ireland or Paris. Check the current list before designing an EU deployment around it.
Interceptors add custom logic, with limits. A gateway takes one REQUEST and one RESPONSE interceptor, both Lambda functions, so their code, dependencies and patching are yours. Headers are not passed unless passRequestHeaders is true, and since Gateway may retry, functions must be idempotent. AWS says the execution role should invoke only those specific functions.
If you are new to the attack these controls guard against, our MCP prompt injection proof on Bedrock shows how tool output can steer an agent.
Code Interpreter, Identity and credentials: where excessive agency starts
According to AWS, AgentCore Identity centralizes agent identities and credentials through SigV4, OAuth 2.0 flows and API keys, while Gateway handles inbound and outbound authentication for tools. That reduces secret sprawl, and it concentrates delegated access, so scoping becomes the main control.
Gateway offers 1-click integrations with Salesforce, Slack, Jira, Asana and Zendesk, and each connection gives an agent real permissions in a business system. AWS calls Gateway the only solution combining comprehensive ingress and egress authentication in a fully managed service. That is AWS's own claim, and whether it fits your estate is a separate question.
Excessive agency, where an agent holds more functionality, permissions or autonomy than its task needs, is the pattern to watch. Code Interpreter is a clear example in 2026. An interpreter with a broad role, open network access and an old SDK turns one injected instruction into an AWS API call.
Four rules keep this layer tight:
- Use separate credentials per tool and per environment.
- Give each interpreter the narrowest network mode that works, and move sensitive workloads to VPC mode.
- Attach an execution role only when the code needs AWS access, and scope it to named resources.
- Update the SDK, and enable CloudTrail data events and Observability logs so commands leave a record.
For role design, see our guide on why AI agents need RBAC.
Prompt-level threats and memory: the layer Policy does not judge alone
Policy decides whether a tool call is allowed. A guardrail score can now feed that decision, but it remains a probabilistic signal you configure, tune and test. Indirect prompt injection, poisoned long-term memory and unsafe model output still need content inspection and tight rules.
Take a permitted action: an agent allowed to post Slack messages can be told by a hidden instruction in an email to post sensitive data publicly. The call matches the rules, so only content inspection or a tighter rule would catch it.
AgentCore Memory raises a related issue. Long-term memory also gives injected content a way to persist. Treat memory writes like database writes: validate them, attribute them to a source and review what agents can store. This is our recommendation, not an AWS requirement.
| Threat | AgentCore building block | Gap to close |
|---|---|---|
| Indirect prompt injection | PromptAttack guardrail in Policy | Tune thresholds, test in LOG_ONLY mode, check Region support |
| Unauthorized tool use | Policy on Gateway traffic | Cover every tool path, including direct runtime invocation |
| Code execution abuse | Code Interpreter network modes | VPC mode, scoped role, patched SDK |
| Memory poisoning | Memory service | Validation and review of memory writes |
For a hands-on view of Bedrock's content controls, read our test of topic detection with Bedrock Guardrails.
Security and governance: securing agents beyond one cloud
Most enterprises will not run every agent on one platform. Agents will live in AWS, other clouds, SaaS tools and on-premises systems, and security teams need one policy and visibility layer across all of them. AgentCore covers the AWS side well. An independent layer covers the rest and separates those who run agents from those who audit them.
We sell TrustGate, so weigh this section with that in mind. The Agent Gateway (TrustGate) routes calls to models, MCP servers, tools and other agents. According to NeuralTrust's product page, it forwards end-user identity through every hop, applies per-agent and per-tool RBAC and keeps cryptographic audit trails. It runs as a managed service with US or EU residency, as a hybrid with a private data plane, or on-premises on Kubernetes.
The pricing page, checked on November 6, 2026, shows 7 days of log retention on Free and 30 days on Standard, with private deployment and OpenTelemetry or SIEM integrations on Enterprise. Agent Runtime Security (TrustGuard) adds prompt injection protection, including multi-turn attacks, and checks on MCP tool responses.
Agent Posture Management (TrustLens) and AI Red Teaming (TrustTest) cover inventory and pre-release testing. None of this replaces AgentCore's controls. It is a second opinion that does not depend on where an agent was built.
Which should you choose?
Choose by where your agents live. For agents that run mostly on AWS, AgentCore gives managed runtime, identity and tool-call policy with consumption-based pricing. For agents across clouds, SaaS tools and on-premises systems, an independent gateway such as TrustGate gives one control point. Many organizations will use both.
| If you are... | Choose | Why |
|---|---|---|
| A CISO securing agents across AWS, other clouds and on-premises | Independent gateway | One policy point outside any single cloud |
| A regulated enterprise with strict data residency rules | Independent gateway | Managed US or EU residency, hybrid or on-premises options |
| An AWS-native team shipping its first production agent | AgentCore | Managed Runtime, Identity and Policy with consumption pricing |
| A team that needs Cedar-based authorization inside AWS | AgentCore Policy | Deterministic rules on Gateway tool calls |
| A team already on AgentCore that wants independent evidence | Both | AgentCore controls plus a separate layer for audit |
Conclusion
AgentCore gives AWS teams strong building blocks for agent security, and 2026 showed that the work does not end at the platform line. A DNS channel in Sandbox mode, two SDK CVEs and new Runtime warnings all fall on the customer side. Patch the SDK, scope roles, bind sessions to users, test guardrails as probabilistic signals and add an independent layer when your agents span more than one environment.
Secure AgentCore Agents in Production with NeuralTrust
Govern every agent, tool call and MCP connection from one gateway that runs where your agents run.
Related Comparisons
- 6 best MCP gateways for enterprise (2026)
- AI gateway vs MCP gateway: key differences
- What is excessive agency?
- The AI control plane for agentic security
FAQs about AgentCore
1. What is AgentCore?
Amazon Bedrock AgentCore is an AWS platform for building, deploying and operating AI agents with any framework and foundation model. The overview lists 13 services, including Runtime, Memory, Gateway, Identity, Code Interpreter, Policy and Registry. Pricing is consumption-based, with no upfront commitment, according to AWS.
2. Has AgentCore had security vulnerabilities in 2026?
Yes, in the open-source Python SDK. AWS published CVE-2026-12530 on June 17 and CVE-2026-16796 on July 23, both in the Code Interpreter install_packages() helper. Fixes shipped in SDK versions 1.6.1 and 1.18.1. BeyondTrust also reported a Sandbox mode DNS channel in March, which it says AWS remediated on April 15.
3. Is AgentCore Gateway an MCP server?
AgentCore Gateway acts as a managed endpoint for MCP tools. It converts APIs, Lambda functions and existing services into MCP-compatible tools and connects to existing MCP servers. AWS calls it a fully managed AI gateway, because it also fronts other agents through passthrough targets and routes inference requests across model providers.
4. How does AgentCore Policy work?
AgentCore Policy intercepts tool calls routed through AgentCore Gateway and checks each one against rules in a policy engine. You write rules in Cedar, in Dogwood or in natural language. Rules can permit, forbid or set conditions, including session counters, budgets and guardrail scores, which AWS says are non-deterministic while policy decisions are deterministic.
5. Which Code Interpreter network mode should I use?
For sensitive workloads, use VPC mode, which connects the interpreter to your own VPC. Sandbox mode gives limited access to AWS services such as Amazon S3, and Public mode opens the internet. BeyondTrust recommends pairing VPC mode with Route 53 Resolver DNS Firewall, and AWS says Public mode brings security considerations.
6. Does AgentCore Runtime map sessions to users?
No. AWS states that AgentCore does not enforce session-to-user mappings, so your client backend must keep that relationship. Each session still gets its own microVM, and memory is sanitized when it ends. AWS advises session IDs of at least 33 characters and recommends JWT authentication over the user-id header.
About the Author
Roger Howroyd is Head of Global SEO and AI at NeuralTrust, where he leads the company's search strategy across SEO, AEO, GEO, and LLM optimization. He specializes in AI-powered search, content strategy, and SEM. Connect on LinkedIn.
NeuralTrust is the leading platform for securing and scaling AI agents. Named a Pioneer in the Gartner Emerging Market Quadrant for AI Application Security 2026, recognized across four Gartner Hype Cycle reports in 2026, and featured in the Gartner Market Guide for Guardian Agents 2026, the Gartner Market Guide for AI Gateways 2025 and the KuppingerCole Leadership Compass for Generative AI Defense 2025. Headquartered in Barcelona with offices in London and New York. ISO 27001 certified.
Sources
All pages retrieved November 6, 2026. AWS and BeyondTrust materials are cited by title without a link, following our external-vendor-links policy.
- AWS, "What is Amazon Bedrock AgentCore?," Amazon Bedrock AgentCore Developer Guide.
- AWS, "Security in Amazon Bedrock AgentCore," Amazon Bedrock AgentCore Developer Guide.
- AWS, "Use isolated sessions for agents" and "Security best practices," Amazon Bedrock AgentCore Developer Guide (Runtime).
- AWS, "Amazon Bedrock AgentCore Gateway: A secure AI gateway for agents, tools, and models" and "Using interceptors with Gateway," Developer Guide.
- AWS, "Policy in Amazon Bedrock AgentCore" and "Guardrails in policies," Developer Guide.
- AWS, "Resource management" (Code Interpreter network modes), Amazon Bedrock AgentCore Developer Guide.
- AWS Security Bulletin 2026-044-AWS, "CVE-2026-12530," published June 17, 2026.
- AWS Security Bulletin 2026-065-AWS, "CVE-2026-16796," published July 23, 2026.
- BeyondTrust Phantom Labs, research on Code Interpreter Sandbox mode and DNS, published March 16, 2026, updated April 22, 2026.
- BeyondTrust Phantom Labs, "Two RCE CVEs in the Amazon Bedrock AgentCore Python SDK Code Interpreter Helper," September 28, 2026.
)
)
)
)
)
)
)