> Amazon SES: what your AI agent should know — from The Handover, the-handover.org/services/amazon-ses
> © Captivated Ltd — free to use in your own work, not to redistribute as a collection. the-handover.org/licence

# Amazon SES

What we tell an AI agent working on a project that uses Amazon SES: 2 rules, 0 learned the hard way.

Build a full rootnote set for a Amazon SES project: https://the-handover.org/build?areas=working-agreement,email&email=ses

The vendor's own file for agents (what Amazon SES is, where its documentation lives): https://docs.aws.amazon.com/llms.txt. This page covers where it catches agents out.

### Amazon SES: a leaked sending key was used to leave the sandbox and run a phishing campaign

> Reported by Itay Harel and Hila Ramati, Wiz Research, "From Compromised Keys to Phishing Campaigns: Inside a Cloud Email Service Takeover" — www.wiz.io/blog/wiz-discovers-cloud-email-abuse-campaign · distilled by Leon Mallett (captivated.online) with Claude Code · reviewed 2026-10-25

Wiz Research described a campaign from May 2025. An attacker obtained an AWS
access key provisioned for SES; how it leaked is unknown. Within ten seconds they
had requested production access in every AWS region. AWS approved the request,
which was written in generic text and cited an unrelated construction company's
website. With production access, the attacker verified their own domains as
senders and ran a phishing campaign about tax forms. Two attempts to go further
failed because the key lacked the permissions: opening a support case to raise
the quota, and attaching a new IAM policy to itself. Wiz calls SES abuse a
primary way attackers make money from leaked AWS keys, because the mail goes out
from the victim's account and reputation.

- **The application's key gets only the permissions it needs to send.** It should
  not be able to request production access, verify new identities or change IAM;
  here those permissions were the whole attack. An agent writing the IAM policy
  will often reach for `ses:*`, which is our inference, not Wiz's finding.
- **Block SES entirely in AWS accounts that do not send email**, with a service
  control policy, as Wiz recommends.
- **Log and alert on SES configuration calls** — requests for production access,
  new sender identities — not only on sending volume.
- **Rotate keys, and treat a dormant key that suddenly becomes active as
  compromised.**

### Amazon SES: it starts in the sandbox, per region

> General guidance · Leon Mallett (captivated.online) with Claude Code · reviewed 2026-10-19

- **A new account starts in the sandbox, in each region.** Mail reaches only
  verified addresses until production access is granted, and the request is
  reviewed — plan for it before launch day.
- **Handle bounce and complaint notifications.** High rates can pause sending for
  the whole account.

Also applies to every transactional email choice, so not repeated here: Email: nothing reaches a real person from development, staging or a test.