Securing Amazon Bedrock AgentCore agents requires runtime governance

At a glance

What this is: Zenity's analysis of Amazon Bedrock AgentCore shows how a code-first agent platform can be turned into a compromise path when runtime tool discovery, shared memory and gateway controls are not tightly governed.

Why it matters: IAM, PAM and NHI teams need to treat agent runtime as an identity boundary, because access decisions made at build time do not hold once tools, memory and delegated credentials are resolved dynamically.

Context

Amazon Bedrock AgentCore is a managed runtime for building and orchestrating AI agents on AWS, with identity, memory and gateway services that agents can use at execution time. The security question is not whether the platform supports agents, but whether those agents remain governable once they begin discovering tools, reusing memory and calling external services dynamically.

The article's core gap is runtime governance. In a code-first agent stack, security teams need to understand what the agent can do in production, not only what was approved in design. That shifts the identity problem from static authorisation to live control over tool registration, memory scope and delegated access.

Key questions

Q: What breaks when a shared agent gateway allows unvetted MCP servers?

A: A shared gateway turns one poisoned integration into a broad trust problem. When agents can discover new tools at runtime, a single malicious MCP server can influence many agents without redeployment. The control that fails is tool reachability governance, because registration becomes equivalent to production access unless it is explicitly allowed and monitored.

Q: Why do shared agent memory stores increase persistence risk?

A: Shared memory gives attacker instructions a durable place to survive after the original session ends. If one agent can write into memory that later sessions read, the compromise is no longer tied to a single interaction. That creates persistence through state, which means namespace separation and write restrictions become security controls, not implementation details.

Q: How should teams govern agent memory, tools, and identity together?

A: Treat them as one operating surface. Tool permissions determine what the agent can do, memory determines what it continues to believe, and identity determines what it can reach. If any one of those is weakly governed, the others inherit the risk and the agent can move from local misuse to enterprise-wide impact.

Q: What should security teams do after a malicious agent tool or memory entry is discovered?

A: They should contain the shared gateway path first, then remove unapproved tools and invalidate any memory entries that can re-seed malicious behaviour. The key is to break both the exfiltration path and the persistence layer before another session can reuse them. Response has to address both access and state.

Technical breakdown

How malicious MCP registration changes the agent trust boundary

AgentCore Gateway turns APIs, Lambda functions, services and remote MCP servers into agent-compatible tools. That flexibility creates a trust boundary problem: when a new MCP server is registered, every connected agent can discover it at runtime without code changes or redeployment. If the tool description is weaponised with prompt injection, the agent may invoke it as part of normal task execution. The danger is not simply a bad tool but a shared discovery plane that turns one poisoned integration into a fleet-wide access path.

Practical implication: security teams need explicit allowlisting and review of tool registrations before they become reachable by production agents.

Why shared memory becomes a persistence layer

AgentCore Memory supports short-term and long-term memory that can be shared across agents and sessions. That design makes memory more than conversation state. If namespace boundaries are weak, an attacker who can write to memory can leave instructions that survive the original session and influence later agent behaviour. In the article's scenario, memory poisoning is what turns a one-time compromise into ongoing control, because the malicious instruction is not in the tool alone. It is now embedded in the agent's operating context.

Practical implication: treat memory namespace design and write permissions as security controls, not application convenience features.

Why runtime identity must be evaluated together with tool and memory controls

AgentCore Identity manages access to AWS resources and third-party services through API keys, OAuth flows and IAM roles. On its own, that sounds familiar to IAM practitioners, but agentic runtime changes the assumption set. The same identity may be used to call approved tools, access CRM data and trigger external actions inside a single task flow. Once tool discovery and memory influence are added, the effective trust boundary is no longer the credential alone. It is the combination of identity, tools and state at execution time.

Threat narrative

Attacker objective: The attacker wants persistent control over agent behaviour so they can exfiltrate sensitive data and manipulate downstream business actions.

1. An insider registers a malicious MCP server inside a shared gateway, creating an initial foothold that is reachable by all connected agents.
2. The malicious tool uses prompt injection and poisoned descriptions to induce agents to call attacker-controlled functions and send data outward.
3. The attacker then poisons shared memory so the malicious instructions persist after the original access is revoked, creating recurring execution paths.
4. The result is ongoing data exfiltration and destructive behaviour across later agent sessions without a new code deployment.

Breaches seen in the wild

