Hackers Are Using AI to Target Businesses. Five Steps That Will Keep Your Business Secure.

In August 2026, Security Affairs reported on an AI assistant that booked its user into a gym class by quietly removing someone else from the waitlist. Nobody asked it to do that. The user set a goal and the assistant found a route to it, on a system it had no business modifying. That is the mild version of what agents do when nobody has decided in advance what they are allowed to touch.

Go back to February 2024 and Microsoft and OpenAI published joint research confirming that state groups from Russia, North Korea, China, and Iran were already using LLMs to write attack scripts, research vulnerabilities, and produce convincing phishing in several languages at once.

Then in July 2026, Hugging Face was hit by what is now the first documented end-to-end AI-driven intrusion. Attackers ran an autonomous agent framework that spread thousands of individual actions across short-lived sandboxes, exploiting code-execution vulnerabilities in the dataset processing pipeline, escalating privileges, harvesting credentials, and moving laterally across internal clusters. Hugging Face published their own account of it. OpenAI, whose agent was involved in the incident, published a separate writeup.

AI has made attacks cheaper to run. The five controls below still stop most of them, and most cost nothing.

1. Know what you own

You cannot protect what you have forgotten you own. Most companies are running things nobody watches: an old project domain, or a service a contractor set up and left behind.

What counts as a digital asset:

• Registered domains and subdomains, including old ones from past projects
• Hosting providers and VPS instances
• Cloud storage buckets (S3, Azure Blob, Google Cloud Storage)
• Cloud accounts and their consoles (AWS, Azure, GCP)
• SaaS tools individual team members signed up for on their own
• API keys and the integrations they power between your services
• Social media accounts and the third-party apps connected to them
• GitHub and GitLab repositories, including archived and forked ones
• Email sending platforms (Mailchimp, SendGrid, Postmark)
• Analytics and third-party scripts running on your website
• Domain registrar and DNS provider accounts

Why this matters now:

Automated scanners sweep the whole internet continuously and surface exposed services within minutes of them appearing. An old subdomain pointing at a staging box you shut down last year. A storage bucket with public access still switched on. An admin panel sitting on default credentials. All of it gets found. You want to be the one who finds it.

What to actually do:

Start a spreadsheet. Work through every invoice and every service the company pays for, then do the parts that usually get put off:

• Run Shodan or Censys against your domains and IP ranges. Both have free tiers, and both show you what external scanners already see.
• Pull your full DNS records and read every CNAME and A record. Records still pointing at cloud services you stopped paying for are a well-known route to subdomain takeover.
• Open your cloud billing dashboard. Every active service shows up there. If something on the bill is unfamiliar, find out what it is before someone else does.
• Search company email for phrases like “you’ve been added as a collaborator”, “welcome to”, or “new account created”. That surfaces tools people signed up for and forgot about.
• Ask the team directly. Someone started a free trial six months ago and it is still running.
• Check Google Search Console for the pages and subdomains Google has indexed under your domain.

Keep it as a living list rather than a one-off audit. Add things when you adopt them, take them off when you stop using them.

2. Review who has access

Former staff, contractors, freelancers, agencies, the developer who built your first site three years ago. Do any of them still have a way in? In most companies the answer is yes, and nobody can say exactly how much.

People leave and their accounts stay live. It is one of the most common ways attackers get in. They find a dormant account, try a password from an old breach dump (cheap to buy, often free to search), and log in. The account has not been touched in a year, so nobody is watching it.

Where to check access:

• Google Workspace or Microsoft 365 admin panel: who has an active account, and what groups are they in?
• GitHub organisation member list and repository collaborators
• AWS IAM users, roles, and access keys, especially any with console access
• Azure Active Directory and resource group permissions
• Your cloud hosting control panel (Cloudflare, cPanel, Hetzner, DigitalOcean)
• Every SaaS tool your team uses: read the full user list, not just recent login activity
• SSH authorised keys on your servers (cat ~/.ssh/authorized_keys on each one)
• Database users and their host restrictions
• API keys issued by your services to third parties

Enable MFA, and use the right kind:

MFA is the cheapest win on this list. With it on, a stolen password is not enough to get in. Enforce it on:

• Email accounts, especially admin and finance
• Cloud provider consoles (AWS, Azure, GCP)
• GitHub, GitLab, Bitbucket
• Hosting and registrar control panels
• Any tool that holds customer data, payment information, or admin access

Use an authenticator app rather than SMS. SIM swapping is a routine attack now, and a text code goes to whoever controls the number. Authy, Google Authenticator, or any TOTP-compatible app will do. Hardware keys such as YubiKey are the strongest option and cost around £40.

What to do this week:

• Pull a full user list from every system your team uses.
• Remove or suspend access for anyone who left more than 30 days ago.
• Set a recurring calendar reminder to audit access quarterly.
• Require MFA for all admin and finance accounts immediately, then roll it out to everyone else within two weeks.
• Look for cloud IAM access keys that have not been used in 90 days and disable them.
• If anyone is still using passwords shared over Slack or email, move them into a team password manager (Bitwarden has a free team tier).

3. Limit what is reachable from the internet

Anything you put on the internet gets probed, constantly, by automated scanners. AI tooling has made that cheaper and faster for the people running them. The obvious answer is to put less on the internet.

Common things left exposed that should not be:

• WordPress /wp-admin open to all IP addresses with no rate limiting
• Staging and development environments running on public subdomains with weak or default credentials
• Admin portals for databases (phpMyAdmin, Adminer, pgAdmin)
• AWS, Azure, and GCP consoles with no IP-based restriction on login
• Internal monitoring tools on public VPS instances (Grafana, Kibana, Prometheus, Jupyter notebooks)
• Remote Desktop (RDP) and SSH listening on default ports (3389 and 22) with no IP restriction
• Development APIs and internal microservices accidentally exposed to the public internet
• S3 buckets or cloud storage with public access enabled and no authentication

