Black Hat 2026: AI changed the clock, not the way in

A cluster of vendor and research reports published around Black Hat USA 2026, which ran from 1 to 6 August at Mandalay Bay in Las Vegas, points at the same conclusion from several directions. Artificial intelligence is measurably accelerating both attack and defence, but it has not replaced the intrusion methods defenders already knew about. Phishing, stolen credentials, exposed infrastructure and poisoned dependencies still account for the overwhelming majority of real incidents. What has changed is how little time you have once a weakness becomes public.

The way in has not changed

The clearest counterweight to the AI headlines comes from incident response data. In its second-quarter trends report, Cisco Talos Incident Response reported that phishing was the top means of gaining initial access, appearing in over half of engagements where the entry point could be determined, up from roughly a third the previous quarter. Talos noted no AI-specific intrusion method displacing it.

The more consequential number sits alongside it. Talos recorded authentication abuse in 65 percent of engagements, up from 35 percent the previous quarter, with attackers defeating multi-factor authentication through adversary-in-the-middle proxies, session token theft, MFA fatigue, self-enrolled devices and legacy protocols that skip MFA altogether. Insufficient logging was the second most common weakness at 42 percent, and in several cases those gaps prevented investigators from establishing the initial access vector at all.

That pattern is corroborated from a different vantage point. CrowdStrike’s 2026 Threat Hunting Report, covering activity from July 2025 through June 2026, recorded monthly device code phishing attempts rising fifteenfold in the first half of 2026 and voice phishing intrusions doubling. In one case the company observed an actor move from account takeover to data theft in under five minutes.

What AI actually changed: the clock

The strongest evidence for a genuine shift is about timing, not technique. CrowdStrike reported that 88 percent of the exploitation it observed involving a publicly available proof of concept took place within 48 hours of that proof of concept being released, with some China-linked actors launching deliberate attacks inside 24 hours of disclosure.

Put that against the remediation windows defenders operate under and the squeeze becomes obvious. When CISA added three actively exploited flaws to its Known Exploited Vulnerabilities catalogue on 4 August, the shortest tier under Binding Operational Directive 26-04 gave federal agencies until 7 August to act. If you want a refresher on how those windows are calculated, our explainer on reading a CVE walks through CVSS, EPSS and KEV together.

Discovery volume is climbing alongside it. Palo Alto Networks Unit 42 published results from an autonomous vulnerability research system it calls NOVA, reporting in its frontier AI vulnerability study that the system analysed 3,915 open-source projects over two months and confirmed 14,090 vulnerabilities, of which 99.4 percent had not previously been reported and 39.7 percent scored High or Critical under CVSS 4.0. Notably, only 4 percent fell into the memory and calculation category that traditional fuzzing already handles well; the bulk were semantic and logic flaws such as broken access control, path traversal and server-side request forgery.

Unit 42 also flagged the supply-chain reach of those findings, counting 1,280 flaws in dependency packages that produced 4,141 downstream exposures, with exploitability proven from the downstream application in 2,776 of them. For anyone maintaining a vulnerability backlog, the operational reading is that prioritisation by project size or direct deployment is no longer sufficient. Where the code is used matters more.

Guardrails are not a security control

The most useful finding for anyone writing an AI usage policy came from Cisco Talos, which collected prompt logs and artefacts from threat actor endpoints running coding assistants and analysed how adversaries are using them. Talos reported that guardrails did not provide much protection, and that it encountered no sophisticated encoding or jailbreak technique. Most of the time an actor simply asserted permission and the model complied.

Talos grouped the evasions into a small set of recurring patterns: unverified ownership claims, capture-the-flag or bug bounty labelling, splitting risky work across separate sessions so no single request looked like an attack, and writing standing authorisation into persistent memory files so the framing carried across every future session. In one case an actor abandoned a model that refused and moved to an uncensored one, which completed the task without objection.

Talos was equally clear about the limits. The operator’s own skill still determined the outcome. Unsophisticated actors produced tooling that technically worked but was fragile and hard to improve, while capable operators used the same models to build considerably more effective platforms. That nuance matters, because it cuts against both the claim that AI has made everyone dangerous and the claim that nothing has changed.

Trust is the surface under attack

Several of the reports converge on a theme worth naming directly. The mechanisms being abused are the ones organisations deliberately chose to trust. Device code phishing abuses a legitimate OAuth authorisation flow rather than breaking it. Talos observed ransomware operators using legitimate remote monitoring and management software, including a trojanised MeshAgent binary and Zoho Assist, to blend malicious traffic into normal administrative activity.

The same logic runs through the software supply chain. CrowdStrike reported that 87 percent of identified software registry threats in the first half of 2026 involved malicious npm packages, and that one actor poisoned 131 AI framework packages. That is the same category of problem seen in the recent npm worm that reached packages in the keyv family, where the malicious release carried valid build provenance because it passed through the project’s own legitimate release pipeline. A signature confirmed where the code came from, not that it was safe.

Reading vendor research carefully

One caveat belongs in any honest summary of conference week. Almost all of this research was published by companies that sell security products, and several reports arrive alongside a product launch addressing the exact problem they describe. That does not make the findings wrong. Incident response data and telemetry at this scale are genuinely hard to get anywhere else, and the technical detail in these reports is checkable.

It does mean the framing deserves separate scrutiny from the data. A useful habit is to read the methodology and the sample first, treat percentage changes as being about the vendor’s own visibility rather than the whole world, and note where a stated conclusion happens to point at something for sale. On this set, the findings that survive that filter best are the ones corroborated independently: exploitation speed, phishing prevalence and identity abuse all show up in more than one dataset from more than one vendor.

Why it matters

If you are an individual reader, none of this changes the advice that was already true, but it does raise the stakes on one specific habit. The attacks that work still start with a message asking you to approve something, and the newest variant asks you to enter a code on a real, genuine login page, which means the page looking legitimate is no longer evidence of anything. Treat any code or approval prompt you did not personally initiate as a stop signal, and prefer passkeys or a hardware key over app-based approval where the option exists. Our Password Studio tools run entirely in your browser if you need to check or strengthen credentials.

For organisations, the decision this research argues for is not a new product. It is closing the gap between disclosure and action. If exploitation reliably lands inside 48 hours and your emergency patch path takes a fortnight, the mitigation is a process change and an escalation route, not more scanning. The second decision is logging: Talos could not always determine how attackers got in because retention was too short, and no amount of detection tooling recovers evidence that was never kept. Third, if your teams are already using AI coding assistants, the policy that matters is workflow-level visibility, because provider guardrails demonstrably do not hold.

For practitioners, the most actionable items are narrow. Restrict the OAuth device authorisation flow through Conditional Access unless a specific use case requires it, and exclude those cases explicitly. Hunt for unauthorised remote monitoring agents installed as services, since that is now a routine ransomware access method rather than an unusual one. Extend log retention to at least 90 days and forward logs off-device so they survive tampering. And treat build provenance as an integrity signal about origin, not an assurance about content.

Follow the news feed for developments, or read the wider vulnerability management collection for the underlying practice.

Last verified: 7 August 2026. Figures reflect the reports as published; several are drawn from vendor telemetry and describe that vendor’s own visibility rather than the whole threat landscape.