Walk into almost any IT team meeting this year and the agenda looks the same. How many developers are using AI assistants? Which workflows can we automate next? What's our AI story for clients? Job posts ask for prompt engineering and LLM experience. Appraisals reward AI adoption.
I understand the excitement. I use these tools every day. But I keep coming back to a question that rarely makes the agenda: while we teach our teams to build faster with AI, who is teaching them to defend what they build?
My view is simple. AI hasn't only made good developers quicker. It has made attackers quicker, cheaper and more patient too. In that world, knowing the fundamentals of cybersecurity is no longer a niche specialism. It is part of being a competent engineer, manager or founder.
"The chatbot refused, so we're fine" is a false comfort
Type "how do I break into a Wi-Fi network" into a popular AI assistant and it will politely decline. I have heard people treat that refusal as evidence that AI is safe from a business point of view. It isn't.
That refusal is a policy on one company's product. It says nothing about the wider toolbox an attacker can reach for:
- Clever phrasing. People share tricks to talk models out of their rules, and vendors keep closing them. It is an ongoing game, not a solved problem.
- Models with no rules at all. Open-weight models can be downloaded and retrained without restrictions. Stripped-down versions are already marketed to criminals for writing scam emails and malicious code.
- Piece-by-piece requests. Nobody needs to ask for "an attack". They can ask for a scanning script here, a protocol explanation there and a polished email somewhere else, then stitch the parts together.
A vendor's content filter protects the vendor. Your customer database, your cloud account and your brand sit outside that fence. Guarding them is still on you.
Every security advisory starts a race, and AI runs it fast
When a library you depend on ships a security fix, its release notes usually explain what was wrong and which versions are affected. That openness exists so you can protect yourself. The catch is that everyone else reads it too.
A few years ago, turning those notes into a working attack took a skilled person days or weeks. Today an AI model can compare the old and new code, explain the flaw in plain language and help sketch the steps to abuse it, in a single afternoon. The fix and the instructions for the break effectively arrive together. Whoever applies the update first wins.
The numbers show the race tightening:
- Rapid7's 2026 threat report counted 146 exploited high and critical flaws in 2025, against 71 the year before. The median gap between publication and confirmed attacks shrank from 8.5 days to 5. (source)
- Qualys reported that 85% of affected systems were still unpatched on disclosure day, and 63% of critical flaws remained open a week later in 2025. (source)
- Cogent, a security vendor, measured the average time from disclosure to a usable exploit falling from roughly 125 days in January 2025 to under a day by April 2026. (source)
There is a quieter problem too. Thousands of weaknesses were documented by human researchers years ago, and many old servers and forgotten plugins still carry them. Machines are very good at spotting a known pattern across millions of systems. Your neglected staging server is exactly the kind of thing they find.
Vibe coding: a brilliant intern with no instinct for danger
I like to think of an AI coding assistant as a very fast, very eager intern. It produces a lot, it rarely complains, and it does exactly what you describe. What it won't do is stop and say, "Are you sure this endpoint should be public?" unless you asked it to care.
In code reviews of AI-assisted work, these are the slips I watch for:
- API keys or database passwords pasted straight into the code, sometimes into the front end where anyone can read them
- User input passed directly into database queries or web pages without checks
- Admin routes and cloud storage left open because access rules were never mentioned in the prompt
- Packages chosen because the name sounded right, including old, abandoned or look-alike ones
- Personal details such as phone numbers and health data written into logs in plain text
None of this is malice. The assistant simply optimises for "it works". A reviewer who knows the basics catches these in minutes. A reviewer who doesn't approves them, and the speed AI gives us becomes the speed at which we ship holes.
That's why I believe AI-generated code needs more security awareness from humans, not less.
Smaller firms are in the blast radius by default
A large bank has a security operations centre watching its systems around the clock. A 40-person software agency usually has one overworked DevOps engineer and good intentions. Many such firms assume nobody would bother with them.
Automated attacks don't make that kind of judgement. A script sweeping the internet has no idea how big your company is. It only sees an open port, an outdated plugin or a login page without two-step verification, and it tries the door.
When it gets in, the damage spreads well beyond IT:
- Customers' personal data leaks, followed by regulatory questions under laws such as India's Digital Personal Data Protection Act or the EU's GDPR.
- Work stops. Ransomware can freeze billing, delivery and support for days.
- Confidence drops. Clients quietly wonder what else you have missed, and some move on.
- Deals stall. Bigger clients now send security questionnaires before signing. Weak answers can lose a contract with no breach at all.
A large company can usually absorb one bad incident. For a smaller one, it can decide whether the business survives the year.
The security literacy every team member should have
Not everyone needs to become an ethical hacker. Everyone who touches the product should be able to recognise a risky pattern and know when to raise a hand.
| Skill area | What "good enough" looks like | Why AI raises the stakes |
|---|---|---|
| Writing safe code | Knows the OWASP Top 10 and can spot injection, missing access checks and unsafe defaults | Assistants reproduce these mistakes confidently |
| Accounts and permissions | Uses MFA everywhere, gives people only the access they need, keeps secrets in a vault | Rapid7 tied 43.9% of its 2025 incident cases to accounts with weak or missing MFA |
| Keeping software current | Follows advisories for the stack in use, runs dependency scans, patches on a rhythm | The gap between a fix and an attack is now days or less |
| Cloud and network hygiene | Checks open ports, storage permissions and firewall rules after every change | Misconfigurations are discovered by bots, not people |
| Spotting manipulation | Recognises phishing, fake invoices and cloned voices or video calls | AI writes flawless, personalised lures in any language |
| Visibility | Knows what gets logged, where it goes and who reviews it | An attack you can't see is an attack you can't stop |
| Responding under pressure | Has a short, rehearsed plan: who decides, how to isolate, what to tell clients | Panic wastes the hours that matter most |
A practical rule: for every AI training session your company runs, run a security session alongside it. Learning to prompt and learning to review should be the same lesson.
A SIEM: the night watch for teams that sleep
No small team can stare at logs all day. Attacks often begin at 3 a.m., during a holiday or in the middle of a release. That is where a SIEM (Security Information and Event Management) platform earns its place.
Think of it as a night watch that never gets tired:
- It gathers activity from your servers, apps, cloud accounts, firewalls and laptops into one searchable place.
- It connects the dots. A burst of failed logins followed by a successful one from an unfamiliar country stops being noise and becomes one clear warning.
- It wakes the right person with an alert by email, Slack or phone, instead of hoping someone notices.
- It keeps the evidence, which you need for investigations, audits and those client security questionnaires.
Cost is no longer an excuse. Wazuh is open source and widely used by smaller teams. Elastic Security, Microsoft Sentinel, Splunk and Google Security Operations fit bigger or cloud-first setups, and many now use AI to sort and summarise alerts.
One caution from experience: a SIEM is only as good as the person tuning it. Someone has to choose what matters, silence false alarms and respond when a real one fires. Tools without knowledge become an expensive inbox nobody reads.
Seven moves for the next 90 days
- [ ] Switch on two-step verification for email, cloud consoles, code repositories and every admin panel
- [ ] Follow the security advisories for your main frameworks and turn on automatic dependency alerts
- [ ] Add five security questions to your pull request template, and use them on every AI-written change
- [ ] Pull passwords and keys out of the codebase and into a proper secrets store
- [ ] Stand up a SIEM, even a free one, and feed it logs from your most important systems first
- [ ] Hold a 30-minute session on phishing, fake invoices and deepfake calls
- [ ] Write a one-page "what we do if we're breached" plan and name who owns it
Speed is a feature; safety is the foundation
I'm not arguing against AI. I'm arguing against lopsided investment. Companies are pouring time and money into making AI do more, while the people who must keep that work safe get little training at all.
Attackers have the same tools we do, and none of our rules. The companies that come out ahead won't be the ones that adopted AI first. They'll be the ones whose customers never had a reason to doubt them. Teach your teams to build with AI, and teach them, with the same energy, to protect what they build.
Top comments (1)
Official Platform Update
Security protocols have been updated for all developer accounts.