Canary Bulletin · AI Agent Security

Fake AWS keys we planted were used 284 times in one week

Published · Sunglasses team · Canary bulletin

We left decoy AWS keys in two places a scanner would look on our own site. They open nothing. From September 19 to September 25 2026 they were used 284 times from 91 IP addresses in 21 countries. Nobody got anything because there was nothing to get. What they tried is the useful part.

Quick answer
sunglasses://reports/decoy aws keys bulletin 2026 09 25#quick-answer
What happened

Each alert from the canary service is one use of a key and it carries the source address and the AWS call. 100 of the 284 calls only asked AWS whose key it was. 57 went looking for AI models to run on someone else's bill. 77 percent came from rented servers rather than home connections.

What to do

Treat a key that ever sat in a public file as used. Rotate it the same day and read its CloudTrail.

one week of decoy key use · Sep 19 to Sep 25 2026 UTC
# 284 uses of keys that open nothing call .. checked the key is alive ×100 from 30 addresses call .. mapped servers storage and secrets ×84 from 14 addresses call .. looked for AI models to run on our bill ×57 from 39 addresses call .. looked for email and SMS sending ×40 from 25 addresses call .. tried to stay in ×3 from 3 addresses [net] 77 percent from rented servers · 55 of 91 addresses [gain] real access · 0 A key that sat in a public file is a used key.
FIG.01 · What they tried

What they tried

IntentCallsAddresses
checked the key is alive10030
mapped servers storage and secrets8414
looked for AI models to run on our bill5739
looked for email and SMS sending4025
tried to stay in33

39 addresses went for AI models. 2 of them checked the key was alive from the same address before the first model call.

FIG.02 · Which tools they used

Which tools they used

Tool from the user agentCalls
Python urllib75
Python boto361
AWS SDK for .NET34
Python httpx28
AWS CLI20
AWS SDK for Go20
TruffleHog14
Go11

Tool names come from the user agent and a caller can fake it.

FIG.03 · Where they came from

Where they came from

Hosting networkCalls
netcup100
Google Cloud30
Datacamp14
Techoff SRV14
M2478
Cloudflare7
WS Telecom7
31173 Services5

55 of the 91 addresses belong to hosting companies and we name those networks. One address on netcup alone made 100 of the 284 calls. The rest are consumer or carrier connections. We do not name those providers and we show only the first three parts of the address because a home line may be someone's infected machine.

FIG.04 · Addresses that came back

Addresses that came back

22 addresses used a key three times or more. One row per address. We do not group addresses into actors because the evidence does not support it.

AddressNetworkCountryUsesWhat it did
152.53.236.20netcupDE100checked the key is alive / looked for email and SMS sending / mapped servers storage and secrets
71.83.210.0/24consumer or carrier networkUS14checked the key is alive
34.156.22.151Google CloudBE9looked for email and SMS sending / mapped servers storage and secrets / tried to stay in
138.199.15.176DatacampFR7checked the key is alive / looked for AI models to run on our bill
35.241.239.86Google CloudBE7looked for email and SMS sending / mapped servers storage and secrets
34.52.133.111Google CloudBE7looked for email and SMS sending / mapped servers storage and secrets
91.200.212.0/24consumer or carrier networkCA5looked for AI models to run on our bill
195.178.110.159Techoff SRVNL5looked for email and SMS sending
108.62.160.144LeasewebUS5checked the key is alive / looked for AI models to run on our bill / mapped servers storage and secrets
94.154.43.0/24consumer or carrier networkNL5looked for AI models to run on our bill
93.123.109.101Techoff SRVNL5checked the key is alive / looked for AI models to run on our bill / looked for email and SMS sending
13.250.110.222Amazon AWSSG4checked the key is alive / tried to stay in
34.140.132.132Google CloudBE4looked for email and SMS sending / mapped servers storage and secrets
84.233.212.9DatacampUS4mapped servers storage and secrets
45.138.12.23TC DatacenterNL4looked for email and SMS sending / mapped servers storage and secrets
193.32.126.14131173 ServicesFR4checked the key is alive / mapped servers storage and secrets
91.90.123.9M247BE3checked the key is alive / looked for email and SMS sending
91.200.214.0/24consumer or carrier networkCA3looked for AI models to run on our bill
34.156.121.46Google CloudBE3mapped servers storage and secrets
88.187.63.0/24consumer or carrier networkFR3checked the key is alive / looked for email and SMS sending
144.172.118.88RouterHostingUS3checked the key is alive / looked for email and SMS sending
2.57.122.80Unmanaged LtdRO3looked for email and SMS sending
FIG.05 · Fetches versus uses

Fetches versus uses

sunglasses://reports/decoy aws keys bulletin 2026 09 25#fetches
Fetches

Our edge logs saw about 740 successful fetches of the decoy files in the same week. That count is sampled and a fetch is not a use. We cannot link a fetch to a later call so we do not claim a ratio.

FIG.06 · What to do this week

What to do this week

  1. Treat a key that ever sat in a public file as used. Rotate it the same day and read its CloudTrail.
  2. Turn on Bedrock model invocation logging and set a budget alarm even if you never use Bedrock.
  3. Deny Bedrock and SES in an SCP for any account that has no reason to call them.
  4. Scan repos and agent config folders for keys before they ship. Our scanner is free and runs locally.

Install it with pip install sunglasses and read the install guide.

FIG.07 · How we counted

How we counted

sunglasses://reports/decoy aws keys bulletin 2026 09 25#method
Source

The keys are canary credentials from a commercial canary service. They carry no permissions. Each use raises an alert with the AWS call name and the source address and we store those in a ledger. Counts here are exact alerts inside the window in UTC. Networks are named from the ASN record. Tool names come from the user agent which a caller can fake.

Why no full list

Consumer addresses are masked to the first three parts because a home line may be someone's infected machine. We name hosting networks only.

Frequently Asked Questions

sunglasses://reports/decoy aws keys bulletin 2026 09 25#faq
Q.01

What is a canary AWS key?

It is a real looking AWS access key that grants no permissions. Any use raises an alert with the AWS call name and the source address. It lets you watch what people do with a leaked key while nothing of yours is at risk.

Q.02

What do people do first with a leaked AWS key?

In our week the most common call only asked AWS whose key it was. 100 of the 284 uses were that identity check. It is the cheapest way to learn whether a key still works.

Q.03

Why would someone look for AI models with a stolen key?

A working key lets the holder run paid AI models and send the bill to the key owner. 57 of the 284 calls in our week went looking for AI models, from 39 different addresses. Our decoy keys grant no permissions.

Q.04

How do I protect my own AWS keys?

Treat a key that ever sat in a public file as used. Rotate it the same day and read its CloudTrail. Turn on Bedrock model invocation logging and set a budget alarm even if you never use Bedrock. Deny Bedrock and SES in an SCP for any account that has no reason to call them. Scan repos and agent config folders for keys before they ship. Our scanner is free and runs locally.

Related reading

Scan what the agent sees, before it acts

Sunglasses is an open source input filter for AI agent security. It blocks prompt injection before your agent reads it. pip install sunglasses