Your AI agent's IAM execution role has `dynamodb:PutItem`. One crafted support email no credentials, no console access can use that role to poison your agent's memory store. Three days later, a compliance officer gets a fabricated report. A real $340,000 fraud alert is never surfaced.

This session shows exactly how it works and exactly how to stop it.

We walk through three implemented attack vectors against a production-realistic AWS agent stack: direct input injection through SES, kNN retrieval flooding via OpenSearch, and tool response injection through a compromised Lambda dependency. Every attack runs against real DynamoDB and OpenSearch, no simulations, no hand-waving.

Then we fix it. Five concrete changes: remove `PutItem` from the agent role, gate writes through a validator Lambda, tag every OpenSearch document with provenance metadata, enforce TTL as a security boundary, and add agent-layer CloudWatch instrumentation that surfaces what CloudTrail cannot.

Every defense ships as working Terraform and boto3. Attendees leave with a deployable lab repository and five IAM and code changes they can assign in a sprint.

The core question every team should be asking but isn't: does your agent's execution role have unconditional write access to its memory stores, and what is preventing an attacker from using it?

This talk answers that — with implementation demo.