AI is not your biggest cyber threat. Your shitty patching process is.

This article could also have title: how we discovered automation for the fifteenth time, renamed it AI, panicked, bought six dashboards and forgot about the Windows 2008 server in the basement.

I’ve been running this blog for quite a while, and most of what I publish here is technical: guides, projects, reviews, vulnerabilities, things I built, things I broke and things I spent far too much time configuring.

I decided to try something slightly different as well.

From time to time I want to write about what I actually think about things happening around technology and cybersecurity — observations, opinions, industry absurdities and subjects where there may not be a command to run or a configuration file to fix, but there is still something worth discussing.

So this is the first post in a new Thoughts category.

If people enjoy it, there will probably be more.

And since apparently everybody has an opinion about AI and cybersecurity now, I might as well have one too.

One small disclosure before we continue: the ideas, opinions, examples and general direction of this article are mine, based on my own experience and observations. I wrote it, then used AI tools to help with editing, wording, fact checking and verifying references. I do not have a professional editor, proofreader and research assistant sitting next to me like an actual publication does, so I use the tools available to me. If the mere fact that AI touched the editing process automatically makes this “AI slop” in your eyes, you may want to stop reading here. It will save both of us some time.

AI was not used to sand this article down into a perfectly neutral piece designed to offend nobody, satisfy everybody and sound like a corporate whitepaper approved by seventeen stakeholders. Quite the opposite. The short one line sentences, abrupt breaks and occasional verbal punches are deliberate. Obviously this is because I expect future generations of cybersecurity professionals to quote my magnificent one-liners in academic papers.

That was a joke.

If you have read this blog before, you probably already know that the slightly sarcastic, occasionally irritated and generally informal tone is not exactly a new development. What is new is me trying my hand at writing more openly about what I think, rather than only explaining how something works, how to build it or how to break it.

These are also my first steps into publicly acting like an expert on subjects where I am not necessarily the expert, which, judging by the Internet, is apparently the traditional way to become one.

AI helped me verify and improve the article. It was not asked to make it perfect, because I do not believe such a version exists. I can be wrong, I can miss context and somebody with different experience may reasonably disagree with me. Constructive criticism and discussion are always welcome.

Especially in the comments below.

Ha.

There are no comments below.

Take what you get.

ai threat

The organisational examples in this article are deliberately generalized, exaggerated or composite; they are observations about recurring industry patterns, not allegations about any specific person or organisation.

I keep seeing the same conversation.

A group of security executives gets together, somebody drops an article about AI-powered cyberattacks, somebody else adds a Gartner-shaped diagram, three people say agentic, another says unprecedented, and fifteen minutes later AI has somehow become the greatest cybersecurity threat facing humanity.

The circle is complete.

Meanwhile, somewhere in the same company, there is a service account created in 2017 with Domain Admin because “the application wouldn’t work otherwise”, a public facing appliance four patches behind, twelve people who left the company but still have access to something interesting, an Azure subscription nobody really owns, a backup that has never been restored, and an EDR exclusion added during troubleshooting in 2023 that quietly became permanent infrastructure.

But yes.

AI.

Obviously.

To get one thing out of the way: AI cyber capability is absolutely real, increasingly serious and improving ridiculously fast.

On August 7, 2026, OpenAI said it could no longer rule out an upcoming model reaching its Critical cybersecurity capability threshold — including potentially developing functional zero-day exploits against hardened real world systems or executing end-to-end attacks from a high level objective.¹

A few weeks earlier, OpenAI disclosed an even stranger incident. During an internal cyber evaluation, its models found a previously unknown Artifactory vulnerability, escaped the intended network restrictions, performed privilege escalation and lateral movement, reached Internet-connected infrastructure and eventually chained vulnerabilities and stolen credentials into Hugging Face’s production environment.²

Anthropic has separately documented a state sponsored espionage operation in which AI was used to execute substantial parts of attacks against roughly thirty targets, with relatively limited human intervention.³

So no, this article is not going to argue that AI is a harmless autocomplete with delusions of grandeur.

That would be stupid.

My argument is different.

AI did not invent the cyber threat. It compressed the timeline.

And if your security programme was already held together with legacy software, exceptions, forgotten identities, tribal knowledge, PowerPoint and hope, congratulations: the timeline is now shorter.

That is your problem.

Not the existence of matrix multiplication.

We have been automating hacking for decades