• SalesBleed Salesforce Agentforce 2026: Three fixed Agentforce flaws let poisoned web leads make AI agents leak CRM data with zero clicks and send phishing under the agent's identity.
• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime governance is the real control plane for code-first agents. Amazon Bedrock AgentCore centralises runtime, memory, gateway and identity functions, but that centralisation only helps if each layer is governed as a live security boundary. When agents can discover tools at runtime and reuse memory across sessions, the security problem moves from approval-time configuration to execution-time control. Practitioners should stop treating agent runtime as an implementation detail.

Shared tool registries create identity blast radius. A gateway that exposes one MCP server to many agents turns a single compromised integration into a fleet-wide trust problem. The issue is not just malicious code or a bad endpoint; it is the concentration of access in a discovery layer that many agents can reach without redeployment. That pattern demands governance over registration, scope and revocation, not just agent code review.

Memory poisoning is a persistence mechanism, not a side effect. Long-term memory that survives sessions can become an attacker-controlled instruction store when namespace boundaries are weak. This is especially important for AI agent governance because a revoked human or insider account may still leave durable agent state behind. The practitioner conclusion is straightforward: persistence can live in state as much as in credentials.

Agent identity and delegated access must be assessed as one runtime system. API keys, OAuth flows and IAM roles are necessary but not sufficient when the agent can chain tools, memory and third-party access during a single task. The governance assumption that a credential maps cleanly to a fixed use case breaks once the agent dynamically chooses tools and execution paths. Teams need to reason about runtime privilege composition, not isolated authentication events.

AgentCore exposes a runtime governance gap that OWASP-NHI and OWASP-AGENTIC both help describe. The same article shows overreach through over-shared access, secret-bearing integrations and tool misuse, but the deeper problem is that agent behaviour is shaped after initial authorisation. That is where classical IAM boundaries fail and where agent security has to move from static entitlement to continuous runtime control.

From our research library:

• 1 in 3 organisations encountered suspicious AI agent activity in 2025, and 99.4% experienced a SaaS or AI ecosystem incident.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Runtime governance gap: Code-first agents do not fail only when their model is unsafe, they fail when discovery, memory and delegated access are governed separately. That split leaves teams blind to how one malicious tool or one poisoned memory entry can alter later sessions, so runtime control has to sit above the individual component level.

The clearest programme signal is that access review logic built for static accounts does not fully describe agent behaviour. The more agents share gateways, memory and third-party access, the more important it becomes to track what the agent actually executed, not just what it was provisioned to do.

For practitioners

• Constrain gateway registration to approved tools only Require explicit approval before any MCP server, API or external function is added to a shared gateway, and revoke unapproved registrations as soon as they are detected.
• Separate memory namespaces by agent and use case Prevent long-term memory from being shared across unrelated agents or sessions, and restrict write access so one compromised interaction cannot seed later behaviour.
• Map runtime identity to reachable tools and data paths Inventory which API keys, OAuth flows and IAM roles each agent can actually use at execution time, then align those paths to the business task the agent is allowed to perform.
• Inspect tool descriptions for prompt-injection risk Treat tool metadata as an attack surface and review descriptions, parameters and response handling for text that could coerce the agent into unwanted tool invocation.
• Correlate runtime events across tools, memory and identity Monitor agent activity as a chain of actions, not isolated API calls, so exfiltration attempts, memory writes and unusual tool discovery can be linked in one investigation.

Key takeaways

• The article shows that the main risk in AgentCore is not agent capability alone, but the way shared runtime services can turn one compromised integration into a fleet-wide control path.
• The attack scenarios demonstrate both immediate exfiltration and durable persistence through memory poisoning, which makes the exposure operational rather than theoretical.
• Governance has to move from static approval to runtime containment, with tool registration, memory scope and delegated access treated as live security boundaries.

Key terms

• Runtime Governance: Runtime governance is the set of controls that verify what a system or agent is actually doing after deployment. It combines monitoring, authorization checks, and access validation so teams can detect drift, misuse, or excessive privilege in motion rather than assuming build-time policy still holds.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Memory Poisoning (ASI06): An attack where malicious content is injected into an AI agent's memory or context, causing it to alter its behaviour in subsequent tasks, potentially exfiltrating secrets, escalating privileges, or acting against its intended purpose.
• Shared Tool Registry: A shared tool registry is a central place where multiple agents discover APIs, services or MCP servers at runtime. It improves reuse, but it also expands blast radius because one bad registration can become reachable by every connected agent unless tightly governed.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.