The rise of the bots

This is the second of six posts drawn from Concordia on 1 October, where our Managing Director, Yogesh Agarwal, opened the day with six things we keep seeing in our work with clients. Last week we looked at identity. This week: the rise of the bots.

More than half of all web traffic is now automated rather than human. Most organisations still picture an attacker as a person who has decided to target them. For the majority of attempts, there is no decision and no person. There is a script, running continuously, against everyone.

That is what we mean by the rise of the bots. Not a new kind of attack, but the same attacks attempted at a volume and speed that human processes were never built to match.

What we are seeing

AI-driven attacks have risen sharply. The number detected rose 12.5-fold in a year. Techniques that used to need skill and time are now available to anyone willing to pay a subscription.

Exploiting known flaws is now the top way in, ahead of stolen passwords. It accounts for 31% of breaches. These are not undiscovered weaknesses. They are published, documented and fixable, and the patch usually already exists.

And most of them are never fixed. Of the critical flaws on the US government’s list of vulnerabilities known to be under active attack, only 26% were fully remediated last year, down from 38%. That is the figure that connects the other two. The flaw is public, the scanning is constant, and the gap between disclosure and patching is widening rather than closing.

If you hold Cyber Essentials, that gap has a second consequence. The scheme asks for high-risk and critical updates within 14 days, and under the April 2026 changes the two questions covering it fail the assessment automatically. An organisation used to be able to certify with up to two major non-compliances against its name. That is no longer the case.

Machine speed against human speed

Attackers work at machine speed. Most organisations still patch and approve at human speed. A vulnerability is published on a Tuesday, scanners are testing for it by Wednesday, and your team books the fix into a change window a fortnight away, because that is how change control works and it has served you well.

The same mismatch shows up on the other side of the business. At Concordia, Michael Earl, who leads security operations and incident response at the specialty insurer Convex, described what AI has done to the pace of building things.

“An individual can go and spend three hours in an afternoon and pop out of that session with a fully built and finished solution. The amount of time that you will then spend shopping that around in the various approval forums becomes disproportionately large.”

Michael Earl, Convex, speaking at Concordia

Three hours to build, weeks to approve. The ratio that lets an attacker move faster than your change window is the same one that pushes your own people around your governance.

What this means for you

AI is finding software flaws at industrial scale, and moving faster than open-source projects can patch them. The supply of known, unpatched weaknesses is growing rather than shrinking. Being a small or uninteresting target offers less protection than it used to, because nothing is choosing targets.

Your own AI tools and agents need governing too. Shadow AI, the use of tools nobody has approved, is now one of the most common causes of accidental insider risk, and 45% of employees are using AI on corporate devices, approved or not, up from 15% the year before. Some of those tools can read company data, draft on your behalf, or take actions in systems they have been connected to.

Sonal Agarwal, who co-founded RightCue, made the point at Concordia that this is a predictable result rather than a discipline problem.

“If you put in too many controls, too many rules in front of people, they find different ways to overcome it. That’s why we have the problem of shadow IT.”

Sonal Agarwal, Acaster Lloyd Consulting, speaking at Concordia

A blanket ban on AI tends to produce shadow AI. The more useful question is which tools are already in use, what they can reach, and whether anyone has written it down.

Where we would start

None of this needs a big programme. These are the practical steps we recommend to clients:

• Measure your actual patching time. Not the policy, the measured median for high-risk and critical updates over the last six months. Most organisations have never looked, and the number is usually worse than expected.
• Separate emergency patching from routine change. A 14-day route for critical fixes does not mean tearing up change control. It means a defined exception path, agreed in advance, that does not wait for a committee to convene.
• Know what is exposed to the internet. Automated scanning finds whatever faces outward. An inventory of internet-facing assets, with an owner against each one, is the baseline.
• List the AI tools already in use. Ask rather than audit, at least to begin with. People answer honestly when the question is not framed as an investigation.
• Decide what those tools may reach. Customer data, source code, finance systems. Those answers belong to the business, not to whoever installed the tool.
• Make the approved route the fast one. If the sanctioned option takes six weeks and the unsanctioned one takes an afternoon, the policy has been decided for you.