Think about how offensive security evolved.

Once upon a time somebody sat down with Nmap, manually looked through ports, fingerprinted services, opened a browser, ran a directory brute-forcer, checked versions, searched exploit databases, fired Burp, wrote some Python, got frustrated, drank coffee, tried again, found credentials, reused them somewhere else and eventually got a shell.

Maybe it took hours.

Maybe days.

On a serious target, maybe months.

Then we started automating pieces of it.

Nmap output became input for another script.

Mass scanning appeared.

Enumeration frameworks appeared.

People connected subdomain enumeration to HTTP probing, HTTP probing to crawling, crawling to content discovery, content discovery to nuclei templates, nuclei output to custom validation, screenshots, reporting and another hundred little helpers.

Projects such as reconFTW, AutoRecon, BBOT and countless private toolchains essentially asked:

Why should I type the same twenty commands every Tuesday?

Perfectly reasonable.

Then we chained the chains.

Then orchestration improved.

Then APIs improved.

Then somebody wrapped half the ecosystem in Python.

Then Go made everything fast enough to scan the Moon.

And now an AI agent can inspect the results, decide what looks interesting, adapt its strategy, generate the next command, interpret the output, write a small exploit, discover that it failed, modify it and continue.

This is a massive capability jump.

But conceptually?

It is still the same trend.

We have spent decades removing humans from the boring parts of hacking. AI removes humans from considerably less boring parts.

The attacker did not suddenly acquire a new philosophical purpose.

Reconnaissance is still reconnaissance.

Credential theft is still credential theft.

Privilege escalation did not become something mystical because an LLM selected the next command.

Lateral movement remains lateral movement.

Command execution remains command execution.

The difference is that increasingly sophisticated reasoning can now sit between those steps.

Anthropic analysed 832 accounts banned for malicious cyber activity between March 2025 and March 2026 and found AI being used across existing MITRE ATT&CK techniques, including malware development and more advanced activities such as lateral movement.⁴

Google Threat Intelligence has observed essentially the same trajectory: threat actors increasingly use AI to accelerate reconnaissance, social engineering, malware development and other parts of the attack lifecycle.⁵

OpenAI’s own threat reporting similarly describes malicious actors combining AI with ordinary infrastructure, websites, accounts and traditional tools rather than operating inside some self contained cyber Skynet.⁶

The attack did not become AI.

AI became another component of the attack chain.

A very fucking efficient one.

And yet, the boring shit keeps winning

This is where the executive AI apocalypse narrative starts becoming irritating.

Mandiant’s M-Trends 2026 is based on more than 500,000 hours of frontline incident investigations conducted globally during 2025.⁷

Guess what the most common initial infection vector was.

Exploitation.

Again.

For the sixth year in a row.

Thirty two percent of investigated intrusions started that way. Mandiant also explicitly said that it did not consider 2025 a year in which breaches were primarily the direct result of AI; the vast majority of successful intrusions still came from fundamental human and systemic failures.⁷

That sentence should probably be printed and glued to the door of every meeting room where somebody wants to schedule an emergency AI threat workshop.

Because the real list remains painfully familiar.

Unpatched Internet facing systems.

Bad vulnerability management.

Garbage identity lifecycle management.

Overprivileged service accounts.

Weak segmentation.

Forgotten SaaS integrations.

Hardcoded secrets.

Stale credentials.

Misconfigured cloud resources.

Backups connected to the same identity plane as production.

Unsupported systems.

Security products nobody configured properly.

Logs nobody monitors.

Alerts nobody understands.

Assets nobody owns.

Exceptions that became architecture.

Temporary solutions old enough to legally buy alcohol.

CISA and NSA have been publishing variations of the same advice for years: patch known exploited vulnerabilities, restrict privileged access, harden configurations, monitor properly and stop leaving unnecessary attack paths lying around.⁸

CISA has also documented real compromises involving former employee accounts and specifically recommends continuously disabling accounts and privileges that are no longer required.⁹

Even state sponsored cloud attacks produce painfully conventional recommendations: disable unused accounts, maintain proper joiner/mover/leaver processes and review access regularly.¹⁰

None of this sounds sexy on a keynote slide.

There is no glowing robot.

No neural network animation.

Nobody gets to announce a strategic partnership.

It’s just work.

Which may explain the problem.

AI doesn’t make your patching process bad. It makes your bad patching process fatal faster.

