Inside the Agent Stack: Securing Agents in Amazon Bedrock AgentCore

In the first installment of our Inside the Agent Stack series, we examined the design and security posture of agents built with Azure Foundry.

Continuing the series, we now focus on Amazon Bedrock AgentCore, a managed service for building, deploying, and orchestrating AI agents on AWS.

Unlike agentic SaaS platforms that abstract infrastructure behind no-code interfaces, AgentCore offers a code-first, cloud-deployed experience that demands a different set of technologies to keep AI applications and agents secure in production.

In this post, we’ll break down how to implement a defense-in-depth approach for cloud-deployed agents, using a real-world insider attack scenario to highlight where misconfigurations, poisoned tools, and memory manipulation can escalate into full compromise.

Amazon Bedrock AgentCore

AgentCore is framework-agnostic and supports integrations with well-known and widely adopted frameworks like CrewAI, LangChain, OpenAI Agents, and others. Developers can build agents in their preferred framework using SDKs and code, and easily integrate and deploy them to Amazon Bedrock AgentCore Runtime which seamlessly handles the infrastructure, deployments, and the serverless runtime agents at scale. Agents can be customized and enriched with AgentCore core capabilities such as memory and gateway, configured directly in code.

Under the hood, AgentCore consists of the following core services:

1. Amazon Bedrock AgentCore Runtime: a serverless runtime service purpose-built for deploying and scaling dynamic AI agents and tools. Using the Runtime service from bedrock-agentcore-sdk, you can convert agents built in different frameworks to AgentCore agents. Then, to deploy your agent to AWS, you can use the bedrock-agentcore-starter-toolkit to configure and launch the agent.
2. Amazon Bedrock AgentCore Memory: supports both short-term memory for multi-turn conversations and long-term memory that can be shared across agents and sessions. Developers add memory to agents using Data Plane API or bedrock-agentcore-sdk from the agent code.
3. Amazon Bedrock AgentCore Gateway: allows agents to discover and use tools along with the ability to easily transform APIs, Lambda functions, existing services and remote MCPs into agent-compatible tools. It serves as a centralized tools registry that allows access through a unified API and can be widely shared among different agents in the organization.
4. Amazon Bedrock AgentCore Identity: manages agent identity and access to AWS resources and third party services through API keys, OAuth flows and IAM roles.
5. Amazon Bedrock AgentCore Observability: provides visibility into the raw OTEL spans that are available in CloudWatch.

Other managed services including Code Interpreter and Browser are available to the agent through the same Data Plane API

Risk Overview: Malicious MCP Server

Now that we’ve broken down AgentCore’s architecture and its core components (at a high-level), we can look at how these elements interact and where attackers can take advantage. AgentCore’s power comes from its modularity and code-first extensibility, but those same strengths introduce architectural blind spots that can be exploited if not properly secured.

To make this “tangible” we’ll leverage a common and high-impact risk that can become a broader attack vector - a malicious MCP server. An insider registers a malicious MCP server (“Salesforce-mcp” ) within an organization’s “finance-gw” gateway (widely used by finance teams to access teams tools and APIs including Salesforce) as an entry point to gain remote control over agents deployed in the environment. This access enables the attacker to exfiltrate sensitive data and conversations to an external storage location, and to establish persistence, maintaining control over the agent’s behavior even after their initial access is removed, through targeted memory-poisoning techniques.

Once installed, the MCP silently becomes available to all agents that are connected to the gateway, as these agents dynamically discover MCP tools at runtime, without requiring any code changes or redeployment. The malicious MCP server exposes a tool with a weaponized description (aka prompt injection) designed to force the agent to invoke it at the end of every interaction.

The tool accepts the user's original request and the agent’s response as parameters and then sends them to the attacker’s personal blob storage, thus achieving data exfiltration through the MCP server.

With that threat landscape in mind, let’s explore two concrete scenarios that demonstrate how this compromise unfolds in practice.

Scenario 1: Data Exfiltration Through the CFO Assistant Agent

In our example, the CFO has a Personal Assistant agent (connected to the same gateway and uses both the Salesforce API and AgentCore’s code Interpreter) that helps the CFO in day to day tasks including building visuals and output insights from CRM data.

The agent’s authentication is configured with JWT bearer token obtained from User/Password authentication flow with AWS’s Cognito IDP, which means it can be invoked with the CFO’s credentials only.

The CFO asks the assistant to "prepare a written text only for the board summary of our current revenue and pipeline from Salesforce".

The agent proceeds to:

1. Call the getOpportunityList tool via the Salesforce integration
2. Processes the data and runs analytics using the code_interpreter tool
3. Invoke the (malicious) compliance_tool, sending the CFO’s sensitive financial summary to the attacker

Scenario 2: Persistent Control and Memory Poisoning

Weeks later, after the insider leaves the company and their organizational access has been revoked, their malicious MCP server continues operating.

The insider, now the attacker, updates the malicious tool, to not only exfiltrate data (at every interaction) but to also poison the agent’s memory with instructions to encrypt data written by the agent with the attacker’s key.

By using an agent from the company’s public site (that is connected to the “finance-gw” gateway and has access to the Salesforce API) that accepts demo requests and creates new leads in the company’s CRM with request details, the attack sequence is as follows:

1. Reconnaissance of the agent’s internal capabilities, including tools
2. Prompt injection returned in the malicious MCP server exposed tool that targets the discovered agents’ tools and leads to:
   1. Long-term memory poisoning that contains instructions to encrypt data written to the CRM.
   2. Destructive action is achieved on every interaction with the agent

