Architecture-specific review
AWS Bedrock AgentCore security review
AgentCore gives an agent strong isolation and identity primitives — Runtime microVMs, Identity, Memory and the Agent Registry. The security decision still depends on how your application uses them: what each agent's credential is scoped to, whether Memory is tenant-isolated, and whether Registry-listed resources were ever reviewed.
Start an AI security review →Review scope
What the reviewer needs to establish
Scope the deployed agent and its application services: the Runtime session model, the Identity grants issued to each agent, the Memory stores it reads and writes, any MCP servers or A2A agents pulled in through the Registry, and the downstream systems its tools can reach. AgentCore's microVM and identity primitives are strong building blocks; your application's authorization, tenant isolation and approval design still need evidence.
Runtime session isolation
Does per-session microVM isolation actually map to your tenant or user boundary, or could an application bug let two sessions from the same tenant share state that shouldn't cross?
Evidence to request: Session-to-tenant mapping, isolation configuration (sandbox vs VPC mode), cross-session state tests, and — if sandbox mode is relied on for network isolation — confirmation that outbound DNS is also blocked or monitored, since "no network access" does not cover DNS by default.
Identity credential scope
What is the actual scope of the credentials Identity issues to each agent — the narrow grant its tools require, or a broad service-level template copied across agents?
Evidence to request: Per-agent credential scopes, third-party connection grants (Slack, Zoom, etc.), least-privilege review notes, and the blast-radius analysis if any single integration credential is compromised.
Memory boundaries
Is short- and long-term Memory scoped per user or tenant, and can one session's stored memory poison or be read by another that shares a store?
Evidence to request: Memory store keying, tenant-scoping configuration, retention policy, and cross-tenant read and poisoning tests.
Registry-sourced dependencies
Are MCP servers and agents discovered through the Agent Registry treated as reviewed dependencies, or is registry presence being over-trusted as an implicit approval?
Evidence to request: A documented review gate for Registry-listed resources, the review record for each MCP server or agent built on, and the distinction — surfaced to whoever browses it — between "catalogued" and "vetted".
Approval, versions and decision
For tools flagged as requiring human confirmation, does the approval bind to the exact recorded call — and is the deployment past the fixes for the CoreBreak confirmation bypass and the CLI docstring-injection issue?
Evidence to request: Confirmation-path tests that a forged approval cannot run an unauthorized tool, the @aws/agentcore version (past 0.14.2 for CVE-2026-11393), open controls with owners, and the signed review decision.
Architecture example
Follow authority and data end to end
A model endpoint is one component. The security decision also depends on the identity that calls it, the data it receives, the actions it can trigger, and who accepts the remaining risk.
For a support agent on AgentCore: customer request → Identity-scoped tool call to a ticketing API → Memory recall of prior context → a refund tool flagged for human confirmation. Check that the tool credential is scoped to that one API, that Memory recall is keyed to the requesting customer, and that the confirmation binds to the exact refund call — not just any tool the session claims was approved.
From review to decision
Describe the system, confirm its architecture, examine threats and required controls, attach evidence, and record a human clearance decision. Unknown or missing evidence remains visible; it is not treated as a passed control.
Read the review methodology →