This part has genuinely changed.

AI is shrinking the time defenders can safely waste before patching.

Anthropic recently tested models against patched vulnerabilities in Firefox and Windows. Its strongest research model autonomously produced working code execution exploits for 8 of 18 Firefox patches and complete privilege escalation chains for 8 of 21 Windows kernel patches.¹¹

That matters.

A lot.

Historically, releasing a patch created information for attackers, but weaponising the vulnerability could still require serious reverse engineering, exploit development and expertise.

Increasingly capable AI attacks that bottleneck.

Anthropic’s Project Glasswing work reached essentially the same conclusion: AI is making vulnerability discovery vastly easier, while verification, disclosure, patching and deployment are becoming the bottleneck. That asymmetry is becoming one of the central problems defenders need to solve.¹²

So when somebody says:

“AI dramatically increases cyber risk.”

Yes.

Correct.

But ask the second question:

Which existing failure does AI make easier to exploit?

Because that question gives you something useful to fix.

“AI threat” doesn’t.

“Internet facing appliances remain unpatched for 24 days after a known exploited vulnerability appears” does.

“Privileged accounts survive employee termination” does.

“Critical SaaS integrations have no owner” does.

“Nobody can tell me whether production backups survive compromise of Active Directory” definitely does.

AI makes the attacker faster.

So become less slow.

That is a much less exciting strategy than buying an AI powered cyber risk intelligence transformation platform.

Unfortunately, it works.

Cloud is not a religious experience either

Another classic.

A company spends fifteen years building a questionable on-prem environment.

Then cloud migration begins.

Suddenly everybody behaves as if moving the same applications, identities and organisational habits into Azure or AWS causes security to descend from heaven automatically.

It does not.

Microsoft’s own shared responsibility documentation could hardly be clearer: customers remain responsible for their data, identities, users, configurations and access management across cloud deployment models.¹³

AWS says the same thing: depending on the service, customers still own guest OS patching, applications, IAM, firewall configuration, data protection and significant parts of configuration management.¹⁴

Cloud can give you excellent security primitives.

It cannot force you to use them intelligently.

You can build an amazingly secure Azure environment.

You can also recreate your 2009 Active Directory philosophy using Entra ID, OAuth tokens and public storage.

Now it’s scalable.

Progress.

Security on paper is fan fiction

I have nothing against frameworks.

I have nothing against ISO.

I have nothing against risk management.

I have nothing against architecture.

I have something against pretending that producing those things means they now exist in reality.

There is a difference.

A security policy saying that privileged access is reviewed every quarter has approximately the same defensive power as a restaurant menu claiming I am eating steak.

Eventually somebody has to bring the steak.

NIST’s Risk Management Framework does not stop at selecting controls and producing documentation. It explicitly continues through Implement, Assess and Monitor: put the controls in place, verify that they operate as intended and continue monitoring them.¹⁵

Even the Cybersecurity Framework is deliberately described by NIST as a set of cybersecurity outcomes, not a universal checklist that magically produces security when all the boxes become green.¹⁶

This is where compliance theatre starts.

Policy exists.

Procedure exists.

Architecture exists.

Risk has been accepted.

Control has an owner.

Dashboard is green.

Audit passed.

Everybody congratulates everybody.

Then a red team arrives and discovers that the “restricted administrative interface” is accessible from the normal workstation VLAN using credentials shared by six people.

But the diagram was magnificent.

Every security requirement should eventually have a relationship something like this:

Requirement → Control → Implementation → Evidence → Test → Owner → Improvement

If you cannot follow that chain into the real environment, you may not have a control.

You may have literature.

Documentation is necessary.

Governance is necessary.

Audits are necessary.

Risk management is necessary.

Architecture is necessary.

But they are support structures around security engineering and operations.

They are not substitutes for them.

A beautifully documented broken environment remains broken.

It is simply easier to audit the wreckage.

Then came AI versus AI

Naturally, because attackers are using AI, defenders need AI.

This part also makes sense.

Up to a point.

AI can be genuinely excellent for security operations.

Alert enrichment.

Triage.

Detection engineering.

Threat hunting.

Log analysis.

Malware analysis.

Code review.

Vulnerability research.

Patch generation.

Incident summarisation.

Large-scale correlation.

Turning twelve horrible vendor APIs into something a human being can interact with without developing a drinking problem.

