Skip to content
    AI Strategy

    Hackers Spent $5k on Their Claude Account in an Hour. Then the Ban Hit.

    JK
    8 min read

    TL;DR

    1

    An affiliated business shared one admin login link with a developer over chat. The developer's laptop was infected. Attackers intercepted the link, issued themselves licences, bought credits, and spent about $5k in under an hour.

    2

    The worse part came next. The attackers used the account against Claude's terms, so Anthropic's automated compliance systems banned the whole team. The business got charged AND locked out for actions it did not take.

    3

    Stolen credentials are now the single biggest entry point into business systems. The Verizon 2025 report puts them in 22% of breaches. Infostealer malware lifted 1.8 billion credentials in 2025 alone.

    4

    The fix is two layers: tighten account security (no shared admin links, individual seats, hardware keys, endpoint checks) and own your method and data outside the account, so a ban cannot wipe out your business.

    A business we work closely with lost five grand in under an hour.

    Not to a failed campaign. Not to a bad hire. To one shared login link and a laptop nobody checked.

    This is not a hit piece on Anthropic. The team behind this business loves Claude, and so do I. The return on investment has been huge. But what happened to them is the clearest AI account security warning I have seen this year, and almost every business using a team AI account has the same hole.

    Here is exactly what went down, and the two-layer fix.

    What actually happened

    One of the founders was in a meeting. A developer needed access to the master team account urgently, the account that issues licences and holds the billing. Instead of setting up proper access, the founder did the fast thing. He sent the developer the login link and said sort it out.

    That single shortcut was the whole breach.

    The developer's computer had a trojan on it. Some kind of infostealer that was sitting quietly, watching. The moment that login link landed, it was intercepted. Within minutes, an attacker was inside the master account.

    What they did next was textbook. They issued a set of licences to themselves. They added a pile of extra credits. Then they burned through about $5,000 of usage in under an hour. The only reason it stopped there is that one of the founders was up late working, saw the activity, and killed it.

    Most businesses would not have someone awake to catch it.

    One shared link was all it took

    People assume a hack means sophisticated code breaking through a firewall. It almost never does. It means someone got a password or a link they should not have.

    The numbers back this up hard. The Verizon 2025 Data Breach Investigations Report found stolen credentials were the initial way in for 22% of all breaches, and showed up in 88% of attacks on web applications. Credentials are the front door, and most businesses leave it wide open.

    Where do the credentials come from? Increasingly, malware on a normal-looking laptop.

    Infostealer malware stole roughly 1.8 billion credentials in 2025, an 800% jump in a single year, with each infected device giving up around 87 saved logins on average. A shared admin login sitting in a chat thread is exactly what these tools are built to grab.

    That figure comes from Infosecurity Magazine's reporting on the 2025 infostealer surge. Worse, Recorded Future found that hundreds of millions of those stolen credentials came bundled with active session cookies, which let attackers walk straight past multi-factor authentication. The infected device does not need to break your security. It just copies the keys.

    So the developer's laptop was never really the developer's problem alone. The second that link touched an infected machine, it became the whole team's problem.

    The part nobody prepares for: the ban

    Here is where it stops being a normal security story.

    While the attackers had control, they did not just spend money. They used the account in ways that broke Anthropic's terms. And Claude, like every major AI provider, runs automated compliance systems that watch for exactly that kind of misuse.

    Those systems did their job. They saw activity that violated the terms, and they banned the entire team.

    So sit with the order of events. The business got charged an extra $5k by the attackers. Then it lost all access because of what those same attackers did. Two punishments, both landing on the victim.

    The team spent the next few days trying to explain. The automated support process could not see the nuance. It saw the black and white: actions happened under this account that broke the rules, so the account is suspended. Reaching a human who could understand "we were hacked" was slow and frustrating. The systems were not built to hear that.

    They did eventually get the team account back. But for a stretch, a business that runs on AI had no AI, through no fault of its own.

    This is a dependency problem, not just a security one

    We talk a lot about AI dependency in terms of a model getting switched off. The Fable ban proved that risk is real. A government can take a model offline in days.

    This story shows a second face of the same problem. Your own account can be switched off by the provider's automated systems, and you do not control that switch either.

    It does not matter whether the trigger is a government directive or a compliance bot. If your delivery sits entirely inside one provider's account, anything that suspends that account stops your business. That is the same single point of failure we keep warning consultants and coaches about in the wider frontier AI risk picture.

    The lesson is not "stop using Claude". It is "stop being one bad event away from zero".

    Layer one: tighten your AI account security

    Most of this breach was preventable with basic hygiene. None of it is hard.

    • Never share a single admin login. Give every person their own seat with role-based permissions. Shared logins remove all accountability and multiply the blast radius.
    • Ring-fence the master account. The account that holds billing and issues licences is the crown jewels. One or two named people only. Never send its login over chat or email.
    • Turn on multi-factor authentication, ideally a hardware key. Session-cookie theft can beat app-based codes. A physical key is far harder to bypass.
    • Check the devices that touch your accounts. A teammate's infected laptop is your breach. Basic endpoint protection and not saving admin links in browsers would have stopped this one.
    • Set spend and usage alerts. The only thing that saved this business was a human happening to be awake. Automated alerts on unusual spend do that job at 3am.

    If you run a team account today and any one of these is missing, fix it before you read the next section.

    Layer two: own what the ban cannot touch

    Security hygiene lowers the odds. It does not make them zero. So the second layer is about surviving the hit when it lands.

    The reason this business recovered is the same reason we build the way we do. Your method and your data should live outside the provider's account.

    • Your prompts, SOPs, brand voice, and decision rules belong in files you own, not locked inside one tool's interface.
    • Your customer context and history belong in your own storage or CRM.
    • Your automations should be backed up where you can rebuild them on another platform.

    When those things sit on your side, a suspended account is an inconvenience, not an extinction event. You point your work at a different provider and keep moving. This is the whole principle behind owning your method instead of renting your stack, and it is exactly what we set up in the first phase of the program. If you would rather have a resilient, model-agnostic setup built for you, DevWiz builds exactly that.

    A business that keeps everything inside one account is trusting that account to never go down. This story is what that trust costs when it breaks.

    FAQ

    Can an AI provider ban your account for something hackers did? Yes. Automated compliance acts on what happens under the account, not on intent. If an attacker breaks the terms using your account, the systems can suspend every user, and the suspension stays live while you wait for a human.

    How do hackers take over an AI account? Usually with stolen credentials, not clever code. Infostealer malware on one device harvests saved logins, session cookies, and links. A shared admin login sent over chat is a prime target.

    What is the safest way to share team AI access? Individual seats with role-based permissions, single sign-on, and multi-factor authentication with a hardware key. Keep the master billing account to one or two people and never share its login link.

    How do you protect against a suspension? Keep your method and data outside the provider. Prompts, SOPs, context, and automation backups in files you own mean a ban cannot erase your business.

    The takeaway

    Five grand and a full lockout, all from one login link sent to save five minutes.

    The attackers were the obvious villain. The real exposure was the setup: shared access, an unchecked device, and a business that lived entirely inside one account.

    Lock the account down. Then own the method and data the account holds. Do both, and the next bad event is a story you tell, not a business you lose.

    Want to know where your own exposure sits? Take the AI readiness assessment and we will map the gaps in your stack before someone else finds them.

    Frequently Asked Questions

    JK

    James Killick

    Founder

    The AI Orchestrator. 10+ years building digital products and 200+ apps shipped, now helping $1M+ educators and consultants turn their IP into AI-powered delivery systems.

    James Killick founded and runs The AI Orchestrators.

    Ready to find out where your biggest AI opportunity is?

    Take the assessment. It takes about 5 minutes. You'll get a clear picture of how ready your business is.