Decide who can message your customers before someone else does

Your store can be fine while the tools that talk to your customers are not.

On the morning of Oct 6, ASOS customers got a notification ASOS didn't write. By the afternoon the company had filed a statement with the London Stock Exchange: ASOS confirmed that "at around 10am today, an unauthorised customer notification was sent to ASOS customers."

The next line is the one every ecom team should read twice: "We are investigating unauthorised activity involving third-party platforms that we use to communicate with customers. We took immediate action to restrict access to the notification platforms."

ASOS says basic personal information, including names and contact details, may have been accessed. It does not believe payment-card information or account passwords were affected. It says its website and app kept running normally. Reuters reported the shares fell 10% on the day.

We don't know how the access happened. ASOS hasn't said, and the attackers' own claims aren't evidence. So this note won't guess. The part that's already clear is enough to act on: the message didn't come from the storefront. It came through the tools that send to customers.

Almost every online store runs those tools. Email, SMS, push, in-app messages. Most of them were set up by different people in different years, and most have more senders than anyone could name from memory.

Here are four moves to do this week.

1. List every tool that can message your customers and who can send from it.
2. Move senders to named seats with 2FA and scoped API keys.
3. Give agents draft rights only. A human presses send.
4. Write the first-hour plan before you need it.

List every tool that can send, and every sender

Open a sheet. One row per tool that can reach a customer: your email platform, your SMS tool, your push provider, in-app and on-site messaging, review requests, and anything else that sends in your brand's name. Add the systems that feed them customer lists, because whoever can change a list can change who gets the message.

Then, for each tool, list everyone and everything that can send. Be literal about it:

• Staff, including people who left this year.
• Agencies and freelancers, past and current.
• Installed apps and integrations.
• API keys, with who created them and what uses them.
• AI agents, and which account or key they act through.

The last two are where surprises live. A key made for a one-off campaign two years ago can still send today. An app installed for a test may still hold full send rights. Nobody logs in as these, so nobody notices them.

Anyone who doesn't need send rights this month loses them. You can grant them back in a minute. You can't take back a message once it's out.

Move to named seats, 2FA and scoped keys

Shared logins make the list above impossible to trust. If five people use one marketing login, you can't tell who sent what, and you can't remove one person without resetting it for everyone.

Give every person their own seat. Turn on two-step verification for every seat that can send, and for every admin. If an agency needs access, it gets seats in the names of the people doing the work, not one agency login.

For API keys, give each integration its own key with the smallest scope the tool allows. A key that only syncs contacts shouldn't be able to send a campaign. Delete keys nobody can explain, and rotate the rest on a schedule you'll actually keep. The exact settings differ by vendor, so check each tool's docs for what scopes it offers.

Give agents draft rights only

Agents add names to the send list fast. One that writes email copy, one that answers reviews, one that drafts SMS for a launch. Each needs some access to the tool. None needs the button that sends to your whole list.

The rule is simple. The agent can draft, segment and schedule a proposal. A named human reviews it and presses send. If the tool can't split draft from send, the agent doesn't get a login to that tool. It hands the draft to a person instead.

Give each agent its own scoped key too, so you can switch off one agent without touching the rest. We wrote up the wider policy, starting from no permissions and adding them one at a time, in Deny by default before you give the agent a browser. The same thinking applies to customer channels: the agent gets the smallest set of actions that does the job, and sending isn't in it.

Write the first-hour plan now

ASOS restricted access to its notification platforms quickly. That's the move you want ready, written down, with names on it. In the first hour of a bad send, nobody should be hunting for an admin password.

The plan fits on one page:

• Who can stop sends and revoke access in each tool, with a backup for each person.
• How to pause scheduled campaigns and automated flows, tool by tool.
• The customer notice, drafted now: what happened, what you'll never ask them to do, and where the real updates will live.
• Who talks to customers, who talks to regulators, and, if you have them, who talks to investors.
• Where you'll record what was sent, to whom and when.

The customer notice matters more than it looks. After a fake message goes out, the next risk is a second fake that looks like you. Telling customers plainly which links and requests they'll never get from you gives them something to check against.

Run it once as a drill. Pick a tool, pretend a message you didn't write just went out, and time how long it takes to stop sends and revoke the access. If the answer is "we'd have to ask the agency," that's your first fix.

This week

Build the sheet of tools and senders. Remove send rights nobody needs. Turn on 2FA everywhere a seat can send. Split shared logins into named seats. Scope or delete old keys. Move every agent to draft rights. Write the one-page first-hour plan and run the drill once.

If you're adding agents to your marketing stack and want them set up with draft rights and their own keys from day one, that's the work we do under AI Development. Start your build or write hello@mail.22atlas.com.

Linked sources

• ASOS plc RNS: Update regarding cyber incident (2026-10-06)
• Reuters via LSE.co.uk: ASOS shares slide after hackers target online retailer (2026-10-06)
• Related Field note: Deny by default before you give the agent a browser