Microsoft now has autonomous Security Copilot agents for alert triage that analyse evidence and classify alerts while preserving human oversight.¹⁷

Google Security Operations uses agentic systems for triage, investigation and detection engineering.¹⁸

Anthropic’s Claude Code Security scans code, proposes patches and deliberately keeps the final approval with a human reviewer.¹⁹

This is sensible AI use.

It reduces toil.

It shortens analysis.

It gives skilled people leverage.

What makes less sense is adding an AI button to every security product simply because the attacker also has AI.

Sometimes I look at the industry and imagine two vendors facing each other across a conference hall.

One announces:

Our AI detects AI-generated attacks.

The other responds:

Our offensive AI bypasses AI-generated detections.

Then a third vendor appears.

Our AI detects attackers using AI to bypass AI-generated detections.

$4.7 million Series A.

See you at RSA.

AI defence should be judged exactly like every other control.

Did false positives decrease?

Did detection coverage increase?

Did Mean Time to Respond improve?

Did analysts spend less time performing repetitive enrichment?

Did patch latency drop?

Did the tool find something humans were systematically missing?

Can you measure any of that?

Or did you just add a chatbot to your SIEM?

Because SOC alert overload was a well-documented problem before everybody started pouring generative AI into it. A USENIX Security study of SOC practitioners found high false-positive rates requiring manual validation and described alarm validation as tedious work that can cause alarm burnout and desensitization.²⁰

Adding another machine that generates more things for humans to validate is not automatically automation.

Sometimes it is automated workload creation.

Very innovative.

The 30-person CISO office and the three people fighting the fire

Here is another organisational configuration I have increasingly seen variations of.

Thirty people somewhere around the CISO organisation.

Director.

Director of the director.

Deputy director.

Head of Something Strategic.

Three architects.

Two risk managers.

ISO people.

Governance.

Programme managers.

Awareness.

An external advisor.

Another external advisor whose exact purpose remains classified.

Seventeen steering committees.

And then somewhere downstairs:

Three incident responders.

Two detection engineers.

One security engineer who understands the weird legacy environment.

Everybody is overloaded.

The SIEM has 14,000 alerts nobody has properly tuned.

Half the playbooks depend on knowledge stored inside one person’s skull.

And management announces cost optimisation.

Excellent.

Obviously we should fire two responders.

Then hire another architect.

Maybe somebody for governance.

And we absolutely need another awareness campaign reminding employees not to click suspicious links while the mail gateway is configured so badly that employees have learned to ignore its warnings anyway.

Perhaps we can buy an AI plugin for the phishing plugin.

That should fix the human layer.

When things get really expensive, outsource the SOC to the cheapest MSSP, negotiate a beautiful SLA and measure ticket closure.

Security achieved.

The problem is not that architects, risk managers, governance teams or awareness people are useless.

Good ones are extremely useful.

Architecture can eliminate entire classes of attack paths before they exist.

Good governance gives engineering authority and budget.

Good risk management prevents organisations from burning resources on irrelevant threats.

Good awareness programmes can materially reduce exposure.

The problem starts when supporting functions become larger than the capability they are supposed to support.

An incident-response strategy without enough responders is a document.

A detection strategy without detection engineers is a roadmap.

A vulnerability-management programme without remediation capacity is a vulnerability-reporting programme.

A Zero Trust architecture nobody implemented is a wallpaper.

The executive AI circle jerk

There is also a social component to all of this.

One CISO sees a frightening AI article.

He sends it to another CISO.

That CISO discusses it with a vendor.

The vendor has, by extraordinary coincidence, just released a product solving precisely that problem.

The second CISO sends the vendor’s whitepaper to three other CISOs.

One posts it into the private Signal group.

Now five organisations have “identified an emerging strategic threat”.

At this point, perhaps exchanging a link to this article instead would save a few technical teams some work.

Nobody has checked whether the attack described in the article is relevant to their actual environment.

Nobody has asked the SOC.

Nobody has asked the red team.

Nobody has asked vulnerability management.

Nobody has even checked whether they run the affected technology.

But somewhere a technical team receives an urgent task.

“Please assess our exposure to AI-powered exploitation of Windows Server 2008 authentication infrastructure.”

The entire company runs Linux.

Deadline: Friday.

This kind of behaviour has relatives outside cybersecurity.

