Securing Amazon Bedrock AgentCore agents requires runtime governance

At a glance

What this is: This is an analysis of Amazon Bedrock AgentCore’s agent architecture and where insecure tool discovery, shared memory and gateway access can be abused.

Why it matters: It matters because IAM, PAM and NHI teams need to govern agent identity, tool access and memory persistence as production controls, not as development afterthoughts.

👉 Read Zenity's analysis of securing agents in Amazon Bedrock AgentCore

Context

Amazon Bedrock AgentCore is a code-first agent platform built for cloud deployment, which means the security model has to cover runtime identity, tool discovery and memory as part of production governance. In this architecture, an agent is not just a model prompt or a workflow. It is an identity-bearing execution path that can call tools, retain state and interact with other services.

The governance gap is that dynamic agents can discover tools at runtime and share gateways, while shared memory can let malicious instructions persist across sessions. For IAM and NHI programmes, that shifts the control question from "who can log in" to "what can this agent reach, what can it remember, and what can it do after first access is gone."

Key questions

Q: How should security teams govern AI agents that can discover tools at runtime?

A: They should treat runtime tool discovery as an authorisation boundary, not a convenience feature. Only approved tools should be visible to production agents, and every newly registered tool should pass provenance, scope and policy checks before any agent can call it. Without that control, a shared gateway becomes an unreviewed extension of the agent’s privilege set.

Q: Why do shared memories increase risk in agent platforms?

A: Shared memories increase risk because they can preserve attacker instructions long after the original session ends. If an agent can write to durable memory without strict namespace separation, poisoned content can influence later actions, cross-session behaviour and other agents that reuse the same state. That turns memory into a persistence mechanism rather than a simple context store.

Q: What breaks when agent identity can reach both cloud and third-party services?

A: Blast radius grows faster than most teams expect. A single compromised agent identity can move from internal data access to CRM, SaaS or external API abuse if its scopes are broad. The failure is not only credential theft. It is the lack of separate trust boundaries for each system the agent can reach.

Q: Who is accountable when a malicious MCP tool exfiltrates data through an agent?

A: Accountability sits with the team that allowed the agent to trust unreviewed tools and shared state in production. Security, platform and identity owners all need shared ownership, because the failure spans gateway governance, identity scoping, memory design and runtime monitoring. Frameworks such as OWASP Agentic AI Top 10 and NIST AI Risk Management Framework help structure that accountability.

Technical breakdown

Dynamic tool discovery turns gateways into an attack surface

AgentCore Gateway acts as a central registry that exposes APIs, Lambda functions, existing services and remote MCP servers as agent-compatible tools. That makes tool discovery runtime-driven rather than pre-baked into the application. If an attacker registers a malicious MCP server, every connected agent can discover and call it without code changes or redeployment. The risk is not just unwanted integration. It is unreviewed expansion of the action surface at the moment of execution, which is precisely where prompt injection can convert a tool description into a command path.

Practical implication: restrict which MCP sources and tools an agent is allowed to discover at runtime.

Shared memory can convert temporary access into persistent control

Agent memory in AgentCore supports short-term conversational state and long-term memory shared across agents and sessions. That improves continuity, but it also creates a persistence layer that attackers can poison. If a malicious tool response writes instructions into shared memory, those instructions can influence later sessions long after the original interaction ends. In practice, this means memory is not passive storage. It is an operational control plane for future behaviour, and shared namespaces can turn a single compromise into a broad, cross-session issue.

Practical implication: isolate memory namespaces and validate what agents are permitted to write back into shared state.

Agent identity must control both AWS resources and third-party access

AgentCore Identity manages access through API keys, OAuth flows and IAM roles. That means an agent can hold multiple credential types across cloud and external services, each with different blast-radius characteristics. If the agent’s identity is too broad, a poisoned tool or manipulated response can reach data stores, CRM systems or other third-party services with the agent’s own authority. Observability can show the activity, but visibility alone does not stop the abuse path. The core issue is that runtime identity for agents has to be treated like a privileged execution identity, not like a normal app integration.

Practical implication: scope agent credentials to the smallest possible tool and service set, then audit cross-service access continuously.

Threat narrative

Attacker objective: The attacker wants to hijack agent behaviour, exfiltrate sensitive data and maintain persistent control across sessions.

1. Entry occurs when an insider registers a malicious MCP server in a shared gateway, turning a trusted discovery path into an untrusted tool source.
2. Credentialed access is then abused when connected agents dynamically discover the malicious tool and execute it as part of normal runtime behaviour.
3. Impact follows when the tool exfiltrates conversations or writes poisoned instructions into memory, creating persistence and data leakage across later sessions.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime tool discovery is now an identity governance problem, not just an application design choice. AgentCore makes it easy for agents to discover tools at runtime, but that convenience collapses the old assumption that integrations are fixed at build time. Once an agent can dynamically select from shared MCP sources, the permission boundary moves from code review to runtime trust. The implication is that governance must account for tool provenance and discoverability as part of identity control, not as a separate DevOps concern.

