The threat model changed while the vendors were still writing datasheets
In September 2026 Anthropic published a 150-plus-page threat intelligence report walking through the misuse of its Claude models it had disrupted over the previous eight months. The specifics are worth sitting with. Attackers used the models to rebuild malware so it would slip past antivirus detection. One operation ran 4,700 fake dating-app personas. Another cloned an activist's writing style to infiltrate his contacts. A group in Yemen used a coding model to build guidance software for a rocket, then came back for help after the test flight failed. A consultant built a spy agency a system meant to watch 25 million phone lines. All of this was done with models at or below the Opus tier that shipped that year.
I keep coming back to one line from Cyber Magazine's coverage of the defensive market the same week: AI in cybersecurity has moved from buzzword to backbone across SOC operations, endpoint protection, and cloud security, because frontier models are getting good at finding and exploiting vulnerabilities. The magazine called the coming wave a "vulnpocalypse." I don't love the word, but the underlying point is right. The question a lot of security leaders are still framing as "should we bring AI into our operations" has already been answered by the other side. They brought it. The only open question is whether your defenses assume that or not.
This is written for the people who have to make that call with a real budget and a real team, not a research lab. We run infrastructure and security engagements for banking, telecom, and critical-infrastructure clients, and the pattern is the same everywhere right now: a pile of vendor decks all claiming an AI engine, a security team that is already underwater, and a board asking why the company isn't "using AI" yet. Here is how we cut through that.
What AI is genuinely good at inside a security operations center
Start with the honest wins, because there are real ones. The place large language models earn their keep in a SOC today is the work that is high-volume, text-heavy, and judgment-light: the first ninety seconds of an investigation, not the decision at the end of it.
Alert triage and enrichment is the strongest case. An analyst opening a SIEM alert normally spends the first several minutes gathering context: what is this host, who owns it, is this IP known, what happened around it, has this fired before. A model wired into your SIEM (Microsoft Sentinel, Splunk, Elastic, whatever you run) and your asset inventory can assemble that context automatically and write a plain-language summary of what the alert appears to be. That is genuinely useful. It shortens mean time to triage and it lowers the cognitive tax on tier-one analysts who are staring at hundreds of alerts a shift.
Detection engineering is the second. Writing and tuning detection content, translating a threat report into a draft Sigma or KQL rule, spotting where two rules overlap, generating test cases for a detection before it goes live, these are all tasks where a model that knows your data schema saves an engineer real hours. We have used this to generate first-draft detection logic at a scale a small team could never write by hand, then had a human review and tune every rule before it shipped. The leverage is in the draft, not the deployment.
Log and incident summarization rounds out the list. Turning a noisy investigation timeline into a readable incident narrative, or condensing a week of a control's telemetry into something a manager can act on, is exactly the kind of dull, valuable work that gets skipped when people are busy. AI does it well and does it consistently.
Notice what these have in common. They accelerate a human who stays in the loop. None of them is the model deciding, on its own, to isolate a production host at 3 a.m.
Where it quietly fails, and where that failure lands on you
The failure modes are less discussed than the demos, so they deserve more room here.
The first is confident fabrication. A model asked to identify indicators of compromise from a log sample will sometimes invent an IP address, a hash, or a CVE number that looks plausible and does not exist. In a chat window that is a curiosity. Fed into an automated block list or a threat-intel feed, it is an outage waiting to happen, or worse, a false sense that you have contained something you have not.
The second is prompt injection, and this is the one that keeps me up. The moment you point an AI agent at untrusted input, and security telemetry is full of untrusted input, an attacker can write instructions into the very data your agent is reading. A crafted log line, a malicious ticket, a filename designed to be interpreted as a command. If your triage agent has any ability to act, retrieve secrets, or call other tools, you have handed the attacker a new path straight through your automation. We treat any agent that reads attacker-influenced data and can also take action as a system that needs the same threat modeling as an internet-facing application, because that is what it is.
The third is data leakage. Security telemetry is some of the most sensitive data a company holds. It describes your network, your users, your controls, and your gaps. Piping it into a third-party model without knowing where it is processed, whether it is retained, and whether it trains the next version is a compliance problem and a confidentiality problem at once. For our regulated clients this is frequently the single line item that decides which tool is even allowed in the building.
The fourth is over-automation. Every vendor demo ends with the AI closing the ticket by itself. Autonomous response against a determined attacker, or against a false positive, can take down more than it protects. The Anthropic report is the tell here: attackers are already rebuilding malware specifically to defeat detection. A response pipeline that trusts its own detection blindly is exactly the pipeline that gets played.
A buying test for anything labelled "AI-powered"
Almost every security product on the market now claims an AI capability. Most of the claims are thin. When we evaluate one for a client, we run it against a short list of questions that cut past the marketing quickly. If a vendor cannot answer these plainly, that is the answer.
QuestionWhat a good answer looks likeRed flag
Does it show its evidence?
Every conclusion links back to the specific logs, events, or data it reasoned from.
A verdict with no traceable basis, "trust the score."
Where does our data go?
Processed in your tenant or a named region; clear retention and no-training guarantees in writing.
Vague "enterprise-grade security," no data-residency answer.
Is a human in the loop for action?
AI recommends and enriches; response actions require analyst approval, or are scoped and reversible.
Fully autonomous containment on by default, hard to constrain.
Can we audit its decisions?
Every AI-assisted decision is logged with inputs and outputs, exportable for ISO 27001 or SOC 2 evidence.
No decision log, nothing to show an assessor.
What is the measured uplift?
A real before-and-after on detection rate, false positives, or triage time against your baseline.
Benchmarks only from the vendor's own lab, on the vendor's own data.
How does it fail?
The vendor can describe the failure modes and the guardrails without flinching.
"It doesn't really fail," or no answer at all.
The point of the test is not to reject AI tooling. It is to buy the tools that treat the model as a component inside a controlled system, and to walk away from the ones selling the model as magic. In practice the good products all look similar under the hood: the AI drafts, enriches, and prioritizes; the system around it enforces where the human decides and logs everything for later.
Where AI actually belongs in the triage pipeline
It helps to be concrete about placement. The diagram below is the model we use when we design an AI-assisted SOC workflow for a client. AI does the heavy lifting on the left, where the work is context-gathering and prioritization. The response actions on the right stay behind a human decision point, and every step writes to an audit log so the whole chain can be reconstructed for an incident review or an auditor.
The shape matters more than the tools. Anything that reads attacker-controlled data and drafts a conclusion is fine to automate, because a human still reads the draft. Anything that changes the state of production, blocks, isolates, disables an account, sits behind a person until you have measured the false-positive rate long enough to trust a narrow, reversible slice of it.
Defending against attacks that now move at machine speed
The defensive tooling question is only half of it. The other half is that the attacks themselves are changing, and the Anthropic report is a preview of what is already normal, not a forecast.
Social engineering is the first thing to get worse. Persona cloning at the scale of thousands of accounts, and writing-style imitation good enough to fool someone's own contacts, means phishing and business email compromise stop having the tells your awareness training was built around. The grammar is clean now. The context is right. Defenses have to shift from "spot the bad email" toward identity and verification controls: phishing-resistant multi-factor authentication, out-of-band confirmation for payment and access changes, and least-privilege so a compromised account is contained by design rather than by the user noticing something felt off.
Faster vulnerability discovery is the second. If frontier models compress the time between a vulnerability being disclosed and being exploited, then your exposure window is the thing that kills you. That puts unglamorous disciplines back at the center: a real asset inventory, a patch cadence you actually meet, external attack-surface management, and hardened baselines. We build a lot of systems to CIS Benchmarks and provision hardened, air-gapped-capable images precisely because a machine-speed attacker punishes configuration drift far more than a human one does.
Detection engineering is the third. If malware is being rebuilt on demand to evade signatures, signature-based and naive machine-learning detection degrade in value. Behavioral detection, identity analytics, and detections written around attacker techniques rather than specific artifacts hold up better. This is where defensive AI and defensive discipline meet: use the model to help you write and maintain far more behavioral detection content than you could by hand, map it to a framework like MITRE ATT&CK, and keep a human owning the quality bar.
None of this is exotic. It is the NIST Cybersecurity Framework functions done seriously: know what you have, protect it with modern identity controls, detect on behavior, and rehearse your response. AI raises the stakes on all of them. It does not replace any of them.
You still have to prove it to an auditor
There is a governance layer under all of this that is easy to skip and expensive to skip. When you introduce AI into security operations you have created a new system that makes or influences decisions, and every serious framework is going to ask you to account for it.
Under ISO 27001, that AI tooling is part of your information security management system, with the same expectations for access control, logging, and supplier assurance as anything else. Under SOC 2, if the model touches a control that supports your report, you need evidence of how it operates and where its data goes. Under PCI-DSS, anything near the cardholder data environment inherits the full weight of the standard, model or not. The NIST CSF gives you a clean way to map where the AI sits across identify, protect, detect, respond, and recover, and to show you thought about it deliberately.
Two governance problems show up in nearly every engagement. The first is shadow AI: analysts and engineers pasting logs, config, and incident detail into consumer chatbots because it is faster, with no policy and no visibility. That is a data-loss channel you are not monitoring. The fix is a sanctioned, controlled tool plus a plain policy, not a ban that everyone quietly ignores. The second is decision logging. If an AI-assisted system contributed to a call during an incident, you need to be able to reconstruct what it saw and what it recommended. Bolt that logging in from the start, because reconstructing it after an incident is not fun for anyone.
For clients operating in the UAE and the wider region, data residency sharpens all of this. Where your security telemetry is processed is not only a confidentiality question, it is increasingly a regulatory one, and it frequently narrows the field of acceptable tools before performance is even on the table.
How Aydahwa Enterprise can help
We help organizations adopt AI in their security operations the way it should be adopted: as a controlled component that accelerates a capable team, with the governance and evidence to survive an audit and the architecture to survive an attacker. Our background is hands-on. We have spent 25-plus years across UNIX, Linux, Windows, cloud, and network design, and our security work is grounded in the standards that matter, ISO 27001, PCI-DSS, SOC 2, the NIST Cybersecurity Framework, and CIS Benchmarks, backed by Microsoft Cybersecurity Architect Expert certification and delivery experience in banking, telecom, and critical national infrastructure.
In practice that means we can assess where AI genuinely fits your SOC and where it would just add risk, run the buying test above against the tools on your shortlist, design an AI-assisted triage pipeline with the human decision points and audit logging in the right places, harden the environment those tools run in, and build the governance so your ISO 27001, SOC 2, or PCI-DSS assessor sees a system that was designed on purpose. For teams that want to know where they stand first, our free cyber security self-assessment and cybersecurity readiness checklist are a fast way to find the gaps before an attacker or an auditor does.
If you are weighing an AI security investment, migrating security workloads to the cloud, or you simply need a second set of experienced eyes on a vendor's claims, our cybersecurity, cloud services, and IT support teams can help. Get in touch and tell us what you are trying to protect. We will tell you plainly what we would do.
