← Course Home
Module 1

Threat Landscape & Shared Responsibility

A fast tour of the Amazon Bedrock AgentCore services and the surface each one hands you, why AI agents change the security picture, where AWS's responsibility ends and yours begins, and how the platform differs from AWS Continuum.

⏱ ~19 min · Amazon Bedrock AgentCore refresher + Threat model + Shared Responsibility

Amazon Bedrock AgentCore in Brief

A five-minute refresher before we look at what can go wrong. Amazon Bedrock AgentCore is an agentic platform of modular services you can use together or independently, with any framework and any foundation model. What matters for this course is not the feature list — it's that each service creates a security surface you now own. Select any service for what it does, the surface it owns, and the module that drills into it.

Amazon Bedrock AgentCore

Amazon Bedrock AgentCore

13 modular services · any framework · any model · no infrastructure to manage

owns a surface we cover named only
Your app Any model Any agent · A2A
Build & run
Act
Remember
Govern
Operate

Select a service for what it does, the security surface it hands you, and the AWS primitives that surface leans on.

Why 13 and not 8 If you've seen an Amazon Bedrock AgentCore architecture diagram before, it probably showed the original core services. The platform has grown: Harness, Payments, Optimization and Registry are recent additions. Four sit outside this course's scope, but two are worth a security thought even so — Payments introduces configurable spending limits as a control, and Registry is where governed tool discovery and an approval workflow live, which is supply-chain territory. Check the current service table in the docs rather than any diagram, including this one.

Every service hands you a surface

Collapse the service list into the seven surfaces this course is organised around. Each later module drills into one or two. This is the map to keep in your head for the rest of the course.

Identity

Who the agent is and on whose behalf it acts. M2

Memory

Encryption, isolation, poisoning defense. M5

Policy (Cedar)

Deterministic authorization decisions. M4

Runtime Isolation

MicroVM per session; plane separation. M3

Network (VPC/SCP)

Private connectivity, org guardrails. M3

Observability

Tracing, audit, compliance. M6

Gateway

The choke point for tool access. M4

The reassuring part: almost none of this is a new security model. Amazon Bedrock AgentCore surfaces land on primitives you already know — Cognito and IAM for identity, KMS for memory encryption, VPC for egress, CloudWatch and CloudTrail for audit, Organizations for SCP guardrails, Security Hub for posture. What's new is where you have to apply them, and that a non-deterministic actor now sits in the middle.

Architecture note Under the hood, Amazon Bedrock AgentCore separates a control plane (management APIs) from a data plane (agent execution), with TLS and SigV4 between them. This separation is what makes per-session MicroVM isolation and centralized policy enforcement possible — we build on it in M3 and M4.
What to carry into the next section Three services do most of the work in the threat model that follows. Gateway is the choke point every tool call should pass through, Policy is what makes an authorization decision deterministic instead of a suggestion, and Memory is the only component whose compromise outlives the session. Hold those three, and the attack chain on the next tab will read as a sequence of controls you already have names for.

Why AI Agents Are Different

Traditional applications are deterministic: given the same input, they do the same thing. Agentic applications are not. They reason, choose tools dynamically, and carry persistent memory — which is exactly what makes them useful, and exactly what expands the attack surface.

Non-deterministic execution

The agent decides its own next step at runtime. You cannot enumerate every path in advance, so controls must be enforced at the boundary, not assumed in the code.

Dynamic tool use

Agents call tools and other agents on the fly. Every tool is a new privilege boundary and a new place for misuse.

Persistent memory

What an agent remembers influences future behavior. Memory becomes a durable attack target, not just transient state.

The attack surface expands in a chain

No single one of these is the breach — the damage comes from the escalation. But note the arrows coming in from the top: an attacker does not have to start at stage 01. Stolen credentials, a confused-deputy call, or an over-permissioned role let them enter directly at any stage. That is precisely why one gate is not enough. Flip the switch, and select any stage for the control that holds that line.

