If you've been following the news recently, you'll have heard about the hacks, vulnerabilities and outright poor cyber hygiene affecting businesses all over the world. It feels relentless.

We're in the middle of a difficult combination. AI tooling lets us produce more code, businesses can launch digital services more easily, and the people attacking those services have access to better tools too. If our checks don't keep up with what we're shipping, we're creating more opportunities for things to go wrong.

Security problems were here long before AI. Unpatched software, stolen credentials and badly configured systems haven't gone away. In Verizon's 2026 Data Breach Investigations Report, which uses 2025 data, exploitation of vulnerabilities was the entry point in 31% of the breaches analysed. That's a reminder of how much damage existing weaknesses can do. Verizon's findings put some numbers behind it.

What worries me is the pace at which we're adding to the problem.

The people on the other side are getting better tools too

I've been part of the cyber world for a few years now, and something I have to admit is that some of the people carrying out these attacks are among the best outside-the-box thinkers I've encountered. The creativity involved in some of the attacks I've seen has blown my mind, and I'd consider myself very technical.

Give someone like that a tool that helps them research a system, understand unfamiliar code or automate repetitive work, and you're helping them move faster. You're also making some tasks accessible to people who wouldn't previously have had the skills to attempt them.

The UK's National Cyber Security Centre expects AI to make parts of cyber intrusion more efficient and to increase the volume and impact of attacks through 2027. Its assessment points to improvements in existing techniques, including finding vulnerabilities and exploiting systems that haven't been updated. The NCSC assessment is worth reading.

For a business running an exposed service, that means less room to leave a known problem sitting in the backlog.

Shipping more code brings more responsibility

Being able to build a working product quickly is exciting. I've spent enough time in startups to appreciate what that makes possible.

But a working demo can hide a lot. A user can log in, a page loads and the data appears where you expect it. None of that tells you whether another user can access the same data when they shouldn't.

Take a customer portal. A test confirms that a customer can open their own invoice. Great. Now test whether they can request someone else's invoice by changing its identifier. The server needs to check their permission to access that particular invoice, even though they're already logged in. This is the kind of problem covered in OWASP's API security guidance.

That's a small example, but it shows why “the tests passed” needs a follow-up question: what did we actually test?

I also worry about what happens when businesses reduce experienced teams because AI can produce more code. If you remove someone who understands why a particular permission is restricted or why a deployment has an extra check, you need to account for that knowledge. Their contribution won't necessarily show up in a count of completed tickets.

An agent can help implement a requirement. Someone still has to realise the requirement matters.

Can the tool check its own homework

We can ask Claude, Codex or another tool to review the code it has written. I think that's useful. It gives us another chance to spot a mistake before it reaches a customer.

I wouldn't make that the whole review process, though. If the implementation and its review both work from the same wrong assumption, a confident explanation doesn't help much. Giving another agent the review can add a useful challenge, but it still needs to be backed up by tests and someone understanding the risks.

The important part is asking specific questions. Which users can reach this data? Where are permissions enforced? What happens if an external service fails? Are we putting sensitive information into logs?

“Check this is secure” leaves an awful lot open to interpretation.

So what can you do

I'd start with the things you can put into practice on the next change you make.

Review the risky parts properly. Changes to login, permissions, payments and customer data deserve particular attention. Get someone who understands the system to review them, and bring in security expertise where you need it. Give that review time in the delivery plan.

Test the things users shouldn't be able to do. Test access across different accounts, expired sessions and attempts to use features without the right permissions. Agree on the expected behaviour before asking an agent to implement it. Otherwise it's easy to end up with tests that simply confirm whatever the agent happened to build.

Automate the checks you can repeat. Scan for credentials accidentally committed to the repository, known vulnerabilities in , and risky configuration changes. Run those checks as part of the build process, and make sure somebody owns fixing what they find. A warning that everyone ignores doesn't offer much protection.

Limit what accounts and tools can access. Use for people, services and agents. Keep development credentials separate from production. An agent experimenting with a feature shouldn't automatically have the ability to alter a live customer database. Be deliberate about which data goes into AI tools as well.

Keep up with the ordinary account and software maintenance. Remove access when people leave. Use passkeys where supported, or strong unique passwords with . Keep software supported and apply security updates promptly, prioritising exposed systems and actively exploited flaws. The NCSC has practical guidance on protecting important accounts and keeping devices secure.

Know what you'll do when something goes wrong. Decide who receives alerts, who can restrict access and who will communicate with customers. Keep backups protected from the same access that could compromise your live system, and practise restoring them. Knowing a backup job ran is different from knowing you can recover the data you need. The NCSC's backup guidance includes checking that recovery works.

None of this is particularly glamorous. It takes time, and it's easy to move down the list when everyone wants the next feature.

AI can help with this work too: suggesting awkward test cases, explaining unfamiliar code and helping investigate a warning. I'd like to see some of the time we save on implementation spent there. If we're going to ship more software, we need to be able to look after it.