Security in the AI Era: Old Problems at Machine Speed

Most of the security problems we deal with today are not new. Unpatched software, weak passwords, phishing, secrets in the wrong place. What AI changed is the price. Attacks that used to need skill or patience are now cheap, so they reach everyone.

That matters most for small operators: a solo developer, a small agency, someone who runs a few sites for clients. For years, being small and uninteresting was part of the defence. That stopped working. Nobody targets you. Everything is targeted, automatically.

Here are the challenges I think matter most right now, roughly in order, with what helps against each. None of it needs a big budget. At the end there is one worry of my own: the caution built into AI tools falls mostly on the people defending.

Turning a security advisory or a patch diff into a working exploit used to take skill and days. With a model’s help it can take hours, and the scanning that follows is fully automated. “We patch once a month” no longer covers software that faces the internet.

• Know what you expose. Keep an inventory you can read in a minute: every domain, service and open port.
• Turn on automatic security updates wherever a failed update is cheap to recover from.
• Keep a fast manual path for the rest, so patching something critical takes minutes, not a weekend.
• Expose less. Admin panels and management interfaces should only be reachable from places you know.
• While you wait for a fix, switch the vulnerable feature off, or block the specific request pattern that exploits it.

Scanners used to throw the same list of paths at everyone. Now probing adapts: it works out which software you run, then asks for the files, endpoints and backups that software usually leaves behind. Password guessing is spread over thousands of addresses with a few tries each, so per-address limits barely notice it.

• Limit login attempts per account, not only per address.
• Use keys, passkeys or MFA instead of passwords wherever you can.
• Keep nothing secret under the web root: no backups, database dumps, .git folders or copies of config files.
• Answer every missing or forbidden path with the same plain “not found”. Don’t tell a scanner what it almost found.
• Make blocking cheap to add and cheap to undo, so you actually use it.

There are far more crawlers now, they are much more aggressive, and many ignore robots.txt while rotating addresses and user agents. A small dynamic site can be knocked over by “polite” traffic alone, and the volume hides real attacks.

• Cache pages for anonymous visitors, so a crawl costs almost nothing.
• Rate-limit the expensive endpoints: search, filters, feeds, anything that hits a database.
• Give login and forms their own, stricter limits.
• Decide which crawlers you want, on purpose, instead of finding out from the load graph.

A coding or operations agent with a shell, cloud credentials and a deploy key is a new kind of privileged user. It is fast, tireless and literal, and it will act on text it reads. Its mistakes happen at machine speed. And the default setup is usually “it can access everything, because that was easier”.

• Give the agent its own identity, scoped to the task. Never hand it yours.
• Prefer short-lived credentials to long-lived keys.
• Require a human to approve anything destructive, irreversible or outward-facing: deleting, deploying, sending, paying.
• Let it work in a sandbox or a separate working copy.
• Limit where it can connect to.
• Keep backups it cannot delete, either append-only or offline.
• Keep a log of what it did that it cannot edit.

Most of this list is old problems made faster. This one is new. Web pages, emails, tickets, issue comments, file names, log lines and form submissions all become input to something that can act. Any place a stranger can write text is now a possible command channel.

• Treat everything an agent reads as data, never as instructions.
• Split the roles. The part that reads untrusted content should not be the part that holds credentials and can act.
• Allow-list actions and destinations instead of trying to block the bad ones.
• Require confirmation for anything that sends data out or changes state.
• Assume injection will sometimes work, and limit what a hijacked agent can reach.

People paste config files, logs and stack traces into assistants. Agents read whole repositories and home directories, including the file with the keys. Secrets end up in transcripts, chat histories and third-party systems that nobody audits.

• Keep secrets in a secrets manager, not in files an agent can read.
• Use one credential per purpose, so an exposed one opens as little as possible.
• Keep lifetimes short.
• Practise rotation until it is quick. If rotating a key is a project, you won’t do it.
• Scan commits for secrets before they leave your machine.
• Make your tools print “set” or “not set”, never the value.