What to do:

• Restrict admin panels and cloud consoles to specific IP addresses. Most firewalls, hosting control panels, and cloud providers give you this in a few clicks.
• Put anything sensitive behind Cloudflare Access or a similar zero-trust gateway. The free tier covers basic authentication and lets you drop a login screen in front of an internal tool without changing the application.
• Use a VPN or a WireGuard tunnel for internal tools that never needed to be public. WireGuard is free and quick to set up.
• Shut staging environments down when they are not in use. If the team keeps forgetting, script it and stop the server outside working hours.
• Move SSH off port 22. It will not stop anyone targeting you specifically, but it takes your server out of most of the bulk scanning noise.
• Audit your firewall rules and close every port nothing is using. Run nmap -sV your-public-ip against your own infrastructure and read what comes back.
• Turn off directory listing on web servers. A public file index is free reconnaissance for anyone who finds it.

For anything customer-facing, spend ten minutes doing what an attacker does first. Search site:yourdomain.com on Google, then site:yourdomain.com inurl:admin, then site:yourdomain.com inurl:login. Things turn up that you did not expect to be indexed.

4. Back up your data, and test that the backup works

Ransomware works because it takes your data and you have no other copy. With a working backup somewhere separate, it drops from a crisis to a bad week. The businesses that end up paying, or losing everything, are usually in one of three positions: no backup at all, a backup sitting on the same network that got encrypted along with production, or a backup that turned out to be empty when they went to restore it.

The 3-2-1 rule:

• 3 copies of your data
• 2 different storage media or locations
• 1 copy that is completely offline or stored in a separate cloud account the attacker could not reach even with your main credentials

Practical options for each tier:

• Cloud-to-cloud backup: If you run Google Workspace or Microsoft 365, tools like Spanning, Backupify, or Veeam keep independent copies in a different cloud. If Google has a problem, or someone deletes a shared drive, you still have the data. This is not the same thing as Google’s own redundancy.
• Immutable object storage: AWS S3 Object Lock, Azure Blob immutable storage, and Backblaze B2 all support object lock. A backup you cannot modify or delete cannot be encrypted by ransomware either. Turn versioning on at the same time so you can go back to a specific version of a file.
• Offline backups: For sensitive data or a small team, an encrypted external drive that only gets plugged in during backup runs, and lives somewhere else the rest of the time, covers the offline tier. VeraCrypt is free and runs on any platform.
• Database snapshots: On a managed database (RDS, Cloud SQL, PlanetScale), turn on automated snapshots and check they land in a different region or account from production.

The part everyone skips: testing.

If you have never restored from a backup, you do not have a backup. You have a job that reports success.

• Once a quarter, pick a file or a database table and restore it. Run the actual restore, do not settle for a green tick on the backup job.
• Once a year, rebuild a non-critical environment from scratch using your documentation. Where the documentation runs out, write the missing steps down.
• Check that whoever would be doing this during an incident knows where the backup credentials and the runbook live.
• Make sure your retention period covers detection time. Some ransomware sits quiet and corrupts data slowly. If it has been active for three weeks and you keep seven days of backups, there is nothing clean left to restore.

What to do this week:

• Confirm you have a backup that sits entirely outside your primary storage and has not been modified since it was created.
• Turn on versioning in your cloud storage if it is not already on.
• Put a test restore in your calendar for next month, and do not move it.

5. Test your own systems before someone else does

You no longer need to be a security specialist to run a basic security test. You can paste code into a model, describe your application, or point a tool at a staging environment and get useful findings in minutes. Attackers already use this to find weak spots faster than they used to. The same capability is sitting there for you.

Testing your code:

Paste a function or a module into Claude, ChatGPT, or Gemini and ask directly:

• “What security vulnerabilities do you see in this code?”
• “Is there anything here that could be exploited for SQL injection, command injection, or path traversal?”
• “How would you attack the authentication logic in this function?”
• “What happens if I send unexpected input to this API endpoint?”

This does not replace a proper code review or a penetration test. It does catch the obvious problems that would otherwise sit in the codebase until someone finds them the hard way. Run it before you ship.

Testing your application and infrastructure:

Free security harnesses now let you drive any LLM from your command line to assess an application, both the code itself and the running system by scanning its URL.

One of the notable free tools for this is CyberStrike, an open source AI-powered offensive security harness built around 13 autonomous agents covering web applications, cloud environments, internal networks, and CI/CD pipelines. Findings map to OWASP WSTG, MITRE ATT&CK, and CIS Benchmarks, and it supports over 150 LLM providers including Anthropic, OpenAI, and fully offline models through Ollama.

Point it at your own staging environment, with authorisation, and read the report. The responsible version of this is running it against yourself before someone else runs something similar against you.

What to do:

• Pick one internal API or codebase this month and paste it into a frontier model with specific security questions. It takes 15 minutes.
• If you have a web application, set up CyberStrike against your staging environment and work through the findings report.

Where to start if this feels like a lot

Five things, in priority order:

Most attacks are opportunistic. They go where the effort is lowest. Do these five and you become the harder target, so whoever is scanning moves on to someone else.

References

• Security Affairs: Gym Booking Task Turns Into Real-World AI Cyberattack
• The Hacker News: Microsoft, OpenAI Warn of Nation-State Hackers Weaponizing AI
• Hugging Face: Security Incident July 2026
• OpenAI: Hugging Face Model Evaluation Security Incident
• CyberStrike on GitHub
• CyberStrike Docs