Shared agent memory creates an identity persistence layer that traditional session controls do not cover. Memory in this architecture can outlive the interaction that created it and influence later behaviour in new sessions. That means a single poisoned write can act like a durable policy override inside the agent’s own execution context. The implication is that teams need to rethink what counts as persistent state when the actor is an AI agent with long-term memory.

Least privilege is no longer just about access at provisioning time. It was designed for actors whose intent and action path are relatively stable during execution. That assumption fails when an agent can choose tools, combine data sources and act inside a live session without human approval gates. The implication is that identity governance must move from static entitlement review toward runtime-scoped authorisation for agentic workloads.

Agent identity should be treated as a privileged operational boundary across cloud and third-party systems. AgentCore Identity allows the same agent to hold AWS access and external service credentials, which makes cross-service blast radius the real control issue. When one identity can reach CRM data, analytics tools and external endpoints, compromise does not stay inside one platform. Practitioners should evaluate each agent as a multi-system authority, not as a single application account.

Defence in depth is the only credible control model for code-first agents. Zenity’s scenario shows why visibility, policy enforcement, detection, automatic response and inline prevention all have separate jobs. No single control can prevent malicious tool registration, memory poisoning and exfiltration at once. The practitioner takeaway is to design layered controls around agent runtime behaviour, not around a one-time deployment checklist.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• To understand the control model behind that gap, see OWASP NHI Top 10 for agentic application risks and governance patterns.

What this signals

Tool provenance is becoming the new control point for agent governance. As organisations add more code-first agents, the question is no longer whether an agent can call a tool, but whether the organisation can prove that the tool should have been discoverable in the first place. The operational signal to watch is gateway sprawl, especially where shared registries and remote MCPs expand faster than approval workflows.

Agent memory needs lifecycle thinking, not just retention thinking. Long-term memory should be governed like persistent identity state, with namespace design, write permissions and offboarding rules that survive session boundaries. If the team cannot explain what happens to shared memory when an agent, user or tool is revoked, the programme is leaving a hidden persistence path in place.

Across the market, the practical direction is clear: runtime policy, inline blocking and continuous observation are becoming baseline requirements for AI agents. That aligns closely with NIST AI Risk Management Framework guidance on governance, mapping and measurement, and with OWASP Agentic AI Top 10 focus on tool misuse and agentic attack paths.

For practitioners

• Constrain runtime tool discovery Allow only pre-approved MCP sources and service integrations for production agents. Block unauthorised gateway registrations before agents can discover them at runtime, and review tool provenance as part of change control.
• Separate shared memory by trust boundary Use distinct memory namespaces for users, agents and environments, then validate every write path to long-term memory. Treat shared memory as durable state that can be poisoned and later reused across sessions.
• Scope agent identity by task and system Assign the smallest viable API keys, OAuth scopes and IAM roles to each agent. Reassess whether a single agent identity can reach multiple business systems without creating avoidable blast radius.
• Instrument runtime detection and blocking Correlate user input, agent reasoning, tool invocation and memory writes so suspicious sequences can be blocked before execution completes. Inline prevention should stop malicious tool calls even when the agent appears authenticated.

Key takeaways

• Code-first agent platforms expand the identity problem from login control to runtime governance of tools, memory and cross-service access.
• Zenity’s scenario shows that malicious tool registration and memory poisoning can create both exfiltration and persistence without changing agent code.
• Production control for agents now depends on tool allowlisting, memory isolation, scoped credentials and inline blocking, not on visibility alone.

Key terms

• Agent Gateway: A gateway is the control point that lets an AI agent discover and use tools, APIs and remote services. In code-first agent platforms, it becomes part of the identity boundary because tool exposure can change at runtime, which means governance must cover registration, approval and revocation.
• Memory Poisoning: Memory poisoning is the act of inserting malicious instructions or corrupted state into an agent’s short-term or long-term memory. The danger is persistence, because later sessions can inherit the poisoned content and execute it as if it were trusted context.
• Agent Identity: Agent identity is the credentialed authority an AI agent uses to access cloud resources and third-party services. Unlike a human identity, it can be used by software at machine speed, so scope, lifecycle and cross-system reach need tighter governance than ordinary application accounts.
• Runtime Tool Discovery: Runtime tool discovery is the process by which an agent finds and selects tools while it is executing, rather than from a fixed build-time list. This creates a live trust decision that can expand the agent’s action surface if the gateway or registry is not tightly controlled.

Deepen your knowledge

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

This post draws on content published by Zenity: Inside the Agent Stack: Securing Agents in Amazon Bedrock AgentCore. Read the original.