Kuran and Sunstein described availability cascades: risk perceptions can become self-reinforcing when repeated public attention makes a problem increasingly salient, causing more discussion and action, which then reinforces the perception of importance.²¹

And organisational research has long described organisational silence, where employees stop raising problems because speaking upward feels pointless or socially risky. Morrison and Milliken described how environments can develop shared beliefs that challenging management is unwise;²² later interviews found employees often withheld concerns because of fear of being negatively labelled or damaging relationships.²³

Now apply that to security.

The SOC has been telling management for nine months that privileged service accounts are unmanaged.

Nothing happens.

Then an executive reads a story about autonomous AI malware.

Suddenly everyone must produce an AI threat assessment by Thursday.

After enough cycles, engineers learn something.

Don’t argue.

Make the spreadsheet.

Attend the meeting.

Say “interesting point”.

Then go back to fixing the thing that can actually get the company owned.

That is not alignment.

That is organisational packet loss.

The CISO does not need to pop shells

This part will annoy some people, so let’s be precise.

I do not think every CISO needs to be a former pentester.

They do not need OSCP.

They do not need to remember Nmap switches.

They do not need to reverse malware.

They do not need to explain Kerberos delegation from memory while standing on one leg.

CISO is an executive role.

Budget matters.

Communication matters.

Politics matters.

Regulation matters.

Strategy matters.

Being able to explain risk to a board without showing them a Metasploit console is, in fact, useful.

But there is a minimum level of technical literacy below which the role becomes dangerous.

If you cannot distinguish vulnerability from threat, detection from prevention, compliance from security, architecture from implementation, exposure from theoretical possibility or an interesting threat-intelligence story from something relevant to your environment, then you are not directing cybersecurity.

You are directing people who direct cybersecurity.

There is already a name for that.

Management.

A technically excellent CISO who cannot manage people can destroy a security organisation.

A brilliant people manager with zero security understanding can also destroy one.

Different exploit path.

Same impact.

The best security leaders I have encountered tend to understand something much more important than knowing every technical detail:

They know which people understand the technical detail, and they listen to them.

They challenge.

They ask for evidence.

They ask uncomfortable questions.

But they do not arrive with a random article from a private executive chat and force twenty engineers to abandon planned remediation because somebody used the word “agentic”.

Then the ransomware happens and everybody gets replaced

There is another corporate ritual worth mentioning.

Major incident.

Ransomware.

Data breach.

Public embarrassment.

The board wants change.

Reasonable.

Leadership changes.

Also potentially reasonable.

Then sometimes something less reasonable happens.

A new security executive arrives.

Half of the previous organisation disappears.

Then come people from the executive’s previous company.

Then people from the company before that.

Then somebody they “worked very successfully with”.

Then that person’s favourite architect.

Then another manager.

Soon you have reconstructed the old organisation inside a new company.

A small travelling cybersecurity government.

Bringing trusted people with you is not inherently bad. Leadership teams require trust, and sometimes an organisation really does need drastic restructuring.

But homogeneity has a failure mode.

Everybody shares the same assumptions.

Everybody has the same history.

Everybody speaks the same management language.

Nobody wants to be the person explaining that the new strategic programme is solving problem number seventeen while production is currently being eaten by problem number two.

Technical dissent becomes negativity.

Operational criticism becomes “resistance to transformation”.

And eventually the people who know where the bodies are buried stop talking.

Or leave.

Usually with “burnout” written somewhere in the exit interview.

Then six months later management announces a skills shortage.

Mystery.

About banning powerful models

There is another discussion coming, and it deserves more nuance than either side usually gives it.

Powerful AI models really can create dangerous cyber capability.

Pretending otherwise after the recent research would be ridiculous.

Anthropic argues that releasing highly cyber-capable open-weight models can create irreversible misuse risk because safeguards can be removed and the models can operate privately beyond provider monitoring.²⁴

That argument is not nonsense.

There are legitimate reasons to protect extremely capable model weights.

But there is another side.

If the eventual policy becomes:

Only governments, giant vendors and companies with eight-figure security budgets may access serious cyber AI,

then we have created an interesting defensive asymmetry.

A well funded criminal organisation or intelligence service can already buy infrastructure, zero days, initial access, developers, operators and enormous quantities of model inference.

Burning millions of tokens attacking a valuable target is not a meaningful economic barrier to that class of adversary.

The small software vendor trying to audit two million lines of old C++ has a very different budget.

