Protected vs Vulnerable — what actually changes

In the code — demos/capstone/agent/agent.py

One file, deployed twice. AGENT_MODE, SCOPED_ROLE_ARN and GATEWAY_URL come from the runtime's environment variables, so the behaviour is chosen at deploy time, not by anything the user can influence.

1 · The trusted identity comes from the token, never from the prompt

2 · The one branch that separates the two modes

3 · How the identity is attached to the credentials — sts:AssumeRole with a session tag

That session tag becomes aws:PrincipalTag/actorId in the request context, which is exactly what the ABAC role's condition compares against. Session tags require sts:TagSession in the target role's trust policy — without it the AssumeRole call itself fails.

4 · The verdict the UI shows is the real exception, caught and reported

In the console — what to open, in order

Five screens, roughly four minutes. Each step has a CLI equivalent; on camera the CLI is usually faster and it does not break when console layouts change. Set the account once:

Run sheet — the on-camera sequence

Start the local server, open the Lab, and sign in as bob before recording. Total run time about seven minutes: three beats on the memory surface (M5), then four on the tool surface (M4) — one that succeeds, one refused on its argument, one refused outright, then the vulnerable comparison.

Talk track — "shouldn't each customer have their own memory?"

This is the most common question the Lab provokes, because it deliberately runs a single shared memory store. The full treatment now lives in the course itself — M5 · Memory Security → Store Topology — with the quotas, the pricing reality and the when-to-split table. What's below is only what to say, and when.

During M5 · Store Topology (~2 min)

Use this right after you've explained actorId and namespaces, while the idea of partitioning is fresh.

During the lab demo (~40 s)

Say this as you show the Security Trace, ideally before anyone asks — it pre-empts the objection and makes the demo's design look deliberate rather than lazy.

Fast answers to the three follow-ups

During the tool-authorization beat (~45 s)

Use this when you flip from the memory attack to the trade attack. The transition is the teaching moment — the audience has just learned that IAM stopped a read, and now a completely different mechanism stops an action.

Two things not to say

Why it denies, and the questions you'll get

"Why does the error say no identity-based policy allows instead of explicitly denied?"

Because there is no Deny statement anywhere in this demo. The ABAC role has exactly one Allow for ListEvents, and it is guarded by a condition. When Bob's session asks for Alice, the condition evaluates false, so that statement simply doesn't apply — and nothing else grants the action. The request falls through to the default: deny.

"Why does the Cedar denial name a policy, but the IAM denial names none?"

Because they are answering different questions. The IAM denial is a default deny — no statement matched, so there is nothing to name. The Cedar denial is an explicit forbid that matched, so the engine can tell you which policy decided and the Gateway returns it in the error: Policy evaluation denied due to ForbidTradeExec-…. Both are deterministic; only one has an author to point at.

"Why did the oversized deposit deny name no policy, when the transfer named one?"

Because they are different Cedar outcomes. The transfer hit an explicit forbid, so there is a deciding policy and the Gateway names it. The 500,000 deposit matched no permit at all — the only permit for that tool carries when { context.input.amount <= 50000 }, and that clause evaluated false — so Cedar fell through to its default: deny. Nothing decided it, so there is nothing to name.

"Can Cedar really see the tool's arguments?"

Yes — the Gateway exposes them as context.input.<param>, typed from the tool schema it generated the Cedar schema from. That is what makes per-call authorization possible rather than only per-capability: the agent proposes the amount, and a policy outside the agent ratifies it. It is also why the parameter is declared integer — a JSON number arrives as a Cedar decimal and would force lessThanOrEqual(decimal("50000.0")) instead of plain <= 50000.

"Isn't this just blocking writes?"

No, and the demo is built to disprove it. open_fixed_deposit is a write, it changes state, it moves real money — and it is permitted, because the customer's own funds stay inside the bank. transfer_funds is forbidden because the money leaves to a third party. The boundary is the risk of the specific capability and the size of the specific call, not the read/write distinction. If your policy set only ever says "reads yes, writes no", you have built a feature flag, not an authorization model.

"There's a permit for transfer_funds too — why doesn't it win?"

Cedar is deny-overrides by design: a request is allowed only if some permit matches and no forbid matches. The demo leaves PermitTransferFunds and PermitTradeExec in place deliberately so you can show this rather than assert it. It also makes forbid a usable kill switch — you can revoke one capability without auditing every permit that might have granted it.

"Why a second gateway instead of flipping the engine to LOG_ONLY?"

LOG_ONLY is the right answer in a real rollout — you observe what a policy would block before you enforce it. It's the wrong answer for a live demo: switching the mode is a control-plane change with propagation delay, and it would change both sides of the toggle at once. Two pre-built gateways make the comparison instant and deterministic on camera. Worth saying out loud, because LOG_ONLY → ENFORCE is the graduated-trust story from M4.

"Could the agent just call the other gateway?"

No. Each execution role's bedrock-agentcore:InvokeGateway grant is scoped to that mode's gateway ARN, so the protected agent cannot reach the ungoverned one even if its prompt talks it into trying. Worth mentioning because it pre-empts the obvious "just point somewhere else" objection — and because in production the equivalent risk is real: a Gateway's controls only apply to traffic that actually goes through it.

"Isn't the KMS key the thing protecting the data?"

No — and the demo proves it, because both runtimes use the same key. The CMK is an encryption-at-rest property that Security Hub BedrockAgentCore.3 checks; it protects the stored bytes and gives you key lifecycle control. It has nothing to say about which caller may read which actor's events. Conflating the two is the most common misread of this demo, which is why it's worth pre-empting.

"Why two runtimes instead of one with a flag?"

Because a flag inside the application would mean the application is the control, and the whole point is that it isn't. Two runtimes with two execution roles means the difference lives entirely in AWS configuration. It also mirrors reality: you don't toggle least privilege at runtime, you deploy with it or you don't.

"Could the agent just lie and claim it was Bob?"

The actorId used for the session tag is read from the validated Cognito JWT that the Runtime's authorizer already checked, and only the Authorization header is on the forwarding allowlist. The agent can request any actorId it likes in the API call — that's exactly what the attack does — but it cannot change the tag on its own credentials, and the condition compares the two.

"Why can't you show session tags in the console?"

AWS documents that session tags cannot be passed using the Management Console — they're an API-level construct. That's precisely why the assume-role happens in the agent code, and why the policy simulator (where you can supply the context key by hand) is the console-friendly way to demonstrate the evaluation.

Mapping back to the modules