How the attack works
An AWS access key ID or a labeled secret access key value ends up in content the system processes, for example an agent's response, log, or generated file. The rule scans that content for known AWS key ID prefixes and for secret-key-shaped values that are explicitly labeled (e.g. next to "aws_secret_access_key"), so it doesn't falsely flag random 40-character strings. When a match is found, everything except the last four characters is redacted before the content is stored or displayed further.
Why it matters
If AWS credentials leak into logs, chat transcripts, or agent output and are not caught, anyone with access to that content could use the keys to access AWS resources. The rule addresses this exposure step, not what happens if a leaked key is later used.
What you can do
- Rotate any AWS key that shows up in logs, chat history, or agent output, even if it looks like a documentation example.
- Restrict IAM permissions on keys that agents or automation systems can reach, so a leaked key has limited blast radius.
- Review where agent inputs/outputs are stored and ensure secrets aren't retained in plaintext logs.
- Treat the well-known AWS example key (AKIAIOSFODNN7EXAMPLE) appearing in output as a sign the agent is echoing untrusted or copied content, not as a false alarm to ignore.
Known benign look-alikes
- The canonical AWS documentation example key (AKIAIOSFODNN7EXAMPLE) is redacted on purpose — it is indistinguishable from a live key and is exactly the value demonstrated leaking through an agent.
- A labeled 40-char value that is not a real secret (still redacted by design).