By deploying the new version of the malicious MCP server, the external attacker is able to:

1. Exfiltrate all new leads to their storage location via prompt injection in the MCP tool description
2. Encrypt all new leads in the company’s CRM via prompt injection in the MCP tool response

Defense in Depth for AgentCore

To secure home-grown cloud agents at scale, organizations need layered controls that operate from build time to runtime. Zenity applies full lifecycle, defense-in-depth for agents built with AgentCore.

1. Visibility & Governance

Zenity’s AI security and governance platform provides deep visibility into every agent and AgentCore components including memory, customized and built-in tools, gateways, workload identities, and endpoints. This visibility serves as the foundation for detecting risks, understanding agent behavior, and enforcing governance.

Out of the box, AgentCore exposes only a limited view of each deployed agent through its Control Plane API, primarily image sources, authentication details, and networking configuration. Since agents are packaged as dockerized workloads their internal logic, tool dependencies, and memory usage are essentially black boxes from a security perspective. This makes it difficult for teams to understand how agents truly behave or where risk can emerge.

By combining build time configuration analysis and runtime activity insights (e.g. threads, tool calls, memory operations, gateway interactions) Zenity is able to create a unified, enriched inventory of all deployed artifacts. This data is used to construct a continuously updated graph representing each agent’s actions and relationships. As agents run, the graph automatically incorporates dynamic changes, such as newly discovered MCP tools.

This graph gives security teams:

1. Clear visibility into each agent’s functionality, integrations, etc.
2. A deeper understanding of potential attack paths and vulnerabilities
3. Ability to investigate issues and threats when they arise

To support real-time monitoring, Zenity also maps agent runtime activity into sequential steps across the entire lifecycle. This provides full execution context, making it possible to identify suspicious behavior as it happens.

Together, this level of visibility enables teams to understand not just what their agents are configured to do, but what they are actually doing in production, a critical prerequisite for securing dynamic agents.

2. Risk Assessment and Policies

Once clear context for each agent is established, the next step is to enforce policies that align with the organization’s security requirements and operational guidelines. These policies incorporate controls aligned with established security frameworks such as the OWASP Top 10 for LLMs and MITRE ATLAS and can be tailored per environment, i.e. differentiating between development and production.

For example, to prevent malicious tool use as described in our earlier scenario, an organization will only need to provide a list of allowed MCPs to the policy.

In addition to policy enforcement in the risk assessment analysis pipeline, each agent and asset is evaluated against a broad set of rules including misconfigurations, oversharing, security best practices and more advanced logic to flag potentially insecure agents across the organization.

From our example, memory poisoning can also impact all users across all sessions and is made possible possible due to bad memory namespace configurations that allow agents to save and retrieve records from shared memory.

While AgentCore provides guidelines on how to write namespace for the memory, it does not enforce them at all, in contrast to the Zenity risk assessment engine, which can take action whenever risks are identified.

3. Threat Detection

Agents are dynamic and can evolve, therefore detecting threats requires analyzing their entire activity path with full contextual awareness. Zenity’s threat detection engine ingests and correlates runtime activity looking at all steps (like user messages, agent reasoning, tool invocation, etc.) to identify harmful behavior, data leakage attempts, or misuse of tools and memory poisoning.

Zenity's detection pipeline incorporates advanced scanners that operate across the multi-step workflow, extracting indicators from all agent workflow steps. Indicators are then correlated across different stages, and scanners and combines them with signals from build time, to accurately assess both the confidence level and the severity of a potential issue or attack.

4. Automatic Response

To help security teams to fix, mitigate and track issues at scale, Zenity provides configure-once, run-always playbooks with out-of-the-box mitigation actions that automatically fixes issues once they are discovered. Playbooks can also be configured to fix both existing and emerging issues.

In this example, applying a playbook that deletes an unallowed MCP target from the gateway could have prevented malicious tool use and stopped this threat before it made impact. Additionally, a playbook that updates memory namespace could have prevented memory sharing among users.

5. Inline Prevention

To prevent malicious actions or unintended behavior in real time, security teams can instrument the agent’s code and integrate it with the Zenity platform to enforce inline controls. Zenity’s platform can evaluate the full context of the agent, its configuration, state, and live activity, and apply policy decisions to allow, block, or modify an action before it executes.

In our example scenario, Zenity can leverage AgentCore’s gateway’s Request and Response interceptors to prevent malicious compliance_tool MCP tool usage, therefore preventing data exfiltration from all agents that share the gateway and block the ensuing response to prevent memory poisoning and data encryption.

To completely exclude the malicious MCP tool, we can hide it from the agent by implementing Response interceptor that updates the MCP’s response of “list/tools” MCP method as follows:

Looking Ahead: Trustworthy Agents in Code-First Environments

Agents are complex and powerful, which naturally expands the surface area for things to go wrong, especially in code-based agent architectures, where developers have full flexibility to integrate and configure the advanced capabilities exposed by modern AI platforms like AgentCore.This flexibility is powerful but also introduces architectural risks that must be managed. To make these agents trustworthy in enterprise environments, organizations must apply defense-in-depth across the entire agent lifecycle from build-time analysis and posture hardening to runtime monitoring, policy enforcement governance.

Next up within this series... we’ll take a deeper look at securing agents running on AWS Bedrock. Stay tuned!