Generated code looks finished, so it gets less review than it needs. It repeats insecure patterns with confidence, and it sometimes suggests package names that don’t exist, which attackers then register. More code, written faster, with less understanding per line.

• Review generated code like a pull request from a stranger.
• Pin and lock your dependencies.
• Before installing a package, check that it exists and is the one you meant.
• Keep dependency trees small.
• Test the security behaviour, not only the happy path: bad input, no login, the wrong user.
• Get a second, independent review for anything that touches authentication, input handling or money.

The language is flawless in any language. Messages are built from what is public about you, voices can be cloned, and fake invoices or “your provider” notices arrive in volume. For a small operator, the accounts worth protecting are the ones that control everything else: the domain registrar, hosting, the mailbox and payments.

• Put phishing-resistant MFA (hardware keys or passkeys) on those accounts first.
• Have a call-back rule: any request to change payment details or access is confirmed on a number you already know, never one from the message.
• Turn on registrar and transfer locks for your domains.
• Set up SPF, DKIM and DMARC on your own domains, so nobody can easily send mail as you.

Everything above multiplies the number of events. Nobody can read them all, and an alert stream nobody reads is the same as none. AI triage helps a lot, but it can be confidently wrong, and it can be steered by what it reads in the logs (see prompt injection).

• Keep few alerts, and make each one require an action. Everything else goes into a daily digest.
• Automate the reversible responses, such as temporary blocks that expire. Keep people for the irreversible ones.
• Let an assistant summarise and propose, then check the raw evidence before acting on anything that matters.
• Test whether you would actually notice a real problem.

• “Nobody would target me.” Nobody needs to. Everything is targeted, automatically.
• Old side projects, demos and test installs left running and unpatched next to the things that matter, sharing a server or credentials with them.
• One credential for everything, never rotated, stored who knows where.
• Backups that were never test-restored, or that anyone with access to the server could delete.
• Admin panels and management ports open to the whole internet, “temporarily”.
• Giving an AI agent your own full access, because scoping it felt like overhead.
• Trusting output because it reads well: generated code, generated log summaries, generated “all clear” reports.
• Collecting logs that nobody, and nothing, ever looks at.
• No written plan for the bad day: who to tell, what to switch off first, which credentials to rotate and in what order.

Mainstream AI assistants are trained to be careful with security questions, and for a good reason. “Find the vulnerability in this code” reads the same whether it comes from the owner or from an attacker. The model can’t see who is asking.

In practice, that caution falls mostly on defenders. People who attack for a living are not bound by anyone’s usage policy. They run open-weight models with the safety training stripped out, or they rephrase until something answers. The people who follow the rules get the refusals. I often get flagged for “hacking” while I’m asking an assistant to check my own code, for purely defensive work.

The gap is less about capability than about friction. The strongest models are still the guarded ones, and a stripped-down open model is usually weaker. But a defender who is refused halfway through an audit loses time, and some stop asking. That is the worst outcome: the bug is still there, and only the attacker went looking for it.

• Give context up front: whose code it is, what you are trying to protect, and that the goal is to fix it. A clear scope is refused far less often than a bare “find exploits”.
• Ask for what a defender needs: where the risk is and how to fix it, not a working exploit.
• Don’t rely on one assistant for security review. Static analysis, dependency scanners and fuzzers never refuse, and they catch a lot.
• For code you own, a local model can do a first pass with no one else’s policy in the way, and without your code leaving your machine.
• When a refusal is wrong, report it. That feedback is how the tools get better.

• Judge requests by context and track record, not by words like “exploit” or “vulnerability”.
• Offer verified access for security work, with a real appeal when an account is flagged by mistake.
• Count the cost of a wrong refusal. Every defender turned away is a small win for an attacker who was never going to ask.

The same tools that make attacks cheap make defence cheaper too. One person with a good assistant can watch and maintain far more than before. The condition is the one that applies to any powerful tool: give it narrow permissions and a way to stop it, and keep a human for the decisions that can’t be undone.

Apart from prompt injection, AI didn’t invent new ways in. It made the old ones cheap. The fixes are mostly the old ones too. You just can’t put them off anymore.