Sheldon Zhao, Director of Product Management | Aurascape
August 20th, 2026 | 🕐 9 minute read

Introduction

Amazon Bedrock AgentCore makes it easier to run AI agents in production. Teams get managed runtime, a gateway, an identity service, and shared memory for their various agents. A finance team can run a lean agent in a locked-down container. A developer team’s agent needs more tools and more network reach, and its container is configured accordingly. The platform handles much of the runtime infrastructure teams used to build themselves. Assemble the pieces, set a few policies, and you’ve shipped your agent.

This environment changes what security teams have to account for. Enterprises spent the last two years governing how employees use AI tools. Platforms like Agentcore are the next phase: teams build agents that reason, hold credentials, call tools, and take actions on their own. Those agents run on AWS-native infrastructure, which means security teams inherit them the way they inherited EC2 and Lambda.

AgentCore ships with native security controls. Every agent carries an identity, tool calls pass authorization decisions, sessions run isolated, and policy at the AgentCore Gateway can check traffic passing through it. This provides a starting security foundation for agents built and run in AWS.

Security teams run defense in depth everywhere else in their AWS infrastructure, and agent platforms should be no different: the platform brings its controls, and a dedicated security layer runs alongside them. For AI agents, this layer is especially vital, given the growing blast radius due to the productivity incentives to plug agents into business systems. For this reason, teams building on Agentcore should run a security layer which applies inline, real-time content inspection and policy enforcement to what agents do on the network.

An agent is a network actor

Strip away the agent framing and look at what a live agent does on the wire. It calls a model and invokes tools. Some of those are direct API calls, some are over MCP. When the agent’s goal requires it to reach a person, it can message them over a collaboration platform. When it has web access, it browses. Every one of those is network traffic, and the agent is a busy network actor with credentials and a task.

Authorization decides which of these calls goes through. An execution role scopes the agent, a policy allows the tool, and the call proceeds. But what authorization decisions lack is understanding of content: the prompt going into a model, the records inside an API request, the instruction coming back in a tool result. Content is where the security risks really live. A threat arrives as content. Sensitive data leaves as content. Whether a permitted call was safe depends on what it carried, and a control that stops at allow-or-deny misses this context.

Let’s take a hypothetical example: A bank builds an agent to answer questions about loan portfolios. Its role grants read access to the reporting database, it uses an approved Bedrock model, and its application writes conversation history to AgentCore Memory so context can carry across invocations. Each destination in that loop has been reviewed and cleared. The security team signs off because the authorization model is clean.

Then one morning the reporting API begins rejecting requests with a schema-validation error. The application’s repair loop passes the diagnostics to the model to work out what went wrong, and those diagnostics serialize the outbound request headers without redaction, including the authorization header that carries a live API key. No one decided to expose a secret; it rode inside the diagnostics. A corrected request goes through and the task completes, so no failure ever reaches a human. The application writes the exchange, diagnostics included, to AgentCore Memory as session history. When that history is reloaded for a later invocation, the stored diagnostics carry the key into the next model prompt, and every later turn that reloads it does the same. Each control answered the question it was built to answer: is this agent authorized to make this call? The identity and destination checks still permit it, because neither has changed, even though the next prompt now carries a live credential. That credential sits in retrievable conversation history, and the bank has to revoke it and work out which later model inputs carried it, for a task that completed without an alert.

Our own threat researchers work on this platform. AuraLabs found an isolation gap in the AgentCore Code Interpreter sandbox, reported it to AWS in September, and AWS validated the fix in December. You can read the full AuraLabs write-up here.

Containment has a ceiling

One response is to narrow the agent’s reach. Cut the agent’s internet access. Strip its tools down to the bare minimum. Run it in the most restrictive sandbox the platform offers. If the agent cannot reach much, it cannot leak much.

Containment helps, but it has two limits:

• First, aggressive containment caps the value AgentCore provides in the first place. The reason to build an agent is that it can reach a system, pull what it needs, and act. An agent with its tools removed and its network cut is a slower way to do what a script already did. Lock an agent down far enough and it becomes too weak to be worth running.
• Second, containment is only as complete as the paths it covers. Enumerating every route out of a container is difficult, and permitted capabilities can open paths the policy author never considered. Restriction also has the same content-level blind spot: a sandbox is good at limiting what an agent can execute, but struggles to understand and act on the content within the interaction. Of course, this content is where data leaves and threats can enter.

Recent model evaluations exposed the same problem from two directions, through a vulnerability and through a configuration mistake. Between late July and early August, OpenAI, Anthropic, and Meta each disclosed that models under cybersecurity evaluation reached real third-party systems from environments meant to be sealed. OpenAI’s models found a novel way out of an environment that was genuinely isolated. In the Anthropic and Meta incidents the isolation was misconfigured, and Anthropic’s evaluation prompt had told the model it had no internet access. None of those organizations caught it in advance.

The way out is not to keep shrinking container privileges. It is to add an additional layer of content-level inspection and policy.

Put the control on the network path

Aurascape sits inline on the traffic moving in and out of the container. The native AgentCore controls stay exactly where they are. Instead of deciding in advance which routes an agent may take and depending on the list being complete, Aurascape applies a full security stack to the traffic itself: access security, threat protection, and data protection, at the tool level and at the content level.