Controls
Any entry point reaches the data

direct entry — starts here escalation — enabled by the stage before

user input · document · tool response
stolen token · confused deputy · rogue MCP server
over-broad memory write · cross-tenant namespace
over-permissioned execution role

Select a stage above to see how an attacker reaches it and which control holds that line.

Framing for the course Two things to take from this. First, you cannot rely on stopping stage 01 — injection can arrive indirectly through a document or a tool response, so the design assumption is that it succeeds and the model is treated as an untrusted actor. Second, every stage has its own front door, so every stage needs its own control; a single gate just moves the attacker's entry point. Note the gate on stage 01 is amber, not green: Guardrails reduce injection probabilistically, whereas Cedar, IAM and VPC controls enforce deterministically. That difference is why the later modules carry the weight — and it is what defense-in-depth by necessity actually means.
SHARED RESPONSIBILITY

The Amazon Bedrock AgentCore Shared Responsibility Matrix

As with every AWS service, security is shared. AWS secures the platform; you secure what you build on it. For agents, the dividing line has one subtlety that trips teams up.

AWS is responsible for

  • Infrastructure and physical security
  • MicroVM session isolation
  • TLS and SigV4 enforcement on the control plane
  • Control-plane hardening and patching

You are responsible for

  • Agent logic and prompt design
  • Tool authorization (which agent may call what)
  • Session-to-user binding
  • Data classification and memory hygiene

Critical insight: The Runtime does not validate user-to-session binding. Confirming that the human behind a session is who they claim to be is an application-layer responsibility. If your app doesn't bind the session to an authenticated user, Amazon Bedrock AgentCore won't do it for you.

What you have to build AWS documents this plainly: Amazon Bedrock AgentCore does not enforce session-to-user mappings. Your backend must (1) keep the relationship between users and their session IDs, (2) validate ownership on every invocation and reject mismatches, and (3) manage lifecycle — a cap on sessions per user, idle timeout, and cleanup on sign-out. It's a small amount of code, but nothing will remind you to write it.
Two more places the line sits where people don't expect Filesystem permissions aren't enforced inside a session — chmod and stat behave normally, but access checks always succeed, because the agent is the only user in the microVM. And any code in the microVM can read the execution role's credentials from the metadata service. Both push the same conclusion: the microVM is the boundary, so scope the execution role tightly (M3).
Why it matters This is the most common source of authorization gaps in agent deployments. We revisit it in M2 (identity) and M4 (policy), where the actorId and sessionId condition keys let you enforce the binding you're responsible for.

Amazon Bedrock AgentCore vs AWS Continuum

Two AWS offerings sit near "AI and security," and they are frequently confused. The distinction is simple once you name it.

Amazon Bedrock AgentCore

  • A platform to build and secure the agents you create
  • Identity, memory, policy, runtime, gateway, observability
  • The subject of this course

AWS Continuum

  • A family of frontier security agents that secure your applications for you
  • Pen testing, code scanning, threat modeling, code vulnerabilities
  • A separate track — not covered in depth here
Maturity note Continuum pen testing is generally available (it began life as AWS Security Agent on-demand penetration testing). Code scanning, threat modeling (STRIDE output), and Continuum for code vulnerabilities are in preview — the last one gated. Because most of the family is still preview, it isn't yet a standalone course.
"Trust is graduated" — a pattern worth borrowing Continuum starts in learn mode with a human in the loop, and every recommendation carries its reasoning. As confidence grows you graduate it to enforce mode, automating remediation by category and risk profile. Hold onto that shape: it's exactly how you should roll out your own agent's authorization in M4 — start in LOG_ONLY, watch the decisions, then switch to ENFORCE.

One-line memory hook: Amazon Bedrock AgentCore is how you secure the agents you build; Continuum is an agent that secures your apps.

Sources

Back toCourse Home Next moduleM2 · Identity & Access