Notifications
Clear all
Topic starter
24/06/2026 11:58 pm
TL;DR: Amazon Bedrock AgentCore centralises runtime, memory, gateway and identity services for cloud-deployed agents, but Zenity shows that malicious MCP registration, prompt injection and memory poisoning can turn shared tools into exfiltration and persistence paths. The control problem is not agent capability alone, but runtime governance across tools, memory and access boundaries.
NHIMG editorial — based on content published by Zenity: Inside the Agent Stack: Securing Agents in Amazon Bedrock AgentCore
Questions worth separating out
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.
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.
Q: What breaks when agent identity can reach both cloud and third-party services?
A: Blast radius grows faster than most teams expect.
Practitioner guidance
- Constrain runtime tool discovery Allow only pre-approved MCP sources and service integrations for production agents.
- Separate shared memory by trust boundary Use distinct memory namespaces for users, agents and environments, then validate every write path to long-term memory.
- Scope agent identity by task and system Assign the smallest viable API keys, OAuth scopes and IAM roles to each agent.
What's in the full article
Zenity's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of malicious MCP registration and how it becomes visible inside AgentCore gateways
- Scenario walkthroughs showing how a CFO assistant and a public demo agent can be abused differently
- Control examples for request and response interceptors that block malicious tool use before execution
- Implementation detail on how build-time analysis is combined with runtime telemetry to form an agent graph
👉 Read Zenity's analysis of securing agents in Amazon Bedrock AgentCore →
Amazon Bedrock AgentCore agents: what IAM teams miss at runtime?
Explore further
25/06/2026 8:47 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Securing Amazon Bedrock AgentCore agents requires runtime governance