Deployment fits the way AgentCore already works. An AgentCore runtime runs from a container image you supply, published to a registry. You build the Aurascape configuration and certificate into that image once. Runtimes built from that image inherit the configuration. The container authenticates to the proxy as a workload, which is the right model for an agent: there is no human at a managed endpoint to authenticate on its behalf. Nothing gets installed inside AgentCore itself, and the work sits with whoever maintains the image. Standardizing it this way moves the control into the deployment pattern, so a new agent inherits it at creation instead of depending on someone to configure it.

Once traffic is on that path, one architecture governs all of it. Three kinds of traffic matter: 

• The model leg. Every agent talks to a model, whether that is Bedrock or something else. The AI Proxy sits inline on this traffic, reading every prompt and every response. Sensitive data heading into a model gets classified inline against hundreds of real-time data classifiers, and policy is evaluated before the exchange completes. Classification reads the payload for the categories a regulated business cares about: personal identifiers, financial account data, health information, credentials, source code. Inspection runs in both directions, so a model response that returns sensitive content, or an instruction an agent should not act on, is inspected on its way back as well. When retrieved memory is inserted into a prompt, it crosses this leg like anything else in the prompt, and a credential riding in it gets classified as credential data.
• The tool leg. Agents act through tool calls, and the Zero-Bypass MCP Gateway governs those calls on the MCP path. Each approved tool carries a Gateway marker. Aurascape checks that marker on the network path, which separates approved MCP traffic from calls that try to reach the same service outside that route. On this path Aurascape inspects the tool call for sensitive data on its way out and for threats on the way in, including dangerous commands and prompt injection buried in a tool result.
• Everything else on the wire. An agent can skip the official MCP server for a service and write a short script that calls that service’s REST API directly. The tool was reached, the data moved, and a control scoped to MCP traffic saw none of it, because the call never went through the MCP server. Security solutions whose primary offering is a standalone MCP gateway will not see that call. Aurascape does, because it sits on the network path and recognizes the HTTP traffic whether or not an MCP server was involved.

That third category also carries collaboration traffic and web browsing. Agents send messages to people and to other systems over collaboration platforms. Aurascape sees the channel an agent is using and can control whether and where it gets used.

Web access also opens a potential path for untrusted content to make its way back to the agent, through malicious downloads and through pages crafted to hijack the agents that reads them. On the browsing path, Aurascape applies threat prevention: malware download protection, file type control, and detection of content injection and prompt injection, including the indirect kind that hides an instruction in a page the agent visits. For example, an agent researching a vendor loads a page that contains text addressed to the agent rather than to a reader, telling it to collect sensitive data and send it over a messaging tool. The agent has no way to know the instruction did not come from you. Aurascape detects this indirect prompt injection attempt and applies policy in real time.

One HTTP control point covers model traffic, tool traffic, direct API calls, collaboration channels, and browsing.

Give agents more access, not less

This added control gives you defense-in-depth for your AgentCore agents. This means security teams can say yes to more for the agents their teams build and run. With inline controls on the model and tool paths, and visibility into the traffic that would otherwise bypass them, cutting an agent’s access stops being the only lever available.

An agent can keep its web access, because browsing runs through threat prevention. It can call the APIs it needs, because those calls are seen whether or not they go through MCP. The finance agent gets the tools its work requires. The developer agent can safely keep its reach, increasing output. The same AI policies that govern the rest of your AI use apply here, and AgentCore agents show up in the same reporting and auditable conversation logs as the rest of your governed AI traffic.

What this looks like in practice

Consider a sales operations agent, the kind a revenue team stands up to keep a customer database clean. Its job is to enrich and merge records: pull account details, fill gaps, and push updates back. It has legitimate reason to touch customer data all day, which is the point of building it. 

Two paths lead to the same customer system. The clean one runs through an approved MCP server, governed and inspected. The other path is to not use the approved MCP server at all. The CRM’s REST API is documented, the agent has credentials for it, and writing a few lines to call it directly is a reasonable way to finish the task. Nothing failed and no rule was broken. That call is permitted, the agent’s role allows it, and nothing about it trips an authorization control. Riding inside it, on the way to a third-party service, are customer names and account numbers. 

On the network path it is visible the moment it leaves the container, because it is HTTP traffic on the path Aurascape governs, and it lands in an interaction record. 

Adopt agents faster

AgentCore helps teams manage their growing fleet of agents. It handles identity, authorization, isolation, and the operational machinery that used to take a dedicated platform team. Those controls remain necessary. Running a security layer alongside the platform is not a criticism of the platform. It is how enterprises already secure everything else on AWS.

Aurascape is the strong security layer for agent traffic: inline on the container’s network path, applying the same content inspection and policy enforcement whether a call goes to a model, through a tool, or straight to an API.

None of it requires a rip-and-replace of your existing controls. Aurascape provides discovery, inline data classification, tool-call governance, threat prevention, and interaction records for policy decisions and flags. That gives you more room to say yes, because you can see and control what your agents are doing.

See how Aurascape can add defense-in-depth for your AgentCore environment