A logistics manager who has never written a line of code builds an internal tool over a weekend. It tracks deliveries, emails customers and has a dashboard the board likes. Work that used to take a team three months took two days, and from a business point of view that's a very good result. Nobody asked what's inside it.
Stopping AI-assisted development would be absurd, and so would telling these people to go back to spreadsheets. They know their domain better than any contractor will, and the tools let them act on it. The problem is narrower: the person who built the app can see the screen, and the screen works. The inside is a different matter.
What's inside the box
Veracode tested more than 100 language models on 80 coding tasks and found that 45% of the code samples failed security tests and introduced OWASP Top 10 vulnerabilities. Java was the worst case, with a 72% failure rate. The October 2026 update is the first meaningful gain since 2025, and it still only moves the average pass rate from 56% to 62%. Models got better at writing code that runs. They didn't get much better at writing code that's safe.
The failures that reach production tend to be boring ones. In 2025 a researcher found that apps generated by Lovable often shipped without proper Row Level Security on their databases, which let anyone unauthenticated read or write tables. It was assigned CVE-2025-48757 (Lovable disputes it, arguing each customer owns their app's configuration). The researcher's write-up counted 303 vulnerable endpoints across 170 projects, about 10% of the ones analysed.
In February 2026, Wiz found Moltbook's database wide open, a social network for AI agents built entirely by prompting. A Supabase key sat in client-side JavaScript and, without RLS policies, it gave full access to 1.5 million API authentication tokens and 35,000 email addresses. In July 2025, Wiz had shown that on Base44 a non-secret app ID was enough to register an account inside someone else's private app. Base44 fixed it in under 24 hours, which is the right way to handle it, and also a reminder that the flaw was there until someone looked.
Anyone can run an attack now
The same tools lower the bar for the other side. In August 2025, Anthropic reported a criminal who used Claude Code against at least 17 organisations, including healthcare and government bodies, to steal data and write the extortion demands, which sometimes exceeded $500,000. The same report describes a ransomware seller with "only basic coding skills" who was selling AI-built malware for $400 to $1,200.
Three months later Anthropic described a state-sponsored campaign against roughly thirty targets in which the AI did 80 to 90% of the work and humans mostly approved the next step. It succeeded "in a small number of cases." It's Anthropic's own tool being misused, and Anthropic is the one who disclosed it.
The wider data points the same way. CrowdStrike's 2026 Global Threat Report counts an 89% year-over-year rise in operations by AI-enabled adversaries, an average eCrime breakout time of 29 minutes and a fastest case of 27 seconds. Mandiant's M-Trends 2026 puts the mean time to exploit at an estimated minus seven days, meaning exploitation often starts before a patch exists. Google's threat intelligence group reported a zero-day (a two-factor bypass) that it believes was developed with AI, planned for mass exploitation and disrupted before it happened. IBM's 2026 breach study found that one in four malicious breaches was AI-enabled, at an average cost of $6 million.
Then there are the fridges
On 11 October 2026 someone reached into the refrigeration controllers of French supermarkets. France's finance minister said about 700 of the country's 10,000 supermarkets were affected, and the reports describe temperatures pushed as high as 50°C and a forced defrost cycle. CERT-FR's alert CERTFR-2026-ALE-012 names Danfoss AK-SM and AK-SC controllers and Copeland and Dixell xweb consoles, and its first instruction is to disconnect them or filter access, because a management interface on the open internet is against good practice.
On 2 November NBC reported a second wave: spoiled food and temperature spikes in Sweden, the Netherlands, Belgium, Ireland, Luxembourg and Estonia, including 13 SuperValu stores. According to Cybersecurity Dive, Shadowserver still counted 1,173 Copeland XWEB Pro and Evo instances exposed to the internet days later.
No credible source says AI was involved in these attacks. I bring them up because of what they show. A device that nobody was responsible for securing, with a web console that nobody remembered was reachable, in a place where a breach costs real money within hours. Replace the controller with an admin panel your logistics manager generated last Saturday and the story is the same. What changed is who can build the thing, and who can find it.
The end of static risk analysis
Plenty of vendors sell "dynamic risk assessment" now, and each one defines it a little differently. The term isn't standardised in security. It comes from emergency services and health and safety work (private security training teaches the same phrase to officers who have to judge risk on the job as a situation changes), where it means assessing risk as conditions change instead of filling in a form beforehand. The security standards describe the idea with other words, and the best established is NIST's continuous monitoring. SP 800-137 defines it as "maintaining ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions." The last part matters: monitoring exists to feed risk decisions. The NIST Cybersecurity Framework 2.0 says managing cyber risk "must be a continuous process", and SP 800-37 adds ongoing authorization and near real-time risk management.
The classic approach is a point-in-time exercise. You list assets, threats and vulnerabilities, score likelihood and impact, decide what to treat, and the result sits in a register until the next review or until something big changes. NIST is fair about its own method. SP 800-30 says risk assessments "are not simply one-time activities", and the RA-3 control asks for updates at an organisation-defined frequency or after significant changes. In practice the register ages while the system moves. SP 800-37 draws the contrast itself: it calls reauthorization "the static, single point-in-time risk determination" and says systems may move "from a static, point-in-time authorization process to a dynamic, near real-time ongoing authorization process."
That's what I mean by dynamic. Assets, exposure and threats get re-evaluated as they change, ideally on every deployment and every new piece of threat intelligence, and the result feeds decisions (block this release, isolate that service) instead of a report. It includes the apps nobody in IT knew existed.
The agencies that write the guidance say the same thing. In June 2026 the Five Eyes cyber agencies warned that cyber risk assumptions "can become outdated in months, not years" and that "defenders must do the same" as adversaries using AI. When the mean time to exploit is negative and a weekend project can reach production by Monday, a document written in January describes an organisation that no longer exists by March.
It also changes who does the first pass of defence. A SIEM collects more than a human team can read. Vectra's 2023 survey of 2,000 analysts found SOCs receiving 4,484 alerts a day and unable to deal with 67% of them, and that was before attackers had agents. Microsoft says it processes more than 165 trillion signals a day, and its 2026 Digital Defense Report is blunt about the consequence: "Attacks conducted at machine speed will only be confrontable by defenders moving with the same speed."
ENISA's July 2026 paper on cybersecurity in the frontier AI era goes further. It says SOCs "must further adopt automation" and recommends AI-assisted triage with human review, aiming for detection and response in single-digit minutes. Anthropic gives the same advice in its report on the espionage campaign, telling security teams to experiment with AI for "Security Operations Center automation".
I read that as a division of labour, and I'd push it further. The AI should be the first line for both halves of the job: running the SOC (triaging, correlating, containing the obvious) and keeping the risk assessment alive, re-scoring exposure whenever a deployment, a new CVE or a new alert changes the picture. Humans shouldn't read the stream. They should get a short list of findings and issues, already triaged and explained, and make the calls that need judgment: escalations, business impact, the unusual case. A human-only SOC with an annual risk register is a queue that attackers can outrun.
The open-source pieces are arriving. DARPA's AI Cyber Challenge finalists found 54 of 63 synthetic vulnerabilities and patched 43, and the Linux Foundation's OpenSSF now hosts OSS-CRS, a framework for LLM-based bug finding and fixing that came out of that competition. OCSF, the shared schema for security alerts, is a Linux Foundation project too. Together they're the plumbing for an AI-first SOC, and the first line itself is still something each team has to build and tune.
DevSecOps, STRIDE and code that's secure by default
The cheapest place to fix a vulnerability is before it exists. DevSecOps means the pipeline does that work on every commit: static analysis, dependency and secret scanning, and dynamic tests against a running build, with the release blocked when they fail. CISA's Secure by Design principle puts it in one line, that cybersecurity belongs in the design of the product, not in a patch afterwards. NIST's Secure Software Development Framework (SP 800-218) turns it into a practice list you can audit against.
Threat modelling is what tells you what to test. STRIDE asks six questions about every component and data flow: can someone spoof an identity, tamper with data, deny having done something, read what they shouldn't, take the service down, or gain privileges they weren't given. Run it against a typical generated app. A Supabase key in the browser with no row-level policies fails on information disclosure and on elevation of privilege before you've looked at a line of code. It takes an hour, and it would have caught Moltbook.
With agents in the loop, add OWASP's LLM06, Excessive Agency. An agent with more functionality, more permissions or more autonomy than its task needs is a liability, whoever wrote the prompt.
Sandbox the AI, and sandbox what it builds
Treat a coding agent like a contractor you haven't vetted yet. It runs with limited access to the filesystem, a network allowlist, and nothing it can touch beyond the project. Claude Code's sandboxing works this way, with the operating system enforcing the boundary around the commands the agent runs, which limits what a manipulated prompt can read or which hosts it can call.
The apps that people build with AI need the same treatment once they're running. Assume the code has flaws, and design the environment so a flaw doesn't become a breach. Zero trust, as NIST defines it in SP 800-207, means no implicit trust from network position: every request is authenticated and authorised, access is least-privilege, and the app can only reach what it was explicitly given. An internal tool made by a non-developer should be able to read the table it needs and nothing else, and it shouldn't be reachable from the internet at all unless there's a reason.
Regulation is moving the same way. The EU Cyber Resilience Act's reporting duties under Article 14 (24-hour early warning, 72-hour notification) have applied since 11 September 2026, and the rest of the regulation applies from December 2027. If you sell software with digital elements in the EU, "we didn't know it was vulnerable" is getting expensive.
Attack yourself first
An attacker with an AI agent needs minutes, so the defender should already have run the same exercise. We use two open-source tools for this.
Strix runs autonomous pentesting agents against your applications. They do the reconnaissance, attempt the exploitation and validate each finding with a working proof of concept before reporting it, which keeps the report to things that actually work. It runs locally in a Docker sandbox with the model of your choice, so the tooling stays in your environment (your code still goes to whichever model provider you choose).
RedAmon covers the red-team side. It maps the attack surface into a graph, exploits it from a Kali sandbox with human approval gates between the steps, and opens pull requests that fix what it finds. The approval gates matter: the human stays in charge of what the agent is allowed to do next.
Both tools do real damage in the wrong hands, so the rule is simple. Only point them at systems you own or are authorised to test.
The models themselves are a catch. The commercial ones are built to be careful with this work. Anthropic says its generally available models "have conservative cyber safeguards that block most cyber work", and its support page adds that malware analysis or exploit validation "may be interrupted by our safety classifiers" (secure code review and threat modelling still work). Anthropic runs a Cyber Verification Program with tiers for defensive and authorised red-team work, but access is by application, and enrolled organisations have to allow data retention so Anthropic can monitor for misuse. OpenAI has a comparable Trusted Access for Cyber programme that gives verified users model versions with less friction on dual-use security work.
Given the cases above, those are reasonable policies. They're also a dependency. A pentest in the middle of an engagement shouldn't stall because a classifier didn't like an exploit, and a client's code and findings shouldn't need to travel to a third party in the first place.
The alternative is for the security team to host its own model. Our recommendation is a Mac with a lot of unified memory. Apple sells the Mac Studio with up to 512 GB (M5 Ultra, 1.2 TB/s of memory bandwidth) and the MacBook Pro with up to 128 GB (M5 Max, 614 GB/s). Memory decides which model fits, and bandwidth decides how fast it answers. For scale, OpenAI's gpt-oss-120b runs on a single 80 GB GPU and gpt-oss-20b within 16 GB. The other route is a GPU box like NVIDIA's DGX Spark, with 128 GB of unified memory, 273 GB/s of bandwidth and NVIDIA's own figure of models up to 200 billion parameters on one unit. It's a good dedicated appliance, but the Mac's ceiling is higher on both memory and bandwidth. There are also open models trained for the job, such as Cisco's Foundation-sec-8B (Apache 2.0). Whichever you pick, the same rule applies: you decide who can use it, what gets logged, and where the code goes.
What we do about it
IBERANT treats security as part of the engineering, not as a review at the end. We build with DevSecOps and STRIDE in our own pipelines, and we write code that's secure by default. We host applications in protected zero-trust environments, including on Claybridge Apps, the open-source platform we run on your own infrastructure. We run pentests and red-team exercises with AI, using Strix and RedAmon with senior engineers reading every result. And we help companies that already have AI-built applications in production: an inventory of what's running, a hardening plan, and the fixes.
If someone in your company built something over a weekend and it's now holding customer data, let's talk.