So does the open-source maintainer.

So does the twenty-person company.

So does the independent researcher.

That is why even organisations warning about offensive AI are simultaneously trying to expand defensive access. Anthropic’s Project Glasswing explicitly aims to distribute strong cyber capability to defenders and open source maintainers,²⁵ while OpenAI says advanced cyber capabilities should reach defenders broadly through trust based access and safeguards.²⁶

OpenAI’s response to the Hugging Face incident moved in the same direction: it added Hugging Face to its Trusted Access for Cyber program and said it was supporting their teams in using its models to improve their defenses.²

There is a difficult policy problem here.

We should treat it like one.

Not like a slogan.

What AI actually changes

AI changes economics.

That is the part I think many discussions miss.

It lowers the cost of expertise.

It lowers the cost of iteration.

It lowers the cost of analysing enormous amounts of information.

It lowers the cost of writing custom tooling.

It lowers the cost of adapting an attack after failure.

It allows one skilled operator to supervise work that previously required several specialists.

Eventually it may remove the operator from increasingly large pieces of the workflow.

That is serious.

But the defensive implication is not:

PANIC ABOUT AI.

It is:

Remove the cheap attack paths before exploiting them becomes nearly free.

Patch faster.

Reduce exposed services.

Destroy stale accounts.

Shorten credential lifetime.

Fix onboarding and offboarding.

Treat identity as infrastructure.

Segment properly.

Monitor the things that matter.

Test backups.

Audit SaaS.

Remove ancient exceptions.

Continuously validate controls.

Make the secure path easier than the insecure one.

Let red teams actually challenge architecture.

Give detection engineers time to engineer detections.

Give responders tools that reduce noise instead of generating prettier noise.

Use AI aggressively where it saves time.

Measure whether it actually saves time.

And for the love of everything holy, stop confusing buying security products with doing security.

AI is a force multiplier. Unfortunately, zero multiplied by anything is still zero.

I like AI.

A lot.

It saves me ridiculous amounts of time.

It can analyse things faster than I can.

It can automate repetitive work.

It can connect tools.

It can explain unfamiliar code.

It can help build tooling.

It can review findings.

It can find things I miss.

It can let a competent technical person operate at a scale that would have looked absurd a few years ago.

That is fantastic.

The same applies to defenders.

The same applies to attackers.

That is the deal.

But AI does not eliminate the need for technical people.

If anything, it makes good technical people more valuable because now one person who knows what they are doing can drive an enormous amount of machinery.

The dangerous combination is not:

AI + hacker.

The really dangerous combination is:

AI + competent hacker + your ten years of accumulated security debt.

And the defensive equivalent is not:

AI security product + dashboard.

It is:

AI + competent engineers + authority to actually fix things.

That last part matters.

The uncomfortable conclusion

Maybe AI eventually becomes the dominant cyber threat.

Maybe fully autonomous systems start discovering vulnerabilities, building exploit chains, compromising infrastructure and maintaining persistence at a scale no human operation could realistically match.

We are clearly moving closer to capabilities that make that scenario worth taking seriously.¹

Prepare for it.

Research it.

Model it.

Build controls for it.

Use AI defensively.

Do all of that.

Just don’t use the future to avoid fixing the present.

Because right now, the attacker with the revolutionary artificial intelligence is still very happy when it discovers that your VPN appliance is six months behind on patches.

The autonomous exploitation agent is delighted that your old service account still works.

The machine-speed credential stealer appreciates that your secret was committed to Git.

The futuristic AI malware would like to thank whoever decided the backup server should authenticate against the same compromised identity infrastructure as everything else.

And somewhere, while all of this is happening, a security steering committee is probably discussing whether employees should be allowed to use ChatGPT.

The biggest cybersecurity problem was never that attackers lacked tools.

Attackers always get better tools.

The problem is that organisations can spend ten years knowing exactly what is wrong and still somehow schedule fixing it for next quarter.

AI has not changed that.

It has simply made next quarter arrive much faster.

Ending

My point is not that CISOs are useless, governance is bullshit, architects should be fired, AI is harmless, frameworks are pointless or every company operates like this.

That would be just another stupid simplification.

My point is that cybersecurity only exists where decisions become controls, controls become implementations and implementations survive contact with reality.

Everything else is preparation.

Or paperwork.

And occasionally, very expensive theatre.

Sources / References

1. OpenAI, Responding to the next frontier of critical cyber capabilities, August 7, 2026.
https://openai.com/index/responding-next-frontier-critical-cyber-capabilities/

2. OpenAI, OpenAI and Hugging Face partner to address security incident during model evaluation, July 21, 2026, with subsequent updates.
https://openai.com/index/hugging-face-model-evaluation-security-incident/

3. Anthropic, Disrupting the first reported AI-orchestrated cyber espionage campaign, November 13, 2025.
https://www.anthropic.com/news/disrupting-AI-espionage

4. Anthropic, What we learned mapping a year’s worth of AI-enabled cyber threats, June 3, 2026.
https://www.anthropic.com/news/AI-enabled-cyber-threats-mitre-attack

5. Google Threat Intelligence Group, GTIG AI Threat Tracker: Distillation, Experimentation, and (Continued) Integration of AI for Adversarial Use, February 12, 2026.
https://cloud.google.com/blog/topics/threat-intelligence/distillation-experimentation-integration-ai-adversarial-use

6. OpenAI, Disrupting malicious uses of AI, February 25, 2026.
https://openai.com/index/disrupting-malicious-ai-uses/

7. Google Cloud / Mandiant, M-Trends 2026: Data, Insights, and Strategies From the Frontlines, March 23, 2026.
https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026

8. CISA / NSA, NSA and CISA Red and Blue Teams Share Top Ten Cybersecurity Misconfigurations, AA23-278A.
https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-278a

9. CISA, Threat Actor Leverages Compromised Account of Former Employee to Access State Government Organization, AA24-046A.
https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-046a

10. CISA et al., SVR Cyber Actors Adapt Tactics for Initial Cloud Access, AA24-057A.
https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-057a

11. Anthropic, Measuring LLMs’ impact on N-day exploits, June 8, 2026.
https://www.anthropic.com/research/n-days

12. Anthropic, Project Glasswing: An initial update, May 22, 2026.
https://www.anthropic.com/research/glasswing-initial-update

13. Microsoft, Shared responsibility in the cloud — Azure.
https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility

14. Amazon Web Services, Shared responsibility — Security Pillar.
https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/shared-responsibility.html

15. NIST, About the Risk Management Framework.
https://csrc.nist.gov/projects/risk-management/about-rmf

16. NIST, Cybersecurity Framework — Frequently Asked Questions.
https://www.nist.gov/cyberframework/faqs

17. Microsoft, Microsoft Security Copilot Security Alert Triage Agent in Microsoft Defender.
https://learn.microsoft.com/en-us/defender-xdr/security-alert-triage-agent

18. Google Cloud, RSAC ‘26: Supercharging agentic AI defense with frontline threat intelligence, March 2026.
https://cloud.google.com/blog/products/identity-security/rsac-26-supercharging-agentic-ai-defense-with-frontline-threat-intelligence

19. Anthropic, Making frontier cybersecurity capabilities available to defenders, February 20, 2026.
https://www.anthropic.com/news/claude-code-security

20. Alahmadi, Axon & Martinovic, 99% False Positives: A Qualitative Study of SOC Analysts’ Perspectives on Security Alarms, 31st USENIX Security Symposium, 2022.
https://www.usenix.org/conference/usenixsecurity22/presentation/alahmadi

21. Timur Kuran & Cass R. Sunstein, Availability Cascades and Risk Regulation, Stanford Law Review.
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=138144

22. Elizabeth Wolfe Morrison & Frances J. Milliken, Organizational Silence: A Barrier to Change and Development in a Pluralistic World, Academy of Management Review, 2000.
https://journals.aom.org/doi/10.5465/AMR.2000.3707697

23. Frances J. Milliken, Elizabeth W. Morrison & Patricia F. Hewlin, An Exploratory Study of Employee Silence: Issues that Employees Don’t Communicate Upward and Why, Journal of Management Studies, 2003.
https://onlinelibrary.wiley.com/doi/10.1111/1467-6486.00387

24. Anthropic, Our position on open-weights models, 2026.
https://www.anthropic.com/news/position-open-weights-models

25. Anthropic, Expanding Project Glasswing, June 2, 2026.
https://www.anthropic.com/news/expanding-project-glasswing

26. OpenAI, Trusted access for the next era of cyber defense, 2026.
https://openai.com/index/scaling-trusted-access-for-cyber-defense/