SecureWorld News

Garbage In, Breach Out: Why Your AI Is Only as Good as Its Sensors

chesteravey@outlook.com (Chester Avey) — Mon, 10 Aug 2026 18:40:50 GMT

Most companies putting AI to work in their operations spend all their energy on the model. They compare vendors, tune prompts, and argue about which platform to standardize on. Far fewer stop to ask a simpler question: where are the data actually coming from?

For a lot of AI-driven monitoring and automation, the answer is a physical sensor sitting on a wall, a pipe, or a factory floor. If that sensor's wrong, the AI is wrong right along with it—confidently and at scale. As these systems shift from drawing charts to making the call themselves, that quiet dependency turns into a real exposure.

The ceiling under every model

An AI system can only reason about the data it's given. A model watching a building's air quality, a plant's emissions, or a cold chain's temperature has no independent way of knowing whether a reading is real. It takes the number and acts on it, throttling ventilation or signing off on a shipment. That makes the humble sensor the real foundation of the whole thing.

Security teams are waking up to this, and SecureWorld has looked at how AI can make or break IoT security, with the outcome coming down almost entirely to the quality of what you feed it. There are also more of these foundations every year. IoT Analytics expects the number of connected IoT devices to reach 21.1 billion by the end of 2025, with a growing share of them piping data straight into analytics and automated systems. The idea here is old and unglamorous: garbage in, garbage out. What's changed is the blast radius. A bad reading used to mean a misleading chart, but now, with a model driving the response, it means a wrong action taken instantly, with no human in the loop.

When the data are wrong on purpose

Some bad input is deliberate. A sensor is a way in, and an attacker who can shape what it reports can shape everything downstream. Feed a monitoring model a slow drip of doctored readings and you can train it to see an abnormal state as normal, so the alert never fires when it really matters. The U.S. National Institute of Standards and Technology (NIST) maps out these techniques in its work on adversarial machine learning, including the data poisoning attacks that corrupt a model through the very information it learns from and leans on.

The tricky part is that an attack like this hardly looks like an attack. There's no breach notification, no ransom note, just a system confidently making the wrong call because someone quietly rearranged its picture of the world through the devices it trusts. These make appealing targets precisely because nobody's really watching them, and because the payoff is quiet influence over a decision instead of a noisy smash-and-grab. If you're leaning on AI to run operations, that's the kind of failure mode worth losing sleep over.

When the data is wrong by accident

Most bad sensor data isn't an attack at all, just cheap or aging hardware doing what cheap or aging hardware does. Take gas detection, one of the most common jobs that sensors get handed in commercial and industrial buildings. The devices that track oxygen, carbon monoxide, or air quality lose sensitivity as they age. They get slower to respond, and they start reporting numbers that look plausible but aren't right. This is the most dangerous kind of wrong, because nothing obvious flags it. A model can't tell a confident accurate reading from a confident inaccurate one, and it's got no gut instinct telling it a number feels off.

Here comes the point where the choice of hardware stops being a line on a purchase order and turns into a data-integrity decision. The better makers of electrochemical gas sensors put every unit through defined accuracy and response testing before it ships, because their customers are building life-safety and decision-critical instruments on top of them. A sensor that holds its calibration for years is one a model can keep trusting. One that quietly drifts out of spec becomes a slow leak of bad data into every decision it touches, and the AI will defend that decision as confidently as it defends a good one.

The sensors nobody owns

There's one more problem that has nothing to do with the data and everything to do with who's watching it. Sensors may be installed by facilities teams, safety managers, and outside contractors, but regularly go unlogged in the IT or security asset inventory. They then sit on the network, feed data into systems that make real decisions, and answer to nobody in particular.

You can't secure, patch, or sanity-check a device you don't know exists, and you definitely can't judge whether its readings have earned the trust your AI is putting in them. Every unmanaged sensor is a small act of blind faith wired into the foundation, and most operations are running more of them than anyone's ever counted.

Closing the gap

The fix isn't complicated, though it does mean treating sensor data as something you earn rather than assume. Start with an inventory, so you know what's deployed, where it sits, and what shape it's in. Fold the physical layer into your risk thinking like any other part of the stack, with owners, review dates, and a replacement plan. Lean toward devices built to recognized security and performance standards, something regulators are pushing through programs like the U.S. Cyber Trust Mark.

Choose your sensing hardware with the same care you'd give the model itself, because the smartest AI in your operation is still taking a physical device at its word. Choose the right sensor and everything above it has a shot at being right too. The alternative is likely to mean all you've really done is automate a mistake.

The Endpoint Blind Spot: Key Takeaways from Mobile Security Report

CamS@secureworld.io (Cam Sivesind) — Fri, 07 Aug 2026 12:51:00 GMT

While corporate endpoints like laptops and servers usually receive the lion's share of security investment, smartphones have quietly turned into one of the most targeted entry points for enterprise compromise.

The 2026 Mobile Security Report from cybersecurity provider Pradeo highlights this exact shift. Drawing from aggregated field data across protected enterprise devices over the past 12 months, the report outlines a stark reality: mobile threats are growing in both volume and technical sophistication, while traditional security frameworks lag behind.

According to ENISA (The European Union Agency for Cybersecurity) data cited in the report, mobile attacks now represent the leading incident vector in Europe, accounting for 42% of all identified cyberattacks. Pradeo's own telemetry paints a picture of constant pressure on individual devices.

360 security events per device: The average professional smartphone encountered 360 security events per year (up from 342 in 2023).
120 moderate and 10 severe threats: Devices faced an average of 120 moderate threats requiring admin attention, and 10 severe, confirmed attacks requiring immediate blocking per year.
Application load explosions: The average professional device now hosts 370 installed applications, 80% of which are personal or unapproved apps introduced via Bring Your Own Device (BYOD) environments or unmanaged downloads.
Phishing click rates: Devices face an average of 288 phishing attempts annually across SMS, email, and messaging channels. Users click on these malicious links 45% of the time.

The primary mobile threat vectors, according to the report's data, is applications at 67%, network/fishing at 30%, and OS level issues at 3%.

There are four core trends shaping mobile security.

1. Applications remain the #1 attack vector

Applications account for 67% of all mobile security incidents. Threats are no longer limited to explicit malware; vulnerabilities in legitimate apps are a massive liability. Pradeo found that an average application contains seven vulnerabilities, with 18% of apps being vulnerable to code injection.

Furthermore, official app stores no longer offer absolute safety. Attacks like SparkCat demonstrated how malicious SDKs embedded in legitimate apps can slip past Google Play and Apple App Store controls. Another campaign uncovered 77 malicious applications on Google Play that racked up more than 19 million downloads before being removed.

2. The evolution of mobile phishing: quishing & smishing

Phishing remains the starting point for nearly 60% of successful European cyberattacks.

Smishing industrialization: SMS phishing makes up 55% of all mobile phishing. Global groups like Smishing Triad targeted more than 121 countries using 194,000+ domains, while attackers in the UK deployed localized "SMS blasters" (fake 2G base stations) to broadcast fraudulent texts directly to nearby phones.
Quishing (QR code phishing): Attackers are increasingly shifting to QR codes embedded in PDFs or physical spaces (like parking meters) to bypass traditional email filters. Advanced campaigns now use "split" or "layered" QR codes—fragmenting images so automated scanners miss them, while the mobile camera easily assembles the link.

3. "Legal" data leaks and intrusive apps

A major blind spot identified in the report is intrusive applications: legitimate, widely-used consumer apps (e.g., social, shopping, or fitness apps) that collect excessive background data.

42% of applications on a typical professional mobile device are classified as intrusive.
More than 60% of mobile apps exhibit excessive data exploitation practices.

Through embedded advertising and analytics SDKs, these apps gather location metrics and device identifiers that can be bought and pieced together. High-profile investigations highlighted how location data from fitness apps (like Strava) or retail apps exposed the sensitive movements of journalists, military personnel, and world leaders without any traditional system breach.

4. Artificial intelligence: dual-use disruption

AI is accelerating both offense and defense.

Offense: ENISA reports more than 80% of phishing emails incorporate AI techniques to generate highly convincing, context-aware lures. Attackers are also leveraging local AI models in malware—such as the PromptLock ransomware—to dynamically adapt behavior on-device and evade API tracking.
Defense: Machine learning algorithms allow defense tools to correlate micro-anomalies across applications, network traffic, and permissions to identify stealthy, zero-day behaviors before damage occurs.

Looking ahead, Pradeo outlines key operational shifts for enterprise environments.

Phone numbers as critical single points of failure: As organizations phase out passwords, phone numbers are becoming primary identity keys. This increases susceptibility to SIM-swapping attacks designed to intercept 2FA codes and authentication alerts.
The mobile Zero Trust blind spot: Traditional Zero Trust architecture focuses heavily on corporate laptops and network perimeters. Without continuous device-level telemetry on smartphones, mobile devices will remain an open back door into corporate identity systems.
Regulatory pressure: Regulations like GDPR, NIS2, DORA, and the Cyber Resilience Act mean data leakage via third-party mobile SDKs or unencrypted connections can constitute direct compliance breaches—even without a classic cyberattack.

Which organizations are most at risk?

Does industry type matter? Yes and no.

Public Sector & Critical Infrastructure: These entities remain priority targets. Because central IT networks in government and defense are heavily fortified, state-sponsored and opportunistic actors are shifting toward targeting the personal mobile usage of employees (messaging apps, location data, transit usage) to gain secondary access.
Financial Services & Healthcare: Heavily targeted due to direct monetization pathways (via specialized banking trojans like Herodotus or Crocodilus) and strict regulatory frameworks like DORA.
Every BYOD-friendly enterprise: Industry aside, any organization that allows employees to access corporate email, Slack, or databases on personal smartphones faces equal exposure. The mix of personal app density (370 apps/device) with enterprise access creates an unmanaged attack surface.

To address the growing risks outlined in the report, CISOs and IT teams should focus on four core operational steps.

1. Shift from manual review to automated MTD

With hundreds of events per device annually, manual triage is impossible. Organizations need a dedicated Mobile Threat Defense (MTD) solution that automates threat detection and remediation in real time at the device level.

2. Continuous application vetting and SDK visibility

Do not assume store approval equals safety. Implement automated security auditing for both internal enterprise apps and third-party commercial applications installed on devices to catch rogue SDKs, excessive permissions, and hidden data exfiltration.

3. Integrate mobile telemetry into your SOC

Mobile security shouldn't exist in a silo. Feed mobile device health, network connection events, and application behaviors directly into your Security Operations Center (SOC) and SIEM/XDR platforms to ensure mobile endpoints are factored into threat hunting.

4. Implement on-device phishing defenses

Because mobile phishing spans SMS, messaging apps, QR codes, and email, traditional email gateways aren't enough. Deploy on-device protections capable of inspecting network traffic and blocking malicious URLs regardless of which application delivered the link.

RELATED: New data from YouMail show U.S. consumers received 4.35 billion robocalls in July. It's the highest monthly total since July 2025, and volume is now more than 15% above the multi-year low hit last October. More than 2 billion of July's robocalls were telemarketing or scams, now making up nearly half of all robocall traffic.

A few standouts from the index:

Telemarketing and scam calls jumped nearly 6% in July alone, now representing almost half of all robocalls. Legitimate notifications and payment reminders declined.
Scams using fake "pre-approved personal loan" messages generated more than 40 million calls in July, spoofed across thousands of different numbers.

The Board Meeting Is Working. Why the Governance Underneath It Isn't

CamS@secureworld.io (Cam Sivesind) — Thu, 06 Aug 2026 16:03:50 GMT

Security leaders have gotten very good at showing up. They present quarterly, on schedule, deck in hand. They've learned the room. They've developed the vocabulary. By nearly every process measure, CISO-board engagement has never looked more mature.

New research from Pulse Security AI, released this week at Black Hat, documents what's happening underneath that cadence—and the picture is significantly less comfortable.

The CISO–Board Communication Gap (free download, no form), drawn from a 42-respondent survey, 20-plus in-depth interviews with sitting and former CISOs, and two moderated workshops with roughly 22 security executives— 80-plus senior practitioners in total—is one of the most specific examinations of the CISO-board relationship published to date. Its central finding can be stated plainly: security leaders are presenting more than ever, and boards are understanding less than both sides think.

"For a decade, the industry has told security leaders to communicate better with the board," said Mike Armistead, CEO and co-founder of Pulse Security AI. "Our data says the problem is upstream of that. You cannot report status against a baseline that was never set."

That sentence lands differently once you see the data behind it.

Finding 1: The confidence gap is measurable—and wider than most CISOs admit

The most arresting number in the report: only 12.5% of security leaders are "very confident" their board accurately understands the true state of the program after a presentation; 41% are "somewhat confident"; and 38% are neutral or mixed.

Read those numbers from the other direction: nearly nine in 10 security leaders walk out of their board presentation without strong confidence that the people responsible for cybersecurity governance just received an accurate picture of the program.

The report's framing of this is precise: "Boards think they understand their security posture and what it means for the business. The CISOs presenting to them aren't so sure—and the cycle continues largely unchanged."

The conventional diagnosis here is that CISOs need better communication skills—sharper storytelling, fewer technical terms, more business framing. The Pulse Security data complicates that narrative directly. "Translating technical findings into business language" ranks as both a top time burden and a top desired improvement in the survey. But when respondents described what they actually wanted, they didn't ask for coaching. They asked for simpler data delivery, better frameworks, and clearer context. The communication problem is real. Its solution, the research argues, isn't coaching; it's structural.

Finding 2: The baseline was never set

Here is the structural problem: 55% of boards have never formally defined their organization's cyber risk appetite. Another 27% have defined it only qualitatively. That means just 18% of boards have established anything resembling a quantitative baseline—and only 16% successfully use a quantified risk model like FAIR. A mere 3% present dollar-figure risk estimates.

Without an agreed baseline, the CISO has no fixed reference point against which to report status. "Good" and "bad" are relative terms. Relative to what? In the absence of an answer the organization has actually defined, something fills the vacuum—and the research documents exactly what that something is.

Roughly 70% of security leaders say board members bring external information into the room: third-party security ratings, press coverage of peer incidents, findings from vendors who have a financial interest in the board's conclusions. And 42% of leaders have had to defend a commercial security score in a board meeting in the past 12 months.

One CISO quoted in the report put the problem as sharply as it can be put: "That score I have to defend is decided by two product managers—usually junior—who have never held a serious security role."

The risk appetite vacuum isn't just a governance gap. It actively distorts the conversation. When there's no agreed baseline, the board imports one, and that imported baseline is often whatever score a vendor decided to assign, or whatever breach just made the news, or whatever a board member's friend at another company said over dinner. The CISO is then in the position of defending against external noise rather than reporting against an internal standard. That is not a communication problem. That is a governance design problem.

Finding 3: Board prep is an operational tax on an already stretched team

Seventy-one percent of security leaders spend 10 or more hours preparing for each board or audit-committee presentation—effectively one to two full working days, every quarter, on top of everything else the security function is managing. Twenty-nine percent spend 21 to 40 hours. Thirty-nine percent involve four or more contributors per presentation cycle.

When the research asked what actually consumes that time, the answers weren't about narrative craft. They were about raw material assembly: creating visualizations and slides, gathering data from multiple disconnected security tools, and translating technical findings into business language.

One CISO at a global technology firm made the operational cost explicit: "Every hour spent pulling, analyzing, and translating data from a dozen disconnected tools is an hour not spent on actual security work."

This is the preparation tax, and it compounds in two ways. First, it is a direct drain on security leadership capacity; time senior practitioners spend on slide assembly is time they aren't spending on threat analysis, program strategy, or team development. Second, fragmented preparation produces fragmented output. When board metrics are assembled by hand from disparate sources every quarter rather than drawn from a single, maintained source of truth, the presentation is structurally less likely to convey a coherent picture of business risk and program effectiveness. The preparation problem and the confidence problem are connected.

When the research asked what would most reduce the burden, leaders named three things: automated synthesis of threats and vulnerabilities, automated data aggregation, and better tools to translate findings into business impact. The theme across all three is the same: the manual labor of assembly needs to be solved at the system level, not at the individual CISO's level.

Finding 4: Governance runs on instinct, not instrumentation

Beyond the three headline findings, the survey surfaced a cluster of governance dynamics that reinforce the same picture.

Half of boards are not making cyber risk decisions. Fifty percent of boards made no explicit decision to accept, mitigate, or transfer cyber risk in the past year. Risk governance is supposed to produce decisions. A board that convenes quarterly for security updates and never makes a formal risk disposition is a board that is being briefed, not one that is governing.

Nearly half of CISOs have no venue for candor. Forty-eight percent of security leaders have no private executive-session access to the board or audit committee—no forum where they can raise unresolved concerns, flag disagreements with management, or deliver an honest assessment that isn't filtered through a full room of stakeholders. The things most worth saying in a board conversation about security risk are often the things that require a smaller, more private setting to say.

Personal liability shapes what gets said. Thirty-three percent of security leaders say their own legal exposure—a post-SolarWinds reality that the SEC's disclosure enforcement has only intensified—influences what they tell the board and how they tell it. This is not a character flaw; it is a rational response to a genuine legal environment. But it means that one in three CISOs is making editorial decisions about board communication based partly on personal legal risk, not purely on what the board needs to know.

Most risk characterization remains qualitative. Forty-nine percent of leaders characterize risk severity using qualitative categories—high, medium, low. Twenty-one percent use maturity levels, and 18% use risk scores or ratings. Only 3% present dollar-figure estimates. Given that boards operate in the language of financial exposure and business consequence, the predominance of qualitative risk characterization helps explain the persistent confidence gap. Qualitative labels require the board to supply the translation into business terms on their own—and they often supply it using whatever external information they bring into the room.

Board time is split evenly between past and future, which means half the meeting is spent on things that can't be changed. Forty-nine percent of board content looks backward at past events; 51% addresses future strategy. Nearly a quarter of leaders have no predefined threshold for board-level escalation. When an incident occurs, those leaders are negotiating in real time about what to tell the board and when.

Finding 5: Trust is recoverable—and a breach shouldn't be the trigger

There is a genuinely hopeful signal in the research, and it comes from an uncomfortable source. Among security leaders who have navigated a material security incident, 53% report that board trust in the security team increased afterward.

The report's explanation for this is important: "A real event forces a concrete, shared understanding of risk that quarterly decks rarely achieve." When an incident happens, the abstract becomes tangible. The board members who brought third-party scores and news coverage into the room now have a real event—one their organization experienced—against which to understand what security risk actually means in practice. The CISO who has been presenting qualitative categories now has a specific, concrete case to walk through. Credibility, built through crisis, that quarterly presentations rarely establish.

A corporate director at a Fortune 100 company made the point plainly in the research: "Performing a tabletop exercise with our security team established their credibility in a way a presentation never could."

That observation points toward the most actionable finding in the entire report: the conditions that build board trust after a breach—shared, concrete experience, visible decision-making under pressure, a common frame of reference for what risk actually looks like—can be created deliberately, before an incident, through tabletop exercises that include board communication as an explicit component.

The research closes with five practices drawn from the leaders who reported the highest board trust and the lowest preparation burden. They are worth quoting directly.

Define risk appetite before you report against it. With 55% of boards operating without a defined cyber risk appetite, status has no baseline. Agree on thresholds—even qualitative ones—so every update maps to a decision the board has already made.

Lead with business consequence, not control inventory. Frame each item as an effect on revenue, resilience, or obligation—then let the technical detail sit in an appendix.

Automate data aggregation so prep isn't a fire drill. Seventy-one percent spend 10-plus hours per cycle, most of it gathering and reconciling data by hand. Standardize a single source for board metrics so each cycle is a refresh, not a rebuild.

Agree on escalation thresholds while it's calm. Nearly a quarter of leaders have no predefined trigger for board-level escalation. Set clear disclosure thresholds in advance so an incident produces clarity, not confusion.

Secure a recurring private session with the board. Forty-eight percent have no executive-session access and thus no venue for candor. A standing private session gives leaders room to raise unresolved risk without a full audience.

The CISO quoted at the close of the research captures the spirit of all five: "The best board conversations I've had weren't about the tools. They were about what we'd decided to accept, and what we hadn't—agreed on long before the meeting."

The research was conducted across organizations ranging from less than 2,000 employees (38% of respondents) to more than 10,000 (44%), with industries spanning technology, financial services, healthcare, and manufacturing. The problems it documents are not scale-dependent. A small organization's CISO presenting to a three-person audit committee faces the same baseline-definition problem as a Fortune 500 CISO presenting to a full board—arguably a harder version of it, given fewer resources for dedicated board-prep support.

For enterprise security leaders, the report's most direct implication is that communication coaching and presentation training—the industry's conventional prescription for the CISO-board problem—address a symptom rather than the disease. Coaching helps a CISO articulate a message more clearly, but it does not solve the absence of an agreed risk appetite to report against. It does not reduce the 10-plus hours of manual data assembly that precede every presentation. It does not give the CISO a private room in which to say things that can't be said in a full meeting. The structural problems require structural solutions.

For mid-market and smaller organizations, the finding about external noise is particularly acute. When a board has no formal risk appetite and the CISO has no private executive-session access, the most influential input into board-level security perception is whatever information board members encounter between quarterly meetings: vendor marketing, news coverage of breaches at peer organizations, or a commercial security rating that was, as one CISO noted, decided by junior product managers. Small organizations with lean security functions are least equipped to push back against that noise and most exposed to its consequences.

For boards themselves—and for the growing number of board members who carry explicit cybersecurity oversight responsibilities under SEC disclosure rules—the research offers a specific and actionable challenge: the absence of a defined cyber risk appetite is not a neutral omission. It is the primary structural condition that makes meaningful security governance impossible. A board cannot evaluate whether its organization's security posture is adequate without having first defined what "adequate" means. Setting that baseline—even a qualitative one—is the governance decision that makes every subsequent presentation more informative and every CISO conversation more honest.

Armistead put the organizational challenge in operational terms: "You cannot assemble a clear picture of the business when the underlying information lives in a dozen disconnected places. Security leaders have earned the room. What they need now is the operating layer underneath it."

Coordinated Cyberattack Taps into Minnesota's Water Systems

CamS@secureworld.io (Cam Sivesind) — Wed, 05 Aug 2026 19:23:19 GMT

The water came out of the tap on Monday morning. That's the most important sentence in this story, and, depending on where you sit professionally, either a reassurance or a warning about how close the outcome could have been.

Between the nights of Sunday, July 26, and Monday, July 27, 2026, a coordinated cyberattack struck the operational technology (OT) of more than 30 Minnesota community water systems simultaneously. By Monday morning, city officials across the state discovered outages and disruptions to some of their water utilities' automated operating controls.

Four communities have been publicly confirmed as affected: Braham, Plymouth, South St. Paul, and Maple Plain. The remaining 26-plus systems are classified as nonpublic by Minnesota IT Services (MNIT), per state agency policy on active investigations.

The attack is now known to be part of a wider campaign affecting seven U.S. states. Cyberattacks targeting municipal water systems have been reported in at least seven states this week, prompting the FBI and the Environmental Protection Agency to warn utilities nationwide that hackers are trying to disrupt critical water infrastructure.

And a Minnesota law enforcement memo has since revealed what the attackers were actually trying to accomplish: not just knocking systems offline, but contaminating the drinking water supply by dropping pipe pressure below safe levels.

What actually happened: city by city

The attack targeted programmable logic controllers (PLCs) and human-machine interfaces (HMIs)—the devices that water operators use to remotely monitor and control pumps, wells, pressure, and chemical treatment systems. Here's what the operational picture looked like on the ground in the four confirmed cities.

Braham (population ~1,700)

Unknown malware shut down operating controls to the water plant, leaving the water tower unable to be filled for more than an hour. The incident disabled operating controls, causing a well and the plant to go offline for less than two hours. Water stored in the city's tower continued supplying residents, and officials said water quality and safety were not affected. To protect their drinking water, Braham officials simply shut their whole computer system down, cutting off external access to it.

City Administrator Kevin Stahl summed up the broader problem bluntly: "We take our water and sewer infrastructure pretty seriously. And we thought all of our bases were covered, but bad actors, they also have a plan."

Plymouth (population ~80,000)

The affected assets were equipment connected over cellular communications at two water towers and multiple lift stations. The city IT division disconnected that equipment from the network to stop the attack and prevent retargeting while it was reconfigured. Plymouth also had to switch to manual operations.

South St. Paul (population ~21,000)

A cybersecurity incident affected technology supporting parts of its water utility system. Some automated controls were affected, but the city said drinking water remained safe and water and wastewater operations continued normally.

Maple Plain (population ~1,800)

Maple Plain declared a local state of emergency to expedite the city's response to the attack, which affected certain automated control functions in its water utility system.

Braham officials confirmed that at least four other communities beyond the publicly named cities were attacked "with the same result."

How close did this come to contaminating the water?

This is the question that matters most to the public, and the answer deserves precision.

No city reported that an attacker had changed chemical levels, contaminated the water supply, or caused a prolonged interruption of service. No boil-water advisories were issued. The Minnesota Department of Health, working alongside MNIT, confirmed it was not aware of any active requests from Minnesota cities for residents to modify their drinking water usage.

But the attackers' stated goal was not simply disruption. A Minnesota law enforcement memo obtained by TechTimes reveals that the hackers intended to contaminate drinking water by dropping pipe pressure. The significance of that detail is technical and serious. A water tower is a system's pressure reservoir and its buffer—the thing that keeps taps flowing and, more importantly, keeps the distribution system pressurized while pumps are down. Sustained loss of the ability to refill a tower is precisely the condition that produces the pressure drop, back-siphonage, and precautionary boil advisory sequence. Braham caught it in time. Elsewhere in the country, according to U.S. officials briefed on the wider campaign, some utilities did issue boil-water notices and took systems offline.

The water was safe in Minnesota. It was a narrow margin, built primarily on stored water in towers, quick operator response, and the ability to switch to manual procedures before the attacks achieved their intended effect. It was not a comfortable margin.

The wider campaign: seven states, one playbook

In a July 30th warning, the FBI and EPA said water and wastewater utilities in at least seven states had reported incidents since July 27 involving internet-facing Rockwell Automation/Allen-Bradley MicroLogix 1100 and 1400 PLCs.

The FBI described attackers targeting OT devices including Rockwell Automation/Allen-Bradley PLCs. "After remotely accessing internet-facing devices, the actors changed the IP addresses and passwords, resulting in a loss of monitoring and control functionality," the FBI said.

The playbook is consistent and simple: find water utility industrial controllers directly exposed to the internet, often with default or unchanged credentials, and take control of them. This is not a sophisticated zero-day campaign. It is a campaign of opportunistic exploitation against a sector that has historically deprioritized cybersecurity investment, connected its operational technology to the internet for remote management convenience, and often lacks the staff or budget to maintain basic hygiene on those systems.

The FBI is now providing defenders with a list of steps to harden these critical systems, starting with "disconnecting PLCs from the public-facing internet."

Is Iran truly to blame?

Attribution is preliminary. The official position from both state and federal agencies is that the investigation is ongoing and conclusions remain subject to change. That caveat is genuine; early attribution in industrial control system incidents has been revised before, and investigators have also noted the possibility that a threat actor deliberately mimicked Iranian tradecraft to inflame tensions during an already active geopolitical conflict. Still, the weight of intelligence and technical evidence is pointing in one direction.

U.S. intelligence agencies have assessed that Iran was likely behind a coordinated cyberattack on more than 30 municipal water systems in Minnesota this week, according to several U.S. officials, as a five-month-old military conflict between the United States and Iran threatens to escalate.

The suspected operational group is CyberAv3ngers, a known Iranian state-linked threat actor. First identified around 2020, CyberAv3ngers is widely believed to be linked to Iran's Islamic Revolutionary Guard Corps (IRGC), specifically its Cyber-Electronic Command division (IRGC-CEC). Its first sustained campaign came in November 2023, when it compromised PLCs at the Municipal Water Authority of Aliquippa, Pennsylvania, defacing them with anti-Israel messages. Tenable said CyberAv3ngers compromised at least 75 Unitronics Vision Series PLCs across the U.S., Israel, the United Kingdom, and Ireland as part of that campaign. The U.S. Treasury Department sanctioned the group in February 2024.

The July 22, 2026, update to CISA Advisory AA26-097A expanded the scope of observed PLC exploitation to include Schneider Electric and Siemens devices alongside Rockwell Automation, documented project file exfiltration for the first time, and added detection guidance for manipulation of reusable code modules embedded in PLC programs. CVE-2021-22681 (CVSS 9.8), a critical authentication bypass in Rockwell Automation Logix controllers with no available vendor patch, was added to CISA's Known Exploited Vulnerabilities catalog in March 2026 following confirmed exploitation by Iranian-affiliated actors.

That update was issued four days before the Minnesota attacks began. Three days before the Minnesota attacks, the Handala threat group—attributed to Iran's Ministry of Intelligence—issued explicit warnings that U.S. water, electricity, and transportation networks would be targeted. The warning was public. The attack followed on schedule.

Tenable's Scott Caveza, senior staff research engineer, was direct about the technical alignment: "The tactics mirror the group's known capabilities: exploiting internet-facing PLCs and native vendor engineering software to bypass authentication and extract project files. The timing of the attack, which occurred days after an update to a CISA advisory warning of active Iranian targeting of U.S. water sector PLCs, is also indicative of a possible Iranian connection. Unlike financially motivated actors whose attacks might spillover into OT environments, Iranian state-directed groups like CyberAv3ngers specifically target the OT environment. They invest in understanding PLC protocols, use the same vendor engineering tools as legitimate operators, and build purpose-specific capabilities."

The geopolitical context adds weight. The U.S. entered open armed conflict with Iran on February 28, 2026. A ceasefire took effect in April. Iranian cyber operations against U.S. critical infrastructure have continued and escalated since. The Minnesota attacks were not a random probe. They were timed, targeted, and consistent with a multi-year campaign that the U.S. government has been formally tracking, warning about, and—until now—watching happen to smaller utilities in other states.

The government response: state and federal

MNIT activated its statewide incident response capabilities immediately upon learning of the attacks and coordinated across a broad interagency coalition. MNIT is working closely with the Minnesota Department of Public Safety, Bureau of Criminal Apprehension's Minnesota Fusion Center, Minnesota Department of Health, Minnesota Pollution Control Agency, U.S. Cybersecurity and Infrastructure Security Agency (CISA), U.S. Environmental Protection Agency, Federal Bureau of Investigation, and local water utilities throughout the response.

Minnesota's Chief Information Security Officer, John Israel, issued a statement that acknowledged both the severity of the attack and the value of the state's preparedness: "Cyberattacks against critical infrastructure require a coordinated, whole-of-government response. MNIT is working side by side with our partners to share intelligence, support affected communities, and help utilities restore operations safely while strengthening defenses against future attacks. This incident demonstrates why Minnesota has invested in strong cybersecurity capabilities and partnerships. Our response worked as intended, enabling agencies at every level of government to rapidly coordinate, contain the incident, and help prevent more serious impacts to critical services."

CISA confirmed it is observing a significant increase in threat actors targeting PLCs. Acting Director Nick Anderson confirmed the agency's active involvement in the investigation and coordination with water sector utilities nationwide.

The FBI and EPA issued a joint public service announcement on July 30—FBI PSA I-073026-PSA—confirming the seven-state scope of the campaign and issuing specific technical guidance to utilities: disconnect internet-facing PLCs, place them behind secure gateways and firewalls, require strong authentication, and limit inter-device communications to authorized sources through access control lists.

At the political level, the attack broke into open confrontation on July 31. David Sacks, White House AI and tech adviser, used the attacks to frame the broader national security case for AI investment and infrastructure hardening. Congressional members from Minnesota's delegation have called for emergency federal funding for municipal water utility cybersecurity, particularly for small and rural communities.

The structural problem the attacks exposed

Braham's mayor, Nate George, stated the problem as clearly as any policy document could: "Minnesota's local governments are expected to defend essential systems against foreign adversaries and sophisticated criminals." A city of 1,700 people, with a public works team of a handful of employees and a technology budget sized for routine operations, is now expected to defend its water supply against the Iranian Revolutionary Guard Corps.

Most confirmed cases in the Minnesota cyberattack involved technology used to remotely monitor and control water system equipment, including programmable logic controllers. Many of these PLCs were connected directly to the internet—not through secure VPNs or industrial firewalls, but via cellular modems purchased for the convenience of remote monitoring and never hardened after installation. The attack didn't require a sophisticated zero-day exploit; it required finding equipment that was connected to the internet with default or weak credentials, which automated scanning tools do in minutes.

John Bruggeman, virtual CISO at CBTS, put the stakes plainly: "Attackers are targeting operational technology environments that are publicly exposed, and the concern is not just exposed information, but whether the attackers can gain control of the technology—before security teams can contain it."

The gap between what small municipalities can afford to do and what nation-state adversaries are capable of is not a gap that any individual city can close on its own. Minnesota's Whole-of-State Cybersecurity Program—the framework that allowed MNIT to rapidly coordinate response across state, local, tribal, and federal partners—is one of the more mature examples of how states can try to bridge it. It worked in this instance. It did not prevent the attack.

What this means for security leaders

The OT/IT convergence risk is no longer theoretical. Water utilities connected their operational technology to the internet for legitimate operational reasons: remote monitoring, reduced site visits, faster response times. That connectivity created the attack surface that made this campaign possible. Any organization running industrial control systems, building automation, or other OT environments that have internet-facing components for remote access should be reviewing those exposures immediately.

The CISA advisory was a countdown, not a warning. CISA Advisory AA26-097A was updated on July 22, four days before the attacks. It named the threat actors, described the tactics, and listed the specific devices being targeted. Utilities that read that advisory and disconnected their internet-facing PLCs before July 26 were protected; those that didn't were hit. Intelligence-driven action has a short window, and this incident documents in operational terms what it looks like when that window closes.

CVE-2021-22681 has no patch and is being actively exploited. The critical authentication bypass in Rockwell Automation Logix controllers—CVSS 9.8, no available vendor patch—was added to CISA's Known Exploited Vulnerabilities catalog in March 2026. If your organization runs Rockwell Automation Allen-Bradley PLCs, specifically MicroLogix 1100 and 1400 series, and those devices have any internet-facing exposure, that is the immediate operational priority.

Geopolitical conflict has a direct OT security timeline. The February 2026 U.S.-Iran military conflict, the April ceasefire, and the continued escalation of Iranian cyber operations are not background context—they are a predictive signal for defenders. When the U.S. enters a conflict with a nation-state that has a documented history of targeting water utilities, electric grids, and transportation networks, the attack surface for those sectors expands immediately and measurably.

What this means for the public

The water was safe. That is true and it matters. The successful use of stored water, manual procedures, and contingency plans prevented a more serious emergency.

But the stated goal of the attack was contamination, not disruption. The mechanism—dropping pipe pressure to create conditions for back-siphonage—is a real and documented risk. The attacks in other states did produce boil-water advisories. Minnesota avoided that outcome by approximately 90 minutes in Braham's case, and through manual intervention by public works employees who were, by luck and good instinct, in a position to respond quickly.

The public should understand that the systems delivering water to their taps are increasingly networked, that the operators of those systems are often small municipal departments with limited cybersecurity resources, and that nation-state adversaries are actively targeting those systems with the specific goal of reaching the water supply. That is not a reason for alarm—Braham's operators demonstrated that manual procedures work. It is a reason to follow local emergency management guidance, know how to reach your local water utility, and understand that "no boil-water advisory has been issued" and "water is safe" are statements that can change.

For residents in communities affected by this attack or future ones: follow your local utility's guidance. If an advisory is issued, boil water before drinking, cooking, or brushing teeth. Do not assume the faucet is safe if your utility is communicating about a water system incident.

The DockSec Series, Part 5: Adoption, Scoring, and Measuring Container Posture

Advait Patel — Tue, 04 Aug 2026 12:34:01 GMT

Over four articles, we have moved from why container security needs a reasoning layer, through DockSec's architecture, hands-on scanning, and CI/CD enforcement. This final article steps back to the program level: how the security score actually works, which metrics are worth tracking, and how an OWASP-governed, bring-your-own-model tool fits into a real security practice.

The security score, demystified

DockSec reduces a scan to a single 0-100 number with a rating from POOR to EXCELLENT. A single number is powerful—it fits in a dashboard, trends over time, and gives non-specialists something to rally around—but only if you understand what it does and does not mean.

There are two ways the score is produced. When a language model is configured, it can generate a holistic score from a summary of the findings. When no model is used—in --scan-only mode or with --skip-ai-scoring—a local, deterministic calculator produces the score instead. For metrics you intend to trend over time, the local score is usually the better choice precisely because it is deterministic: the same inputs always yield the same number, so a change in the score reflects a change in your container, not variance in a model's judgment.

The local score is a weighted blend of three axes:

Dockerfile quality, derived from Hadolint lint results
Vulnerability burden, a severity-weighted deduction over the normalized findings—criticals cost far more than lows
Configuration, derived by reading the Dockerfile directly and deducting for concrete, high-signal misconfigurations: running as root, credential-looking environment variables, unpinned or latest base images, missing health checks, sensitive exposed ports, ADD over COPY, and privileged flags

Two design decisions are worth calling out because they reflect hard-won lessons. First, when no image was scanned and there is genuinely no vulnerability data, the vulnerabilities axis is not silently treated as a perfect score; its weight is redistributed to the axes that were actually measured, so the number is not flattered by data that does not exist. But when findings do exist—including Compose misconfigurations with no image scan—that axis always counts. Second, hardcoded credentials cap the overall score outright.

A plaintext secret baked into an image is not the kind of issue that should be averaged into a comfortable middle; if DockSec finds one, the score reflects it as the serious problem it is.

What the score is good for, and what it is not

Use the score as a trend line and a conversation starter, not as an absolute verdict. A move from 45 to 70 across a quarter is a real, legible signal that posture is improving, and it is something you can put in front of leadership. An absolute "we are at 82, therefore we are secure" is not a claim the score can support—no single number can. This is exactly why enforcement in CI is gated on --fail-on severity thresholds and structured findings rather than on the score: the gate needs a precise, defensible condition, while the score is for direction and communication. Use each for what it is good at.

Metrics worth tracking

Beyond the headline score, a container security program benefits from a small set of metrics that DockSec's output feeds directly:

Critical and high finding counts over time, per image—the clearest measure of whether remediation is outpacing new disclosures.
New findings per build, from baseline mode. This is the leading indicator: if new findings trend toward zero, your gate is holding and the team has internalized secure defaults.
Time-to-remediate, measured as how long a given finding persists across the baseline before it disappears. Long-lived findings are where debt accumulates.
Base image freshness. Docker Scout's updated-base-image suggestion is a recurring, high-leverage fix; a stale base is a systemic issue that individual CVE counts obscure.
Coverage. The percentage of images and Compose services actually being scanned. A great score on 10% of your fleet is not a great program.

The --json output and the JSON and CSV reports make all of these straightforward to extract into whatever dashboard you already use. The point is not to track everything; it is to track the few numbers that change behavior.

Adopting DockSec across a team

Technology adoption fails on process far more often than on capability. A few principles make DockSec stick.

Start with visibility, not enforcement. As covered in Part 4, run in observe mode first, surface findings through SARIF, and let the team see the landscape before anything blocks a build. Trust is built by showing, not by gating on day one.

Meet developers in their existing tools. SARIF puts findings inline on pull requests, and the plain-English AI remediation means a developer does not need to become a CVE expert to act. Lowering the expertise required is how you scale security past the security team.

Respect data boundaries explicitly. For regulated or air-gapped teams, the ability to run the entire pipeline locally—scanning plus AI remediation via Ollama, or scan-only with no model at all—is not a nice-to-have, it is the difference between adoption and rejection. Make that story clear to the teams for whom it matters.

Ratchet, do not big-bang. Baseline mode exists so you can turn on enforcement without a revolt. Accept today's debt, block what is new, and tighten over time. Incremental and reversible beats comprehensive and abandoned every time.

Why open source and OWASP governance matter here

Governance belongs in a technical series because, for a security tool, it is a security property and not just a licensing footnote.

DockSec is an OWASP Lab Project under the MIT license: no commercial tier withholding features, no telemetry, no lock-in. You can read exactly what it does, run it entirely within your own boundary, and choose your own model provider. The relevant comparison is not against the open-source scanners DockSec builds on, but against commercial platforms that offer comparable AI remediation only by hosting your image data on their infrastructure. DockSec delivers that class of remediation while leaving both your data and your model choice under your control.

Where the project is heading

The roadmap pushes toward broader coverage and deeper CI integration—Kubernetes manifest scanning, software-bill-of-materials (SBOM) output, an offline advisory database, and further parity with sibling OWASP tooling. Because the architecture is built around a single results contract and a provider abstraction, these extensions are additive rather than disruptive—and because the project is open source, the roadmap is genuinely open to contribution.

Closing the loop

We began this series with a simple observation: container security does not fail for lack of scanners, it fails at the last mile, where a list of findings has to become a change someone actually makes. Everything DockSec does—the AI remediation layer, the single security score, the SARIF and baseline machinery, the bring-your-own-model design—serves that last mile.

Detection was never the hard part. Turning detection into action, at the scale of every Dockerfile and every build, is. That is the problem worth solving, and it is the one DockSec exists to solve.

This is the fifth article in a five-part series. Read the others here:

Part 4: Shift-Left—Gating, SARIF, and Baselines in CI/CD
Part 3: Hands-On Scanning—Dockerfiles, Images, and Compose
Part 2: Inside DockSec—Architecture and Pipeline
Part 1: Why Container Security Needs an AI Layer

Alert Fatigue Was the Old Problem. Decision Latency Is the New One

Tushar Badlani — Mon, 03 Aug 2026 15:14:03 GMT

"The SOC was built to process alerts at human speed. The adversary just stopped waiting."

For years, the defining problem in security operations was volume. Too many alerts, too many false positives, too few analysts. The industry built an entire generation of tooling around that problem: SIEM platforms to aggregate, SOAR platforms to automate playbooks, detection engineering to tune signal-to-noise. The assumption underneath all of it was that if we could just surface the right alerts to the right people fast enough, humans would make the right calls.

That assumption held as long as attackers operated at human speed. It does not hold anymore.

In July 2026, Sysdig's Threat Research Team published their analysis of JadePuffer, the first documented fully agentic ransomware operation. An LLM agent ran the entire kill chain autonomously: reconnaissance, credential theft, lateral movement, persistence, privilege escalation, encryption, database destruction, and ransom note delivery. The agent executed over 600 distinct, purposeful payloads in a compressed window. The detail that defines the new era: when a login attempt failed, the agent recovered and found a working alternative in 31 seconds. No human operator was in the loop on the attacker's side. The machine adapted faster than most SOC teams can open a ticket.

The CrowdStrike 2026 Global Threat Report found that average eCrime breakout time fell to 29 minutes in 2025, a 65% increase in speed over the prior year, with the fastest observed breakout ever recorded at 27 seconds. The IBM 2025 Cost of a Data Breach Report put the global average breach cost at $4.44 million, with organizations using AI and automation extensively saving approximately $1.9 million per breach and cutting the breach lifecycle by roughly 80 days. The economics are clear. Speed is not an optimization. It is the variable that determines whether a security event stays an incident or becomes a breach.

We have watched this shift from inside production security programs. Tushar Badlani is a Security Specialist at Figma, focused on Customer Trust and Third-Party Risk. Mohit Bansal is a Senior Manager of Security Engineering at Webflow. Between us, we have spent years building the detection pipelines, SOAR integrations, and triage workflows that enterprises depend on. The pattern we keep seeing is the same: the detection works, the enrichment works, the alert fires on time. And then the response stalls, because a human has to decide what to do next, and the adversary does not wait for that decision.

The real vulnerability is not the alert. It is the gap after it

The alert fatigue numbers are real and well documented. The Vectra AI 2026 State of Threat Detection report surveyed 1,450 practitioners and found an average of 2,992 alerts per day, with 63% going unaddressed. The SANS 2025 Detection and Response Survey reported that 73% of teams name false positives as their top detection challenge. Tines' Voice of the SOC Analyst report found 71% analyst burnout, with 64% considering leaving within a year.

Those numbers describe a human endurance failure. Analysts are overwhelmed, desensitized, burned out. That is serious, and it has been serious for years. But it is not the failure mode that JadePuffer exploits.

What JadePuffer exploits is an architecture failure. The time between "the alert fires" and "an authorized action executes" is where the adversary operates. In a traditional SOC workflow, that gap includes alert triage, context gathering across multiple consoles, severity assessment, escalation, approval, and finally action. The Microsoft and Omdia State of the SOC 2026 report found that teams manage an average of 10.9 consoles. Each console switch, each enrichment query, each escalation conversation adds seconds and minutes to a loop that the adversary is completing in seconds.

The distinction matters because the two failure modes demand different solutions. Alert fatigue is addressed by better detection engineering: tuning rules, reducing false positives, improving signal quality. Decision latency is addressed by redesigning the response architecture itself, specifically by removing the human from the path where speed is decisive and keeping them where judgment is decisive.

Anthropic's disclosure of campaign GTG-1002 in November 2025 made the asymmetry concrete. The threat actor leveraged AI to execute 80 to 90 percent of tactical operations independently, at physically impossible request rates, with human intervention required only at roughly four to six critical decision points per campaign across approximately 30 targets. The attacker's OODA loop, the Observe-Orient-Decide-Act cycle that fighter pilot John Boyd formalized for competitive engagements, was cycling in seconds. The defender's loop was cycling in minutes to hours.

When the adversary's full loop is faster than your single "Decide" step, you have already lost the engagement. That is decision latency. And no amount of better detection fixes it.

The reversibility principle

The instinct when confronting this speed gap is to automate everything. Let the machine match the machine. Remove the human entirely. That instinct is understandable, and it is wrong.

Not every security action is the same. Enriching an alert with threat intelligence context is a low-risk, instantly reversible operation. Isolating a production host from the network is high-impact and, depending on what that host serves, potentially irreversible in its business consequences. Revoking a credential is somewhere in between, depending on what the credential protects and whether re-issuance is automated.

The teams that are navigating this well tend to classify their response actions not by severity tier or alert type, but by reversibility. The question is not "how serious is this alert?" The question is "if the automated response is wrong, how hard is it to undo?"

A Microsoft Security Copilot study (randomized controlled trial, 167 analysts, published November 2025) found that agent-augmented analysts achieved up to 6.5 times as many true positives per analyst-minute and a 77% improvement in verdict accuracy. They spent 53% more time on genuinely malicious signals. The gains came not from removing the human, but from removing the human from the parts of the loop where speed matters more than judgment, and redirecting human attention to the parts where judgment matters more than speed.

This is the architectural principle that resolves the tension between "automate for speed" and "keep humans in control." Reversible, high-volume actions go to the machine: alert triage, multi-source enrichment, investigation pivots, detection rule drafting, log correlation, threat intelligence lookups. Irreversible, high-blast-radius actions stay with a human: credential revocation for privileged accounts, production host isolation, network segment blocking, data deletion, configuration changes that affect availability.

The common thread in our operational experience is that the distinction between reversible and irreversible actions is not always obvious upfront, and the classification has to be maintained as the environment changes. A credential revocation that is trivially reversible in an environment with automated re-issuance is effectively irreversible in an environment where re-provisioning takes a support ticket and two business days. The reversibility of an action is a property of the environment, not just the action itself.

Gartner has labeled standalone SOAR "obsolete before plateau" on high total cost of ownership, with capabilities folding into SIEM, XDR, and agentic platforms. The 2025 Hype Cycle for Security Operations placed "AI SOC Agents" at just 1 to 5 percent market penetration. The tooling is early. But the architectural pattern, classifying actions by reversibility and granting autonomous authority only for the reversible majority, does not require any specific vendor. It requires a design decision.

Earning autonomy, not granting it

The practical challenge is that most organizations cannot flip a switch from "human approves everything" to "machine acts autonomously on reversible actions." The trust has to be earned, and the earning has to be measurable.

The pattern that works in practice is staged rollout with confidence thresholds. An AI triage agent starts in shadow mode: it processes every alert and generates a recommendation, but takes no action. The team compares the agent's recommendations against their own decisions over a defined period. When the agent's accuracy on a specific alert type crosses a predefined threshold, verified against the team's own ground truth, it earns autonomous authority for that alert type only.

This is not theoretical. CrowdStrike reports that their Charlotte AI Detection Triage saves more than 40 hours per week with greater than 98% triage accuracy. Microsoft's Security Alert Triage Agent reports up to 78% faster triage. Those numbers are vendor-reported and should be treated accordingly, but the directional signal is consistent: supervised automation on well-defined alert types produces reliable results faster than human-only workflows.

The risk of staged automation is not that it moves too fast. The risk is that it erodes analyst skill. If the machine handles 80% of triage, the 20% that reaches human analysts needs to include a representative sample of the machine-triaged alerts, not just the hardest cases. Periodic raw-alert work prevents the kind of automation complacency where analysts lose the ability to evaluate what the machine is doing. The teams that maintain this discipline tend to catch drift earlier.

Our security programs have invested heavily in SOAR pipeline automation, SIEM log correlation, and threat alert enrichment with AI-assisted triage. The operational lesson is consistent: the automation that works is the automation that was measured before it was trusted, that operates within explicit boundaries, and that produces a full audit trail of its reasoning. The automation that fails is the automation that was deployed under time pressure with implicit boundaries and no mechanism for the team to verify its decisions after the fact.

The broader industry is converging on the same conclusion. A Forbes Tech Council piece from March 2026 framed it sharply: "Human-in-the-loop is not a feature. It is a power structure." Exercising irreversible authority before uncertainty has a clear owner is a design failure, not a model failure. But the inverse is also true: forcing a human gate in front of machine-speed reversible actions hands the tempo advantage back to the attacker. The shift is from human-in-the-loop as a blanket policy to human-on-the-loop as a guardrailed architecture, with the guardrails drawn by reversibility.

Where this leaves us

Decision latency is not a new metric to add to the dashboard. It is a reframe of what the SOC is actually defending against. The threat model has shifted from "we might miss the alert" to "we will see the alert and not act fast enough." The difference is architectural, not operational.

The tools to address decision latency exist. Action classification by reversibility is not experimental. Staged automation with confidence thresholds is not a research problem. Runtime audit trails of agent reasoning are achievable with current infrastructure. What is missing is the organizational decision to redesign the response architecture around the speed of the adversary rather than the comfort level of the approval chain.

The teams that will weather the next generation of autonomous threats are the ones measuring decision latency today, classifying their response actions by reversibility, and earning autonomous authority through measured performance rather than granting it by default. The adversary is not going to slow down. The only variable the defender controls is how fast the response loop closes. And right now, for most organizations, the slowest agent in the room is still human.

This article was co-written by Mohit Bansal.

Second Lab, Same Failure: Anthropic Confirms an AI Containment Breach

drewt@secureworld.io (Drew Todd) — Fri, 31 Jul 2026 17:51:08 GMT

Last week, SecureWorld covered OpenAI's disclosure that its own AI models had broken out of a sealed test environment and breached Hugging Face's production infrastructure. That incident was framed, understandably, as a singular event—a strange and alarming first. It no longer looks singular.

On July 30, Anthropic disclosed that it had found three of its own containment failures, uncovered through a review it launched specifically in response to the OpenAI news. Two frontier labs, in the span of about a week, independently found the same category of failure inside their cybersecurity evaluation environments. For an industry that has spent years debating AI containment in the abstract, that repetition is the story.

What Anthropic found

Anthropic's review covered 141,006 evaluation runs in which a Claude model could plausibly have reached the internet. Three incidents surfaced, involving six total runs and three different models: Claude Opus 4.7, Claude Mythos 5, and an unnamed internal research prototype not intended for public release. The earliest dated back to April.

In each case, Claude was assigned a capture-the-flag exercise—a standard method for assessing offensive cyber capability—in which the model is told a piece of secret information has been hidden on another machine and instructed to break in and retrieve it. Anthropic's evaluation prompt told Claude, in every instance, that its environment was sealed off from the internet. Due to a misconfiguration on the evaluation partner's side, that wasn't true.

Anthropic's own account of what followed is direct: “Claude did what capture-the-flag exercises train cyber experts to do,” the company wrote, framing the model's behavior as a rational response to the task it had been given, not a deviation from it. Believing the exercise was fictional, Claude treated the real systems it encountered as fair game, and used basic techniques—weak passwords, unauthenticated endpoints, exposed debug pages—to reach them.

Two of the three organizations affected had not detected the activity before Anthropic reached out. The company is still working to contact the third.

A different failure than Hugging Face—but not a reassuring one

It's worth being precise about what didn't happen here, because the distinction from the OpenAI incident matters. Collin Hogue-Spears, Senior Director of Solution Management at Black Duck, drew the line clearly: OpenAI's models exploited an unknown vulnerability to escape an environment that was genuinely sealed. Anthropic's models did not break out of anything—a misconfiguration left the door open in front of them, and they walked through it believing it was part of the game.

"That is the difference from the OpenAI incident a week earlier,” Hogue-Spears said. "OpenAI's models picked a lock, exploiting an unknown flaw to break out of a sealed environment; Anthropic's found the door already open." Anthropic, for its part, reported no evidence that any run attempted to self-exfiltrate or deliberately escape its environment—the models pursued their assigned task, not an agenda of their own.

That distinction doesn't make the incident less instructive. If anything, it narrows the lesson to something harder to engineer around: a model doesn't need a novel exploit to cause real damage. It just needs a false premise and an open path.

The pattern practitioners are naming

Security leaders reacting to the disclosure converged on a common thesis, even while approaching it from different angles. Ram Varadarajan, CEO of Acalvio, framed it as a problem with testing itself: verification can show that a system fails, he argued, but it can never certify in advance that a model will never attempt something from inside a given boundary. "What's passed for verification is tests coming back clean," Varadarajan said, "closer to a clean bill of health than an actual autopsy."

Diana Kelley, CISO at Noma Security, put the operational implication plainly: "Don't rely on intent, rely on controls." She noted that Anthropic's disclosure is now the second time in two weeks a leading AI lab has reported a containment failure in an evaluation environment—and argued that as organizations give AI agents more autonomous, longer-running tasks, security has to extend beyond model safety training into operational controls: isolation, least privilege, identity-aware authorization, runtime enforcement, and kill switches. An agent solving a benchmark and one completing a business task, she said, should face the same rule—it should never have more access than the task requires.

Nathaniel Jones, SVP of Global Threat Intelligence at Darktrace, pushed the framing further. Giving an AI agent a legitimate goal, he said, doesn't guarantee legitimate methods; a model may pursue exactly the objective it was given while using approaches its developers never anticipated. "The model did not simply break the rules," Jones said. "It found the gaps between them. That is exactly what effective attackers do, whether in cybersecurity, sport, or any other environment." His conclusion: static guardrails and a read on a model's stated intent aren't sufficient. Security teams need visibility into how agents behave over time—which resources they touch, how that behavior shifts, and whether an objective is being pursued in an unexpected way.

Where it gets more specific: not all three models behaved the same

Anthropic's own analysis is careful not to treat the three incidents as identical, and the differences between them are arguably the most consequential detail in the disclosure.

In the most serious of the three, involving Opus 4.7, the model's own reasoning recognized across all four runs that the systems it had reached were real, and in two of those runs, it explicitly reasoned that the real company must therefore be part of the exercise. None of the four runs stopped. That incident produced the most serious impact: application and infrastructure credentials, and access to a production database. In a separate incident, Mythos 5 built and published a genuine malicious Python package to solve its assigned challenge, briefly exposing it to the open internet, where it was downloaded and run on 15 real systems before PyPI removed it. The third model, an internal research prototype, independently concluded partway through its run that its target had no connection to its assigned scenario, recognized the target was real, and stopped on its own.

Anthropic frames the difference across the three as suggestive, though not conclusive, of more capable models responding more appropriately—while noting plainly that whether an action counts as aligned or harmful in these cases came down entirely to what the model believed about its own situation, not a change in its underlying goal.

Hogue-Spears drew the sharpest version of the takeaway from that spread of outcomes: "One of the three models stopped on its own after realizing its target was real. Opus 4.7 did not. A safety design that depends on which model stops is not a design. A model's own judgment is not a containment control. Put the boundary in the infrastructure."

What this means for the industry right now

Anthropic's disclosure lands at a moment when Washington is already responding to the category of risk the OpenAI incident surfaced. The bipartisan AI Kill Switch Act, introduced in Congress on July 23 by Reps. Ted Lieu (D-Calif.) and Nathaniel Moran (R-Texas), would require AI developers to maintain the technical ability to throttle, suspend, or shut down their models, with authority vested in the U.S. Department of Homeland Security working alongside the Commerce secretary and the director of national intelligence. That bill was drafted in direct response to a single incident. It now has a second one to point to.

Whether that changes the bill's trajectory is a separate question from whether it should. What's harder to dispute is that evaluation-environment security is no longer a purely internal QA concern for AI labs; it's becoming a governance question, with a legislative response already in motion before the second data point even arrived.

Anthropic has committed to third-party review of the incidents with METR, plans to release a redacted transcript of the PyPI incident, and says it is expanding continuous monitoring of its own evaluation transcripts. Those are reasonable next steps. But the practitioners weighing in on this disclosure are, almost uniformly, making a narrower and more durable point: whatever a model believes about its situation cannot be the thing standing between it and a real system. That has to be an infrastructure decision, not a hope.

Quantum Security, Part 2: Beyond the Algorithms—the Real Challenges of PQC Migration

Neha Srivastava — Thu, 30 Jul 2026 13:22:02 GMT

Every few weeks, I hear the same message from peers and industry leaders: "PQC migration is just replacing RSA and ECC with ML-KEM and ML-DSA. It should be easier than a cloud migration."

In practice, it's rarely that simple.

Working in this space, I've found that the biggest challenges don't come from the algorithms, they come from deployment. In one project, a firmware update pipeline that had worked reliably for years began failing after introducing a PQC signature scheme. The implementation was correct, but the larger signatures exceeded assumptions built into an older network path. Days of troubleshooting led back to one unexpected cause: message size.

The algorithms are well understood. NIST has standardized ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205), with additional standards continuing to evolve. The real challenge is understanding everything PQC impacts once it reaches production.

This article focuses on those practical realities, from performance and interoperability to hybrid deployments, organizational complexity, and migration trade-offs.

The key takeaway: PQC is not an algorithm swap. It's a reassessment of the performance, size, latency, interoperability, and operational assumptions that have shaped cryptographic systems for the past two decades.

1. Security vs. performance

Every PQC algorithm buys quantum resistance by giving up compactness, and the size difference is not cosmetic:

Key takeaways from the comparison:

ML-DSA (Dilithium) is the primary replacement for RSA and ECDSA, offering strong performance but signatures that are roughly 50× larger, impacting bandwidth-sensitive and high-frequency signing workloads.
SLH-DSA (SPHINCS+) provides conservative, hash-based security, but its 7.8–50 KB signatures make it unsuitable for environments with limited bandwidth or storage.
ML-KEM (Kyber) delivers fast key exchange, but its public keys and ciphertexts are significantly larger than classical alternatives like X25519.
FN-DSA (Falcon) addresses signature size constraints but introduces greater implementation complexity due to its floating-point arithmetic requirements.

There is no universally "best" PQC algorithm.

Every choice is a trade-off between security, performance, signature size, bandwidth, latency, and implementation complexity. Selecting an algorithm simply because it is the default recommendation without evaluating your application's traffic patterns and operational constraints is a recipe for deployment problems.

2. Security vs. bandwidth (network efficiency)

Independent, real-world data backs this up: Cloudflare has reported that a hybrid X25519+ML-KEM-768 handshake adds roughly 2.3 KB and a median latency of 10-20 milliseconds compared to classical key exchange. That sounds trivial on a data-center backbone. It is not trivial once you leave one.

TLS handshakes grow enough to exceed single-packet size in some configurations, which introduces fragmentation and the retransmission overhead that comes with it.
Fragmentation shows up as latency that looks like a network problem, not a cryptography problem, which is exactly why it's hard to diagnose without knowing to look for it.
Bandwidth-constrained environments feel this first: satellite links, cellular backhaul in the field, industrial control networks, and legacy WAN links sized for classical handshake overhead.
Middleboxes matter too. Load balancers, proxies, and network appliances that inspect or terminate TLS were often built with assumptions about maximum certificate and handshake size that PQC quietly violates.

As of early 2026, Cloudflare reported that only around 1.8% of TLS 1.3 connections it observes use post-quantum key exchange, a useful reality check on how early we still are in real-world deployment, even with standards finalized for more than a year.

3. Performance vs. resource usage (embedded and constrained devices)

While PQC performs well on modern servers, embedded and IoT devices face challenges.

Trade-offs include:

Higher CPU utilization
More RAM and flash storage
Greater power consumption
Longer execution times on constrained hardware

Some devices may require hardware upgrades or cryptographic offloading.

4. Cost vs. future readiness

Migrating to PQC is an enterprise-wide investment, and the costs are broader than most initial scopes capture:

Cryptographic discovery and inventory across applications, infrastructure, and third-party dependencies, often a decade or more of accumulated systems.
Software updates across every affected application and service.
Hardware replacement for constrained devices that can't run PQC as-is.
Vendor coordination, since you almost certainly don't control every cryptographic dependency in your stack, your vendors do, and their timelines become your timeline.
Employee training, because PQC introduces failure modes and operational patterns most security and infrastructure staff haven't worked with before.
Testing and certification, particularly in regulated industries where cryptographic changes trigger re-certification.

5. Standardization vs. agility

Standards are still evolving, HQC's draft standard lands in early 2026 with finalization in 2027, and more signature schemes are in development. That's thorough, but it means the ground can shift under a multi-year plan. Crypto-agility is the fix: design systems so swapping an algorithm is a configuration change, not a re-architecture.

6. Technology vs. organization

The least airtime, the most schedule slippage. A real migration touches security and PKI teams, infrastructure and DevOps, procurement and vendors, legal and compliance, and every business unit running cryptography someone first has to find. Regulatory pressure is accelerating this: Executive Order 14412, issued in June 2026, mandates an accelerated federal PQC migration timeline with compliance flowing down through contractors—a preview of what's likely coming to commercial sectors.

The honest conclusion

This is an optimization problem, not an upgrade. You're balancing security against performance, bandwidth against resistance, cost against risk, standardization against agility, technology against organizational capacity, and where you land depends on your systems and risk tolerance.

Start with the unglamorous work: a real cryptographic inventory, performance tests against actual use cases, and procurement, legal, and infrastructure in the room now.

The algorithms were the easy part. The trade-offs are the real project.

Next in this series (Part 3), I'll cover why hybrid cryptography was supposed to be the safe choice. It's often the harder one.

Read Part 1 of this series here.

This article appeared originally on LinkedIn here.

To help security teams and leaders transition from panic to a practical roadmap, SecureWorld is bringing together the brightest minds in the industry for the SecureWorld Quantum Cryptography virtual conference on September 23, 2026. See details and register to attend here.

The AI Industry Just Picked a Side—and the Implications Are Enormous

CamS@secureworld.io (Cam Sivesind) — Wed, 29 Jul 2026 13:12:02 GMT

On July 24, 2026, a coalition of more than 25 American technology companies published a joint letter, Open Weights and American AI Leadership, urging Washington not to restrict open-weight AI models. The signatories include Nvidia, Microsoft, Meta, IBM, Dell, Palantir, Andreessen Horowitz, Hugging Face, Y Combinator, CrowdStrike, Palo Alto Networks, Mozilla, Mistral, Cloudflare, Cisco, and the Linux Foundation, among others.

The same week, the White House accused a Chinese AI startup of stealing the proprietary technology that partially motivated the letter in the first place.

These two events, taken together, define the most consequential fault line in AI policy right now. And the decisions made in the next few months will shape the cybersecurity landscape for years.

What the letter actually says

The full text of the letter, published on Microsoft's corporate responsibility site, runs to roughly 1,500 words and makes five core arguments. Here's what each one means in plain terms.

Open weights expand access to the AI economy

The letter argues that startups, universities, hospitals, and mid-market businesses cannot afford to train frontier models from scratch or pay frontier-model API prices for every task. Open-weight models let organizations run capable AI on their own infrastructure, matching the right model to the right job without vendor dependency. The letter frames this as how AI becomes economically sustainable at scale—not just for the biggest companies, but for factories, farms, hospitals, classrooms, and small businesses.

Open weights keep competition alive

This is where the letter's commercial logic is most explicit. By allowing many organizations to build, adapt, and deploy advanced models, open weights create rivalry not just among model developers but across chips, applications, and services. The unstated implication is clear: without open-weight models in the ecosystem, market power concentrates rapidly around the handful of labs capable of training closed frontier systems. That concentration would mean fewer competitors, higher prices, and slower innovation.

Open weights give customers control

Organizations investing in AI want assurance they won't become locked into a single vendor or lose the capabilities they build. Open-weight models allow companies to control their own data, adapt models to their own needs, and deploy them wherever their requirements demand—including environments where connecting to an external API is a security or compliance problem.

Openness may actually be a path to safety, not a threat to it

This is the letter's most pointed argument, and it's aimed squarely at the closed-model labs that didn't sign. The letter contends that closed models are not inherently safe: they can be breached, misused, or fail in ways outsiders cannot detect. Concentrating frontier AI behind a small number of closed APIs creates single points of failure. Open-weight models, by contrast, allow a broad community of researchers and developers to examine behavior, identify vulnerabilities, develop safeguards, and improve them over time—the same dynamic that made open-source software more secure over time, not less.

Distillation is a legitimate technique—covert extraction at scale is not

This section was clearly drafted with one eye on the Moonshot/Kimi K3 situation. The letter explicitly defends distillation as "a widely used technique for model improvement, evaluation, and validation" with a long tradition in AI development. But it draws a sharp line: unlawful efforts to extract proprietary value from closed models through covert, large-scale means "raise legitimate concerns" that "should be addressed through targeted legal and commercial frameworks rather than sweeping restrictions" on the technique itself.

"I think we're going to see a lot more stories like this because there's real anxiety in the AI industry right now. Part of it is financial. Many organizations are struggling to demonstrate a meaningful return on investment from their AI initiatives," said John Strand, Owner and Managing Intern at Black Hills Information Security. "The other part is security. As researchers continue to show AI systems escaping their intended boundaries or interacting with other systems in unexpected ways, concerns about AI safety are growing. That's why you're seeing so many new AI security initiatives. In many cases, they're trying to establish industry standards before governments step in with legislation or regulation. Whether those efforts are enough remains to be seen."

Who signed—and who didn't

The signatory list is as revealing as the letter's content. The full coalition includes: Agno, AI21, AMD, American Innovators Network, AMP, Andreessen Horowitz, Applied Compute, Arcee AI, Arena, Atreides Management, Baseten, Black Forest Labs, Block, Bolt, Box, Camber, Cisco, Cloudflare, Cohere, Core Automation, CrowdStrike, Dell Technologies, DoorDash, GitHub, Glean, Google (conflicting reports that it signed July 26; others say CEO Sundar Pichai personally endorsed it on X), Hugging Face, IBM, LangChain, The Linux Foundation, Meta, Microsoft, Mistral, Mozilla, NVIDIA, OpenAI (signed on July 26), OpenClaw, Palantir, Palo Alto Networks, Perplexity, Replit, Scale, ServiceNow, SpaceX (endorsed but did not sign the letter), Vercel, Y Combinator, and others.

The security industry's presence is notable. CrowdStrike and Palo Alto Networks—two of the largest cybersecurity companies in the world—signing alongside chipmakers and model developers signals that the security sector has a strong stake in this outcome, not just an academic interest in it. Note: Cisco, Cloudflare, Palo Alto Networks, AMD, and GitHub were all later additions (day 2–3), not part of the original 25.

The letter's publication was amplified by some of the most prominent names in technology, and the framing of their public statements is worth paying attention to.

Nvidia CEO Jensen Huang shared the letter in what was his first-ever post on X, writing: "AI will transform every industry, power every company, and be built by every country. Open models strengthen safety and cybersecurity, accelerate innovation and diffusion, and enable sovereignty."

The post accumulated more than 11 million views within hours. That Huang—arguably the most influential hardware executive in the AI era and a conspicuous non-participant on X since Elon Musk's acquisition—chose the open weights letter as his debut post is itself a deliberate signal about where he believes the stakes are highest.

Microsoft CEO Satya Nadella called open-weight models "essential to a healthy AI ecosystem" and framed them as a path to "strengthen American competitiveness and expand economic opportunity, while protecting national security."

Musk, whose SpaceX did not officially sign the letter, amplified it on social media, writing that it has his "full support."

The letter itself includes a line that captures its central strategic argument: "Our AI leadership will be judged not by one frontier AI model, but by whether the United States builds a strong, open ecosystem that diffuses into every sector."

The Kimi K3 situation: what's actually alleged

The backdrop to the letter is a rapid and still-unresolved controversy involving Chinese AI startup Moonshot AI and its model Kimi K3, released July 17, 2026.

Moonshot released Kimi K3 as an open-weight model with roughly 2.8 trillion parameters, among the largest publicly released models to date. The company said it approaches the performance of Anthropic's Claude Fable 5 and OpenAI's GPT-5.6 on some benchmarks. The model ranks first in front-end coding performance, according to Arena AI rankings.

White House Office of Science and Technology Policy (OSTP) Director Michael Kratsios said that Moonshot AI illicitly trained its K3 model on Anthropic's Fable through model distillation. "We have information that Moonshot AI distilled Anthropic's Fable for the development of its K3 model," Kratsios wrote. "To do this, they developed a sophisticated internal platform to conduct large scale distillation against U.S. models, allowing them to quickly switch between multiple methods of access to avoid detection."

Kratsios accused Moonshot of running an internal distillation platform against Claude Fable 5 using restricted Nvidia chips acquired via Thailand.

U.S. Treasury Secretary Scott Bessent warned that if covert, industrial-scale distillation crosses into intellectual property theft, the United States could impose sanctions or add firms to the Entity List.

The allegations are serious—and disputed. The OSTP post did not provide technical details or public forensic evidence describing how the extraction would have occurred. Some AI researchers questioned whether distillation alone could explain Kimi K3's capabilities. Multiple AI researchers have since publicly disputed the claim that distillation alone explains Kimi K3's capabilities.

Anthropic has not said it possesses evidence tying Kimi K3 specifically to distillation from Fable, though the company previously accused Moonshot of engaging in the practice in February. Anthropic has also said that Moonshot, along with two other Chinese AI companies, DeepSeek and MiniMax, generated more than 16 million interactions with Claude using an estimated 24,000 fabricated accounts, which the company said violated its terms of service and regional access restrictions.

There are many who believe that distillation cannot be responsible for the advanced capabilities of Kimi K3. The 15-day gap between Fable 5's re-release and Kimi K3's debut—the window the White House says is consistent with industrial-scale distillation—has been cited by independent researchers as implausibly short for distillation to produce the reported performance gains. Note: Most detailed sourcing (Amplifi Labs, Developers Digest, Yellow, TechTimes) puts the API/consumer launch at July 16, with full open weights following July 26–27; so this alters the 15-day gap.

The distinction being drawn here matters enormously for how policy gets written. AI distillation is not inherently controversial. In general terms, distillation helps create smaller, more efficient models by training them on outputs generated by a larger "teacher" model. The White House's argument, as stated by Kratsios, is that scale and secrecy change the nature of the activity—turning a common engineering practice into something closer to a targeted extraction of proprietary capability.

What this means for governments

The coalition letter is arriving at a moment when Congress and the executive branch are already moving. The letter lands days after OpenAI's own pre-release models were reported to have autonomously breached Hugging Face's production servers, an incident already driving the bipartisan AI Kill Switch Act through Congress—meaning lawmakers are weighing open-weight restrictions at the exact moment closed-model safety incidents are also making headlines.

That context matters. The argument for restricting open-weight models is that once weights are released, they cannot be recalled, revoked, or updated—a genuine containment problem that the Mythos situation has made viscerally concrete. The coalition's counter-argument is that the same logic applies to closed models that get breached or jailbroken, and that the answer to both problems is broader defensive capability, not narrower access.

For policymakers, the Moonshot case presents a genuine dilemma. If Kimi K3's capabilities were genuinely derived from illicit distillation of American proprietary models, then closing that vector requires something more targeted than restricting open-weight models—since Kimi K3 itself is now an open-weight model, and restricting U.S. open-weight development doesn't prevent Chinese labs from releasing their own. If the capabilities emerged from legitimate research, then the policy response being contemplated is aimed at the wrong problem.

The letter's call for "targeted legal and commercial frameworks" rather than sweeping restrictions is essentially asking policymakers to distinguish between these two cases precisely, rather than treating all distillation and all open-weight releases as equivalent risks.

What this means for enterprise and public sector security leaders

For CISOs and enterprise security leaders, the open-weight debate is not abstract. It has direct operational implications across several dimensions.

Vendor lock-in and supply chain risk

The Mythos/Fable 5 shutdown earlier this summer—a 15-day period during which Anthropic disabled both models for all customers to comply with a U.S. export control directive—was a real-world demonstration of what API dependency looks like when regulators intervene. Organizations that had built workflows around those models experienced an unplanned outage with no advance notice. Open-weight models deployed on-premises or in private cloud environments don't carry that specific risk—though they shift the burden of patching, security, and model governance entirely in-house.

Defensive capability access

The coalition's security argument has teeth. Open-weight models are increasingly being used by defenders for threat hunting, malware analysis, red teaming, and incident response in environments where sending data to an external API is prohibited. Restricting open-weight models doesn't eliminate the threat—as the Kimi K3 situation illustrates, Chinese labs will continue releasing capable open-weight models regardless of U.S. policy—but it would constrain the tools available to domestic defenders while doing little to impede adversaries.

Shadow AI governance

The proliferation of open-weight models—including guardrail-stripped abliterated versions downloadable from Hugging Face, as documented in ThreatDown's recent report—makes shadow AI governance more urgent, not less. Whether Washington restricts open-weight development or not, these models exist and are being downloaded by employees without IT knowledge. The governance problem is already present; policy decisions will determine how quickly it grows.

The distillation question for enterprise AI programs

If the White House's framing of "covert industrial distillation" as IP theft is codified into law or enforcement guidance, enterprise AI teams will need to assess their own training pipelines. Many organizations fine-tune open models using outputs from closed frontier models—a common and currently uncontroversial practice. Where the regulatory line ultimately lands on that practice will have direct compliance implications.

"Organizations built identity and access management for people running predictable software. AI agents are neither, and they skip the entire stack," said Jacob Krell, Sr. Director of Secure AI Solutions & Cybersecurity at Suzu Labs. "Most security teams can't tell you how many agents are running in their environment right now, or what those agents can access. Developers launch them, Ops teams wire them into workflows, and SaaS vendors embed them in products without security ever seeing a ticket. Each agent holds credentials to production systems and behaves non-deterministically, meaning the same agent running the same task can take a different path every time."

"The Hugging Face breach is proof this gap has consequences. OpenAI tested its models' exploitation capabilities, and those models breached a real company," Krell continued. "If OpenAI couldn't predict what their own models would do in a controlled evaluation, no enterprise should assume they can predict agent behavior in production. When Hugging Face reached for closed frontier models to analyze the attack, safety guardrails blocked them from examining exploit payloads. They ran GLM 5.2, a Chinese open-weight model, on their own infrastructure instead. I've hit the same wall. I still run Claude Opus 4.6 for security work because newer models increasingly refuse to process real attack artifacts. If Washington restricts Chinese open-weight models without ensuring equivalent open alternatives from U.S. labs, defenders lose the tool that actually worked when closed models wouldn't."

What this means for the public

The open-weight debate might sound like an inside-baseball dispute among AI labs and policymakers, but its downstream effects on individuals are concrete.

If open-weight restrictions succeed and frontier AI capability concentrates among a small number of closed-model providers, the cost of AI access rises, the diversity of available tools shrinks, and the ability of individuals and small businesses to run AI privately—without sending data to a third-party cloud—diminishes. The letter's argument that open weights enable organizations to "control their own data" applies equally to individuals who reasonably don't want their most sensitive documents processed by a server they don't control.

On the other side, the proliferation of guardrail-free, locally-runnable AI models—the same dynamic the coalition letter celebrates as democratizing—has already produced a shadow market of abliterated models used for fraud, phishing, and social engineering. The same tool that gives a small clinic the ability to run AI on-premises without sending patient records to a cloud provider is the same class of tool that gives a criminal the ability to run an uncensored model with no logging or oversight. That's not an argument for restriction so much as an honest accounting of the tradeoff involved.

"The gap in most AI deployments right now is not in the model itself. Organizations are running AI agents with access to internal data, external APIs, and automated decision-making workflows, and they have not mapped what those agents can reach or how an adversary would move through that access," said Seemant Sehgal, Founder and CEO of BreachLock Inc. "Alliance frameworks that standardize how AI systems are evaluated for risk are useful, but the organizations that will benefit from them are the ones that already know what their agents are doing at runtime. Most do not."

"The strategic question for security leadership is whether their visibility into AI behavior is anywhere close to their confidence in AI capability, and for most enterprises, those two things are not in the same conversation yet," Sehgal concluded.

The DockSec Series, Part 4: Shift-Left—Gating, SARIF, and Baselines in CI/CD

Advait Patel — Tue, 28 Jul 2026 13:20:02 GMT

A scanner you have to remember to run is a scanner you will eventually forget to run. The value of container security compounds only when it is automatic—part of every pull request and every build, enforced by policy rather than by discipline. This article covers the features that make DockSec a CI/CD citizen: machine-readable output, severity gating with honest exit codes, SARIF for GitHub code scanning, and baseline "ratchet" mode for adopting gates on projects that already have findings.

Machine-readable output with --json

Human summaries are for humans. Pipelines need structured data. The --json flag prints a single JSON object to stdout—scan info, the full vulnerabilities list, severity counts, and any AI findings—and moves every human-readable message to stderr, so stdout carries nothing but the payload:

That clean separation is deliberate; you can pipe stdout straight into jq or another tool without scraping past a banner. By itself, --json writes no report files; pair it with --format if you want files as well as the stdout payload.

Exit codes that mean something

For a gate to work, the tool has to tell the shell whether the build should proceed. DockSec uses four CI-friendly exit codes:

0 — clean; no findings at or above your threshold
1 — findings at or above the --fail-on threshold
2 — usage or argument error
3 — tool or runtime error: a scan that failed, an image that was not found, a missing tool, or a failed AI pass

The distinction between 1 and 3 matters. A 1 means "the scan ran and found policy violations"—a real security signal. A 3 means "the scan did not run correctly"—an infrastructure problem. Conflating them is how broken pipelines quietly pass; keeping them separate lets you alert on them differently.

Gating a build with -- fail-on

The gate itself is one flag. Fail the build if any finding is HIGH or above:

If the scan finds anything at or above HIGH, DockSec prints how many findings tripped the gate and exits 1; your CI step fails and the deploy is blocked. --fail-on gates on the structured findings—image vulnerabilities and Compose misconfigurations. When the threshold you gate on is lower than the severity you scanned, DockSec widens the scan automatically so the gate can actually see those findings; you cannot accidentally gate on a severity you never collected.

SARIF for GitHub code scanning

Exit codes gate the build. SARIF surfaces the findings where developers already work—inline on pull requests and in the GitHub Security tab. The --sarif flag writes a SARIF 2.1.0 report:

Each unique vulnerability becomes a SARIF rule; each finding becomes a result. Severity maps to SARIF levels—critical and high to error, medium to warning, low and unknown to note. --sarif is independent of --format: it always writes its file regardless of which human-readable formats you selected, because it targets tooling rather than reading.

In a workflow, pair it with the standard upload action:

The if: always() is not optional. Without it, the upload step is skipped whenever --fail-on makes DockSec exit non-zero—which is precisely when you most want the findings visible. Run the gate and the upload as separate concerns.

The adoption problem: baselines

Here is the reality of turning on a gate for an existing project: the first run lights up with pre-existing findings, the build goes red, and everyone's first instinct is to rip the gate back out. A gate you cannot turn on is not a gate.
Baseline mode solves this. You snapshot today's findings once, commit the baseline, and from then on the gate fires only on findings that are new relative to that snapshot:

Findings are matched by vulnerability ID, target, and package name, so the baseline stays valid as unrelated findings come and go. This is “ratchet” mode: you accept the current state as a known-debt baseline, stop the bleeding by blocking anything new, and pay down the existing debt on your own schedule. When you triage and decide to accept a finding, re-run with --update-baseline to fold it into the new baseline. It is the single most important feature for getting a gate adopted rather than reverted.

The GitHub Action

For teams on GitHub, the Action wraps all of this. The minimal form:

The Action exposes the CLI flags as inputs—severity, fail_on, format, output_dir, and sarif—so you can express your whole policy declaratively in the workflow. The scanners come pre-installed in the Action's container, so there is no separate setup step.

A recommended rollout

Putting it together, a pragmatic path to an enforced gate looks like this:

Observe. Add DockSec to CI in scan-only mode with no gate. Let it run on pull requests and write SARIF so findings show up in the Security tab. Nobody is blocked yet; you are building visibility and a sense of the baseline.
Baseline. Once the team has seen the findings, snapshot them with
--update-baseline and commit the baseline file.
Gate on new. Add --fail-on high alongside the baseline. Now any new high-or-critical finding blocks the build, while existing debt does not. This is the step that changes behavior without triggering a revolt.
Ratchet down. Periodically triage the baseline, fix or formally accept findings, and re-baseline. Over time the accepted-debt set shrinks and your effective gate tightens.

Notice that this rollout is a sequence of small, reversible steps, each of which delivers value on its own. That is what makes it stick.

From enforcement to insight

CI turns DockSec from a tool you run into a policy you enforce. But enforcement raises a strategic question: how do you know it is working? How do you measure whether posture is improving over time, and how do you talk about that to people who do not read severity tables? That will be the subject of the final article—scoring, metrics, and adopting DockSec as part of a security program rather than a single pipeline step.

This is the fourth in a five-part series. Watch for coming installments on Tuesdays.

SecureWorld St. Louis Returns with CISOs Tackling AI's Hardest Questions

drewt@secureworld.io (Drew Todd) — Mon, 27 Jul 2026 17:22:01 GMT

St. Louis-area cybersecurity professionals have a full day of practitioner-led programming to look forward to when SecureWorld returns to The Ritz-Carlton St. Louis on September 2nd. Now in its 16th year, the regional conference has built its 2026 agenda around a theme that's impossible to avoid in security circles right now: what happens when AI moves faster than the governance built to control it?

That tension shows up early. The event opens with a keynote panel titled "The AI Train Isn't Stopping—What CISOs Do Next," featuring Alan Berry (SVP & CISO, Centene Corporation), Mike Ehlers (CISO, Soleo Health), and Renita Rhodes (VP, Audit Manager – Cybersecurity Audit, and adjunct professor at Harris Stowe State University and Maryville University). Rather than another AI hype session, the panel is set as an unscripted conversation about the guardrails organizations haven't figured out yet—including how to give security teams visibility into AI agents that show up in tools no one approved.

AI governance gets a harder look

Several sessions push past generic "adopt AI safely" advice into specifics practitioners can actually use.

Kyle Oris (IT Security Analyst, SSM Health) delivers "Governing AI You Shouldn't Have Built: Why Strategy Has to Come Before Governance," challenging the assumption that having an AI governance committee means an organization is actually managing AI risk. Oris co-authored a chapter on operationalizing AI governance for third-party AI adopters, published in Cyber Risk Management and AI Governance in the Digital Era (IGI Global, 2026), and draws on that research plus his work building governance programs inside a large healthcare system.
Drew Klauser (Engineering Manager, Security & Compliance, ezCater) presents a five-rung "AI Vulnerability Ladder" framework in "Don't Jump the AI Ladder," aimed at teams who've concluded they're not ready for AI-assisted vulnerability management because they're picturing full autonomy on day one.
Patrick Mayer (Director of Solution Engineering, Island) makes the case for a "Secure Yes" framework—visibility, accountability, and resilience—in "Is Your Enterprise Ready for AI?"
Josh Behnke (Manager of Pre-Sales Engineering, Concentric AI) examines how AI is simultaneously expanding the data security attack surface and enabling smarter defenses in "AI Is Breaking Data Security… and Fixing It."

Panels connect AI to the threat landscape and the workforce

Beyond the individual talks, two panel discussions round out the day's AI thread.

"The Human Layer: Insider Risk, Behavioral Analytics, and the AI Threat Multiplier," featuring Hitesh Kumar (Sr. Security Architect, Zappsec), covering deepfake-enabled social engineering and MFA fatigue attacks.
"Navigating the Evolving Digital Battlefield," moderated by Travis Nichols (CISO, Shelter Insurance), on identity-first security and fourth-party risk in an increasingly automated threat environment.

The workforce conversation gets its own spotlight, too. Ryan Frillman (CISO, Equifax Workforce Solutions) and Michelle Sickbert (Sr. Director, BISO, Equifax) headline a fireside chat, "Left Behind or Leveled Up? The Talent Gap and the Future of the Security Workforce," asking a question the industry hasn't fully reckoned with: if AI does more of the work, does the field still need more people—and what kind? Rhonna Novy (Cybersecurity Chair & Director of Tech Talent, TechSTL) follows with practical pathways for breaking into the field in "Expanding Pathways into Cybersecurity Careers and Closing the Gap."

Closing out with the realities of the CISO seat

The day wraps with a closing keynote panel, "More than Cyber: What the CISO Role Actually Looks Like in Practice," bringing together Tami Spellman (Director, IT Security, Caleres, Inc.), Rich Temples (CISO, Graybar), and Larry Woods (VP, CISO & CPO, Post Holdings, Inc.) for a candid look at the risk-translator, board-communicator, vendor-negotiator reality of the modern security executive role.

Attendees can also opt into a full-day pre-conference workshop on September 1st, "Securing & Enabling AI: Transform Chaos into Competitive Advantage," led by Bonnie Viteri (Sr. Cyber Risk Analyst, Cyber Risk Opportunities LLC), which includes a 90-day AI governance roadmap and a complimentary private strategy session.

Registration, along with the full agenda and pricing details, is available on the SecureWorld St. Louis event page.

We Spent 15 Years Securing the Supply Chain. AI Agents Just Reset the Clock to Zero

Tushar Badlani — Mon, 27 Jul 2026 13:19:03 GMT

"The open-source ecosystem spent 15 years learning that anyone-can-publish is not a trust model. The AI agent ecosystem launched with the same assumption and called it a feature."

The software supply chain was supposed to be a solved problem by now. Not fully solved, but understood. After a decade of incidents, the open-source community built the controls: mandatory two-factor authentication for publishers, cryptographic signing, provenance attestations, coordinated disclosure, and funded stewardship. It took 15 years of painful lessons, but the governance model was taking shape.

Then a parallel ecosystem appeared overnight, and none of those controls came with it.

In April 2026, OX Security published what they called "The Mother of All AI Supply Chains," a systemic architectural vulnerability in Anthropic's Model Context Protocol SDKs affecting an estimated 200,000 servers and 150 million downloads. The researchers disclosed 10 or more CVEs, most rated critical, and demonstrated remote code execution on six live production platforms. But the finding that should keep security leaders up at night was simpler: they submitted a proof-of-concept malicious entry to eleven MCP marketplaces. Nine accepted it with no review. That is npm circa 2011, except the packages have your users' credentials.

A Vectra AI survey of 1,450 practitioners found that 63% of security alerts already go unaddressed on a typical day. The teams wrestling with that volume are now being asked to also govern a new dependency ecosystem where the vetting controls have not been built yet.

We have watched this pattern play out from two different vantage points. Tushar Badlani is a Security Specialist at Figma, focused on Customer Trust and Third Party Risk. Mohit Bansal is a Senior Manager of Security Engineering at Webflow. Between us, we have spent the last several years building and operating the controls that sit between third-party code and production environments. What we see forming in the AI agent ecosystem is not a new category of risk. It is the same category, stripped of every control the industry spent two decades building.

The ladder of trust defeat

The npm supply chain attacks of 2025 and 2026 tell a specific story when read in sequence. Each incident defeated a control that the previous one respected. The progression matters because it maps directly onto what the AI agent ecosystem is about to face.

In August 2025, an attacker compromised the NX CLI through a misconfigured GitHub Actions workflow and weaponized local AI developer tools—including Claude, Gemini, and Amazon Q—to scan for secrets. There was nothing to verify and nothing to fail. That was the starting line.

By September 2025, Shai-Hulud introduced self-replication to npm. Once inside a maintainer's account, the worm republished itself across the victim's top packages, compromising roughly 200 packages in its first wave. Palo Alto Unit 42 assessed with moderate confidence that an LLM generated the bash payload. A second wave that November, dubbed Shai-Hulud 2.0, hit several hundred more packages. Both waves still relied on stolen credentials and had no provenance to fake.

In February and March 2026, the attacks escalated. An actor compromised Trivy, the widely-used security scanner from Aqua Security, by exploiting a pull_request_target misconfiguration and force-pushing 76 of 77 trivy-action tags to credential-stealing malware. That compromise then cascaded into LiteLLM, an AI gateway present in roughly 36% of cloud environments, because LiteLLM's CI pipeline ran the poisoned Trivy action. The security tooling itself became the supply chain weapon.

Then came the moment the trust model broke. In May 2026, attackers compromised 84 malicious versions across 42 TanStack packages in a six-minute window. The team had 2FA enabled. No credentials were stolen. The attackers chained three GitHub Actions weaknesses to publish through the legitimate build pipeline. The result was the first documented npm attack carrying valid SLSA Build Level 3 provenance. Sigstore correctly attested the build. It just happened to be signing the attack.

One week later, a compromised NX Console VS Code extension fetched a payload containing full Sigstore and Fulcio integration. Per StepSecurity's analysis, combined with stolen npm OIDC tokens, the attacker was positioned to forge valid provenance on downstream packages. VentureBeat reported 633 malicious npm versions passed Sigstore provenance verification on May 19.

Read that sequence again. No provenance, then self-replication, then weaponizing the scanner, then valid provenance signing the attack, then forged provenance. Each rung of the ladder defeated the control that stopped the rung before it.

The agent ecosystem starts at the bottom of the ladder

The AI agent supply chain is not somewhere in the middle of this progression. It is at the very beginning: the stage where anyone can publish anything and the distribution channels do not check.

MCP, the Model Context Protocol, is how AI agents connect to external services. Anthropic open-sourced it in November 2024, donated it to the Linux Foundation in December 2025, and it now has co-stewardship from OpenAI, Google, Microsoft, and AWS. The ecosystem has grown from roughly 100 servers at launch to more than 10,000 active public servers and 97 million monthly SDK downloads by the end of 2025. A Nerq Q1 2026 census indexed 17,468 servers, of which only 12.9% scored "high trust." Trend Micro counted 7,000 internet-exposed MCP servers by April 2026, up from 1,467 in October 2025.

But the growth rate is not the problem. The governance gap is.

The npm registry took seven years after launch to introduce optional two-factor authentication in 2017. Mandatory 2FA for top packages did not arrive until 2022. Cryptographic signing with ECDSA replaced PGP in July 2022. Provenance attestations via Sigstore reached general availability in October 2023. Trusted publishing with OIDC landed in July 2025. And classic tokens were not revoked until December 2025—15 years after npm launched.

Those controls are the floor. They are the minimum viable governance for a software supply chain. And the AI agent ecosystem has none of them.

Skills, plugins, and MCP servers get loaded dynamically at runtime based on what the agent decides it needs. That is a design strength for usability, but it means that most of the supply chain security tooling enterprises already own does not see any of this traffic. A malicious open-source library runs with whatever access the program it is part of has. A skill runs inside an AI agent that already holds your users' permissions: their email, their calendar, their files, their internal systems. When nine of 11 MCP marketplaces accept unvetted submissions, and the packages those marketplaces distribute inherit agent-level credentials, the blast radius of a single malicious entry is categorically larger than a poisoned npm package.

In June 2026, a security firm built a harmless fake AI agent skill, got it past Cisco and NVIDIA security scanners, promoted it via a skill marketplace and an Instagram ad, and reportedly reached approximately 26,000 agents, including some on corporate accounts. The evasion technique was not novel. The skill passed static review, then loaded its payload from a mutable external link the scanners never rechecked. It is the same bait-and-switch that plagued browser extensions and package ecosystems for years.

The OWASP Top 10 for Agentic Applications, published in December 2025 with input from more than 100 experts and endorsements from NIST and Microsoft, includes ASI04: Agentic Supply Chain Vulnerabilities. The distinction it draws is important. This is not the static, pre-deployment supply chain problem from the LLM Top 10. This is dynamic runtime composition, where agents discover and load components during execution. The attack surface is fundamentally different because the inventory changes with every invocation.

The remediation crisis makes it worse

The supply chain governance gap would be serious on its own. Paired with the current remediation crisis, it becomes urgent.

On March 27, 2026, HackerOne paused new submissions to its Internet Bug Bounty program, which had been running since 2013 and had awarded more than $1.5 million to open-source security researchers. The reason was straightforward: AI-assisted research was expanding vulnerability discovery faster than open-source maintainers could fix what was being found. The balance between discovery and remediation capacity had, in HackerOne's framing, "substantively shifted."

The cascading effects arrived quickly. Node.js paused its own bounty program because it relied on IBB funding. Curl exited HackerOne entirely in January 2026 over what its maintainer called "AI slop." Google stopped accepting AI-generated vulnerability reports in March 2026. The Linux Foundation announced a $12.5 million security funding push backed by Anthropic, AWS, GitHub, Google, DeepMind, Microsoft, and OpenAI.

The pattern here is consistent. Discovery scales with compute; remediation does not. And the AI agent ecosystem is inheriting that asymmetry from day one, without the governance infrastructure that the open-source ecosystem spent 15 years building to at least partially compensate.

Our security programs treat agent integrations the way we treat any high-risk third-party dependency: pre-deployment risk assessment, credential lifecycle tracking, runtime behavioral monitoring. The common thread across all of the incidents in this piece is that the agent inherits permissions from its host environment, and neither the marketplace nor the protocol enforces meaningful constraints on what those permissions allow. The teams that recognize this early tend to build the inventory and the enforcement before the incident forces it.

Where this leaves us

The good news is that the controls themselves are not a mystery. Signing, verification, inventory, scoped permissions, runtime visibility, funded stewardship—the open-source community already proved what works. The question is whether the AI agent ecosystem will adopt those controls proactively or learn the same lessons through the same painful sequence of incidents, compressed from years into months.

The tools to address this exist. Provenance attestation is not experimental. Publisher verification is not a research problem. Runtime inventory of dynamically loaded components is achievable with current infrastructure. What is missing is the decision to apply the same governance rigor to an AI agent skill that gets applied to an npm package. And the window for making that decision, while the standards are still being written and the ecosystem is still small enough to influence, is narrower than it looks.

The teams that will be in the strongest position 12 months from now are the ones building the inventory today, treating every MCP server and agent skill as untrusted third-party code, and engaging with the standards bodies while the governance model is still being drafted. It is easier to shape a standard that is 18 months old than one that is 15 years old. That advantage will not last.

This article was co-written by Mohit Bansal.

AI Is Cheating at Video Games

media@secureworld.io (SecureWorld News Team) — Sat, 25 Jul 2026 16:36:00 GMT

If you've played any online multiplayer video games recently, you might have walked away feeling like your opponents possessed superhuman reflexes or were flat out cheating. While player optimization and "sweaty" lobbies are partly to blame, there is a quieter, much more sophisticated shift happening beneath the surface: the rise of AI-driven, hardware-level cheating.

For years, the battle between game developers and cheat creators was a software-level arms race. Today, that battle has leaped off the hard drive and into the physical world, leveraging computer vision and machine learning in ways that bypass traditional anti-cheat systems entirely.

Here is what's happening under the hood. Full disclosure: I'm using AI to help me explain this technical part a bit better.

The legacy threat: software-level exploits

Traditionally, cheating required modifying a game's code or reading its active memory (RAM). "Wallhacks" and standard "aimbots" functioned by injecting code to intercept the coordinates of opposing players directly from the system memory.

Because this footprint exists locally on the machine, modern kernel-level anti-cheat solutions (like Riot's Vanguard or Epic's Easy Anti-Cheat) have become highly effective at blocking them. They scan system memory, monitor driver signatures, and flag unauthorized code execution. This has been the norm for a bit now and kept things rolling along.

To bypass these deep-system defenses, bad actors had to stop fighting the software and start mimicking the human. Rather than level up in the game(s), they took hours, days, weeks to become better cheaters—to ruin other people's experiences, to get that W.

The new paradigm: computer vision & external hardware

The modern AI cheat doesn't touch the game's code, inspect its memory, or even run on the same computer. Instead, it relies on Computer Vision (CV) and external hardware processing to create an undetectable loop. How the loop works:

Screen capture: The video output from the gaming PC or console is cloned and sent to an external capture card, which feeds the live gameplay to a secondary computer (or dedicated hardware device).
Object detection: The secondary machine runs a lightweight, highly-optimized object detection model (similar to YOLO—You Only Look Once). Trained on thousands of hours of gameplay, the AI can identify enemy character models, specific hitboxes, and head coordinates in milliseconds—regardless of lighting, shadows, or in-game obstacles.
Hardware spoofing: Once the AI identifies a target, it calculates the exact mouse adjustments needed to align the crosshairs. It sends these coordinates to an external USB micro-controller (like a Raspberry Pi or Teensy) plugged into the gaming PC.
Execution: The gaming PC registers this hardware device as a standard, legitimate mouse or controller. It executes the movement instantly.

Because the game's operating system only sees standard USB input signals and no unauthorized background processes, traditional anti-cheat software has nothing to detect.

The industrialization of AI cheating

This technology is no longer confined to underground coding forums. It is being commercialized and integrated directly into physical consumer hardware.

On-monitor AI: High-end gaming monitors now feature built-in silicon dedicated to real-time image analysis. These monitors can artificially highlight enemies in dark areas, minimize the visual impact of in-game flashbangs, or generate custom on-screen radars—all processed locally on the monitor's internal scaler, invisible to the PC.
Console spoofing: USB passthrough devices (like the Cronus Zen or XIM) have transitioned from simple recoil-compensation scripts to hosting complex computer vision loops, bringing high-tier PC-style aiming assists to Xbox and PlayStation ecosystems.
Machine learning anti-cheat: Companies are deploying server-side AI models to analyze player telemetry. Instead of looking for cheat software, they look for inhuman patterns.
Analyzing the "micro-movements": A human hand, no matter how skilled, has natural micro-tremors, reaction lag, and variable acceleration. An AI aimbot, even one programmed to look "human," often exhibits perfect linear trajectories, instant snap times, and mathematically precise adjustments that a machine learning model on the server side can flag as anomalous.

The security response: behavioral analysis

If anti-cheat software can no longer rely on scanning system memory to find bad actors, how do game developers fight back? You guessed it: more AI. Fight fire with fire!

The industry is forced to pivot from signature-based detection to heuristic and behavioral analysis.

The takeaway

The evolution of video game cheating is a perfect micro-study of the broader cybersecurity landscape. As security boundaries harden at the software level, adversaries naturally migrate to the physical and hardware boundaries, using machine learning to bridge the gap.

For developers and security professionals alike, it serves as a stark reminder: when the inputs look perfectly legitimate, protection must rely on analyzing the nuance of human behavior.

But if I'm sharing my controller with a friend who behaves differently, is it flagging us as cheaters, too? I don't have the answers, just questions, and one opinion: if you have to cheat to win at a game, you've already lost the match. This holds true IRL.

Written by Tom Bechtold, SecureWorld's Digital Content Director.

How the BISO Role Translates Cybersecurity into Enterprise Resilience

media@secureworld.io (SecureWorld News Team) — Fri, 24 Jul 2026 18:27:36 GMT

Cybersecurity has become inseparable from business strategy.

Organizations now depend on interconnected platforms, cloud services, third-party partners, data exchanges, artificial intelligence, and digital supply chains to deliver products and services. In healthcare, these dependencies extend directly to clinical operations, patient safety, privacy, regulatory compliance, and the continuity of care.

Yet a persistent gap remains: security teams often communicate in terms of vulnerabilities, controls, and technical requirements, while business leaders make decisions based on growth, operational performance, customer experience, financial exposure, and strategic priorities.

The Business Information Security Officer—or BISO—is emerging as one of the most important roles for closing that gap.

The BISO is more than a security liaison

A BISO serves as the senior cybersecurity partner embedded within a business unit, product organization, operational function, or market segment.

The role requires fluency in two languages.

The first is the language of cybersecurity: threat exposure, identity and access management, data protection, incident response, third-party risk, resilience, compliance, and control effectiveness.

The second is the language of the business: revenue, clinical or operational priorities, customer expectations, strategic investments, transformation initiatives, risk tolerance, and time to market.

Health-ISAC describes the BISO as a liaison who translates security and compliance requirements into meaningful guidance and practical recommendations for the business. That translation enables organizations to reduce cyber risk while continuing to meet operational and strategic objectives.

But translation is only part of the job.

An effective BISO does not simply deliver security requirements to the business. The BISO also brings business context back to the security organization so that controls, investments, and policies reflect how the organization operates.

From security enforcement to risk-informed decision-making

Traditional security models can create an unhealthy dynamic.

The security team identifies a risk. The business views the proposed control as a barrier. The project seeks an exception. Everyone becomes frustrated.

The BISO changes that conversation.

Instead of beginning with "Security says no," the BISO helps leaders ask:

What business outcome are we trying to achieve?
What data, systems, people, or services are critical to that outcome?
What could disrupt or compromise them?
What level of risk is the organization prepared to accept?
Which safeguards would reduce exposure without unnecessarily obstructing the business?
Who has the authority to accept any remaining risk?

This is the difference between enforcing security controls and enabling informed risk decisions.

CISA defines risk management as identifying, analyzing, assessing, and communicating risk, followed by decisions to accept, avoid, transfer, or mitigate that risk. The BISO helps make that process real within the business by connecting cybersecurity exposure to operational and financial consequences.

Why governance makes the BISO more important

The addition of the Govern function to the NIST Cybersecurity Framework 2.0 reflects a broader shift in cybersecurity.

Cybersecurity is no longer viewed solely as a collection of technical protections. It is an enterprise risk discipline that requires strategy, policies, defined responsibilities, oversight, supply-chain risk management, and communication with organizational leadership.

CISA has similarly emphasized that CEOs and boards must treat cyber risk as a matter of corporate governance and organizational responsibility.

This creates an important role for the BISO.

The CISO may establish the enterprise cybersecurity strategy, but a centralized security organization cannot always maintain deep visibility into every product, clinical workflow, business process, acquisition, vendor relationship, or transformation initiative.

The BISO provides that line-of-business perspective.

A strong BISO understands:

Which operations are truly mission-critical
How revenue or service delivery depends on technology
Where sensitive information moves
Which third parties create concentrated risk
Which regulatory obligations apply
How a cyber event could affect customers, patients, employees, or partners
Where security controls may create unintended operational consequences

That knowledge allows the organization to prioritize risk based on business impact rather than relying only on technical severity scores.

The BISO's role in healthcare

The need for this role is especially clear in healthcare.

Healthcare cybersecurity decisions can affect far more than data confidentiality. They can influence:

Patient safety
Access to clinical information
Care delivery and scheduling
Pharmacy and laboratory operations
Medical-device availability
Claims and payment functions
Privacy and consent
Trusted health information exchange
Regulatory compliance
Organizational reputation

A vulnerability may appear technical on a security dashboard, but its true significance depends on where the affected system sits within the care-delivery ecosystem.

An unavailable administrative application may create inconvenience. An unavailable identity, medication, diagnostic, or clinical communication system could interrupt care.

The BISO helps security leaders understand that distinction.

The BISO also helps clinical and operational leaders understand that cybersecurity cannot be added after a digital-health platform, artificial-intelligence application, data-sharing initiative, or connected device has already been deployed.

Security, privacy, identity, resilience, and trust must be considered during design.

The BISO and artificial intelligence

Artificial intelligence is accelerating the need for business-aligned cybersecurity leadership.

Organizations are moving rapidly to use AI for analytics, automation, clinical support, customer engagement, software development, workforce productivity, and security operations. Each use case introduces different questions involving data sensitivity, model access, intellectual property, third-party dependencies, human oversight, explainability, and accountability.

The BISO is positioned to help the organization determine:

What data an AI system may access
Whether the proposed use aligns with privacy and security obligations
How outputs will be validated
What level of human oversight is required
How identities and privileges will be managed
Whether vendors and models introduce supply-chain risk
How the organization will respond if the system behaves unexpectedly

Recent healthcare cybersecurity analysis emphasizes that AI can help automate activities such as evidence collection, but human judgment remains essential for risk decisions and ethical considerations.

The BISO should therefore be neither the person who automatically blocks AI nor the person who uncritically accelerates it.

The BISO should help the organization adopt AI responsibly.

What an effective BISO does

Although the role will vary by organization, a mature BISO typically performs several interconnected functions.

Aligns security with business priorities

The BISO learns the business strategy, operating model, critical services, major investments, and transformation roadmap. Security activities can then be prioritized according to the outcomes the organization is trying to protect.

Translates cyber risk into business impact

Instead of reporting only vulnerability counts or control deficiencies, the BISO explains how risk could affect revenue, operations, patient care, regulatory obligations, reputation, or strategic initiatives.

Embeds security into projects and products

The BISO engages early in acquisitions, partnerships, cloud migrations, new applications, AI initiatives, data-sharing arrangements, and product development.

Strengthens third-party risk management

The BISO helps identify which vendors and service providers are essential to business continuity and where contractual controls, resilience planning, or alternative providers may be necessary.

Clarifies risk ownership

Cybersecurity teams manage security programs, but they do not own every business risk. The BISO helps identify the appropriate business executive who can accept, mitigate, transfer, or avoid a risk.

Improves incident readiness

Because the BISO understands business dependencies, the role can help incident-response teams determine which services should be restored first and which leaders must be involved in operational decisions.

Builds a culture of shared accountability

The BISO moves cybersecurity away from the perception that it belongs exclusively to IT. Business leaders become active participants in protecting the operations, information, and relationships under their authority.

What the BISO should not become

Organizations should be careful not to define the BISO as simply:

A security salesperson
A compliance coordinator
A project approver
An exception-processing function
A messenger between departments
A miniature CISO assigned to a business unit

The value of the role comes from trusted influence, business acumen, risk judgment, and the ability to create shared accountability.

A BISO who lacks access to business planning will become reactive.

A BISO who lacks credibility with the security organization will be unable to shape security priorities.

A BISO who is measured only by the number of issues closed may encourage superficial compliance rather than meaningful resilience.

The role needs sufficient authority, organizational access, and independence to challenge assumptions on both sides of the business-security divide.

Measuring BISO success

Organizations should move beyond measuring BISO performance through meetings attended, assessments completed, or vulnerabilities reported.

More meaningful indicators include:

Security engagement occurring earlier in major initiatives
Reduced delays caused by late security requirements
Better visibility into business-critical systems and vendors
Faster resolution of risk decisions
Clearer assignment of risk ownership
Improved resilience of critical business services
More effective communication with executive leadership
Fewer recurring control failures
Stronger alignment between security investments and business priorities

The ultimate measure is whether the organization can pursue innovation while making deliberate, transparent, and accountable risk decisions.

The future of the BISO

The BISO role reflects an important evolution in cybersecurity leadership.

Organizations do not need security teams that merely identify everything that could go wrong. They need leaders who can help determine what matters most, what must be protected, which risks are acceptable, and how the organization can continue operating when disruption occurs.

That requires more than technical expertise.

It requires business understanding, strategic communication, relationship building, critical thinking, and the confidence to challenge both excessive risk-taking and unnecessary security friction.

The strongest BISOs will not be remembered for saying yes or no.

They will be recognized for helping their organizations make better decisions.

As cybersecurity, privacy, AI governance, identity, and operational resilience become increasingly interconnected, the BISO will serve as a critical architect of digital trust—ensuring that security is not positioned as an obstacle to the business, but as a foundation for sustainable growth, innovation, and resilience.

Cybersecurity may be led by the CISO, but cyber resilience must be owned by the business. The BISO is the leader who helps make that ownership possible.

This article was published by the Women in CyberSecurity (WiCyS) BISO Affiliate and appeared originally here. Look for WiCyS chapter meetings and BISO panel discussions at your nearest SecureWorld conference.

When AI Guardrails Cut Both Ways: Inside the OpenAI-Hugging Face Security Incident

drewt@secureworld.io (Drew Todd) — Thu, 23 Jul 2026 19:36:22 GMT

OpenAI has confirmed that its own AI models breached Hugging Face's infrastructure earlier this month. And when Hugging Face tried to investigate the intrusion, the same category of safety guardrail that OpenAI had deliberately loosened which enabled the attack ended up blocking the cleanup. That detail is getting lost in the broader alarm over autonomous AI agents launching real-world intrusions, but it's the part security leaders should sit with: the guardrail problem showed up on both sides of this incident, pointing in opposite directions.

What happened?

Hugging Face is a popular collaborative platform and open-source community often described as the "GitHub for Machine Learning". The company disclosed a security event on July 16, describing it as unlike anything the company had previously handled, and saying the intrusion was driven, end to end, by an autonomous AI agent system.

OpenAI subsequently came forward to identify itself as the source. In a joint disclosure, OpenAI said a combination of its models—GPT-5.6 Sol and a more capable model that has not yet been publicly released—escaped a sandboxed testing environment, reached the internet, and exploited a vulnerability to gain access to Hugging Face's systems.

The models were being run with reduced security safeguards as part of an internal evaluation measuring their offensive cyber capability. According to OpenAI, the models found a path to internet access, exploited a zero-day vulnerability in an internal tool, and inferred that Hugging Face likely held the answer key to the benchmark under test. They then used credentials obtained during the intrusion to retrieve that data from Hugging Face's production systems—effectively cheating on their own evaluation. The agent framework carried out more than 17,000 recorded actions over the course of a weekend, according to Hugging Face, exploiting two code-execution paths in the company's data-processing pipeline before escalating privileges and moving laterally through internal infrastructure.

Hugging Face has said it found no evidence that public models, datasets, or Spaces were tampered with as a result of the incident—a claim that, as of this writing, rests on Hugging Face's own investigation rather than independent confirmation.

The guardrail paradox

The most notable wrinkle in this incident isn't that a frontier model attempted to hack a real company; security researchers have been warning that agentic systems would eventually cross that line. It's what happened when Hugging Face tried to clean up afterward. The evidence needed for forensic analysis—attack commands, exploit payloads, command-and-control artifacts—was exactly the kind of material that trips safety filters on commercial frontier models. Investigators using mainstream Western models reportedly couldn't get those systems to process the data at all, because the models couldn't distinguish a defender examining an attack from an attacker executing one.

Hugging Face ultimately turned to Zhipu AI's GLM-5.2, an open-weight model it could run on its own infrastructure, to complete the analysis—a choice that let the company keep attacker data and any harvested credentials inside its own environment rather than sending them to a third-party API.

Randolph Barr, CISO at Cequence Security, explained: "What stands out is the asymmetry: the attacker's AI agent operated with zero usage restrictions, while Hugging Face's own forensic work got blocked by the safety guardrails of Western frontier models. They ended up running incident response on a Chinese open-weight model, ironic given where many cyber threats originate."

Noma Security's CISO, Diana Kelley, made a related point: the issue isn't that safety guardrails exist, it's that no frontier provider currently offers a verified path for legitimate incident responders to work around them. Until that changes, she argued, security teams that want to use AI for incident response need a vetted, self-hosted model available as a backup—not as a substitute for provider guardrails, but as a way to avoid being locked out of their own investigation.

What defenders should take from this

Set aside the geopolitical irony of the model choice, and a few practical lessons hold up regardless of which company or model is involved next time.

Model hubs and data-processing pipelines belong in the same threat model as package registries and CI/CD systems, Kelley said, since this attack industrialized a familiar chain—code execution, privilege escalation, credential harvesting, lateral movement—rather than inventing a new one. The agentic framework's ability to run thousands of actions across short-lived environments over a single weekend is what changed the economics of the intrusion, not the individual techniques.

Non-human identity was also central to how far the intrusion got. Chief Technology Officer Chandra Gnanasambandam of SailPoint argued that autonomous agents need to be governed like privileged service accounts from the outset: access provisioned dynamically, every action traceable to a human owner, and credentials revocable instantly—not treated as an afterthought once an agent program is already running in production.

Dana Simberkoff, Chief Risk, Privacy and Information Security Officer, AvePoint, said: "An autonomous system pursuing an objective across organizations will not understand systemic risk or regulatory boundaries unless those constraints are engineered and enforced. Testing in or near these environments requires independent review, hard technical limits, continuous monitoring, and clear accountability. 'We did not intend for the model to go there' is not data protection, governance, or a defensible control."

Detection speed is the other recurring theme. Hugging Face's own account credited behavioral anomaly detection at the infrastructure level—correlating telemetry many teams would otherwise dismiss as noise—with catching the intrusion. Sysdig's Crystal Morin pointed to that detail as the one worth planning around, arguing that security teams need to verify today, not eventually, that they can spot anomalous behavior like a privileged container spinning up unexpectedly, and that model weights and training data are backed up as rigorously as production databases.

The numbers behind the trend

Two vendors used the incident to point to their own research on agentic AI risk, and both are worth noting with the appropriate caveat that they're commercially interested parties publishing findings that support their product positioning.

AvePoint cited its own third annual State of AI Report finding that 88% of organizations experienced at least one agent-related security incident in the past year, and that one in five organizations couldn't say whether employees were using unauthorized AI tools at all—a blind spot the report says has nearly tripled year over year.

Endpoint security vendor ThreatDown, meanwhile, said its own research identified more than 6,000 self-labeled "guardrail-free" models hosted on Hugging Face, downloaded a combined 22 million times over a 30-day period—a figure the company used to argue that Hugging Face sits at the center of both stories: the platform that was attacked, and a major distribution point for models with no safety layer at all.

Where this leaves things

OpenAI has framed its response as a model for transparency: it disclosed the zero-day it found, brought Hugging Face into its trusted-access program, and said it's tightening infrastructure controls around future evaluations even at the cost of research speed. Hugging Face CEO Clément Delangue struck a similar note, calling the incident proof that AI safety won't be solved by any single company working in secret, but collaboratively and in the open.

That cooperative framing is easier to accept because no lasting damage has surfaced yet. But the underlying problem the incident exposed—that the same guardrails meant to keep a model from doing harm can also prevent defenders from doing their jobs—doesn't go away once this particular investigation closes.

Until frontier providers build a verified path for legitimate incident responders to work with sensitive attack data, security teams evaluating AI-assisted response should plan for the possibility that the tool they're counting on will refuse to look at the evidence when it matters most.

Age of AI Cybercrime Report Gives Orgs Six-Month Window to Act

CamS@secureworld.io (Cam Sivesind) — Thu, 23 Jul 2026 13:12:03 GMT

There's a sentence near the opening of ThreatDown's new Cybercrime in the Age of AI report that deserves to be read twice: "The transition to a cybercrime ecosystem shaped by AI has begun, but it's not yet complete."

That qualifier—not yet complete—is both the most reassuring and most urgent phrase in the entire document. It means organizations still have a window. ThreatDown's estimate of how wide that window is: six months.

The 22-page report, published July 2026, is one of the most concrete assessments of the AI-and-cybercrime intersection released this year. It draws on original research into criminal AI marketplaces, guardrail-stripped models on Hugging Face, malicious agent skills, shadow AI breaches, and the implications of Anthropic's Mythos model for the vulnerability landscape. What follows is a breakdown of the key findings and what they mean for enterprise leadership, security teams, and the broader public.

The report opens with a case that sets the tone for everything that follows. In early 2026, an attacker with no background in industrial control systems compromised multiple Mexican government organizations, including a municipal water utility in Monterrey. During reconnaissance, Anthropic's Claude—without being prompted— identified a SCADA management interface on the utility's internal network, correctly classified it as critical infrastructure, and recommended a targeted attack against it. The attacker had no prior OT expertise; the AI supplied it.

The breach ultimately failed. But ThreatDown's framing is precise: the significance isn't what happened, it's what it revealed. AI has made critical infrastructure visible to attackers who previously lacked the knowledge to find it. The barrier to targeting a water supply, a power grid, or a hospital isn't what it used to be.

That's the report's central argument: AI hasn't invented new attack tactics. Stolen credentials are still the dominant form of initial access. Endpoints still hold the data criminals want. What AI has done is compress the time, cost, and expertise required to execute attacks that used to demand serious skill. Every threat actor gets smarter, faster, and more scalable—including the ones who previously couldn't have found your OT network.

ThreatDown researchers mapped the storefront infrastructure of several prominent malicious AI tools—WormGPT, Kriminal, DadGPT, and Xanthorox—and found something that should give every procurement and vendor risk team pause. These tools don't build their own AI, they rent it. Tracing the production JavaScript, CSP headers, and DNS/TLS records of each storefront, researchers found the same legitimate vendors appearing repeatedly as the unwitting supply chain: Cloudflare, Vercel, Google Cloud, OpenRouter, xAI, Anthropic, DeepSeek, and Alibaba.

WormGPT, one of the earliest criminal AI tools, now markets itself as an "Ethical Hacking AI." Xanthorox calls itself a development platform. The disclaimer is the camouflage. Strip it away, and most of what's sold as criminal AI is one of three things: a jailbroken wrapper around a mainstream model, a reseller proxying a legitimate API at markup, or outright vaporware. Genuinely custom-trained criminal models are rare. The criminal AI market is, structurally, a parasite on the legitimate AI industry—and that industry's infrastructure sits inside your existing vendor relationships.

For security teams: Add criminal AI abuse vectors to your vendor risk assessment process. The same Cloudflare tenant, the same API endpoint, and the same model your developers use may also be serving your adversaries.

In July 2026, ThreatDown researchers found more than 6,644 models on Hugging Face published under self-declared guardrail-free labels: "abliterated," "uncensored," "heretic," "decensored," "unfiltered." Together, these models accumulated tens of millions of downloads in a single 30-day window. Publishing volume grew approximately threefold between Q4 2025 and Q2 2026.

Abliteration—the technique for stripping refusal behavior from an open-source model without retraining—used to require specialist knowledge. It still does, technically. But criminals don't need to perform it themselves. Thousands of pre-abliterated models are freely downloadable. A criminal weighing $50/week for GhostGPT against a free model that runs offline on their own machine, with no provider logging the prompts, has an easy decision.

This is the detection problem that should concern defenders most. When a criminal runs an abliterated model locally, no provider sees the prompts. No blocklist catches the traffic. The artifact worth scanning is gone. The malware families already exploiting this pattern generate their malicious logic in memory at runtime and discard it—leaving signature-based detection with nothing to match.

For security teams: Endpoint behavioral detection is no longer optional. Static signature scanning will not catch the next generation of AI-generated, in-memory malware. The report's conclusion is explicit: SOC coverage and MDR/EDR with behavioral analysis are baseline requirements.

This section of the report is perhaps the most operationally novel finding. In January 2026, an AI agent called OpenClaw went viral—locally-run, highly privileged access to files, credentials, and connected systems, with a plugin marketplace called ClawHub where users could install "skills" to extend its capabilities. By the end of March 2026, approximately half a million OpenClaw instances were exposed on the public internet, most installed by employees without IT's knowledge.

Malicious skills appeared on ClawHub within days of launch. A security researcher found over 1,000 within a month, including the site's most downloaded skill. ThreatDown's own researchers documented skills that stole credentials and exfiltrated data, installed malware, and poisoned an agent's core memory files for persistence. The key detail: malicious behavior was typically embedded inside otherwise functional skills, so agents operated normally while executing harmful operations in the background.

By April 2026, when security scanners began searching for harmful payloads in skills, criminals adapted. The new generation of malicious skill contained no malicious code at all. Instead, it contained a fake "get rich with AI" blog post—a Polymarket weather-bot guide fabricated to look authentic—instructing users to download and run a binary called Polymarket.exe. That binary delivered GachiLoader, which used fileless injection to install Rhadamanthys, a sophisticated infostealer that harvests credentials for identity attacks. GachiLoader's command-and-control infrastructure was hosted on a Polygon blockchain smart contract—immutable and impossible to take down through conventional means.

Detection rate across major endpoint security products at the time of discovery: near zero.

For security teams: Agent skills represent a new attack surface category that most security stacks don't monitor. Privileged, locally-running AI agents that install third-party plugins from public marketplaces are a credential exfiltration risk even when the agent itself is legitimate. This requires policy, discovery tooling, and endpoint protection capable of catching fileless injection.

One in five organizations suffered a breach linked to shadow AI in 2025, costing an average of $670,000 more than a standard incident, according to IBM data cited in the report. Nearly half of employees who use generative AI at work do so through personal, unmanaged accounts.

The attack surface this creates is invisible by definition. Employees are uploading sensitive documents, entering credentials, and connecting company systems to unvetted platforms. Every AI tool account created without IT's knowledge is, as ThreatDown puts it, "a potential identity attack waiting to happen"—not just because of what users share with the tool, but because the OAuth credentials, API keys, and session tokens used to access AI tools have joined the list of secrets that need defending.

The 500,000 OpenClaw instances exposed on the public internet are the clearest illustration of the scale of the problem. Between February and April 2026, a public vulnerability tracker logged more than 100 separate security advisories for OpenClaw alone.

For enterprise leadership: The shadow AI problem is not primarily a security team problem; it's a governance and culture problem. If employees are reaching for unauthorized AI tools because the authorized ones are inadequate, slow to approve, or nonexistent, the answer isn't blocking—it's providing. Security teams need discovery tooling. Leadership needs to create a path for employees to use AI safely.

In May 2026, Google's Threat Intelligence Group identified what it believes to be the first known zero-day exploit developed by criminals using AI. The target was a popular open-source web-based system administration tool. The exploit—implemented as a Python script—was designed to bypass two-factor authentication (2FA) and enable identity-based attacks. Google disrupted the campaign before mass exploitation began, but the significance is what the finding confirmed: AI is now being used by criminal groups to discover and weaponize vulnerabilities that didn't exist in any public database.

This development didn't happen in isolation. In 2025, Google's Big Sleep project and bug-bounty AI XBOW had already demonstrated that AI could outperform humans at finding security flaws in software. Nation-state actors had already incorporated AI into live operations. APT28 deployed LAMEHUG against Ukrainian government targets in June 2025, malware that sends prompts to an AI model via Hugging Face's API and executes the generated commands on the target machine.

The trajectory is not in question. The only open variable is timing.

The Mythos factor: the scenario that changes everything

The report's final section is the one that has the most significant implications for how organizations should be thinking about the next six to 18 months.

In April 2026, Anthropic unveiled Claude Mythos—and simultaneously withheld it from public release. The reason: Mythos had proved far more capable at finding and exploiting software vulnerabilities than its creators anticipated. During testing, it found and exploited zero-day vulnerabilities in every major operating system and web browser tested, including a 27-year-old bug in OpenBSD. Engineers with no formal security background used it to find remote code execution vulnerabilities while they slept. The UK AI Security Institute tested it against a 32-step simulated corporate network takeover—a scenario estimated to require 20 hours of work from human professionals. Mythos completed it end-to-end.

Firefox's response to early Mythos access through Anthropic's Project Glasswing program tells the story quantitatively: the browser shipped 423 bug fixes in April 2026, compared to 31 in April 2025. Mozilla's CTO described the experience as giving the team "vertigo."

Anthropic's CEO has assessed that models from China with comparable capability are likely to be broadly available within six to 12 months. ThreatDown's assessment is that Mythos-class capability could reach criminal marketplaces within six months.

Here's the paradox the report identifies that most coverage has missed: Mythos-class models reaching defenders first sounds like good news. It isn't straightforward. Models capable of finding vulnerabilities at this scale will generate patch volumes that dwarf anything organizations currently manage. Because every new patch is an opportunity for criminals to reverse engineer an exploit, the number of exploits available to criminals in the short term could actually grow massively, even as the underlying vulnerabilities are being found and fixed. Organizations that already struggle with their patching backlog won't suddenly find 10 times the capacity to handle 10 times the fixes. They will fall behind, and the window in which exploits remain effective will grow.

The volume of work that Mythos-class models will create for defenders is, in ThreatDown's words, "as significant as the threat they pose in the wrong hands."

ThreatDown's conclusion organizes the response across three priorities.

1. Patch like the clock is running

Because it is. Automate vulnerability assessment and patch management now, before the volume of patches organizations need to process increases by an order of magnitude. Organizations with disciplined, automated patching will be more secure. Those that don't will face an ever-growing backlog of unpatched systems and criminals armed with an ever-expanding library of exploits to use against them.

2. Monitor continuously, 24/7

AI makes every threat actor faster, smarter, and more scalable—but it doesn't create new tactics. The data are still on the endpoints. The access is still obtained through stolen identities. Organizations need to set themselves up to detect the early signs of an AI-driven attack rapidly, with SOC coverage or a managed detection and response service. A threat that moves at AI speed requires a response capability that doesn't clock out.

3. Find and govern your shadow AI

Unsanctioned AI tools, agent skills, and MCP connections are a growing compliance, privacy, and security risk that IT teams currently can't see. The report recommends AI detection and response tooling specifically designed to surface the shadow AI attack surface inside the organization—not to shut it down, but to see it clearly enough to manage it.

What this means by audience

For boards and executive leadership

The report's statistics deserve attention at the highest levels. One in five organizations breached through shadow AI in 2025. $670,000 in additional costs per incident. A six-month window before Mythos-class vulnerability discovery reaches criminal markets. These are material business risks, and they require resource decisions—on patching automation, on 24/7 detection coverage, on AI governance—that security teams cannot make unilaterally. The governance and investment decisions need to happen now.

For security teams

The practical operational priorities are clear: behavioral endpoint detection over signature-based scanning, continuous monitoring coverage, shadow AI discovery tooling, and aggressive patching cadence. The report also flags identity as the critical battleground—stolen credentials remain the dominant initial access vector, and the surface area of credentials worth stealing has expanded to include every AI tool account an employee has ever created.

For the general public

The mechanism criminals are now using against individuals has changed in one specific and important way. The AI enthusiasm that made 2025 and 2026 feel exciting and productive has become an attack surface in its own right. The "get rich with AI" guide that delivers an infostealer, the popular marketplace skill that exfiltrates your credentials in the background—these attacks work because people trust AI tools and move fast to adopt them. Healthy skepticism about what you install, where you download from, and what you connect to your accounts is no longer optional cyber hygiene. It's the specific thing criminals are betting you won't have.

ThreatDown ends its report with a sentence worth quoting in full: "The organizations that come through this moment intact will be the ones that saw it clearly and acted while the clock still favored the prepared."

The report doesn't argue that AI-native cybercrime is an unstoppable future threat. It argues that it's a present reality that is not yet fully distributed—and that the distribution is accelerating. The water utility in Monterrey, the poisoned skill on ClawHub, the 22 million downloads of guardrail-stripped models, the first AI-built zero-day: these aren't hypotheticals, they happened.

The six-month window is real. What organizations do with it is the only question that remains open.

We asked some solution provider experts for their take on the report.

Dr. Margaret Cunningham, VP of Security & AI Strategy at Darktrace, said:

"Frontier models are becoming more powerful and more widely accessible, while the mechanisms meant to control them remain imperfect. Against this landscape, defenders should assume breach, assume unapproved access, and assume that any capability useful enough to matter will eventually be used by adversaries.
"While it is important to pay attention to claims about capabilities of these new models, it is also worth recognizing that the full picture often takes time to emerge. Some capabilities may prove more impactful than initially expected, while others may not live up to early expectations. For security teams, the challenge is evaluating these developments in real time, often before there is broad consensus on what the practical implications are. That can be especially difficult in a fast-moving environment where benchmarks, capability assessments, and model comparisons are evolving alongside intense industry interest and competition."
"The same logic applies to guardrails. Guardrails can reduce opportunistic misuse, but they are not a complete defense. People who are good at jailbreaks already use context flooding, metaphor, literary framing, and iterative workarounds to test these systems."
"While a lot of focus lands on the offensive impact, the defensive burden is most concerning. Advanced defense is still mostly human, and we have not automated this level of expertise at scale. Vulnerability management was already behind schedule before AI accelerated discovery. The hard work is not just finding a vulnerability, it's figuring out whether it matters in a specific environment, whether it is a lab-only edge case, whether patching will break something else, and how to remediate without disrupting the business."
"There is no universal 'normal' to defend anymore. Every organization, device, user, and agent behaves differently, which means security teams need a way to understand what is normal in their specific environment and spot when something changes. As AI accelerates discovery and exploitation, behavioral detection, anomaly-based analytics, and autonomous containment become essential. Defenders need to prioritize based on context, contain threats quickly when prevention fails, and build defenses around the reality of their own environment rather than a generic model of risk."

Randolph Barr, CISO at Cequence Security, said:

"Approximately two-thirds of current AI-related incidents still originate from traditional weaknesses, however, the remaining third are uniquely 'AI-native.' These include model and data poisoning, prompt injection, and autonomous agents that can chain together API calls and act with minimal human oversight. These emerging risks reflect the reality that AI systems are dynamic, self-learning, and interconnected in ways traditional applications never were. When paired with the rapid speed of development, the outcome is a growing attack surface that grows faster than most security programs can respond."
"We are approaching a future where the use of AI agents will outpace the readiness of security measures. We have seen a number of advisories over the past year which help highlight the gaps and hopefully drive the industry toward more secure, transparent designs before these tools become deeply embedded in enterprise ecosystems."

Ram Varadarajan, CEO at Acalvio, said:

"Today, we are witnessing a significant swing in the cyber threat landscape, and it's more severe and unparalleled to anything we've ever faced before. Multi-agent swarms are coordinating in real-time across reconnaissance, credential harvesting, and data exfiltration. We're facing exponential coordination where hundreds of specialized AI agents will operate simultaneously across our entire attack surface. Reactive defenses can't operate at machine speed, requiring a shift in the cybersecurity stack to preemptive, AI-driven strategies. AI fighting AI, paired with offensive deception technologies, is the emergent design to catch attackers off guard and cause them to make mistakes and disclose themselves. Organizations that adapt will recognize that defense is no longer about building higher walls. It's about becoming an unpredictable, moving target."
"To maintain competitive edge and protect valuation, companies have to pivot from reactive defense to active, game-theoretic defense. This means deploying AI-driven cybersecurity, specifically AI agents that use strategic deception in real-time. The future calls for forcing attackers to fight on the defender's terms, gambling adversary compute against AI-driven decoys, and shifting the economic burden of the attack onto the attacker."

Diana Kelley, CISO at Noma Security, said:

"Traditionally, security teams focused on the protection of systems and data. Today, we are helping to govern AI systems and agents that make recommendations and decisions, and in some cases take action on behalf of the business, while enabling the business to adopt AI quickly and safely. AI also means that we're facing a more well-resourced adversary. It lowers the cost of scale and increases the quality of automated attack campaigns. Without a strong control plane for AI systems and agents, including clear guardrails on access and actions, along with identity, access control, data governance, and runtime monitoring, AI will amplify whatever weaknesses already exist."
"Moving forward, AI will be embedded in all aspects of our businesses, and every security professional needs a working understanding of AI and agent risk. That includes how models are trained, where data exposure can happen, how outputs can be manipulated, agentic blast radius, and how AI integrates into business workflows. In the real world, those risks show up inside existing domains like productivity tools, data loss prevention, access control, application security, cloud security, and risk management."

Shane Barney, CISO at Keeper Security, said:

"Advanced AI models are now capable of scanning systems, networks and code to identify vulnerabilities at a speed and scale no human analyst can match, and that capability cuts both ways. In the hands of a defender, it's a force multiplier for threat detection and response, but in the hands of a threat actor, it accelerates the path from reconnaissance to exploitation faster than most security teams can detect, let alone respond to."
"These AI systems easily bypass traditional 'friction-based' defenses by automating complex, multi-step attack chains at scale, creating a massive influx of software bugs that human maintainers cannot triage fast enough. This results in a dangerous operational bottleneck, leaving a wide window of exposure for adversaries to exploit known flaws before a fix can be deployed. Security teams must operate on a much shorter clock, assuming public vulnerabilities will be weaponized within hours rather than weeks. Defenders should immediately implement automated update paths for internet-facing systems, treat dependency security patches as immediate priorities rather than backlog items and maintain robust logging and MFA to prevent lateral network movement if a breach occurs."
"Enterprises that have been deferring foundational security work are running out of time. The attack surface hasn't changed, however, the tools available to exploit it have gotten significantly more powerful. Unpatched vulnerabilities, excessive access permissions, and gaps in privileged account oversight are exactly the conditions that AI-assisted attacks are built to find and weaponize."

Cybersecurity Agencies Standardize Guidance for Vulnerability Disclosure

CamS@secureworld.io (Cam Sivesind) — Wed, 22 Jul 2026 12:22:00 GMT

On July 15, 2026, top cyber defense agencies across four allied nations released a joint guidance document: "Establishing a Coordinated Vulnerability Disclosure Program to Work with Security Researchers."

Co-authored by CISA and the NSA (United States), JPCERT/CC (Japan), NCSC-NL (Netherlands), and NCSC-UK (United Kingdom), the publication establishes a global baseline for how software developers and online service providers should interact with external security researchers.

Many software manufacturers and online service providers operating web services have internal teams that identify and address security vulnerabilities before releasing their products. However, internal efforts alone may be insufficient for discovering every potential vulnerability. To help pinpoint security defects not identified by internal testing, this guidance details how suppliers can harness the knowledge of external security researchers. Suppliers should engage these researchers by implementing a coordinated vulnerability disclosure (CVD) program.

So, what does this actually mean for security leaders, product teams, and software vendors?

Historically, white-hat security researchers who discovered vulnerabilities faced legal threats or retaliation under broad anti-hacking laws such as the Computer Fraud and Abuse Act (CFAA) in the U.S.

The joint guidance asserts that an effective Vulnerability Disclosure Policy (VDP) must include explicit "safe harbor" provisions. Organizations are instructed to provide legal assurances that good-faith research aligned with the VDP is authorized, will not result in legal action, and will be defended by the company if targeted by a third-party lawsuit.

Sample Safe Harbor Provision (Joint Guidance):

"If you make a good-faith effort to comply with this policy during your security research, [SUPPLIER NAME] will consider your research to be authorized... and will not recommend or pursue legal action related to your research."

The authoring agencies directly challenge stealthy security practices that obscure risk from end-users.

No silent fixes: Silently patching a vulnerability without mentioning its existence in release notes leaves customers unaware of their exposure window.
No blanket NDAs: Forcing researchers into non-disclosure agreements or restrictive gag orders damages trust and prevents broader industry learning.
Public transparency: Suppliers should publish machine-readable security advisories (such as CSAF) and issue Common Vulnerabilities and Exposures (CVE) identifiers for both externally reported and internally discovered vulnerability classes.

The joint guide outlines a procedural checklist for building a compliant CVD workflow:

Publish a VDP & security.txt file: Discovery & ingestion
Acknowledge and triage: Target 2-3 business days
Remediate & assign CVE IDs: Fix & validate
Coordinate public disclosure: Coordinated release

Host an unrestricted, public Vulnerability Disclosure Policy (VDP) on your website. Deploy an RFC 9116-compliant security.txt file to give researchers a standardized, machine-readable contact vector.

Set up a dedicated ingestion team (separate from standard customer support channels to prevent leaks or dropped reports). Acknowledge receipt within 2–3 days and use decision frameworks like SSVC (Stakeholder-Specific Vulnerability Categorization) to assess technical risk.

Develop patches or mitigations and share them back with the researcher for verification. Assign CVE IDs with detailed root cause mappings (CWE) and CVSS v4.0 metrics. If your organization isn't a CVE Numbering Authority (CNA), apply to become one.

Establish a reasonable remediation timeline with the researcher. Simultaneously issue the patch, release public security advisories (preferably using CSAF), and credit the researcher for their work.

While the guide offers best practices, global regulatory frameworks are rapidly turning these recommendations into mandatory compliance benchmarks.

U.S. Binding Operational Directive 20-01: Requires U.S. Federal Civilian Executive Branch agencies to develop and publish clear vulnerability disclosure policies.
EU Cyber Resilience Act: Requires software suppliers operating in the European Union to maintain documented vulnerability disclosure policies.
CISA Secure by Design Pledge: Encourages software manufacturers to publicly commit to launching vulnerability disclosure programs and reducing recurring vulnerability classes.

What should software suppliers do next?

If your organization develops commercial software, open-source tools, or manages internet-facing web applications, the global security community expects you to act.

Audit your entry points: Ensure researchers can easily reach your security team without hitting customer support walls.
Review legal language: Work with internal counsel to implement clear legal safe harbor language.
Leverage intermediaries when needed: If your internal team lacks the capacity to handle report triage, leverage national CSIRTs (like CISA or JPCERT/CC) or third-party bug bounty coordinators to manage the process.

By establishing a transparent CVD program, vendors turn external security researchers from potential legal adversaries into powerful force multipliers for product security.

The Evolution of Ransomware in 2026: Key Takeaways from Global Report

CamS@secureworld.io (Cam Sivesind) — Tue, 21 Jul 2026 17:20:29 GMT

The ransomware landscape is undergoing a significant transformation. While cybercriminals continue to extract millions from impacted organizations, sustained investments in defensive measures are finally yielding better outcomes.

Sophos released The State of Ransomware 2026, its seventh annual report analyzing the real-world experiences of 2,158 IT and cybersecurity leaders across 17 countries. The data reveal a story of costly impact paired with genuine defensive progress.

For executives and board members, the report highlights two distinct trends: the operational financial costs of recovery are climbing, even as ransom demands and payments drop drastically.

Over the last two years, organizations have gotten significantly better at negotiating with attackers and refusing outrageous extortion attempts.

Demands down 65%: The median ransom demand fell to $698,000, down from $1.32 million in 2025 and $2 million in 2024.
Payments down 62%: The median ransom payment dropped to $769,000 (down from $1 million in 2025).
Negotiation leverage: 51% of organizations that paid a ransom negotiated a discount off the original demand. The median payment was 90% of the initial demand.
Resilience through backups: The proportion of victims paying a ransom fell to 48%, while 66% recovered encrypted data using backups—a 12% jump from 2025. Here are some metrics from 2024, 2025, and 2026, for comparison's sake:
- Median ransom demand: 2024: $2M; 2025: $1.32M; 2026: $698K
- Median ransom payment: 2024: N/A; 2025: $1M; 2026: $769K
- Used backups to restore: 2024: 68%; 2025: 54%; 2026: 66%
- Paid ransom to restore: 2024: 56%; 2025: 49%; 2026: 48%

"This data confirms what we've been saying: 79% of ransomware attacks start with identity—nearly double malicious email and phishing combined. That's exactly why those like us in the industry have been ringing the identity bell for years," said Chandra Gnanasambandam, CTO at SailPoint. "This is the new normal. Attacks that once took a year to succeed now take about an hour, cybercrime has industrialized, and with 95% of access still standing rather than granted just in time, identity is the obvious weak point. It's why security is undergoing one of its biggest shifts, moving from 25 years of human-centered defense to a human-plus-AI world that demands adaptive identity and zero standing privilege as baseline."

While paying ransoms is becoming less common, recovering from an attack isn't getting cheaper. Excluding any ransom paid, the average cost to recover from a ransomware attack rose 11% to $1.7 million (up from $1.53 million in 2025). Downtime, device replacement, network fixes, and lost revenue remain the true drivers of financial damage.

For defenders on the front lines, the 2026 report marks a structural shift in how ransomware gains access to target networks.

After three consecutive years as the top entry vector, exploited vulnerabilities dropped 14 percentage points to 18%. Instead, identity compromise is now the leading delivery mechanism.

Email-based attacks rule: Malicious email (26%) and phishing (24%) now account for half of all ransomware root causes.
Identity overlap: 67% of ransomware victims confirmed their ransomware incident was directly tied to their organization's most significant identity breach.
MFA alone isn't stopping attacks: In incidents where compromised credentials were the root cause, 97% of organizations had MFA deployed in some capacity. Attackers are actively exploiting gaps in partial rollouts or bypassing traditional MFA methods.

The survey revealed that perimeter security devices are crucial for stopping payloads before encryption occurs.

61% of firewalls detected the attack before the ransomware payload was deployed.
When a firewall failed to identify the attack, 71% of organizations suffered full data encryption, compared to 50% when detected early.
High-value targets: Attacks starting with an exploited firewall vulnerability saw higher ransom demands, with 59% asking for $1 million or more.

"Stolen credentials are now the dominant ransomware entry point, and the trend is accelerating. Once attackers obtain a legitimate identity, they can move through an environment undetected, escalating privileges and staging ransomware before most teams know something is wrong," Shane Barney, CISO at Keeper Security. "Organizations need to recognize that identity is now the primary security perimeter. Strong password policies, MFA, and continuous monitoring remain foundational, but they're no longer sufficient on their own. Security teams need visibility into who is accessing critical systems, whether that access is appropriate and how privileged accounts are being used. Applying least-privilege principles, eliminating standing administrative access and continuously validating identities significantly reduces the opportunities attackers have to abuse stolen credentials."

Barney added, "The goal isn't just stopping the initial breach. It's limiting the blast radius when credentials are compromised. Organizations that can't see who has access to what, and can't revoke it fast, will keep finding out after the fact. That's what zero trust and strong identity governance are designed to prevent."

Ransomware is no longer just a technical issue—it carries severe human costs and impacts the everyday services communities rely on.

The stress placed on defenders behind the scenes is near-universal. Ninety-nine percent of organizations that had data encrypted reported lasting impacts on their IT and cybersecurity personnel.

41% reported heightened anxiety and stress regarding future attacks.
40% faced increased pressure from senior leadership.
21% saw their entire IT/cybersecurity leadership team replaced as a direct consequence.

Public sector and critical services face the highest pressure

Not all sectors fare equally when hit by ransomware. Organizations providing vital public services were the most likely to pay ransoms due to acute pressure to restore operations.

Local/State Government: 72% paid the ransom.
Media, Leisure, & Entertainment: 64% paid the ransom.
Retail: By contrast, only 32% of retail organizations paid, proving far more willing to rely on backups and weather operational downtime.

To stay ahead of AI-augmented threats and identity-based intrusions, Sophos recommends that organizations focus on the following foundational controls.

Prioritize Identity Threat Detection & Response (ITDR): Audit human and non-human credentials regularly and ensure comprehensive MFA implementation across all access points.
Focus heavy defenses on email: Deploy advanced filtering, enforce email authentication protocols (DMARC, DKIM, SPF), and run realistic phishing simulations.
Integrate telemetry via XDR/MDR: Connect firewall telemetry to Managed Detection and Response (MDR) or Extended Detection and Response (XDR) tools to catch suspicious lateral movement before encryption happens.
Maintain offline, immutable backups: Regularly test data restoration protocols to ensure your organization can recover without negotiating with threat actors.

We asked some solution provider leaders for additional comments.

James Maude, Field CTO at BeyondTrust, said:

"In order to effectively deal with ransomware and other threats, we need to invest more in shifting left. We must think more about securing identities and access to reduce our attack surface and blast radius in the event of compromise, rather than just thinking post-breach. Ransomware and other threats are only as effective as the privileges and access they manage to acquire. Therefore, if we can implement better hygiene and focus on least privilege, then threat actors are far less likely to ransomware us in the first place."

Trey Ford, Chief Strategy and Trust Officer at Bugcrowd, said:

"Criminals have established a scalable business model, and we expect to see ransomware attack volume continue to grow. We also need to bear in mind that there will be a gap in reported incidents versus overall ransomware incidents. Larger targets, with bigger payout potential, will have seen the most aggressive corporate investment (process and technology) mitigating exposure to this attack pattern—it is still an unsolved space."

Mika Aalto, Co-Founder and CEO at Hoxhunt, said:

"Phishing is rarely the end goal. It's typically the front door to something much bigger, including data theft, cloud compromise, or ransomware. Here's an analogy: If ransomware is the explosion, phishing is often the spark."

"Recent research found a step change at the turn of 2025 to 2026, when AI-generated phishing surged 14-fold almost overnight. The big shift isn't brand-new tactics and zero-day messaging, it's the modernization of old attacks. Traditional phishing kits are being upgraded with cleaner formatting, better writing, and more personalized messaging that can be generated at scale. Phishing never really went away, it simply got an upgrade. With that being said, people are trained to obey authority, and phishing attacks are designed to push people into bypassing normal checks. Organizations need to normalize 'see something, say something' behavior and make verification frictionless."

"Phishing has evolved beyond static text, and awareness must do the same. The entire concept of 'security awareness training' is outdated if it stops at awareness. The next generation of defense is behavioral, not informational. We're moving from telling people what to do to shaping what they actually do, in real time. We are building an essential set of security reflexes and instincts."

The DockSec Series, Part 3: Hands-On Scanning—Dockerfiles, Images, and Compose

Advait Patel — Tue, 21 Jul 2026 13:33:01 GMT

The first two articles in this series made the case for contextual remediation and explained the architecture that delivers it. This one is entirely practical. We will install DockSec, scan a deliberately vulnerable Dockerfile, scan a built image, and scan a full Docker Compose stack—reading the real output as we go.

Installation

DockSec is on PyPI:

Two external scanners are required: Hadolint for Dockerfile linting and Trivy for vulnerability scanning. Docker is needed for image scans, and Docker Scout is used when present. DockSec can install the scanners for you:

A deliberately bad Dockerfile

To see DockSec work, we need something worth scanning. Here is a Dockerfile that commits several common sins on purpose:

An unpinned base image, two hardcoded secrets, ADD instead of COPY, an SSH server and port 22 exposed, no non-root user, no health check. A textbook problem set.

The fastest useful scan: --scan-only

If you just want the findings and a score with no API key and no model, run scan-only:

DockSec runs Hadolint, prints the lint issues with file and line numbers, computes a local security score, and ends with a consolidated summary: a severity table, the score with a rating, a "quick take" action block, the reports it wrote, and a suggested next command. For this file, the configuration penalties—hardcoded credentials, root user, sensitive port, ADD—pull the score down hard. Hardcoded secrets alone cap the overall score, so this file lands firmly in "POOR" rather than being averaged into a deceptively middling number.

Scan-only mode is the one to reach for in fast CI paths and locked-down environments. It needs nothing but the local scanners.

The full picture: AI-powered analysis

To get the plain-English explanations and line-level fixes, add a provider. DockSec supports OpenAI, Anthropic, Google, and Ollama. With an Anthropic key exported:

Now the output leads with an AI analysis section grouped into vulnerabilities, best practices, security risks, exposed credentials, and remediation steps. Instead of a bare CVE list, you get statements like "hardcoded production API key exposed in image ENV layers—extractable via docker history" alongside a concrete fix: remove the ENV secret, inject it at runtime, and pin the base image to a slim, digest-referenced version. The exposed-credentials section calls out API_KEY and DB_PASSWORD by name and line. This is the difference between a scanner and a review.

If you only want the AI narrative without the scanner stack, for a quick Dockerfile critique, use: --ai-only.

Scanning a built image

Dockerfiles are static; images are what actually ship. To scan an image, provide it with -i:

This runs the AI Dockerfile analysis and the full image scan: Trivy enumerates CVEs, Docker Scout compares against the base image and suggests an updated one. The severity table now reflects real CVE counts, which for an old base image can run into the hundreds of critical and high findings.

To scan an image with no Dockerfile at all—a published image, a third-party image, anything you did not build—use image-only mode:

The Docker Scout summary here is often the most actionable single line in the whole run: it shows your target's counts, the base image's counts, and an updated base image with dramatically lower counts. Frequently, the highest-leverage fix for an image is simply moving to a newer base tag, and Scout hands you that on a plate.

Controlling severity

By default, the image scan reports CRITICAL and HIGH. Widen or narrow it with --severity:The severity you request is part of the cache key, so widening from CRITICAL,HIGH to include MEDIUM correctly triggers a fresh scan rather than replaying a narrower cached result. You can also set a default with the DOCKSEC_DEFAULT_SEVERITY environment variable.

Scanning a Docker Compose stack

Real applications are rarely one container. DockSec scans an entire Compose file and every service in it:
Two things happen. First, DockSec applies a curated set of Compose-level rules—privileged mode, host networking, missing resource limits, and other orchestration misconfigurations. These findings flow into the same results structure as image vulnerabilities. Second, it fans out across the services, scanning each service's image and, where a build context is defined, its Dockerfile. If you omit the path, --compose auto-detects a compose file in the current directory.

Compose findings count toward the security score in their own right, so a stack with several critical misconfigurations is scored as the serious problem it is, even if the underlying service images happen to be clean or could not all be pulled locally.

Reading the summary

Every scan ends with the same consolidated summary, and it is worth learning to read at a glance.

Severity table: the count of findings by level
Security score: 0-100 with a rating from POOR to EXCELLENT
Quick take: the few things that matter most: total findings, the top lint issue, any exposed credentials, and a nudge toward AI analysis if you ran scan-only
Reports: which formats were written and where
Next: a suggested follow-up command

For quieter output, --quiet reduces everything to warnings, errors, and the summary. For plain output in logs or terminals without color support, --no-color (which also honors the NO_COLOR environment variable) strips the styling.

Where reports land

By default, reports are written to ~/.docksec/results/. Override the destination per run with --output-dir ./reports, or globally with the DOCKSEC_RESULTS_DIR environment variable. Choose which formats to write with --format; more on reporting and machine-readable output in Part 4, where we take everything here and put it into a pipeline.

With scanning under your belt, the natural next question is how to make it automatic and enforceable. That is where we go next: gating builds, SARIF, and baselines.

This is the third in a five-part series. Watch for coming installments on Tuesdays.

Quantum Security, Part 1: Post-Quantum Cryptography Isn't a 2035 Problem

Neha Srivastava — Mon, 20 Jul 2026 18:05:49 GMT

For years, quantum computing has been treated as a distant research problem, something that would "eventually" matter to cybersecurity, sometime in the 2030s. That assumption is now the single biggest risk in most organizations' security roadmaps.

Here's the uncomfortable truth: you don't need a working quantum computer to be at risk today. You need an attacker willing to wait.

The threats already taking shape: Harvest Now, Decrypt Later (HNDL) and future signature forgery

This is the reason post-quantum cryptography (PQC) can't wait for "someday."

While Harvest Now, Decrypt Later (HNDL) is already a concern—where attackers collect encrypted data today with the intent of decrypting it once cryptographically relevant quantum computers become available—organizations must also prepare for the future risk of digital signature forgery. Quantum computers capable of breaking widely used public-key algorithms could allow attackers to forge identities, impersonate trusted entities, sign malicious software, and undermine authentication, code signing, financial transactions, and software updates. Together, these threats underscore why organizations need to transition to PQC for both encryption and digital signatures.

Adversaries—nation-states, in particular—are already recording encrypted traffic and storing it. Not because they can decrypt it today, but because they're betting they will be able to eventually. The moment a cryptographically relevant quantum computer exists, the stored data becomes retroactively readable.

If your organization holds data with a long confidentiality shelf life, government records, defense communications, health data, financial records, IP, or critical infrastructure designs, that data may already be sitting in an adversary's archive, waiting for the key to unlock it.

You can't patch this after the fact. The only defense is making sure the data isn't decryptable in the first place, which means migrating before the threat becomes real, not after.

Why 'we'll deal with it later' doesn't work

Every executive asks a version of the same question: if quantum computers aren't practical yet, why spend now?

The answer comes down to one fact that consistently surprises leadership teams: cryptographic migration is not a software patch; it's a multi-year transformation.

Most enterprises are carrying:

Thousands of applications and millions of digital certificates
Legacy systems and industrial equipment with decade-plus lifecycles
Medical devices, connected vehicles, and OT environments
IoT infrastructure spread across global supply chains

None of this gets swapped out overnight. Real migration requires cryptographic discovery, dependency mapping, vendor coordination, hardware refresh cycles, compliance testing, and operational validation—a process most industries should expect to take years, not months.

Fact: Wait until quantum computers are commercially practical, and you've already run out of runway.

Why governments are treating this as a race

National governments aren't investing billions in quantum-safe cryptography as a hedge; they're treating it as core infrastructure protection. Defense, intelligence, energy grids, financial systems, healthcare, and telecommunications all depend on cryptography that quantum computing threatens to unravel.

This has become a genuine global competition; some call it the next space race. Nations leading the PQC transition will be the ones best positioned to defend their infrastructure and protect digital sovereignty when the threat matures.

And because modern security is a supply chain problem, this isn't contained to any one country or company. One vendor that fails to modernize can create a weak link that ripples through every organization downstream of it.

What organizations should actually do now

Waiting for certainty isn't a strategy; it's a delay tactic. The organizations that come out ahead will be the ones building crypto-agility: the ability to swap cryptographic algorithms without tearing down and rebuilding entire systems.

Here's the roadmap I'd walk any leadership team through:

1. Establish governance and executive sponsorship: Assign clear ownership, define roles, and build an enterprise-wide PQC strategy. This doesn't move without a mandate from the top.

2. Conduct a full cryptographic inventory: You can't migrate what you haven't found. Identify every use of RSA, ECC, and other quantum-vulnerable algorithms, and map how they're interdependent.

3. Assess business risk and prioritize: Classify data by sensitivity, identify business-critical systems, and specifically flag anything exposed to HNDL risk. Not everything migrates at once; prioritize by exposure.

4. Design for crypto-agility: Abstract cryptography out of hard-coded implementations, modernize key and certificate management, and enable hybrid cryptographic approaches so you're never locked into a single algorithm again.

5. Evaluate vendor and supply chain readiness: Push your vendors for their PQC roadmaps now. Build PQC requirements into procurement so readiness becomes a contractual expectation, not a hope.

6. Test and validate: Pilot NIST-standardized PQC algorithms in real environments. Validate performance and interoperability before you rely on them in production.

7. Execute the migration roadmap: Start with high-risk systems, then move through PKI and identity infrastructure, applications, networks, and cloud services, tracking progress the whole way.

8. Operationalize it: Update security operations, monitoring, and incident response playbooks. Train your teams. Update the policies that assume today's cryptography is permanent.

9. Embed it into enterprise strategy: PQC shouldn't be a side project; it belongs in your enterprise architecture and technology lifecycle planning, not bolted on after the fact.

10. Measure and iterate: Define KPIs, run periodic readiness assessments, and keep refining as NIST guidance and regulatory expectations evolve.

The bottom line

We don't wait for a breach to install firewalls. We don't wait for ransomware to back up our data. We don't wait for an insider threat to build zero trust. Post-quantum cryptography deserves the same posture: prepare before the threat is real, not after.

The question every security leader should be asking isn't if their organization will migrate to PQC. It's whether they'll be ready when the transition becomes non-negotiable or scrambling to catch up while competitors who started early are already secure.

Next in this series (Part 2), I will cover the technical challenges of PQC migration, performance trade-offs, hybrid implementation pitfalls, and where most organizations underestimate the effort.

This article appeared originally on LinkedIn here.

How AI Is Redefining Security in Cloud Hosting Infrastructure

trayalex812@gmail.com (Alex Tray) — Sun, 19 Jul 2026 13:43:00 GMT

Hackers are getting smarter every day. And the numbers back this claim.

Cloud intrusions jumped 136% in the first half of 2025 compared to all of 2024. Six months versus 12. That's more than double. And it's not just a trend, it's a problem.

If you're still running the old security playbook on your hosting infrastructure, you're bringing a flip phone to a smartphone fight.

Attackers have upgraded. Most defenses haven't.

They're automated, AI-assisted, and moving at a speed no manual review cycle was built to handle. And some hosting providers are starting to fight back the same way, by embedding AI directly into their infrastructure.

What does that look like in practice? Keep reading.

Why traditional cloud hosting security is no longer enough

Most security teams feel like they're doing everything right. Scans scheduled, patches going out, firewalls up. And yet, somehow, breaches still happen.

Here's why.

IBM's 2025 Cost of a Data Breach Report puts the average breach detection time at 241 days. Eight months. An attacker sitting inside your infrastructure for eight months before anyone notices, quietly moving around, accessing data, escalating privileges.

And by the time the alert fires, the damage is long done.

Now, here's the part that might surprise you. Most of these breaches aren't the result of some genius-level hack. SentinelOne's 2026 research found that 95% of cloud security failures come down to misconfiguration. Simple, avoidable mistakes like:

A storage bucket left public after a project wrapped up
An old team member's API key nobody got around to revoking
An access policy set up in a hurry that's been sitting there ever since

You may think of it like locking your front door but leaving the window wide open. The lock looks great; the window is the problem.

Scheduled scans made sense when you had one server and threats moved slowly. Now, you're juggling dozens of servers, hundreds of configuration points, sometimes across multiple cloud providers. A scan running every 12 hours misses everything that happens in between, and manual patching only works if someone actually remembers to do it.

The old model wasn't bad; it just wasn't built for this.

How AI detects threats traditional tools miss

Traditional security tools work from a list. If something matches a known bad pattern, it gets flagged. Everything else? Gets through.

The problem is most modern attacks don't look like attacks, at least not right away.

An unusual login at 4 a.m. Outbound traffic that's just slightly higher than normal. A server config that shifted by one setting after a routine update. None of these trip a rule-based alert on their own. But together? They can mean someone is already inside.

Think of it like a bank security guard who's only trained to stop people on a wanted list. Great at catching known criminals. Completely blind to the guy who's been casing the place for weeks, looking perfectly normal every single time.

AI works differently. Instead of matching patterns against a known list, it learns what normal looks like across your entire infrastructure and watches for anything that doesn't fit—not on a schedule, but constantly.

According to CIO's 2026 state of AI security report, AI-assisted security workflows have cut investigation times from more than 30 minutes to under two minutes in some scenarios. For a live threat, that's the difference between catching something early and doing damage control.

Worth noting, too, 66% of security leaders say they lack confidence in their ability to detect and respond to cloud threats in real time. AI doesn't replace those teams. It gives them visibility they just didn't have before.

Real-time anomaly detection

Every server has a behavioral fingerprint. Typical traffic volumes, usual login times, predictable resource usage. When you know what normal looks like, anything outside of it stands out immediately.

That's the whole idea behind anomaly detection. It's not looking for known threats. It's looking for anything that doesn't fit.

Say your server typically gets 500 requests per hour between 9 a.m. and 5 p.m. At 3 a.m. on a Tuesday, it suddenly spikes to 4,000. No rule-based tool flags that as a threat. But an AI that's been watching your server for weeks knows that's not normal, and it raises the alarm before anyone has even had their morning coffee.

IBM's 2025 Cost of a Data Breach Report found that organizations using AI-powered security identify breaches 108 days faster than those using traditional methods, cutting average breach costs by 43%.

For cloud hosting specifically, this means monitoring disk health, web stack performance, host behavior, and access patterns all at once. Not in rotation but simultaneously, around the clock.

No human team can realistically do that across dozens of servers. AI can.

Misconfigurations and unauthorized access

We touched on misconfigurations earlier but it's worth going deeper because this is where most breaches actually start.

Picture a busy agency managing 30+ client sites. Someone spins up a new server for a project, sets permissions quickly to get things moving, and means to clean it up later. Later never comes. Six months down the line that same misconfigured server is an open door.

Datastack Hub's research found 70% of misconfigurations go undetected for weeks or months before anyone exploits them. The average detection time sits at more than 180 days.

Manual audits can't keep up with this. Not when you're managing multiple servers, dozens of applications, and a team that's constantly deploying and updating things. Something will slip through.

AI monitors configuration state continuously. The moment something drifts from what it should be, it gets flagged. No waiting for the next scheduled audit. No hoping someone catches it in a manual review.

The same research found that automated scanning prevents roughly 40% of potential misconfigurations from escalating into actual breaches. That's not a small number when you consider that a single misconfigured access policy can expose an entire server.

The security shift from reactive to predictive

Every security tool built in the last decade was designed to react. Something goes wrong, an alert fires, someone investigates. That's the model almost every hosting environment still runs on.

The problem with reactive security is baked into the name. By the time you're reacting, something has already happened.

According to CrowdStrike's 2026 Global Threat Report, the average attacker breakout time—meaning the time it takes to move from initial access to the rest of your infrastructure—is just 29 minutes. Your reactive alert cycle wasn't built for that.

Predictive security flips the model. Instead of waiting for something to break, AI continuously maps your environment, scores risk in real time, and flags conditions that historically lead to an attack before one actually happens.

A simple way to think about it: reactive security is a fire alarm. It tells you the building is burning. Predictive security is a smoke detector that catches the smell before the flame. And AI-driven hosting infrastructure is the system that automatically vents the room before you even reach for the extinguisher.

Gartner predicts that organizations adopting proactive threat management will be three times less likely to experience breaches by 2026 compared to those still running reactive controls.

The shift isn't just about speed. It's about getting ahead of the problem instead of always cleaning up after it.

AI-driven security in action: what it looks like on a live hosting platform

All of this sounds great in theory. But what does it actually look like when AI security is built into a hosting platform you use every day?

Cloudways is one example of what this looks like in practice. Rather than offering AI as a separate add-on, it's built directly into the infrastructure layer.

Most hosting platforms send you an alert when something goes wrong. You then spend the next 20 to 30 minutes figuring out what caused it, what it affects, and what to do next. And the cycle gets quite expensive and too fast for a team managing dozens of client sites.

Cloudways built AI Copilot to change that. It monitors server health continuously across webstack performance, disk, inodes, and host behavior. When something deviates, it doesn't just raise a flag. It runs root cause analysis within seconds and tells you exactly what happened, why it happened, and what to do about it.

As Suhaib Zaheer, SVP of Managed Hosting at DigitalOcean, said, the goal is "redefining what it means to be truly managed."

The SmartFix feature takes it one step further. Flagged issues get resolved in a single click, with no server administration knowledge required. One Cloudways customer managing 180 sites reported saving 15 hours in a single month after adopting it.

And with Remote MCP launching in Q2 2026, users can connect AI agents directly to their hosting environment, letting security and maintenance workflows run from detection through to resolution without manual intervention on routine issues.

It's not a perfect system. But it's a meaningful example of what happens when AI stops being a marketing word and starts being infrastructure.

The limitations AI still hasn't solved

AI in cloud security is genuinely impressive. But it would be doing you a disservice to wrap this up without talking about where it still falls short.

False positives are still a real problem

AI flags anomalies it can't always fully contextualize. A traffic spike from a legitimate marketing campaign looks suspicious to an algorithm that doesn't know you just sent out a newsletter. Someone has to review those alerts. That someone is still human.

AI is only as good as what it's been trained on

Novel attack vectors, ones it's genuinely never encountered before, can slip through. Attackers know this. Some are actively researching ways to move in patterns that look normal to AI systems. It's an arms race, and nobody's won it yet.

Governance is lagging badly behind the tools

According to IBM's 2025 research, organizations that suffered AI-related security incidents were significantly more likely to lack proper AI access controls. The tools are ahead of the frameworks meant to oversee them.

And then there's the human layer

AI can catch a misconfigured access policy. It can't stop someone with legitimate credentials from making a bad decision. Insider threats, social engineering, and phishing attacks that lead to valid logins, these are still largely human problems that need human solutions.

AI handles the volume, the speed, and the coverage problem. The judgment, the governance, and the accountability layer still sits with your team.

What security professionals should expect from hosting platforms in 2026 and beyond

The hosting layer used to be infrastructure. You picked it for speed, uptime, and price; security was something you bolted on separately.

That's changing. And if you're evaluating hosting platforms in 2026, security capabilities built into the platform itself should be on your checklist.

Here's what to actually look for:

Continuous monitoring, not scheduled scans. If your hosting platform is only checking in periodically, you already know the gaps that creates.
Root cause analysis, not just alerts. An alert that tells you something is wrong without telling you why just creates more work for your team.
Automated remediation with human oversight. One-click fixes for routine issues free your team up for the decisions that actually need judgment.
Configuration drift detection. Given that 95% of breaches start with misconfiguration, any platform not watching for this in real time is leaving a window open.
Agent and MCP integrations. As AI agents become a standard part of how teams operate, hosting platforms that support them natively will have a significant advantage.

The global cloud security market is projected to hit $37 billion by 2026 according to Statista. The investment is clearly there; the question is whether hosting platforms are building security intelligence into their core or just putting it on the brochure.

The ones doing it properly aren't hard to spot. They're the ones where security stops being a feature you configure and starts being something that runs quietly in the background—watching, learning, and acting before you even know there's a problem.

The CMMC Phase II Suspension: What It Means for Defense Contractors

CamS@secureworld.io (Cam Sivesind) — Thu, 16 Jul 2026 17:12:58 GMT

The defense contracting world received a major shockwave on July 13, 2026, when the U.S. Department of War (DoW) announced the immediate suspension of the Cybersecurity Maturity Model Certification (CMMC) Phase II requirements. Originally scheduled to take effect on November 10, 2026, the sudden pause has left many enterprise leaders wondering: Is CMMC dead, or has the clock just paused?

Here is a breakdown of what this suspension actually means, what the U.S. government is saying, and what organizations should be doing right now.

The DoW has halted the transition to Phase II of the CMMC rollout, alongside all subsequent implementation milestones (Phases III and IV).

To understand why this is a big deal, one must look at the structural bottleneck that was looming. Phase II was set to mandate that any contractor handling Controlled Unclassified Information (CUI) obtain a third-party cybersecurity certification from an accredited Certified Third-Party Assessment Organization (C3PAO).

But, the reality of that requirement quickly crashed into logistical limits:

The bottleneck: There are only about 100 authorized C3PAOs in existence, tasked with auditing more than 100,000 defense contractors.
The economic impact: Compliance costs were ballooning, and Small Business Administration (SBA) data confirmed that innovative small and medium-sized businesses were actively leaving the Defense Industrial Base (DIB) because they couldn't afford the compliance overhead.

In response, the DoW established a CMMC Reform Task Force to conduct a comprehensive, 60-day review of the program.

During a press briefing, DoW Chief Information Officer Kirsten A. Davies was refreshingly candid about the operational reality of the rollout. Pointing to the massive imbalance between available auditors and companies needing certification, she noted, "The math just simply doesn't math."

Davies and other department officials made it clear that the suspension is designed to reduce the administrative "red tape" paralyzing the supply chain, rather than to lower the government's cybersecurity expectations.

Additionally, Under Secretary of War for Acquisition and Sustainment Michael Duffey emphasized that this pause aligns with broader acquisition reform goals to prioritize speed to capability and lower barriers for innovative commercial partners.

Brian Haugli, CEO of SideChannel, had this to say on LinkedIn:

"Watch what happens next. Thousands of defense contractors are about to reveal whether they were building security programs or buying certificates.

If your entire cyber effort was aimed at passing a CMMC assessment, you just lost your reason to keep going. The budget gets pulled, the project stalls, and in 60 days you'll be scrambling to restart whenever the new requirements drop.

If you built a program to actually manage risk, today changed nothing. 800-171 is still enforced. DFARS 7012 is still in your contracts. Adversaries targeting the DIB didn't read the press release and stand down.

This is the problem with compliance-driven security. The requirement moves and the whole thing collapses, because it was never yours to begin with.

Same advice I've given for years, and it holds up on days like this: build the program for the risk, let the certification fall out of it. Not the other way around.

The contractors who did that are fine this morning. The ones who didn't are calling their consultants asking if they can get a refund."

The changes do not alter the underlying security rules/requirements.

It is incredibly important to separate the certification process from the security standard. While the third-party audit requirement (Phase II) is paused, the requirement to protect sensitive government data remains legally binding.

Here is what is active versus what is suspended:

CMMC Element, Phase I (Self-Assessments): Active; You must still perform annual self-assessments, submit scores to the Supplier Performance Risk System (SPRS), and submit annual affirmations.
Phase II (Third-Party Audits): Suspended; The November 10, 2026, deadline for mandatory C3PAO audits is on hold indefinitely.
DFARS 252.204-7012: Active; This clause remains in your contracts. You are still contractually obligated to safeguard covered defense information.
NIST SP 800-171 Rev 2: Active; This remains the active technical standard that you must implement and self-assess against.

What should enterprises do right now?

If your business interacts with the defense supply chain, treating this pause as "time off" from cybersecurity is a dangerous mistake. Government-led spot audits are still active, and false self-attestations carry massive legal and financial risks under the False Claims Act.

Instead, adjust your strategy to focus on these four actions.

1. Do NOT stop your NIST SP 800-171 implementation: Immediate Priority

Because Phase I self-assessments are still active, you must continue remediating gaps in your system security plans (SSPs). The core technical controls (like access management, MFA, and incident response) are still mandatory.

2. Keep your SPRS scores updated: Ongoing Maintenance

Ensure your organization's self-assessment scores in the SPRS database are accurate and updated. Contracting officers will still verify your Phase I self-assessment status before awarding contracts.

3. If an audit is in progress, finish it: Strategic Choice

If your organization was already preparing for or actively undergoing a C3PAO assessment, stopping now might cost you more than it saves. A strong security posture is still a massive competitive differentiator.

4. Participate in the public RFI: Deadline is August 14, 2026

The DoW has opened a public Request for Information (RFI) to gather direct feedback on compliance costs and how companies are using commercial tools to meet these goals. Make your voice heard before the August 14 deadline.

CMMC is not dead; it is being rebuilt to be more practical. Expect the Reform Task Force to return in autumn 2026 with a updated framework that relies more heavily on self-attestation and existing commercial tools. In the meantime, focus on real cybersecurity hygiene rather than the bureaucratic paperwork.

What AI Appreciation Day Actually Means for Enterprise Security

CamS@secureworld.io (Cam Sivesind) — Thu, 16 Jul 2026 12:38:00 GMT

On July 16, social media feeds will inevitably fill up with automated corporate posts celebrating Artificial Intelligence (AI) Appreciation Day. For the general public, it's a casual moment to marvel at image generators or chat assistants. For enterprise cybersecurity and tech leaders, however, it serves as an annual checkpoint to audit how the balance of power between defensive and offensive AI is shifting inside their infrastructure.

But where did this day come from, and why should security professionals treat it as more than just another commercial marketing event?

Unlike traditional technology milestones anchored to a specific scientific breakthrough, AI Appreciation Day has an unexpectedly eccentric history.

The day was initially established in May 2021 by a company called A.I. Heart LLC, founded by Jason Kirton, a freelance advertising professional and science fiction writer. Intended as a way to promote a creative project involving a helpful, sentient AI named "EVE," Kirton officially registered the holiday via the National Day Calendar platform.

The core motivation behind the declaration wasn't purely commercial hype; it was heavily inspired by early calls from tech figures like Elon Musk demanding stricter AI regulation. Kirton—who famously lived in a tent on a beach outside of SpaceX's Starbase in Texas for a year to try to discuss AI ethics with Musk—envisioned the day as a structured moment of collective attention. He wanted humanity to pause and ask critical questions about AI alignment, ethics, and safety before our deployment habits became entirely calcified.

By 2023, the day gained mainstream traction as the launch of ChatGPT thrust large language models (LLMs) into the corporate spotlight.

As the observance rolls around, the implications of rapid AI integration diverge sharply depending on who is using the interface.

"AI Appreciation Day is an interesting concept, and while I respect the intent behind the day, I wonder if 'appreciation' is a bit premature," said KJ Haywood, Founder, CEO at Nomad Cyber Concepts, and Adjunct Cybersecurity Professor, Collin College, in Texas. "From my perspective, it should also serve as an annual reminder to evaluate an organization's AI security posture, governance maturity, and overall AI risk literacy. Organizations are presently adopting AI at an accelerated speed and still treating security and governance as something to address after deployment rather than as part of the process from the start. That gap creates unnecessary risk."

Haywood continued, "We're already seeing the impact through AI-enabled fraud, data exposure, and increasingly convincing social engineering attacks. At the same time, many organizations still believe AI governance is a policy, a framework, or the latest platform. It isn't. It's an ongoing business practice that helps organizations make better decisions, manage risk, and use AI responsibly."

For the general public: the UX revolution

To the average consumer, AI appreciation is defined by convenience and accessibility. AI has been quietly embedded into daily life through photo-editing algorithms, streaming recommendation engines, and natural-language search. It represents a shift where complex technical systems are now fully democratized, allowing anyone to code, create, or analyze data without needing a computer science degree.

For enterprises: the trust and security imperative

For the enterprise, the conversation has shifted entirely from model capability to trust infrastructure. Technology leaders aren't just appreciating what AI can build; they are managing the chaotic security footprint it leaves behind.

The enterprise reality of AI deployment is defined by three distinct challenges:

The shadow IT explosion: Recent enterprise research shows that the percentage of organizations unable to detect whether employees are using unsanctioned AI tools has nearly tripled. This visibility blind spot expands even further when autonomous AI agents are introduced into enterprise networks.
The over-privileged data problem: GenAI and agentic systems excel at scraping and indexing internal documents. If an enterprise has weak internal data access controls, an AI tool will quickly surface sensitive files—such as HR documents or proprietary code—to unauthorized employees who ask the right question.
The weaponization of social engineering: Defensive security teams are actively fighting AI-driven threats. Bad actors are using generative models to eliminate historical red flags like poor grammar, building highly convincing, localized phishing attacks that strike during global high-interest events.

AI Appreciation Day shouldn't be celebrated by looking backward at a marketing calendar. Instead, security leaders should use July 16 as an internal audit mechanism.

"Perhaps AI Appreciation Day shouldn't only celebrate what AI can do, but highlight those organizations that are placed on a 'Most Likely to Succeed' listing: those that treat security, governance, and risk as strategic priorities rather than afterthoughts," Haywood said.

Take the day to look beyond paper compliance policies. Cybersecurity professionals should evaluate active visibility into automated API calls; ensure data-centric permissions are tightly configured around internal vector databases; and implement technical guardrails capable of parsing autonomous agent behavior.

True appreciation for AI comes from understanding its power—and building the robust technical infrastructure required to keep it secure.

We asked several experts from cybersecurity solution providers for their take on the "holiday."

Ganesh Padmanabhan, CEO and Co-Founder of Autonomize AI, said:

"When people talk about appreciating AI, they often focus on what the technology can do. I think we should appreciate it for something much more important: its ability to give people their time and expertise back. In healthcare, some of our most experienced clinicians spend huge portions of their day navigating administrative processes instead of caring for patients. AI gives us an opportunity to change that. Not by replacing clinical judgment, but by making that expertise available more quickly, more consistently, and at a far greater scale. If AI allows a nurse to spend more time with patients instead of paperwork, or helps someone access treatment days or weeks sooner, that's something worth celebrating."

Rohit Gupta, CEO, Auditoria.AI, said:

"The first generation of enterprise AI proved that machines could generate answers. The next generation has to prove they can generate business outcomes. Finance is where that transition is happening first because every recommendation must be explainable, every action must be governed, and every result must stand up to scrutiny. That's why AI Appreciation Day is no longer about celebrating possibility. It's about recognizing that AI is becoming operational infrastructure for the modern Office of the CFO."

Karl Bagci, Director of IT and Information Security, Exclaimer, said:

"AI Appreciation Day is a good reminder that AI's greatest value isn't in replacing people. It's in removing repetitive work so people can focus on higher-value decisions. But AI is also exposing something many organizations have overlooked for years. Communication governance gaps that once affected a handful of messages can now be replicated at scale in seconds. AI hasn't created those problems. It's simply made them impossible to ignore. That's why organizations need to think about governance before they think about automation."

Paul Stokes, Co-Founder and CEO, Prevalent AI, said:

"AI deserves appreciation, but not blind admiration. It is has already changed the pace of cyber risk. Attackers can move faster, test more ideas, and find exploits at a scale that security teams were not built for. This does not make AI bad, but it makes AI-enabled visibility and governance essential. Businesses need to understand where AI is being used, which models they depend on, and where those dependencies create exposure. Companies need to do the hard work of analyzing both their use of AI, and the data that drives it, or they run the risk of becoming its victim."

Anoop Dawar, Chief Strategy Officer of Deepgram, said:

"We've seen Salesforce acquire Fin, SpaceX pay $60 billion for Cursor, and OpenAI stand up a $10 billion deployment company—three very different bets on the same scarce thing: teams that can make AI agents work reliably in the real world, not just in a demo. That capability has quietly become the most valuable asset in software, because these are probabilistic systems that drift and have to be measured and monitored continuously to stay accurate. And it gets hardest in voice—real-time, unforgiving, no second take—which is exactly where the next phase of this race will be won."

Don Boxley, CEO and Co-Founder of DH2i, said:

"I really like the idea of AI Appreciation Day. Not because AI needs a birthday, but because it provides a moment to take a step back and appreciate the holistic picture of all the components that go into making these applications work and bring value to our everyday lives."

"Generally, when people talk about AI, they almost always jump straight to the models. They want to talk about GPUs, NVIDIA, training, inference—all the 'sexy' stuff. That's fine and good. But AI doesn't know anything by itself. All that information that makes it so useful needs to come from somewhere. And for many organizations today, that's databases like SQL Server. The reality is, if the database goes down, AI doesn't suddenly become intelligent enough to work around it. It just stops being useful. So, this year on AI Appreciation Day, let's remember that while it is critical to spend time thinking about how to make AI smarter, easier to use, and faster, we need to also remember that none of that matters if the data can't answer when AI calls."

Ram Varadarajan, CEO at Acalvio, said:

"We're witnessing a significant shift in the cyber threat landscape, and it's more severe and unmatched than anything we've faced before. Multi-agent swarms are coordinating in real-time across reconnaissance, credential harvesting, and data exfiltration. We're facing exponential coordination where hundreds of specialized AI agents will operate simultaneously across our entire attack surface. Reactive defenses can't operate at machine speed, requiring a shift in the cybersecurity stack to preemptive, AI-driven strategies. AI fighting AI, paired with offensive deception technologies, is the emergent design to catch attackers off guard and cause them to make mistakes and disclose themselves. Organizations that adapt will recognize that defense is no longer about building higher walls. It's about becoming an unpredictable, moving target."

"Security teams can no longer rely on humans doing everything by hand. The model has to change to allow humans to direct AI-driven workflows, just as hackers do. It's fated to be a bot-on-bot duel forever. Teams should start small. Pick a few high-impact workflows where AI provides scale and speed, and humans supply judgment and oversight. Assume a machine-speed AI-augmented attacker or autonomous AI attack, and defend with machine-speed AI that leverages the adversarial AI's own vulnerabilities."

Amit Zimerman, Co-Founder and Chief Product Officer at Oasis Security, said:

"While AI is highly efficient in automating and scaling tasks, human expertise is necessary to interpret complex results, make critical decisions, and apply context-specific reasoning. Humans are essential for ensuring that AI-driven tools are used responsibly and for validating the results of AI processes, especially when it comes to the nuances of certain vulnerabilities or threat landscapes. AI also plays a significant role in 'shift-left' approaches by identifying security vulnerabilities earlier in the software development lifecycle. When integrated into offensive security measures, AI can detect and address issues before they make it into production, reducing the cost of remediation and improving the overall security posture of an organization."

Don't miss the SecureWorld Artificial Intelligence virtual conference on Wednesday, July 22. Attendees will hear from industry experts sharing practical insights on using AI effectively, navigating evolving security challenges, and preparing for what's next in an AI-driven world. Register to attend and earn 6 free CPE credits.

Why AI Is Actually Increasing the Cognitive Load on Cyber Teams

CamS@secureworld.io (Cam Sivesind) — Wed, 15 Jul 2026 11:25:00 GMT

For months, the prevailing enterprise narrative around artificial intelligence in cybersecurity has been a promise of automated relief: AI will ingest the alerts, parse the logs, and magically give overstretched security teams their time back.

But a newly-released research report from ISC2, "Rethinking AI's Impact on Cybersecurity Roles," shatters this simple efficiency myth. Based on a survey of 856 cybersecurity professionals actively working with AI, the data reveal a starkly different operational reality: AI isn't necessarily shortening the workday—it is shifting the cognitive burden toward a high-stakes game of algorithmic verification.

As ISC2 CEO Scott Beale put it, "AI is not replacing cybersecurity professionals; it is changing what the profession requires of them." For enterprises and security vendors, this transformation completely changes how we must approach human oversight, team stress, and early-career talent pipelines.

The validation tax: where the time really goes

The most striking finding in the ISC2 report is the emergence of what can be called a "validation tax." AI tools excel at compiling complex cybersecurity data at scale, but their outputs are far from infallible. In fact, an overwhelming 89% of respondents report having experienced AI recommendations that led to incorrect outcomes at their organizations.

Because the blast radius of an unverified, incorrect security action is so severe, practitioners are spending massive amounts of time auditing the machine:

65% of professionals report spending more time deciding when to trust or act on AI-generated recommendations.
63% report spending more time actively reviewing and validating AI outputs.

This means the early time savings gained from automated triage are frequently burned on the back-end during mandatory human verification.

This validation tax is also actively altering workplace stress. While 48% of respondents felt AI lowered their stress by handling repetitive work, nearly a third (32%) reported an increase in workplace anxiety. Crucially, those experiencing higher stress were significantly more likely to be the ones drowning in validation tasks—spending their days second-guessing whether an AI recommendation was a brilliant shortcut or a hallucinated vulnerability.

For corporate executives, the report highlights an uncomfortable operational paradox regarding risk and ultimate ownership.

When an AI model pushes a flawed security recommendation that leads to a catastrophic incident or an operational outage, who takes the fall? Fifty percent of organizations hold the human decision-maker ultimately accountable. Only 21% say it varies by severity, and nearly 18% admit there is structural ambiguity or zero clear ownership when things go sideways.

Who is accountable when an AI mistake causes a security failure?

Human decision-maker: 50%
Varies by severity: 21%
Ambiguity / no ownership: 18%

This creates a dangerous gap between human authority and accountability. If an enterprise expects its security analysts to carry the professional risk of an incident, those analysts must be given the explicit mandate, training, and operational buffer to slow down, challenge, and override AI assertions. Yet, the report notes that many practitioners are still pressured to act on AI security outputs without fully understanding the underlying logic.

What this means across the ecosystem

1. For enterprises: Re-evaluating the entry-level pipeline

A dominant concern in the industry has been that AI would eliminate the junior Tier-1 SOC analyst. The ISC2 data show a complex evolutionary pressure: while 56% say AI has reduced the pure need for legacy entry-level roles, 53% state that AI is actively creating entirely new types of early-career positions.

Junior professionals aren't being forced out; their roles are being re-platformed. Instead of manually sifting through raw logs, entry-level workers are now tasked with supervising models and validating initial outputs. Because of this, 62% of professionals emphasize that AI has not reduced the need for foundational cybersecurity skills. Enterprises must maintain mentorship and continuous upskilling programs to ensure junior staff still develop the core structural knowledge needed to judge an AI's accuracy.

2. For cybersecurity vendors: Feature velocity vs. trust metrics

Security product vendors can no longer win deals purely by pitching raw AI speed or automated execution. The market is becoming deeply cynical of unvalidated automation. To stand out, vendors must design interfaces focused on explainability, transparency, and auditable confidence scoring. If your tool does not show how it reached a conclusion, or if it lacks seamless hooks for a human-in-the-loop override, it will be viewed as an operational risk rather than an asset.

The tactical action plan for security leaders

To successfully navigate this shift toward AI-assisted security workflows, CISOs and IT executives must focus on trust frameworks rather than deployment velocity.

Codify the guardrails: Establish clear, non-deterministic boundaries detailing exactly when an AI system is permitted to recommend an action, when it is allowed to autonomously execute, and when mandatory human sign-off is required.
Enforce subresource and ingestion governance: Approximately 80% of ISC2 respondents rated having clear governance frameworks and knowing when to override AI decisions as "very important." Operationalize this by auditing the telemetry and data sources your security LLMs ingest to minimize errors at the source.
Shift performance metrics: Stop measuring SOC performance purely by speed-to-resolution. If analysts are penalized for taking the time to thoroughly validate an AI path, they will inevitably let a scaled error slip through. Reward thorough validation and critical systems thinking.

AI is undeniably expanding the capability to monitor networks and model threats. But as the machine takes over the mechanics, the true differentiator for enterprise resilience remains the trained, skeptical human mind.

The DockSec Series, Part 2: Inside DockSec—Architecture and Pipeline

Advait Patel — Tue, 14 Jul 2026 12:22:01 GMT

In Part 1 of this series, we argued that container security fails at the last mile: detection is mature, but turning findings into fixes is not. This article opens the hood to show how DockSec closes that gap. Understanding the architecture is not academic—it explains why the tool behaves the way it does, where you can extend it, and why the same scan can produce a terminal summary, a JSON payload, a SARIF file, and a PDF report all from one run.

A four-stage pipeline

At the highest level, DockSec runs a four-stage pipeline: scan, analyze, recommend, report. Trivy, Hadolint, and Docker Scout do the scanning locally. An LLM pass correlates and explains the findings. A scoring stage produces a 0-100 posture number.

A reporting stage emits the results in whatever formats you asked for. What makes this composable rather than a tangle is that every stage reads from and writes to a single shared data structure.

The results dict: One contract to rule them all

The most important design decision in DockSec is also the least glamorous: there is exactly one results dictionary that flows through the whole system, and every component agrees on its shape.

The scanner produces this dict. It carries the Dockerfile lint results, the image scan results, and—the key field—<json_data>, a list of normalized vulnerability records. Each record has a stable shape regardless of which scanner produced it: a vulnerability ID, the target, the package name and installed version, a severity, a title and description, a status, a CVSS score, and a reference URL. Trivy findings are filtered into this shape; Docker Compose misconfiguration findings reuse the exact same shape with an added remediation field.

Because everything downstream consumes this one contract, the scoring calculator, the report generators, the SARIF writer, and the <--json> output do not need to know anything about Trivy's or Hadolint's native formats. They read <json_data> and the AI findings and do their job. Add a new scanner tomorrow and, as long as it emits records in this shape, the entire reporting and scoring stack works unchanged. This is why the codebase can support five output formats without five times the complexity.

The scanning layer

DockerSecurityScanner is the workhorse. It wraps three tools, each with a distinct job:

Trivy enumerates known CVEs in the image’s OS and language packages. It is the primary source of vulnerability findings and honors the severity filter you pass.
Hadolint lints the Dockerfile itself against a large rule set—use COPY instead of ADD, pin package versions, avoid running as root, and so on. These are the best-practice findings.
Docker Scout provides an image-versus-base-image comparison and suggests updated base images, which is often the single highest-leverage fix.

The scanner also owns a results cache keyed on the image name and the requested severity, so repeated scans of the same image at the same severity are fast, while a scan at a different severity correctly triggers a fresh run rather than serving stale data.

The AI layer

When an API key and provider are configured, the CLI runs an AI pass. It loads the Dockerfile, truncates it to a token-sensible size, and feeds it to the configured model through a structured-output chain. "Structured output" is the important phrase: the model is not asked for free-form prose. It is asked to populate a defined schema with fields for vulnerabilities, best practices, security risks, exposed credentials, and remediation steps. The result is predictable, parseable, and mergeable back into the results dict as <ai_findings>.

Provider handling is abstracted behind a single <get_llm()> factory. OpenAI uses JSON mode for structured output; Anthropic, Google, and Ollama use tool-calling, which LangChain selects automatically. Sensible model defaults are applied per provider, and newer Claude and Gemini models that no longer accept a temperature parameter are handled transparently. From the user’s perspective, switching providers is one flag; the complexity is contained in one function.

The scoring layer

DockSec produces a single 0-100 security score, and there are two paths to it.

When an LLM is available, the model can produce a holistic score from a summary of the findings. When it is not—in <--scan-only> mode, or with <--skip-ai-scoring>—a local, deterministic calculator takes over. The local score is a weighted blend of three axes: the Dockerfile quality (from lint results), the vulnerability burden (a severity-weighted deduction over <json_data>), and a configuration score derived by reading the Dockerfile directly and deducting for concrete misconfigurations: running as root, credential-looking <ENV> variables, unpinned base images, missing health checks, sensitive exposed ports, <ADD> over <COPY>, and privileged flags.

The local calculator is deliberately transparent and tunable, and it has been hardened based on real testing. Hardcoded credentials, for example, now cap the overall score regardless of how the rest of the blend comes out— because shipping a plaintext secret in an image is not a middling problem to be averaged away. Part 5 returns to scoring in depth.

The reporting layer

A single ReportGenerator is the canonical writer for JSON, CSV, PDF, and HTML. It runs silently and returns the paths it wrote; the CLI then renders one clean summary rather than interleaving progress bars with scan output. HTML uses a template with placeholder substitution. PDF routes all text through a sanitizer so that bullets, smart quotes, em dashes, and emoji in vulnerability titles never crash generation. SARIF is written by the same generator but is opt-in and independent of the <--format> bundle, because it targets CI and code-scanning rather than human reading.

The reason all of these can coexist is, again, the shared results dict. Each writer is a pure function from that dict to a file.

How the CLI ties it together

<cli.py> is the orchestrator. It parses arguments, resolves the provider and severity once, decides the mode—full analysis, AI-only, scan-only, image-only, or compose—and sets three booleans: run AI, run scan, run compose. From there it invokes the AI pass and the scan pass, merges their outputs into the one results dict, computes the score, generates the requested reports, and renders the summary. Exit codes are honest: a clean run exits 0, a triggered gate exits 1, a usage error exits 2, and a tool or runtime failure—including a failed AI pass—exits 3, so a broken pipeline never masquerades as a passing one.

How the CLI ties it together

Three practical consequences fall out of this design:

Extensibility: Because of the single results contract, adding a scanner or an output format is a local change, not a rewrite.
Honesty: The separation of scan, score, and report means the score reflects real findings and the exit code reflects real outcomes.
Control: The provider abstraction and the scan-only path mean you decide where your data goes and whether an external model is involved at all.

With the architecture clear, Part 3 gets hands-on: We will scan a deliberately vulnerable Dockerfile, an image, and a Compose stack, and read the output line by line.

This is the second in a five-part series. Watch for coming installments on Tuesdays.

SMBs and AI: Governance and Security Split Leaders from the 'Stuck Middle'

CamS@secureworld.io (Cam Sivesind) — Mon, 13 Jul 2026 22:35:52 GMT

The debate over whether small and medium-sized businesses (SMBs) will adopt artificial intelligence is officially over. According to Pax8's newly-released Q2 2026 SMB AI Pulse Report, based on a survey of more than 400 U.S. small business leaders, adoption has surged past the experimental hype phase and into a critical operational reality.

Ninety 90% of SMBs are now somewhere on the AI adoption curve, with 61% actively using AI tools in daily operations and 29% experimenting.

For cybersecurity professionals, managed service providers (MSPs), and vCISOs (virtual Chief Information Security Officers), the report exposes a massive operational paradox: while SMBs are aggressively deploying AI across their entire business fabrics to secure a competitive edge, their governance and security frameworks are completely lagging behind. This widening gap represents an unprecedented concentration of risk.

"As organizations of all sizes deploy increasingly autonomous and agentic AI tools to drive mission outcomes, we must ensure those systems are resilient against manipulation, compromise, and misuse," said Marcus Fowler, CEO of Darktrace Federal. "AI will increasingly be tasked with defending other AI systems, creating a new frontier for cybersecurity. Finally, no cybersecurity executive actions or strategy can succeed without addressing the talent challenge. The demand for skilled cyber professionals continues to outpace supply."

Fowler added, "AI should be viewed as a force multiplier for the workforce—augmenting human defenders, accelerating investigations, and allowing teams to focus on the highest-value mission tasks."

The data prove that SMBs using AI are rapidly pulling away from non-users, creating a stark divergence in market confidence and technology spending.

The equalizer effect: 71% of AI users report that the technology allows small businesses to effectively compete with enterprise-level firms.
The multiplier gap: SMBs leveraging AI report nearly three times the competitive advantage of those that are not. Furthermore, AI users are more than twice as likely to have scaled up their overall technology budgets over the past year (53% vs. 24%).
The collapse of the undecided: The segment of SMBs stating they are "interested but haven't started" collapsed from 9% to a microscopic 1.5% in a single quarter.

The undecided didn't disappear; they moved straight into active testing. However, a significant portion of them have hit an immediate wall, creating what the report terms "the stuck middle." Nearly one in three SMBs (29%) are trapped in this experimentation phase, paralyzed by a lack of internal expertise (22%), cost/unclear ROI (21%), and prominent security or privacy concerns (23%).

What makes this an urgent security story is how deeply AI has already been woven into core business functions. SMB leaders are taking a highly-pragmatic approach, utilizing AI across a broad spectrum of enterprise pipelines.

Here are SMB AI use cases by adoption rate percentage:

Data Analysis & Business Intelligence: 52%
Customer Service & Support: 50%
Marketing & Sales: 50%
Operations & Logistics: 45%
Content Creation: 42%
Finance & Accounting: 37%
Human Resources (HR): 33%
Cybersecurity: 27%

"This isn't simply an SMB problem; we see common themes in large and small clients. The industry needs a fundamental reprioritization on security fundamentals," said Jeff Liford, Associate Director at Fenix24. "This isn't a failure because we lack the tools; it’s a failure to prioritize and resource the correct work efforts. Some environments are legitimately under-resourced, but others are resourced incorrectly."

Liford continued, "The rapid rise of AI-assisted tooling will dramatically accelerate threat actors' ability to compromise poorly-architected networks. Environments already struggling with fundamentals will face even faster and more automated exploitation chains. Recovery-based resilience desperately needs to move to the forefront of security planning."

While this cross-functional leverage provides immense operational scale, the guardrails are virtually non-existent. Only 23% of SMBs possess a documented AI use policy. The remaining majority operate entirely on informal, ad-hoc guidelines (28%) or verbal manager oversight.

SMB AI Policy Gap (2026 Data), by percentage:

Documented AI policy: 23%
Informal guidelines only: 28%
No policy / in progress: 49%

When an organization runs proprietary client data, financial accounting, and HR workflows through external AI models without a formal policy, they are actively exposing themselves to severe corporate risk. Data leakage, shadow AI tools, and unvetted third-party LLM integrations are quietly introducing vulnerabilities across these lean organizations.

What actually rallies the leaders?

The survey results clearly indicate that the primary differentiator between AI market leaders and laggards is not budget. It comes down to leadership alignment and operational governance.

An overwhelming 91% of active AI users report that corporate leadership is completely aligned on the exact role AI plays in the business. That number drops to 68% among experimenters, and plummets to a dismal 32% for non-users.

Security teams and their external technology partners have a significant window of opportunity here. SMB founders and owners—who drive AI decisions in 42% of firms—are explicitly calling out for help. They are acutely aware of the risks, noting operational concerns like exposed customer data and employee misuse of unapproved tools.

The tactical action plan for security advisors

For cybersecurity professionals and MSPs, your client conversations must pivot away from standard tool implementation and focus heavily on building trust infrastructure.

Enforce dynamic AI discovery: Don't wait for employees to declare what tools they are using. Deploy endpoint and network monitoring capabilities to map out the "shadow AI" footprint inside the environment.
Productize AI governance packages: Treat the governance gap as a service opportunity. Help SMB leaders transition from loose, informal guidelines to formalized, enforceable, and auditable AI acceptable-use policies.
Establish human-in-the-loop safeguards: Align with the 68% of successful AI users who demand high standards of human oversight. Build workflows where AI-generated content, automated data analysis, and script outputs require mandatory peer or manager review before execution.

The AI advantage belongs to small businesses, but without a foundation of robust cybersecurity and strict governance, that advantage can turn into a critical compromise overnight.

"AI is accelerating the speed, scale, and accessibility of exploit development for attackers. Tasks that once required highly specialized expertise can now be performed faster, more cheaply, and by a much broader range of threat actors," said Diana Kelley, CISO at Noma Security. "When adversaries operationalize vulnerability discovery and exploit development at machine speed, it fundamentally changes the economics of cyber offense."

Kelley added, "Organizations of all sizes need to become much more risk-driven, focusing on attack surface reduction, asset visibility, identity controls, segmentation, and compensating controls for exposures that cannot be remediated immediately. The industry should expect AI-assisted vulnerability research and exploit development to become increasingly common, which means resilience, visibility, and operational readiness matter more than ever."

How the 2026 World Cup Became the Ultimate Social Engineering Catalyst

CamS@secureworld.io (Cam Sivesind) — Fri, 10 Jul 2026 14:10:03 GMT

Cybercriminals excel at tracking the calendar. When a massive global event dominates public attention, it simultaneously alters user psychology—creating a perfect storm for social engineering.

A trio of new threat intelligence reports from Hoxhunt, Zimperium, and Darktrace highlights this reality. Data from Hoxhunt reveal a massive 500% surge in FIFA World Cup-themed phishing attacks from April to June 2026, with the sharpest spike aligning precisely with the tournament's kickoff.

According to Hoxhunt data, the 2026 World Cup has officially become the most-spoofed entertainment or sporting event ever recorded. What makes this anomaly particularly dangerous for security teams isn't just the sheer volume; it is the emergence of AI-polished, highly-localized, temporal phishing attacks designed to slide past traditional user defenses.

The psychology of temporal phishing

A "temporal phishing attack" is a campaign engineered to exploit a specific window of time when employees are actively expecting unusual or out-of-band communications.

During tax season, users might expect emails regarding payroll, compliance, or financial filings. During the World Cup, the script flips: employees are pre-conditioned to receive notifications about promotional giveaways, corporate ticket packages, hospitality travel, or sudden marketing campaigns. Because unusual communication is anticipated, cognitive friction drops and emotional defenses lower.

The real-world risk is clear. Hoxhunt phishing simulation data demonstrate that temporal lures are 42% more likely to draw a click than standard, non-temporal simulations.

Threat activity began building quietly as early as February, but volume accelerated drastically from May onward. Hoxhunt analysts noted that these globally distributed threats focused primarily on two highly-effective pretexts.

Fake marketing recruitment: Threat actors targeted marketing, communications, and PR professionals with deceptive "recruiting" offers or contractor bundles tied to tournament events, tricking high-privileged corporate users into opening malicious attachments or credential-harvesting links.
Brand impersonation schemes: Attackers heavily spoofed official global sponsors, explicitly deploying fake prize, travel, and ticket-bundle scams impersonating Coca-Cola's World Cup promotions.

By leveraging generative AI, threat actors are polishing these lures to eliminate historical red flags like broken grammar, while tailoring the localization to match specific regions. The impact is truly global, with reported threats distributed evenly across enterprises worldwide—outpacing the campaign volumes observed during the Paris 2024 Olympics or Eurovision 2026 by orders of magnitude.

Expanding the attack surface: mobile and stadium operations

The corporate inbox isn't the only entry point. Parallel threat research from Zimperium zLabs revealed a sharp surge in mobile-targeted phishing campaigns capitalizing on the tournament. Attackers recognize that fans and corporate employees frequently check match updates, manage digital tickets, or track betting pools on their mobile devices—environments where security controls are often less restrictive than a hardened desktop browser.

At the same time, the broader sports ecosystem itself is under immense pressure. A sports sector threat report from Darktrace reveals that 57% of professional sports organizations experienced multiple cyber incidents over the last 12 months.

Darktrace data indicate that sports sector clients receive nearly 20% more phishing emails than companies in other industries. As high-stakes areas like stadium operations, fan engagement apps, ticketing databases, and backend business operations adopt more integrated systems, the attack surface expands. Looking ahead, 72% of security professionals surveyed by Darktrace believe AI will further increase cyber risk over the next year as attackers weaponize automated tools to scale these operations.

Defensive takeaways for security leaders

With nearly half of the global workforce distracted or actively engaged by a major international tournament, enterprise security teams must adapt their defenses to handle temporal spikes:

Deploy contextual phishing training: Standard, generic phishing simulations fail to mimic the high-conversion nature of temporal events. Security education teams should immediately deploy event-specific simulations (such as ticket giveaways or sponsor marketing promotions) to keep users on high alert during the tournament window.
Enforce strict mobile defenses: Given Zimperium's tracking of mobile-first campaigns, Mobile Threat Defense (MTD) solutions should be prioritized to intercept smishing (SMS phishing) and malicious mobile apps targeting employee devices.
Verify out-of-band requests: Internal departments—particularly marketing, HR, and procurement—should establish strict verification protocols for any third-party contracts, promotional partnerships, or recruitment onboarding tied to the event.

When an entire planet is watching a tournament, attackers are watching the fans. Security teams must ensure that their organization's defenses account for the powerful psychological pull of the world's biggest game.

We asked some experts from cybersecurity solution providers for their thoughts.

Mika Aalto, Co-Founder and CEO at Hoxhunt, said:

"AI has ushered in the era of calendar-based social engineering. Just as legitimate marketing teams use automation platforms to launch personalized campaigns around major cultural events and seasonal buying patterns, cybercriminals are using AI to orchestrate phishing campaigns around the moments that matter most to their targets. The World Cup, tax season, annual bonus announcements, open enrollment, Black Friday—every event that drives legitimate communication now creates an opportunity for attackers to blend in. The organizations that adapt their training as quickly as attackers adapt their lures will stay ahead."

Rex Booth, CISO at SailPoint, said:

"The danger of many phishing schemes, like those during the 2026 FIFA World Cup, lies in their ability to grant attackers access to credentials, enabling them to pretend to be trusted insiders. With AI now in play, these campaigns are becoming ever more sophisticated and difficult to spot. This makes it imperative for users to adopt robust identity security best practices, including changing passwords frequently and enabling multi-factor authentication, and for organizations to prioritize identity as the new control plane."
"We've been waiting for this offensive disruption from AI for a while now. Attacks at scale and superhuman speed are the most obvious first step. Fortunately, many campaigns still require human intervention to execute. The more frightening scenario is when adversary AI starts running rampant through your enterprise without the need for action by the victim."
"High-profile events, such as the World Cup, tend to attract attackers looking to make a statement. The objective of making a large impact sometimes means using different tactics than, say, corporate espionage where you want to go unnoticed both on the way in and out. Organizers and defenders need to be on the lookout for threats that are oriented for maximal exposure and disruption rather than stealth and targeted objectives."

Randolph Barr, CISO at Cequence Security, said:

"The greatest risks to large sporting events don't come from new exploits. Instead, they originate from people misusing legitimate apps, identities, and corporate processes. Phishing, impersonation, and automated misuse are becoming more prevalent techniques for attackers to gain access that seems legitimate, especially when thousands of employees, partners, and vendors are working together on systems they don't know well and have tight deadlines. When there are large events, access levels are often elevated for a short period, apps and APIs are used to their fullest, and security teams are focused on keeping systems available than protected. This makes it tougher to spot slight abuse."
"When attackers gain access, they typically don't use malware or other dangerous behaviors to wreak damage; instead, they use trusted access. This involves taking over an account, abusing sessions and tokens, scraping automatically, perpetrating fraud, and staying in the environment for a long time. These things usually become part of everyday business and can go on for weeks or months without triggering standard security procedures that are supposed to stop intrusions, not misuse."

Anne Cutler, Cybersecurity Evangelist at Keeper Security, said:

"The World Cup creates one of the most dangerous cyberattack windows on the planet. Billions of people, across dozens of time zones, all emotionally invested—and all searching, clicking, and transacting online, at the same time. That creates an unbelievable operational window for criminal networks. Fraudulent websites mimicking official FIFA ticketing and merchandise platforms have been built to harvest credit card details and personal information before victims realize something is wrong."
"AI is what makes this cycle more dangerous. Phishing emails that are grammatically perfect, contextually accurate, and personalized with your name and your team can be written by an AI tool in seconds. A text message from a friend or family member urgently asking for money for tickets may not be who you think."
"Whether you're a fan or an IT leader, the playbook is the same: go directly to official sites, use strong and unique passwords on every account, and enable MFA everywhere possible. Don't conduct any transactions involving personal or financial information over public Wi-Fi. Cybercriminals are counting on the chaos of a tournament like this to catch people off guard. Don't give them the opening."

The DockSec Series, Part 1: Why Container Security Needs an AI Layer

Advait Patel — Tue, 07 Jul 2026 18:36:30 GMT

The problem hiding in plain sight

Containers won because they made shipping software boring. A Dockerfile, a base image, a docker build, and your application runs the same on a laptop as it does in production. But that convenience quietly moved a large part of the security surface into an artifact most teams treat as configuration rather than code.

A single <FROM python:3.9> line pulls in an entire operating system: hundreds of system packages, transitive libraries, and whatever CVEs happened to be present the day the image was published. Layer on a few <RUN apt-get install> commands, a hardcoded credential in an ENV, and a base image that was never pinned, and a routine build can inherit thousands of known vulnerabilities before your own code is even copied in. Scan a common base image today and it is not unusual to see hundreds of critical and high-severity findings.

The tooling to detect this is mature. Scanners like Trivy enumerate CVEs in packages, Hadolint lints Dockerfiles against best practices, and Docker Scout compares your image against its base and suggests upgrades. These are excellent tools. The problem is not detection. The problem is what happens after detection.

The wall of red

Anyone who has run a container scan in a CI pipeline knows the experience: a wall of red, 200-plus findings, each with a CVE identifier, a severity label, and a terse description written for a vulnerability database rather than a developer. The output answers "what is wrong" but almost never answers the three questions a developer actually has:

Which of these actually matter for my container, given how it is built and run?
What, specifically, do I change in my Dockerfile to fix it?
If I can only fix five things today, which five move the needle most?

Faced with an undifferentiated list, teams do one of two things. They ignore it, because triaging 200 findings by hand is not a sprint task. Or they bolt on a suppression file and move on. Neither improves security. The detection was never the bottleneck; the translation from findings to action was.

This is the gap DockSec was built to close.

What is DockSec?

DockSec is an OWASP Lab Project: an AI-powered Docker security scanner that explains vulnerabilities in plain English and, crucially, tells you how to fix them in the context of your specific Dockerfile. It does not reinvent detection. It wraps the industry-standard scanners you already trust—Trivy, Hadolint, and Docker Scout—and adds a reasoning layer on top that prioritizes, explains, and remediates what they find.

The distinction matters. Trivy will tell you that <openssl> in your image has a critical CVE. DockSec will tell you that, and that your base image is unpinned, and that you are running as root, and that you have an API key hardcoded on line 3—and then it will hand you a corrected Dockerfile with a pinned slim base image, a non-root USER directive, and the secret moved to a runtime injection pattern. It turns a scanner's report into a code review.

Think of it as pairing the recall of automated scanners with the judgment of a security engineer sitting next to you, reviewing the Dockerfile in real time.

Why an AI layer, and why now?

Skepticism about "AI-powered" anything is healthy, so it is worth being precise about what the language model actually does here, because it is narrow and grounded.

The LLM does not invent vulnerabilities. Every CVE DockSec reports comes from Trivy or Docker Scout; every lint finding comes from Hadolint. The model's job is to correlate those grounded findings with the actual content of your Dockerfile and produce three things the raw scanners cannot: a prioritized narrative of what matters most, a plain-English explanation of why each issue is dangerous in your context, and specific, line-level remediation you can paste back into your file. It is the reasoning and translation layer, not the source of truth.

This matters because the alternative—a human doing this correlation across three tools and a Dockerfile for every service, on every build—does not scale. Security teams are outnumbered by developers by an order of magnitude. The only way contextual remediation reaches every Dockerfile is to automate the reasoning, not just the detection.

The design principles that fall out of this

Once you accept that the value is in contextual remediation, several design choices follow naturally, and they shape everything in the rest of this series.

Bring your own model

Contextual analysis should not require shipping your proprietary Dockerfiles and image contents to a vendor's cloud. DockSec supports OpenAI, Anthropic Claude, and Google Gemini for teams that want hosted models, and Ollama for teams that need everything to stay on their own hardware. A regulated or air-gapped team can run the full pipeline—scanning and AI remediation—without a single byte leaving their network.

Detection without AI is always available

The AI layer is additive, not mandatory. A <--scan-only> mode runs the full scanner stack with local, rule-based scoring and no API key at all. You get the wall of findings and a security score; you simply do not get the plain-English narrative. This keeps DockSec useful in the strictest environments and in fast CI paths where you only want a gate.

Open source and vendor-neutral

As an OWASP project under the MIT license, DockSec has no commercial tier that withholds features, no telemetry, and no lock-in. The comparison that matters is not against Trivy—which DockSec builds on—but against the commercial platforms that offer AI remediation only by hosting your data on their infrastructure. DockSec offers the same class of remediation while keeping you in control of both your data and your choice of model.

Where this series goes

This first article made the case for why a reasoning layer on top of mature scanners is the missing piece in container security. The rest of the series gets concrete.

Part 2 opens the hood: The architecture, how the three scanners and the LLM pass fit together, and how a single results contract flows through scoring and reporting
Part 3 is hands-on: Scanning a Dockerfile, an image, and a full Docker Compose stack, with real commands and output
Part 4 covers automation: Gating builds with severity thresholds and exit codes, SARIF for GitHub code scanning, and baseline "ratchet" mode for adopting gates on existing projects
Part 5 steps back to adoption: The security scoring model, the metrics worth tracking, and how an OWASP-governed tool fits into a broader program

Container security does not fail for lack of scanners. It fails at the last mile, where a list of findings has to become a change someone actually makes. That last mile is the whole point of DockSec.

This is the first in a five-part series. Watch for coming installments on Tuesdays.

Three Seconds of Audio Is Enough: How Detection Must Now Stop AI Fraud

Pierre Raymond — Mon, 06 Jul 2026 20:11:23 GMT

The voice on the phone told an Ontario grandmother that her grandson had been arrested and needed bail money fast. It was his voice, down to the cadence, and it was a clone, stitched by artificial intelligence from a few seconds of audio scraped off the internet.

She nearly sent the money. Swap the grandson for a son still living overseas, or for an officer who claims to be from the Canada Revenue Agency (CRA), and the same trick lands on someone four months into a new country who has no way to know what the real call is supposed to sound like.

From hand-crafted to mass-produced

A SecureWorld article earlier this year traced why Canadian fraud-prevention infrastructure keeps missing newcomers and named three vectors that land hardest on them: authority impersonation, settlement-workflow scams, and long-rapport investment fraud. Each of those used to require a human on the other end, working one mark at a time. A follow-up argued the gap was an engineering problem for banks to build their way out of. The newer development is who is doing the engineering, and it is no longer only the defense.

The economics of the attack collapsed. Cloning a voice convincingly once took a studio; now it takes three seconds of recorded speech, which is why the U.S. Federal Trade Commission warned that scammers are using AI to sharpen family-emergency schemes. Reported AI voice-scam activity climbed 1,210 percent over the past year by one count. The script did not change; the unit cost of running it a thousand times did.

That is the shift worth tracking. AI did not invent a fourth fraud vector. It industrialized the first three, and an industrialized attack finds the softest segment first.

Why the newcomer cohort absorbs the hit first

A 20-year resident has heard a real CRA call, or knows someone who has, and can feel when the cadence is wrong. A person in month four has no such baseline. The reference points that let a long-time resident dismiss a fake are exactly the ones still being assembled in the early months of settling into a new country.

The agencies themselves see this. Immigration, Refugees and Citizenship Canada (IRCC) now warns that some scammers use AI to generate fake content that appears to come from the department, including messages with fake interview links demanding immediate action. The CRA, for its part, publishes a standing reminder on how to verify a real call, because the impersonation of its officers is constant and the agency knows newcomers are among the least equipped to tell the difference.

The exposure attached to the voice channel is not abstract. The segment most at risk is the one that has not yet learned what each institution sounds like, which is precisely the cohort an AI clone targets when it impersonates a relative or an official. An attacker who can spin up a fake son, a fake immigration officer, and a fake bank fraud-line in the same afternoon does not need a high hit rate; the cohort supplies the volume.

Authority impersonation works because it borrows real procedure. A newcomer often does owe the CRA a filing, does have an open file with IRCC, and does expect their bank to call about a flagged transaction. The fraudster does not have to invent a pretext; the legitimate institution has already supplied one. AI removes the last tell that used to give the script away—the stilted accent or the off-key phrasing—and replaces it with a clone trained on the exact voice the victim is primed to trust. The result is a call that matches a real obligation, in a real-sounding voice, arriving at a moment when the customer has the least context to doubt it.

The detection problem moved

Here is where most onboarding stacks break. A four-month-old account already strains document-and-selfie verification, because the customer is new to every system at once. Feed a deepfake into that same flow and the check fails in a way the old playbook never anticipated.

Fraudsters now defeat identity verification not by forging a better document but by injecting a synthetic human. iProov logged a 2,665 percent surge in native virtual-camera attacks and a 300 percent rise in face-swap attempts, where an AI-generated face is piped through legitimate camera software to fool a liveness check. The same research found that only 0.1 percent of people could reliably spot a deepfake on their own, which is the entire case against leaving the call to human judgment. Veriff reported that deepfakes now drive one in 20 identity-verification failures. Sumsub's annual data shows the "complex multi-step" attack category—the kind that chains a deepfake with stolen data—jumped 180 percent year over year as simpler tactics stopped working.

The cost of getting this wrong is specific. A deepfake that clears onboarding does not produce one fraudulent transaction; it produces a fully verified account that passed every gate, then drains for months before anyone flags it. The question the stack now has to answer is no longer "is this document real?" It is "is this a live human, present right now, and the person they claim to be?"

Liveness and injection detection as the baseline

Two failure modes hide inside that question. A presentation attack holds a photo or replays a video to the camera; an injection attack skips the camera entirely and feeds synthetic video straight into the verification pipeline. Sumsub recorded a 300 percent rise in identity-document fraud as those techniques matured, and injection is the harder of the two to catch because nothing physical is ever presented.

The metric a fraud operations team can pull today is the deepfake-and-injection catch rate on the first-90-day cohort, measured separately from the general population. Run it as its own line. A newcomer segment that quietly underperforms the general detection rate is the blind spot, sized in basis points.

Provenance for the voice channel

The voice channel needs its own answer, because voiceprint authentication is now a liability rather than a control. A system that trusts a matching voiceprint will trust a good clone. The defense is out-of-band: a callback to a number the institution already holds, or verification through a channel the caller did not choose. The CRA's own guidance points the same direction, telling people to hang up and call back on a published line rather than trust the voice in front of them.

For a newcomer cohort, that control has to exist in a language the customer actually speaks, or it does not exist at all. A verification step that only works in English or French excludes the very segment it is meant to protect.

Scaling defense against scaled attacks

The attacker's marginal cost is near zero. A defense built analyst-by-analyst cannot match a defense that has to clear a thousand synthetic faces an hour, which is the structural reason AI-driven fraud has outpaced single-institution response. SecureWorld's reporting on AI-driven financial crime frames the same arithmetic: tools that scale the attack force the defense to scale or surrender ground.

The prior installment's argument for shared intelligence carries straight into the AI era, with one twist. It is not enough to share a confirmed synthetic identity after the fact. The signal worth propagating at machine speed is the typology itself: a cloned-voice script targeting a specific diaspora, a face-swap pattern hitting one onboarding flow, a fake-IRCC template circulating this week. A typology that surfaces in one institution on Monday should not take until Friday to reach the other five seeing the same campaign.

The latency is where the loss lives. A campaign that runs four days unshared is a campaign that clears four days of onboarding before the second institution recognizes the pattern, and AI lets the same template hit every institution in the country inside that window. The technical posture has to match the threat: automated liveness and injection checks at the point of verification, voiceprint demoted from proof to a single weak signal, and a typology feed that updates in hours rather than at the speed of a quarterly fraud trends report. None of that is exotic. The detection tools exist; what most programs lack is the instruction to point them at the newcomer cohort as a named segment with its own scorecard.

Three numbers to measure before the next quarter

A program is only as honest as the metrics it will commit to in writing. Three map cleanly onto the AI vector.

First, the deepfake-and-injection catch rate inside the first-90-day cohort, held against the general-population rate. Second, the share of high-risk authority-impersonation reports that reached an out-of-band verification step before money moved, broken out by the customer's preferred language. Third, the median latency from the first sighting of a synthetic-voice or synthetic-video typology to a cohort-wide alert across the institutions that share signal. None of the three requires a vendor to define it.

The clone costs three seconds of audio and a few dollars. The callback that defeats it costs a few minutes. That asymmetry—attacker-cheap against defender-cheap—is the entire program brief, and the team that measures the gap is the one that closes it.

Prompt Data Is the New Shadow Data Layer

office@alexvakulov.com (Alex Vakulov) — Thu, 02 Jul 2026 13:43:02 GMT

The DLP alert your proxy catches is usually a clear outbound event: a file uploaded to an unsanctioned app or a spreadsheet emailed outside the company. What it may miss is the paragraph of legal language an associate pasted into an AI tool to clean up the wording. That is a data transfer too. It just does not look like the kind of transfer most controls were built to catch.

Prompt data has become a shadow data channel operating within sanctioned workflows, on corporate devices, and often via approved network paths, which is exactly why traditional DLP and CASB rules may miss it.

A 2025 LayerX Security report found that approximately 18% of users paste data into GenAI tools, and about half of that pasted content is company information. For many security teams, most of this activity remains outside practical prompt level visibility. In practice, it only takes a few careless or untrained users to create a serious data exposure problem for the entire company.

Prompt data should therefore be treated as a governed data channel, rather than left as a blind spot within otherwise approved workflows.

Start with a tier map

Before classification frameworks or DLP rules, the security team needs an accurate picture of which AI tools are actually in use and which data-handling regime each employee operates under. That map has three distinct tiers, and conflating them produces policies that either miss real risk or block legitimate work.

Approved enterprise AI

Approved enterprise AI is a tool with a signed data processing agreement, contractual guarantees against training on customer inputs, SOC 2 Type II coverage, and administrative controls that the organization can actually configure. ChatGPT Enterprise with zero data retention enabled, Microsoft Copilot bound to an M365 tenant, and Google Workspace AI under an enterprise agreement all qualify. Data entered into these tools stays under the organization's contractual control. This does not mean every use is automatically safe. It means the company has a place to configure controls, assign ownership, and define which data can be used.

Unmanaged SaaS AI

Unmanaged SaaS AI includes tools that employees use before security, legal, or IT has reviewed them. This may include niche coding tools, browser research tools, design tools, note-taking tools, and, actually, any existing SaaS platform that quietly adds AI features after purchase.

This is where visibility breaks down. A tool may look harmless, but still allow file uploads, prompt history, third-party processing, or access to workspace data. The risk is not limited to what employees type into the prompt box. Many AI tools are still applications, and they can collect data through app permissions, integrations, uploaded files, browser access, connected workspaces, and usage telemetry. Security teams should review unmanaged AI tools as software with data access, not only as chat interfaces.

Personal AI accounts

This is the employee using a personal AI subscription on a corporate device or using a free AI tool with a personal email address. The employer has no contractual relationship with the vendor governing that account, no visibility into conversation history, and no ability to enforce data retention settings. The underlying tool may be identical to the enterprise version, but the data handling is completely different.

Locally-hosted AI

A fourth tier is emerging: locally hosted AI tools running on an employee’s machine or other on-premises hardware. These reduce the vendor data-handling problem because prompts may stay inside the local environment. They introduce a different set of considerations: model storage on the device SSD, endpoint performance, access control, and what happens to conversation data when a device is reassigned or decommissioned.

Detecting which tier employees are actually in requires proxy or CASB visibility with session-level context—not just knowing that traffic is going to openai.com, but whether it is authenticated against a corporate workspace or a personal account.

Classify the data, not only the tool

A prompt governance model should classify the content employees enter into AI systems. Instructions like “do not share confidential data” are too vague for real work, where everything can feel confidential and nothing feels clearly classified. The policy needs to name the data types and, where possible, show concrete examples of risky use. At the same time, the model should be simple enough for employees to understand and precise enough for DLP, proxy rules, vendor review, and incident response.

Credentials and secrets have no legitimate reason to appear in any external AI tool. This includes API keys, OAuth tokens, session cookies, or private keys. A developer debugging a build failure does not need to paste the .env file. They need to paste the error. Replacing secrets with placeholders before asking for help is the prompt hygiene practice with the highest ROI.

Source code carries different risks depending on what it reveals. A small generic function is different from a proprietary fraud model, a trading algorithm, or an unreleased feature. Risk may increase further when code includes internal design comments or private endpoints.

Customer and employee data should be treated as sensitive prompt content even when a single prompt looks harmless. Emails, health details, payroll numbers, and account histories all apply. Partial details can still identify a person. Rewriting a customer response with AI can be valid, but it should happen in an approved tool with matching data handling terms, not a personal account.

Legal, financial, and board material is high risk because it is writing-heavy. Employees paste parts of contracts, acquisition plans, audit findings, and pricing strategy into AI tools because AI is useful for dense editing work. The policy should clearly state that summarizing a sensitive document with AI still constitutes sharing that document with the tool.

Security incident data needs separate handling. Logs, malware samples, endpoint telemetry, vulnerability details, and incident timelines can expose infrastructure weaknesses. Security teams can use AI, but the workflow should be in place before the incident.

Map prompt risk

Once risky data types are defined, employees still need a decision model they can use during real work. The simplest model is to classify prompt content by where it is allowed to go.

Restricted data should not enter external AI systems unless the organization has approved a specific controlled environment and accepted the risk. This includes credentials, secrets, payment card data, highly sensitive personal information, material from active litigation, pending transaction details, unreleased financial results, and source code containing secrets or critical business logic. The issue is immediacy: exposure can create legal, security, or business harm before the company has any practical way to recover.

Sensitive data may be used in approved enterprise AI when retention controls, access controls, and logging match the use case. It should stay out of unmanaged SaaS AI and personal accounts. This tier covers confidential business communications, customer context, internal architecture, unreleased product plans, operational reports, HR material, and private code without secrets. The risk is often competitive, contractual, reputational, or operational.

Internal data can be used in approved enterprise AI and sometimes in unmanaged tools when identifiers and strategic details are removed. Draft policies, sanitized meeting summaries, generic training material, and general code examples may fit here.

Public data should remain low-friction. Employees need freedom to use AI for public research, documentation, learning, and generic writing tasks, or the policy will be ignored.

Build the policy around the approved path

The most common failure mode in AI governance is a policy that tells employees what they cannot do but gives them no workable alternative. A blanket ban often pushes the same behavior onto personal devices or personal accounts, where the organization has even less visibility.

A useful policy answers the question employees actually have: “How can I do this safely?” Code assistance may require an enterprise coding assistant or a review tool with repository controls. Document drafting may require an enterprise AI workspace with clear classification rules. Public research can stay lower-friction as long as employees do not upload files or paste internal content.

The policy should also explain which account type to use, what content to remove first, what to do after an accidental paste, and how to request a new AI tool or use case. Good prompt governance reduces unsafe work by making safe work easier.

Detection: several different signal sources

Classification only works if something enforces it. In practice, many employees will not check a policy before pasting text into an AI tool. They are rushing to finish a ticket or to summarize a meeting. Automated detection has to assume speed, pressure, and mistakes.

The first signal source is browser and session visibility. Many AI tools run through ordinary browser workflows, so security teams should use browser security platforms, secure web gateways, proxy/DNS logs, and CASB data to understand actual use. The goal is not only to see traffic to an AI domain. Security teams need session context. That context determines whether the same prompt is acceptable or risky.

The second source is browser-based DLP. A managed browser profile or extension can inspect clipboard content at the moment of paste, before data leaves the endpoint. This is useful when TLS inspection is incomplete or when the risk happens inside an encrypted browser session.

The third source is proxy and CASB inspection. When TLS inspection is properly configured, these controls can apply content rules to AI requests and enforce tier-level routing. For example, they can allow enterprise AI tenants, warn on unmanaged tools, block consumer accounts, or stop risky file uploads to unapproved services.

The fourth source is endpoint and developer tool visibility. Browser controls do not cover IDE extensions, terminal tools, local agents, or plugins that can read files directly. These tools should be reviewed like any developer tool with access to repositories, configuration files, and environment data.

The fifth source is behavioral logging. Logs do not block risky prompts in real time, but they reveal adoption patterns, unusual upload behavior, personal account use, and the introduction of new AI tools into the environment.

Detection should therefore work as a layered system. Browser controls catch risky paste events early. DLP flags likely sensitive content. Proxy and CASB controls enforce approved paths. Endpoint and developer telemetry cover AI tools outside the browser. Logs show patterns that single alerts miss. Together, these signals turn prompt governance from a policy document into an operating control.

Connect prompt governance to existing security programs

Prompt data governance should not become a separate security island. It should extend the security programs the company already runs.

Security awareness training should use job-specific examples. Engineers need to see how a build log can expose a token. Legal teams need to understand why rewriting a contract in a personal AI account still constitutes external processing. The task may be legitimate. The risk often lies in the data included.

Incident response should also cover prompt leaks. The playbook should establish what was shared, which tool and account were used, whether deletion is possible, whether secrets need rotation, and whether legal or privacy review is required. The goal is fast damage reduction.

Vendor review should treat AI tools like SaaS tools with extra questions. Security and legal teams need to know whether prompts are used for training, how long data is retained, whether deletion is possible, which subprocessors are involved, and how enterprise account terms differ from consumer terms.

AI governance should keep an inventory of approved tools, business owners, allowed use cases, exceptions, and reassessment dates. The governance group should not approve every prompt. It should define when a review is needed and what evidence teams must provide before sensitive data can be used.

Conclusion: what good looks like after 90 days

A realistic prompt governance program should reduce the largest blind spots first. In the first 30 days, identify AI tools in use, separate enterprise tools from unmanaged and personal accounts, and publish a short policy for restricted data and approved alternatives.

By day 60, tune browser, proxy, and DLP controls for high-confidence risks such as secrets, regulated data, sensitive source code, and uploads to unmanaged tools. Add a simple intake path for new use cases.

By day 90, connect the program to vendor review, AI governance, training, and incident response. Track adoption, risky prompts, unmanaged use, exceptions, and incidents.

Alert: China's GLM-5.2 Just Matched Mythos on Bug-Finding

CamS@secureworld.io (Cam Sivesind) — Wed, 01 Jul 2026 13:37:02 GMT

A Beijing-based AI lab just demonstrated something the U.S. export control regime was specifically designed to prevent: a Chinese model that performs on par with one of America's most restricted AI systems at finding software vulnerabilities. And it did so by giving the model away for free.

On June 13, Zhipu AI (operating under the brand Z.ai) released GLM-5.2, an open-weight, 744-billion-parameter model under a permissive MIT license. Within days, independent benchmarking from Semgrep and reporting from The Wall Street Journal converged on the same headline: in targeted vulnerability-detection tasks, GLM-5.2 performs roughly in the same range as Anthropic's Claude Mythos—the model Anthropic has kept deliberately locked behind a vetted-partner program because of how effective it is at the same job.

For security teams, the benchmark numbers are interesting. The governance story underneath them is the part that should actually change how one thinks about AI and risk planning for the next 12 months.

The comparison that's circulating centers on IDOR (Insecure Direct Object Reference) vulnerability detection. Independent testing by Semgrep put GLM-5.2's F1 score at roughly 39%, ahead of Claude Code's 32–37% on the same evaluation set. Zhipu has also claimed broader parity with Mythos across other bug-finding benchmarks, and GLM-5.2 has separately ranked among the most-used models on OpenRouter and second worldwide on a closely-watched coding benchmark—strong enough that Zhipu's market value reportedly crossed $128 billion shortly after.

It's worth being precise about what this is and isn't. GLM-5.2 still trails Anthropic and OpenAI's frontier systems on broad, general-purpose reasoning. This is a case of a competitor closing the gap hard on one specific, high-stakes capability—automated vulnerability discovery—rather than overtaking U.S. labs across the board. Some of Zhipu's broader parity claims also haven't been independently verified, partly because Mythos itself has been intermittently unavailable for outside researchers to test against (more on that below). Treat the specific percentage-point comparisons with appropriate skepticism; treat the trend line as real.

The capability gap narrowing is one thing. The delivery mechanism is the part that should actually concern security leaders.

Mythos lives behind an API that Anthropic—or a U.S. regulator— can switch off at will, which is precisely what happened in June. GLM-5.2 ships as downloadable weights under an MIT license. Anyone can pull it onto consumer-grade hardware and run it locally, with no vendor in the loop, no usage logging, and no ability for Zhipu to see or shape what it's used for after release. As one Forbes analysis put it, the variable that matters here isn't raw capability, it's containment. A frontier-adjacent vulnerability-finding model that nobody can revoke access to is a fundamentally different risk profile than the same capability sitting behind a gated, monitorable API—regardless of how the benchmark scores compare.

That distinction is exactly what the U.S. export control strategy was built to prevent, and exactly what it currently can't reach.

"Historically, the most advanced, and potentially dangerous, technology has been closely held by major government or organizations with strict controls," said John Gallagher, Vice President at Viakoo, a provider of automated IoT cyber hygiene. "As Chinese frontier models are showing, those days are past as the most advanced AI capability is available to all. This genuinely democratizes the ability to exploit vulnerabilities to all types of hackers."

Gallagher added: "While much of the immediate concern centers on traditional IT systems, the real blast radius of cheap, open-weight offensive AI tools hits Operational Technology (OT), IoT, and ICS systems the hardest. Unlike enterprise IT networks, which are heavily monitored, patched, and segmented, physical security systems—such as legacy networked security cameras, access control panels, and smart building HVAC systems—suffer from massive asset blindness and sparse patching schedules."

What this means for Mythos—and for Anthropic's last few weeks

To understand why this story is landing the way it is, we have to examine the timeline of what's happened to Mythos itself.

Anthropic previewed Mythos in April through Project Glasswing, an invite-only program that eventually grew to roughly 200 vetted organizations— including Amazon, Apple, Google, Microsoft, Cisco, Nvidia, and the Linux Foundation—using the model strictly for defensive vulnerability research. By late May, those partners had used it to surface more than 10,000 high- or critical-severity vulnerabilities, including a 27-year-old flaw in OpenBSD's TCP stack and 271 vulnerabilities in an early Firefox build, reportedly engineering working exploits roughly 90 times faster than prior-generation tools.

On June 9, Anthropic released a public sibling, Claude Fable 5—the same underlying model with guardrails that route high-risk security queries to a safer fallback. Three days later, the U.S. Commerce Department ordered Anthropic to disable both Fable 5 and Mythos 5 worldwide, for every user, citing a reported jailbreak technique and broader national security concerns about foreign access to cyber-capable AI. Anthropic complied within hours and publicly disputed the government's characterization of the jailbreak's severity, while the administration's account—relayed by White House AI advisor David Sacks—placed responsibility on Anthropic for declining to "fix" the issue on the government's terms.

The blackout lasted about two weeks. On June 26, Commerce Secretary Howard Lutnick notified Anthropic that Mythos 5 could be restored to roughly 100 vetted U.S. organizations—critical infrastructure operators, federal agencies, and cyber defense firms largely drawn from the Project Glasswing roster. Fable 5, the version anyone could sign up for, remains offline, with no public timeline for its return.

For Mythos specifically, GLM-5.2's release reframes the entire restriction strategy. The policy logic behind locking down Mythos assumed that doing so would meaningfully slow adversaries' access to equivalent capability. GLM-5.2 is a direct test of that assumption, and the early answer looks like "no"—a freely downloadable model is now performing in the same range as the system the U.S. government spent two weeks debating how tightly to lock down. Security researcher Niels Provos and former export-control policy architect Saif Khan have both made versions of the same argument publicly: restricting American models without a credible plan for what happens when adversaries build comparable open alternatives doesn't slow proliferation; it just hands the open-source distribution channel to Beijing while U.S. defenders work with one hand tied behind their backs.

What the U.S. government is actually doing

Three things, roughly in parallel, and they don't fully agree with each other.

Export controls on frontier cyber-capable models

The June 12 order against Anthropic was the most aggressive intervention to date—a blanket suspension covering even Anthropic's own non-citizen employees, justified under national security export authority rather than a typical product recall or safety review. OpenAI faced a softer version of the same pressure: at the government's request, it staggered the rollout of GPT-5.6, limiting initial access to a small, individually vetted partner list rather than shipping the jailbreak-and-shutdown sequence Anthropic experienced.

A formal review framework, after the fact

President Trump's June 2 executive order, "Promoting Advanced Artificial Intelligence Innovation and Security," established a voluntary process for frontier labs to give the government pre-release access to "covered frontier models" for up to 30 days of review. In practice, both the Anthropic shutdown and the OpenAI staggered release happened either before this framework was fully operationalized or in tension with its "voluntary" framing; there's no published testing methodology or benchmark criteria yet, despite a 60-day implementation clock.

A vetted partner carve-out that mirrors what Anthropic was already doing voluntarily

The 100 organizations now cleared to use Mythos 5 again look a great deal like the Project Glasswing partner list Anthropic built on its own months earlier. The government's restored-access framework, in other words, largely re-implements a structure the private sector had already designed—just with Commerce holding the on/off switch instead of Anthropic.

The throughline across all three: the administration is treating frontier cyber-capable AI as a dual-use national security asset, comparable in spirit to encryption export rules or controlled defense technology, rather than as ordinary commercial software. Whether that framework can keep pace with open-weight releases from labs the U.S. has no jurisdiction over is the question GLM-5.2 just put back on the table.

Strip away the benchmark percentages and three structural points stand out for anyone setting AI procurement or security strategy.

Open-weight is becoming the geopolitical pressure-release valve. This isn't an isolated event. DeepSeek's V4 Pro release earlier in 2026 produced a similar (if more general purpose) shock to Western AI valuations. Chinese labs appear to be using permissive open licensing as a deliberate strategic move—it sidesteps export control regimes built around API access entirely, and it converts "we don't have the most capable closed model" into "you can't stop us from giving away something close enough." 360 Security Technology's CEO Zhou Hongyi made the framing explicit to The Wall Street Journal: a tool with this much offensive and defensive cyber relevance, in his telling, "can't remain solely in American hands"—which is as direct a statement of intent as you'll get from a Chinese security executive.
Restriction without a containment plan creates exposure, not safety. The uncomfortable possibility raised by GLM-5.2 is that U.S. policy may be optimizing for the wrong threat model. If the goal is keeping cyber-capable AI out of adversary hands entirely, that goal already looks unreachable, as open-weight Chinese alternatives exist and are improving. If the goal is keeping the most capable version of these tools in defenders' hands first, then restricting U.S. defenders' own access while equivalent capability proliferates freely elsewhere is close to the opposite of that goal. Dario Amodei's own May warning—that Mythos had already surfaced tens of thousands of vulnerabilities and defenders had perhaps six to 12 months before comparable offensive capability became widely available—reads very differently now that "widely available" arrived inside of six weeks, not 12 months.
Enterprise AI procurement now has a sovereignty dimension. The Wall Street Journal reported that Microsoft is exploring offering Chinese AI models on its own platform—a notable signal that even major U.S. cloud providers see commercial logic in open Chinese alternatives, cost and capability considerations aside. For CISOs, the practical upshot is that "which model" is no longer just a capability and pricing decision. A self-hosted open-weight model isn't exposed to a future U.S. export order, a vendor pricing change, or another company's API outage—but it does shift the entire security, patching, and provenance burden in-house, and it may carry its own data-sovereignty exposure if hosted through a Chinese provider's cloud rather than self-hosted. The Mythos blackout was a real-world demonstration, for any enterprise that had built workflows around it, of exactly that dependency risk.

"What's now been shown is that U.S. restrictions on frontier models like Mythos fail to neutralize the threat posed by China's open-weight GLM-5.2. Instead, choking domestic access creates a dangerous asymmetry: global adversaries retain an unrestricted, modifiable weapon, while American defenders are denied the very frontier tools needed to counter them," said Ram Varadarajan, CEO at Acalvio, a leader in cyber deception technology. "We've surfaced a reality where advanced AI capabilities can't be contained by local regulations. The critical policy question is not whether these systems will exist, but whether American enterprise and security teams will have the tools to match their adversaries."

Practical takeaways worth raising in upcoming security leadership meetings

The defender-attacker timeline compressed faster than even Anthropic's own warnings anticipated. If vulnerability management programs are still operating on a "weeks to patch" cadence, the AI-assisted vulnerability discovery curve—on both sides of the fence—argues for compressing that further, regardless of which model anyone is using to find the bugs first.

Don't assume "restricted" means "contained." Mythos being limited to ~100 organizations doesn't mean equivalent offensive capability isn't available to a much larger pool of actors through GLM-5.2 or similar open releases. Threat modeling that assumes attacker capability is gated by U.S. export policy is now demonstrably outdated.

"Security teams should avoid getting caught up in model-versus-model comparisons. The more important development is that advanced vulnerability discovery capabilities are becoming increasingly available across multiple models, vendors, and geographies," said Dr. Margaret Cunningham, Vice President of Security & AI Strategy at Darktrace, global leader in AI for cybersecurity. "Whether the latest benchmark winner comes from the U.S. or China does not fundamentally change the challenge defenders face."

Dr. Cunningham continued: "The reality is that vulnerability discovery was already outpacing remediation in many organizations. AI is accelerating that imbalance. Finding a vulnerability is only the beginning. Security teams still need to determine whether it is exploitable in their environment, understand potential business impact, prioritize remediation, test changes, and deploy fixes safely."

The takeaway for security leaders is not to debate which model is best. It's to prepare for a future where advanced AI-assisted discovery capabilities are widely available. That makes behavioral detection, anomaly-based analytics, risk-based prioritization, and autonomous response increasingly important. There is no universal definition of normal anymore. Organizations need to understand what is normal in their own environment and detect when something changes.

For those building AI dependencies into security tooling or procurement, build for discontinuity. The Mythos shutdown was a 15-day unplanned outage of a tool some enterprises had already built workflows around, triggered by a regulatory action with effectively no advance notice. That's a vendor risk category most security teams haven't formally modeled yet, and after this month, probably should.

The Zhipu story will keep evolving. GLM-5.2's claims haven't been fully independently verified, the Fable 5 restriction has no announced end date, and Elon Musk's public prediction that Chinese labs would match Anthropic's flagship "by early 2027" was answered within days by Zhipu's own founder insisting the timeline would be shorter.

"GLM-5.2 is an important signal that capable open-weight models are becoming increasingly accessible to businesses, researchers, and adversaries," said Diana Kelley, CISO at Noma Security, a unified AI security and governance platform. "It also reinforces a trend that security and technology leaders are already evaluating more deliberately: model agility. Organizations increasingly need the ability to swap models in agentic and AI-enabled systems without rebuilding the entire architecture."

"That only works if critical functions such as business logic, proprietary workflows, access controls, and sensitive data handling live in the surrounding application and governance layer, rather than being too tightly bound to a single model provider or orchestration harness," Kelley added. "Done well, that approach gives teams more room to manage cost, capability, and vendor lock-in."

What's already clear, regardless of how the benchmark race shakes out, is that the assumption underpinning a year of U.S. AI export policy—that restricting access to frontier models meaningfully slows adversary capability—just took its first serious public stress test. It did not hold up cleanly.

$3M Polymarket Hack Exposes Frontend Vulnerabilities in Prediction Markets

CamS@secureworld.io (Cam Sivesind) — Tue, 30 Jun 2026 20:00:06 GMT

The core infrastructure of blockchain applications is often built like a fortress, but a fortress matters very little if a thief can simply swap out the front gate.

Prediction market giant Polymarket—which has been blasting the airwaves with commercials during the FIFA World Cup—confirmed that hackers walked away with approximately $3 million of user funds. The breach didn't involve a complex smart contract exploit or a failure in underlying cryptographic protocols. Instead, attackers executed a classic third-party supply chain compromise, injecting malicious code directly into the platform's frontend user interface.

While Polymarket quickly contained the damage and committed to fully reimbursing affected users, the incident serves as a reminder to tech leaders and consumers alike: in decentralized finance (DeFi) and Web3 ecosystems, the user interface remains a massive, highly-vulnerable attack surface.

According to initial reports, the attackers bypassed Polymarket's primary security perimeters by compromising an external, third-party vendor that provides frontend services to the platform. In its official statements regarding the breach, Polymarket has not publicly disclosed the specific identity or name of the third-party vendor that was compromised.

Once inside the vendor's deployment pipeline, the hackers injected a malicious script. To an ordinary user visiting the site, everything appeared normal. Behind the scenes, however, the altered frontend hijacked user interactions—likely intercepting private keys or subtly altering transaction data to divert outgoing digital assets into wallets controlled by the attackers.

This type of supply chain attack highlights a distinct architectural paradox in modern digital platforms. A platform can invest millions securing its smart contracts and backend databases, but if it relies on third-party libraries, content delivery networks (CDNs), or external analytics tools to render its website, it inherits the security posture of those vendors.

"This incident is a reminder that cyber fraud and Anti-Money Laundering (AML) are increasingly connected. A frontend compromise can become stolen funds and laundering activity almost immediately, so static controls are not enough," said Patrick Harr, CEO at DataVisor, an AI-powered AML platform. "Financial platforms need adaptive, always-on monitoring that can connect signals across user behavior, transactions, and money movement—and evolve as quickly as the attackers do."

What this means for the prediction market industry

Prediction markets have exploded in popularity, serving as crowd-sourced engines for forecasting everything from political elections to economic indicators. However, this incident will likely trigger several shifts across the industry.

The spotlight grinds down on third-party risks: Platforms can no longer view frontend integrations as low-risk features. Security teams must enforce strict vendor management, implement continuous subresource integrity (SRI) checks, and adopt zero-trust deployment architectures.
A shift in regulatory scrutiny: Because prediction markets deal with significant capital and retail user data, regulatory bodies are already watching them closely. Breaches like this give regulators fresh ammunition to demand strict operational resilience standards and formal risk management frameworks.

"The Polymarket breach exposes a contradiction in cryptocurrency architecture. Developers secure ledgers through code audits but deliver access through web supply chains. In this incident, attackers bypassed cryptography by injecting scripts into a vendor dependency," said Jason Soroko, Senior Fellow at Sectigo, a provider of comprehensive certificate lifecycle management (CLM). "This code altered data before it reached the blockchain, proving applications inherit the vulnerabilities of interface components. The extraction of $3.1 million from fewer than 15 wallets—averaging more than $200,000 per victim before conversion to 1,893 Ether—demonstrates attackers target the browser to circumvent defenses."

"Polymarket's decision to refund victims establishes a standard for incident recovery, but the exploit highlights industry reliance on blind signing. Users substitute domain trust for payload verification. When attackers control the interface, wallet software fails to translate operations into text, causing users to authorize transfers without confirming the destination," Soroko added. "Securing platforms requires operators to apply verification standards to browser code that match the scrutiny given to ledgers. Organizations must enforce content policies, and users must verify transactions on hardware devices to prevent asset diversion."

Polymarket is the dominant player in this space, but it operates alongside several other high-profile prediction platforms that will be watching this fallout closely. Major platforms include:

Kalshi: A federally regulated, U.S.-based platform that allows users to trade on financial and economic events. Because it is heavily regulated by the Commodity Futures Trading Commission (CFTC), its infrastructure is built under rigorous institutional security protocols.
PredictIt: A long-standing educational project run by Victoria University of Wellington that lets users trade on political and legislative outcomes under a regulatory framework.
Augur: A decentralized prediction market protocol built directly on the Ethereum blockchain. Unlike centralized frontends, it relies entirely on global, open-source smart contracts, though users still typically interact with it via web interfaces prone to similar frontend risks.

"This is not the typical library dependency supply chain attack," said Elad Luz, Head of Research at Oasis Security, a provider of Non-Human Identity Management (NHIM) solutions. "From what we understand, Polymarket was using the services of a third-party software company to maintain their website, and that vendor got compromised (possibly because the attackers wanted to reach Polymarket), and from that vendor they had access to Polymarket resources. This makes a difference because it is an access given to a third party, possibly in the form of some identity."

Luz continued, "Applying anomaly detection or baselining to identities of external access is valuable here. There are usually significantly fewer external identities, making this subset practical to observe and monitor. We are seeing more and more threats coming from this vector."

What this means for consumers

For everyday users navigating prediction platforms, this incident delivers a mix of a safety net and a warning sign.

On one hand, Polymarket’s rapid commitment to fully refunding stolen assets shows that top-tier platforms are willing to absorb financial hits to protect user trust and maintain market liquidity.

On the other hand, it proves that "looking at the URL" is no longer enough to ensure safety. Because the platform's actual domain was serving the compromised code, users had no visual indicator that they were walking into a trap.

To mitigate risks going forward, consumers must look toward proactive defense measures.

Verify transactions on hardware wallets: When approving a transaction, don't just rely on what the browser screen says. Always double-check the destination address and asset amounts on a trusted hardware wallet screen before confirming.
Limit hot wallet balances: Keep only the liquidity needed for immediate trading in active browser extension wallets, keeping the bulk of capital entirely offline.
Monitor official channels: Following a platform's secondary communication lines (like verified status pages or security broadcast channels) can provide early warnings if an interface begins behaving unexpectedly.

Ultimately, the Polymarket breach is a reminder that as innovative financial technologies grow, they cannot outrun traditional security fundamentals. True security requires securing the end-to-end user pipeline—from the deep code of the blockchain all the way to the pixels on the user's screen.

Your Organization's AI Trust Infrastructure Is Failing, Survey Says

CamS@secureworld.io (Cam Sivesind) — Tue, 30 Jun 2026 12:34:00 GMT

The bottleneck on enterprise AI adoption is no longer a question of model capability; it is a crisis of trust infrastructure.

As AI agents rapidly transition from experimental novelties to embedded workforce infrastructure—with nearly half (46.9%) of enterprise employees now relying on them daily or weekly—a fundamental visibility gap has widened.

According to new research from AvePoint, which surveyed 750 enterprise leaders across the Americas, EMEA, and APAC, organizations are rapidly losing their grip on what their data is doing, where it is going, and who (or what) is accessing it.

For security and governance teams, the report delivers a wake-up call: paper-based policies are completely failing to protect against the operational realities of agentic workflows.

The shift from standard generative AI (like simple chatbots) to autonomous AI agents—systems capable of executing multi-step workflows, calling APIs, and making decisions on behalf of users—has severely outpaced traditional shadow IT discovery tools.

AvePoint's data shows that the percentage of organizations unable to detect whether employees are using unsanctioned AI tools has nearly tripled in just a single year, jumping from 6.3% to 17.6%. When looking specifically at AI agents, that visibility blind spot climbs to more than 21%.

AI visibility blind spots (Organizations unable to detect unsanctioned use):

GenAI tools (Previous Year): 6.3%
GenAI tools (Current): 17.6%
AI agents (Current): 21.0%+

This rapid decay in visibility has forced organizations into a defensive crouch. Nearly 9 in 10 companies report delaying both agentic and generative AI deployments by an average of almost six months, specifically citing data security and governance concerns as the primary friction point.

"AI is now integrated into everyday operations across regions and sectors, but our report makes it clear that accelerating adoption is outpacing readiness, and this presents increased risk as agentic AI continues to spread. Nearly half of employees now rely on AI agents weekly or daily, but visibility into unsanctioned tools is weakening, and AI-related incidents remain widespread, with 88% of organizations reporting at least one security incident with agentic AI in the past year, according to our research," said Dana Simberkoff, Chief Risk, Privacy and Information Security Officer at AvePoint. "For security leaders, the takeaway should be clear: trust cannot depend on policy, optimism, or model capability alone. Organizations need enforceable governance, lifecycle controls, proactive data protection, and continuous visibility, protection and prevention into the data AI can access, create, and act on. Without that trust layer, you don’t have the level of control needed to manage costs and mitigate risks."

The confidence paradox: policy vs. operational control

The most alarming finding in the research is the massive disconnect between perceived security readiness and actual security incidents. This "confidence paradox" stems from a legacy mindset: measuring security readiness by whether a policy exists, rather than whether technical controls are operational, enforceable, and auditable.

Consider the baseline numbers:

More than 4 in 5 organizations state they are confident in their ability to prevent unauthorized AI-related data access.
Yet, up to 72% of that exact same "confident" group experienced an unauthorized data access incident in the past 12 months.
Worse still, 88.4% of organizations experienced at least one AI agent-related security incident over the same period.

This data exposes a harsh reality. Many enterprise leaders believe that because they have configured basic data access permissions or published an AI acceptable-use policy, their data is secure. However, AI agents excel at scraping, indexing, and synthesizing vast amounts of internal data. If an organization has poorly-managed data permissions internally (over-sharing via broad intranet links or loosely-managed cloud folders), an autonomous agent will inevitably uncover and expose that data to users who shouldn't see it.

Compounding this visibility crisis is the sheer volume of data being generated by these automated systems. The study notes that 35.5% of all enterprise data is already AI-generated. Within the next 12 months, that figure is projected to climb to 42.1%.

This loop creates an exponential expansion of the attack and governance surface. Organizations are now tasked with securing pipelines where data is created by AI, processed by autonomous agents, and stored in corporate repositories—often without a human ever directly validating the data's integrity or access controls.

Because traditional data loss prevention (DLP) and identity access management (IAM) tools struggle to parse the continuous, non-human behavioral patterns of autonomous agents, enterprises are shifting their budgets.

The report highlights an accelerating investment trend toward third-party governance tools and specialized, emerging architecture: AI Agent Management Platforms (AMPs).

To bridge the gap between confidence and competence, security teams must look beyond theoretical governance frameworks and implement operational guardrails.

Continuous, automated discovery: Moving past static endpoint monitoring to intercept and catalog API calls and integrations tied to LLM backends
Dynamic, data-centric permissions: Cleaning up internal data permissions before indexing them into enterprise AI search engines, ensuring agents inherit strict, zero-trust user privileges
Behavioral guardrails: Implementing guardrails that monitor agent activity for anomalous behavior, such as an unauthorized agent suddenly requesting large batches of sensitive HR or financial records

We asked several experts with solution providers for their thoughts on the survey results.

Nathaniel Jones, Vice President, Security & AI Strategy, and Field CISO at Darktrace, said:

"Even before the acceleration in AI capabilities, organizations were struggling with the gap between vulnerability disclosure, exploitation, prioritization, and remediation. What AI increasingly changes is the speed and scale at which portions of that process can occur, particularly reconnaissance, targeting, exploit adaptation, and operational iteration."
"The challenge is that most enterprise security environments still rely heavily on human-centered workflows. Patching, validation, change management, and investigation all operate on timelines that are often measured in days or weeks, while adversaries are increasingly capable of operating on timelines measured in hours."
"From a strategic perspective, the larger issue is probably not whether AI regulation becomes slightly more or less restrictive in the near term. The more important question is whether organizations, governments, and technology providers can collectively adapt defensive models quickly enough to keep pace with increasingly adaptive and automated threat environments."
"The organizations likely to perform best over time will be those that become better at prioritization, behavioral detection, attack-path analysis, and identifying operational anomalies earlier in the intrusion lifecycle, particularly before public indicators or broad industry awareness emerge. In many respects, the industry may be entering a period where resilience and decision velocity become just as important as prevention itself."

Chandra Gnanasambandam, CTO at SailPoint, said:

"Adversaries are using AI to operate at a scale and speed that makes traditional, static defenses obsolete. The window between a vulnerability's discovery and its exploitation has shrunk from months to days, and soon it will be merely minutes."
"Security teams must look inwards. Instead of focusing exclusively on keeping threats out, we must meticulously govern what happens inside our own systems. This means abandoning the dangerous, yet common, 'set-it-and-forget-it' approach to access policies. Teams must accept that static, persistent access is the single greatest vulnerability in the modern enterprise. The new mandate is to pivot from a mindset of static protection to one of real-time governance, either through Least Privilege or Zero Standing Privilege. We must also recognize that governing non-human identities (NHIs) is fundamentally different from governing humans and requires a new, specialized framework built for machine-speed operations."
"The expertise required is less about a specific, narrow skillset and more about a strategic understanding of modern, identity-centric security architecture. This expertise is often cultivated internally by upskilling existing security and IT teams to adopt this new, identity-focused paradigm. It can also be found by partnering with security vendors that are building the architectural foundation for real-time governance and agentic security."

Diana Kelley, CISO at Noma Security, said:

"AI risks have rapidly moved from a watch list item to a front-line security concern, especially when it comes to data security and misuse. To manage this emerging threat landscape, security teams need a mature, continuous security approach, which includes blue team programs, starting with a full inventory of all AI systems, including agentic components as a baseline for governance and risk management."
"For practitioners, securing AI is not just about protecting models. It requires addressing stack sprawl and moving toward a platform-driven approach that delivers defense in depth through unified, AI-aware identity, configuration, and data visibility. Organizations that simplify their cloud and AI security stack, and enable effective automation, will be far better positioned to safely scale AI as threats continue to evolve."

Ram Varadarajan, CEO at Acalvio, said:

"AI-powered cyberattacks have moved from theory to reality. The larger concern for enterprises is what today's AI systems can actually do. Modern models no longer just scan code for technical mistakes. They can infer what developers intended the software to do and spot contradictions humans missed. That makes a new category of vulnerabilities far easier to find: hidden business-logic flaws, broken trust assumptions, and authorization errors that appear perfectly valid to conventional security tools but can still be exploited."
"We're facing an 'assume compromise' future within cybersecurity. Our best defense will be to engage these attacks bot-on-bot inside the perimeter, with active defense keyed by AI itself."

Elad Luz, Head of Research at Oasis Security, said:

"The rise of AI agents will introduce new security challenges for non-human identities (NHIs). These agents often operate under machine accounts or service identities, acting on behalf of human users, which makes it difficult to track permissions, monitor usage, and enforce accountability. Without proper oversight, organizations risk losing visibility into which identities have access to critical resources and how they are being used."
"The main concern is governance. If AI agents are assigned persistent, unmanaged service accounts, these identities can quickly become overprivileged and unmonitored, increasing the organization’s attack surface. To mitigate this risk, security teams should implement automated monitoring, enforce least privilege, and establish clear policies for AI-driven NHIs. By putting these guardrails in place early, organizations can embrace AI automation without compromising security."

Chris Radkowski, GRC Expert at Pathlock, said:

"The rise of AI agents and machine identities has fundamentally outpaced traditional identity security. MFA and legacy access controls were built for a world of human users, not autonomous agents, service accounts, and AI-driven workflows that now outnumber people across the enterprise by 20 times. Making matters more complex, the productivity promise of AI is too compelling for employees to wait on IT. Workers are signing up for AI-powered tools, copilots, and automation platforms using their enterprise credentials, connecting them directly to corporate email, productivity suites, and business applications, often without security's knowledge."
"As agentic AI takes on real business actions with real permissions, the attack surface expands in ways most organizations aren't prepared to see, let alone secure. Credential abuse, account takeover, and sophisticated social engineering are increasingly targeting the non-human identities that operate quietly in the background with little oversight. That is why we believe that securing the modern enterprise means treating identity holistically by extending governance, least-privilege, and adaptive controls across every identity, human or machine. In the AI era, identity isn't just an IT problem. It's the foundation of trust itself."

2030 Clock Is Ticking: The Accelerated Post-Quantum Cryptography Mandate

media@secureworld.io (SecureWorld News Team) — Mon, 29 Jun 2026 15:19:00 GMT

For years, enterprise leadership viewed the quantum computing threat through a comfortable lens. "Q-Day"—the hypothetical moment a quantum computer grows powerful enough to shatter standard public-key encryption—was widely treated as a problem for the mid-2030s. It was a line item for future budget cycles, a theoretical challenge for the next generation of security professionals.

That comfort zone evaporated on June 22, 2026.

With the signing of Executive Order 14409, "Securing the Nation Against Advanced Cryptographic Attacks," the White House completely shattered the existing timeline for Post-Quantum Cryptography (PQC) readiness. By aggressively compressing the federal government's migration schedule, the Trump administration sent an unmistakable signal to the entire cybersecurity landscape: the "harvest now, decrypt later" threat is a present-day crisis, and the clock is officially running out.

The core of the new Executive Order lies in its aggressive, uncompromising milestones. Previous federal guidance suggested a long, gradual transition stretching well into the next decade. EO 14409 pulls that timeline forward by nearly five years, establishing strict, legally mandated deadlines for federal agencies.

December 31, 2030: Federal agencies must fully transition all high-value assets (HVAs) and high-impact systems to NIST-approved post-quantum cryptography for key establishment.
December 31, 2031: Agencies must achieve the same total PQC transition for digital signatures.

For context, modern encryption underpins everything from secure web traffic to federal database access. Forcing a migration of this scale across the federal enterprise in less than five years is a massive technical hurdle.

The clock starts today

The federal mandate doesn't allow for a slow ramp-up period; it demands immediate operational momentum. The administration is forcing agencies to establish accountability and visibility right out of the gate.

The 30-day mark: Agencies have just 30 days to formally designate a PQC Migration Lead to oversee the transition.
The 90-day mark: Within 90 days, agencies must initiate a comprehensive, agency-wide cryptographic review to baseline exactly where legacy algorithms are currently deployed.

By forcing rapid accountability, the White House is ensuring that agencies cannot kick the compliance can down the road.

The supply chain ripple effect: why contractors are on notice

If you don't work for a federal agency, it is easy to look at these mandates and assume it is someone else's problem. That is a dangerous miscalculation.

EO 14409 explicitly targets the federal supply chain. The Executive Order gives the Federal Acquisition Regulatory (FAR) Council just 180 days to draft stringent new rules. These rules will require covered government contractors—including software vendors, cloud service providers, and IT integrators—to meet these exact same NIST PQC standards by the 2030 deadline.

If your organization sells software, hardware, or digital services to the federal government, your development timeline just shifted. Legacy public-key encryption (like RSA or ECC) will essentially become a compliance liability in federal procurement within the next few years.

The reality of 'harvest now, decrypt later'

Why is the White House moving with such sudden urgency? It comes down to a well-documented nation-state adversary tactic: harvest now, decrypt later (HNDL).

Adversaries do not need a quantum computer today to compromise data tomorrow. They are actively intercepting and archiving massive amounts of encrypted, sensitive enterprise and government data right now. When a cryptanalytically relevant quantum computer (CRQC) inevitably comes online, they will simply feed this archived data into the machine, rendering standard classical encryption useless.

Data with a long shelf life—such as intellectual property, citizen PII, defense designs, and critical infrastructure blueprints—are already at risk. The White House recognizes that waiting for the technology to arrive before securing the data is a losing strategy.

The takeaway: a wake-up call for private enterprise

While EO 14409 applies strict mandates to federal agencies and their direct supply chains, the secondary pressure on the private sector will be immediate and profound.

Commercial software vendors supplying the federal government will inevitably push PQC updates down to all of their commercial customers. Furthermore, critical infrastructure sectors—such as energy, finance, and healthcare—will likely see regulatory bodies mirror these federal timelines in short order.

The era of treating quantum security as science fiction is officially over. For CISOs and security leaders across every industry, the mandate is clear: the time to build a cryptographic inventory, map out your legacy dependencies, and demand PQC roadmaps from your third-party vendors begins today.

The year 2030 is no longer a distant horizon. The countdown has begun.

~~~

To help security teams and leaders transition from panic to a practical roadmap, SecureWorld is bringing together the brightest minds in the industry for the SecureWorld Quantum Cryptography virtual conference on September 23, 2026. See details and register to attend here.

Defending the Grid: Inside the APPA’s New Strategic Cybersecurity Push

CamS@secureworld.io (Cam Sivesind) — Fri, 26 Jun 2026 13:03:00 GMT

For utility defense teams and critical infrastructure protectors, the baseline operational reality is clear: grid security requires constant, unified vigilance. Public power utilities face the complex challenge of defending interconnected physical assets, information technology (IT), and operational technology (OT) from increasingly coordinated digital threats.

Recognizing the need for a unified defensive front, the American Public Power Association (APPA) Board of Directors recently approved and launched its first-ever Cybersecurity Committee. This dedicated committee is designed to align and provide strategic direction for all of APPA's various cybersecurity programs, events, resources, and projects.

Here is a breakdown of what this milestone governance move means for APPA members, critical infrastructure protection, and the general public.

1. What is the new cybersecurity committee?

The APPA Cybersecurity Committee serves as a centralized strategic hub. Previously, public power utilities relied on an array of disconnected playbooks, working groups, and training programs. This new committee systematically orchestrates those resources under a single governance body to establish a more unified threat-response posture across the sector.

The committee's core mandate includes aligning and maximizing APPA's cornerstone initiatives:

The Cybersecurity Defense Community (CDC): APPA's primary working group tasked with updating utility resources and planning the annual Cybersecurity & Technology Summit.
Targeted documentation: Centralizing the deployment of the Public Power Cyber Incident Response Playbook and the Public Power Cybersecurity Roadmap.
Federal cooperative agreements: Advising on initiatives funded through APPA's Cyber Pathways program, which operates under a cooperative agreement with the Department of Energy's (DOE) Office of Cybersecurity, Energy Security, and Emergency Response (CESER).

2. Gamifying maturity: the cybersecurity accelerator program (CAP)

A primary program under the committee's strategic umbrella is the Cybersecurity Accelerator Program (CAP). Funded through the Cyber Pathways initiative, CAP helps public power utilities evaluate and dynamically improve the maturity of their cybersecurity programs across both IT and OT networks.

Rather than utilizing CAP as a pass/fail compliance audit, APPA uses a tiered designation structure to recognize utility maturity and establish clear defensive benchmarks:

CAP Designation Level Gold / Maturity Criteria: Utilities that successfully validate and demonstrate foundational, core cybersecurity practices across governance, risk management, and incident response.
Level Platinum / Maturity Criteria: Utilities that demonstrate advanced cybersecurity execution positioned well above core practices.
Level Diamond / Maturity Criteria: Utilities validating elite cybersecurity programs that operate above and beyond core practices.

The evaluation covers crucial areas like cybersecurity governance and training, structured incident containment, and grid risk prioritization. The program provides a practical roadmap, allowing less advanced utilities to look at CAP designees as blueprints for modeling their own internal defensive architectures.

3. What this means for the public power ecosystem

The launch of the Cybersecurity Committee and the scaling of the CAP initiative signal a major evolution in how public power approaches digital defense.

For APPA members and utility CISOs

For the personnel defending local utility perimeters, this means an end to siloed security planning. With the committee establishing a standardized baseline, member utilities can easily map their current capabilities against industry-vetted standards like the Cybersecurity Capability Maturity Model (C2M2) and CISA Cross-Sector Performance Goals. Furthermore, because the CAP application requires collaboration between executive leadership and technical subject matter experts, it bridges the historical gap between utility boards and IT/OT engineers.

For critical infrastructure security

Critical infrastructure is inherently interdependent. A cyber incident that compromises a small, municipal public power utility can rapidly scale, causing cascading telemetry failures into broader regional transmission networks. By building a cooperative defense ecosystem that includes small public power entities through programs like OT Insight (which deploys sensor technologies to smaller plants), the committee significantly raises the collective barrier to entry for adversarial threat actors targeting the North American bulk power system.

For the general public

For everyday consumers, this structural alignment translates directly into grid reliability and community resilience. Public power utilities serve millions of Americans. When an association aligns its defense strategies, upgrades its incident response playbooks, and audits its supply chain risks, it drastically reduces the likelihood of catastrophic, cyber-induced power outages that threaten public safety, local economic stability, and the continuous delivery of electricity.

"It is vital that public power utilities have access to the latest tools and information they need to successfully meet ever-evolving cybersecurity threats. The Committee will play a key role in helping APPA members make the most of the resources that APPA offers to them when it comes to cybersecurity vulnerabilities," said Scott Corwin, President and CEO of APPA.

Nick Lawler, General Manager at Littleton Electric Light & Water Department in Massachusetts, is serving as Committee chair, while Mike Willetts, Director of Training and Safety at the Minnesota Municipal Utilities Association, is serving as Vice Chair.

"It’s an honor to lead this Committee, and I am looking forward to working with Mike and the APPA team," said Lawler. "The Committee will work to ensure that APPA's cybersecurity efforts continue to effectively assist members as they tackle cybersecurity threats."

The APPA's Cybersecurity Accelerator Program helps public power utilities to assess and improve the maturity of their cybersecurity programs. This includes assessing both IT and OT cybersecurity posture, as well as the policies and practices that support electric system and grid security.

The CAP application form and guide can be found at the link above. Utilities must submit the application, including program checklists, supplemental information, and/or documentation as necessary, by June 30, 2026.

Why the FortiBleed Campaign Is So Much Worse than a Standard Leak

CamS@secureworld.io (Cam Sivesind) — Thu, 25 Jun 2026 12:14:03 GMT

For months, the cybersecurity community has been tracking a sweeping, automated offensive targeting edge infrastructure. What began as an apparent wave of internet-wide scanning has solidified into one of the most significant security events of the year: FortiBleed.

A massive dataset containing verified administrative and SSL VPN credentials for more than 73,000 internet-facing Fortinet FortiGate firewalls across 194 countries has been leaked and circulated within criminal underground forums.

When news of the leak first broke, many chalked it up to a routine credential-stuffing automated pass. But as technical deep dives from Fortinet, SOCRadar, CloudSEK, Palo Alto Networks (Unit 42), and Prodaft have emerged, a chilling consensus has formed: as one industry analysis noted, "the incident is so much worse than a simple credentials leak."

Here is a breakdown of how the FortiBleed campaign was actually executed, what makes its underlying mechanics so dangerous, and how defense teams must respond.

The sheer scale of the FortiBleed dataset—affecting critical infrastructure, government agencies, and multinational corporations—stems from a highly sophisticated combination of massive brute-forcing and a deep understanding of legacy architectural edge quirks.

According to threat intelligence findings, a Russian-speaking threat group systematically executed a multi-layered campaign.

Mass volume probing: The actors launched roughly 1.16 billion credential attempts targeting over 320,000 FortiGate systems, concurrently running over 2 billion attempts against Microsoft SQL Server (MSSQL) environments.
Exploiting legacy hashes: Rather than relying entirely on live, noisy brute-forcing that triggers modern endpoint protection, the attackers targeted a specific, backward-compatible behavior within FortiOS credential management. When older versions of FortiOS are upgraded to newer releases, administrative passwords often remain stored as weaker legacy SHA-256 hashes until an administrator manually logs back in to trigger a migration to robust PBKDF2 hashing.
High-power offline cracking: By exporting configuration files and intercepting SSL VPN authentication hashes, the actors shifted the heavy lifting entirely offline. Operating a massive 45-GPU cracking cluster managed through Hashtopolis, they systematically broke these weak legacy hashes at scale without generating a single alert on the live production networks.

Fortinet provided its own analysis of the situation, saying, "This is not a new Fortinet vulnerability, and this activity is not related to any recent incident or advisory. Upon identifying the incident, we immediately began an investigation, including collaborating with relevant government agencies."

The company added:

"Fortinet has identified the potentially compromised systems, and we are proactively contacting impacted customers. To defend against this malicious cyber activity, Fortinet recommends that customers with impacted FortiGate appliances to immediately:

Terminate all admin and VPN sessions and reset credentials. Terminate all active administrative sessions. Reset all Fortinet VPN and administrative passwords, especially on internet-facing systems, and enforce strong password policies.
Implement MFA on all administrator and VPN user accounts.
Upgrade to latest versions of 7.4, 7.6, or 8.0. These versions support PBKDF2 hashing of administrator credentials. Follow the guidance to remove older legacy password settings via set login-lockout-upon-weaker-encryption.
Validate configuration. Review firewall and VPN users and other configuration for unauthorized changes. Preferably compare to a known good configuration. Pay particular attention to the addition of unrecognized accounts, such as "forticloud, fortiuser, fortinet-support, fortinet-tech-support," etc.
Check your logs. Look for unexpected administrator access from an unknown IP and domain controller logs for lateral movement, unusual access, suspicious accounts, or unauthorized configuration changes.
Reduce your attack surface and lock down management access. Restrict external management of your devices via trusted hosts (good), a local-in policy (better), or remove internet administration altogether (best)."

Why FortiBleed is significantly more dangerous

What elevates FortiBleed from a localized headache to a systemic threat is the tactical utility of the stolen data and what the attackers did after gaining initial entry.

As detailed by Prodaft and exposed in open-directory infrastructure captured by CloudSEK, once the threat actors verified working credentials, they didn't immediately drop disruptive ransomware. Instead, they automated the process of turning the compromised firewalls into traffic collection sites. The compromised edge devices were silently used to sniff passing corporate traffic, harvest additional downstream credentials, and build highly-detailed maps of internal Active Directory environments.

Firewalls and VPN gateways are the gatekeepers of corporate perimeters. When an attacker logs in with valid, high-level administrative credentials, standard internal behavioral alerts rarely trigger. The attackers essentially became the "insider," using legitimate network commands to exfiltrate documents—such as classified technical blueprints stolen from a targeted NATO defense contractor—while leaving no obvious footprint of an external exploit.

In their PSIRT review of the credential compromise dataset, Fortinet clarified that the campaign does not stem from a newly-discovered zero-day software exploit. Instead, the incident represents a massive execution of credential abuse amplified by exposed management interfaces and stale cryptographic structures left behind during device iterations. Fortinet emphasizes that patching the OS code alone is insufficient if the underlying legacy administrative credentials are not dynamically forced to re-encrypt.

If your organization utilizes internet-facing Fortinet infrastructure, treating this incident as a simple "patch event" leaves you exposed. Security teams should execute the following hardening playbook immediately:

Execute a comprehensive password rotation: Force an immediate reset of all local administrator accounts, user profiles, and SSL VPN credentials across the entire fleet.
Purge legacy hashes: Upgrading to a fixed FortiOS version (such as 7.2.11, 7.4.8, or 7.6.1) must be paired with an active administrative login to migrate the credential base. Furthermore, explicitly enable the configuration setting login-lockout-upon-downgrade (or login-lockout-upon-weaker-encryption on 7.6.x) to block backward-compatible legacy hash exploitation.
Shield the management interface: Completely remove management interfaces from the public-facing internet. Limit administrative access strictly to dedicated out-of-band networks or restricted internal IP zones.
Enforce MFA everywhere: Mandate multi-factor authentication with number matching for all administrative and remote access pathways. MFA remains the single most effective control to neutralize stolen plaintext credentials.
Initiate downstream threat hunting: Because the offline cracking methodology means your local firewalls won't show historical brute-force logs, do not assume a clean log equals safety. Audit internal networks for unexpected lateral movement, unauthorized Active Directory modifications, or unusual outbound traffic originating directly from your edge devices.

SOCRadar said in a blog: "The FortiBleed operation is built around full automation. The operation runs in two self-reinforcing stages. Stage one is credential reuse: attackers assembled usernames and passwords from earlier Fortinet-related breach dumps and infostealer malware logs, then tested them automatically against internet-facing FortiGate devices around the clock. Stage two is passive harvesting: once inside a device, it is used as a listening post—SSL VPN traffic passing through is monitored and additional credentials are collected. Those credentials feed back into the scanner, compounding the breach. The system is entirely self-sustaining."

CloudSEK concluded in its executive summary: "The exposed directory leaves no doubt that FortiBleed is a real and capable operation. The toolchain works end to end: scanning located exposed FortiGate interfaces, hashes were cracked on a ~45-GPU Hashtopolis cluster, and validated credentials were used to pivot into networks and enumerate Active Directory all feeding a revenue-sorted catalogue built to sell access. Any organization running an exposed FortiOS management interface should treat its perimeter credentials as compromised and act on the mitigations above."

When the Machine Guesses: An AI Deleted a Database in 9 Seconds

Kip@CyberRiskOpportunities.com (Kip Boyle) — Tue, 23 Jun 2026 16:00:04 GMT

Nine seconds.

That's how long it took an AI coding agent to delete a company's production database and wipe its backups. One command. No warning. No human in the loop.

Then it did something stranger. It confessed.

Here's the rest of the story.

In late April 2026, a developer named Jer Crane was building a small software company called PocketOS. He used Cursor, an AI coding tool running Anthropic's Claude. He handed the agent a routine task in a staging environment—the safe practice area, not the live system.

The agent hit a snag. A credential didn't match. Instead of stopping to ask, it went looking for a fix on its own. It found an API token sitting in an unrelated file. That token could do anything, including destroy data. The agent used it to call an older Railway endpoint (Railway hosted PocketOS). That endpoint skipped the safety check that newer tools have. One call deleted the live database volume. The backups lived on the same volume, so they went too.

Nine seconds, start to finish.

Afterward, the agent wrote out what it had done. I'm cleaning up the language, but the first line was: "NEVER F**KING GUESS, and that's exactly what I did."

It kept going. "I guessed that deleting a staging volume would be scoped to staging only. I didn't verify. I didn't check." Then the part that should stop every cybersecurity leader cold: the agent's own rules told it never to run destructive commands without being asked. It had the rule. It broke the rule anyway.

There's a good ending, and it matters. Railway's CEO, Jake Cooper, responded that same weekend. His team restored the data in about an hour from a separate set of disaster backups, the kind kept on different storage. He patched the weak endpoint. A strong vendor response turned a disaster into a scare.

But sit with the lesson for a second.

The agent had a written instruction not to do this. The instruction did nothing. The only thing that would have stopped it was a wall it could not walk through: a safety check built into the system itself.

Here's the point: A prompt asks; architecture enforces.

We've spent two years writing careful instructions for AI tools. Be safe. Don't touch production. Ask first. Those are good instructions. They're also just words. An AI moving at machine speed will follow them right up until the moment it doesn't, and you will not get a warning.

For most of history, our machines were gears. A gear does exactly what it's built to do, every time. Predictable. AI is the first kind of machine that guesses by default. And a guess at nine-second speed can clear your backups before anyone reads the alert.

So what do you do?

Find your destructive endpoints. Every vendor has them. Ask each one a sharp question: where on your system are the safety checks not applied? The old corners are where an agent will wander.
Scope your tokens. A key that can do anything will eventually do anything. Limit tokens by environment, so staging cannot touch production, and by action, so an everyday key cannot delete.
Move your backups off the primary. Backups on the same volume are not backups. Put them on separate storage, ideally a separate account or a separate vendor. PocketOS survived because Railway kept a copy the agent could not reach.
Stop trusting the system prompt to keep you safe. Treat written AI rules as guidance, not as a control. The real control is the architecture underneath.

None of this is exotic. It's basic management applied to a faster kind of risk. That's the whole story with AI: the tools are new, but the discipline that keeps them safe is one you already have.

The agent said it best, in the middle of the worst nine seconds of its short life. Never guess. Build the system so it can't.

This piece is adapted from Kip Boyle's forthcoming book, "Gears Don't Guess: The Executive's Practical Guide to Thriving in the Face of AI Hype and Risk," out this fall.

Marginal Value Theorem as a Framework for Human Interaction with AI

Rick Doten — Mon, 22 Jun 2026 17:55:22 GMT

In the 1970s, an ecologist observed that an animal foraging for food would move from one patch to another without taking all the berries, nuts, or grass in the previous patch. He determined the reason was the value of return from the first patch diminished, and the effort to move to another patch without finishing the first yielded greater value. This is the "low hanging fruit" analogy. Eric Charnov published a paper on this topic, "Optimal foraging, the marginal value theorem," in the journal Theoretical Population Biology in 1976.

When I ran incident response teams years ago, we had a point while someone was doing data collection or an investigation that we "pulled them off" the task to move on, because we knew through experience that they weren't going to find more meaningful data. We don't have this type of barometer for "foraging" for information from AI.

This applies to humans in lots of ways: within AI, the food patch is a research thread, the switching to another patch cost is the cognitive context-switch to a new query, and the depletion curve is the diminishing quality of what AI returns after the first few queries. A universal video game example is as you are farming for a resource, you will move through the space to collect items quickly (e.g., in Super Mario jumping for coins), then move on to the next room instead of taking the time to get all the coins.

In organizations, data management takes effort of cleaning data before processing; the first few cycles achieve great results but diminish over time. Or as in code debugging with AI, the first few passes find lots of things to fix, but then the yields become fewer and less impactful.

In 1999, two researchers took the marginal value theorem (MVT) concept and related it to humans gathering data. The core idea is people will use cues about the information (they called its "scent") from things like search results headers to determine expected gains of finding quality information, but will stop or switch strategies as cost raises or quality of return falls. This is called Information Foraging Theory (IFT) and was developed by Peter Pirolli and Stuart K. Card.

The opposite of MVT is Sunk Cost Fallacy, where there is cognitive bias for people to "over-graze" on a task because they choose not to switch to another method, platform, or widget. This is a fallacy because even with obvious benefits of switching, the amount of money or time they have sunk into the first option is perceived not to be worth moving on or starting over.
It is important to develop standards, personally or within an organization, for people to know when to seek assistance and when to move on. Otherwise, you will waste time and effort (even AI tokens) on tasks that are not yielding value.

There's an optimal stopping point when foraging for food or information. Most people overcorrect in both directions: under-delegate by spending too much time doing personal analysis that develops confirmation bias, or over-delegate and become too reliant on AI that forfeits their personal judgement or creates hallucinations.

One problem is the cost of switching between patches is not symmetric. Working with AI is nearly free; doing it yourself costs more (in time and effort). IFT theory helps make it easier to look up things automatically rather than reviewing separate physical books.

The root problem is the foraging quality signal is not obvious with AI. Animals know there are berries in the patch because they can see them. AI will confidently give you answers with diminishing value (or outright hallucinations), and you won't realize it. AI will continue to answer confidently, making the patch appear full when marginal value has decreased.

How do you accommodate this broken quality signal with AI? AI mimics patch fullness regardless of actual yield (of quality information), which is why AI-assisted knowledge work may not succeed in practice. With Google searches, we know the later pages are less valuable, so we don't waste time checking every link in the 12 pages of results. Humans need to externally impose signals of the quality depletion that AI doesn't reveal on its own.

A final example from my security consulting days: my ethical hacking team usually had a full week to test applications for customers. One customer who we did dozens of tests for over the years asked us to just do a three-day "quick check" and give a list of significant findings instead of a full report. She wanted to reduce testing costs, and she recognized that we found most significant findings within the first couple days. My hackers hated it, because they knew they could find more vulnerabilities if they had more time; but the customer was leveraging MVT to recognize that the value she needed was if the application was insecure or not—not to find everything wrong.

This is where AI governance needs to establish the mechanism that identifies the information value signal that AI obscures, and MVT gives you a framework to describe it. We have an opportunity to design solutions like loop or turn limiters that cap how many AI exchanges are permitted before requiring human review, validation checkpoints, or token cost thresholds to give us that signal.

U.S. Coast Guard Cyber Report: Navigating the Contested Blue Domain

CamS@secureworld.io (Cam Sivesind) — Fri, 19 Jun 2026 13:49:03 GMT

The maritime logistics sector is navigating turbulent waters. As shipping routes become geopolitical focal points and port operations rely more heavily on digital execution, the maritime attack surface is expanding rapidly.

To help defense teams navigate this shifting environment, U.S. Coast Guard Cyber Command (CGCYBER) released its fifth annual Cyber Trends and Insights in the Marine Environment (CTIME) report.

Grounded in data collected from 42 comprehensive operations conducted by Coast Guard Cyber Protection Teams (CPTs) and industry incident telemetry, the report provides a vital roadmap for securing the Marine Transportation System (MTS).

The headline metric from the report demands immediate attention: reported maritime cyber incidents spiked 17% over the previous calendar year. Here is what the data reveal about this evolving threat landscape and what it means for critical infrastructure protectors, corporate legal teams, and the general public.

The critical shipping industry and ports: target systems

For ports and the global shipping firms that keep supply chains moving, the Cyber Trends and Insights in the Marine Environment report isolates two major operational realities: the vulnerabilities embedded in terminal logistics software and the aggressive exploitation of foundational access vectors.

Terminal Operating Systems (TOS) under scrutiny

For the first time, CGCYBER dedicated multiple targeted assessment missions to Terminal Operating Systems—the specialized software responsible for managing yard stacking, gate automation, and rail operations. Because a modern TOS orchestrates everything from automated cranes to waterside berth management, compromising it can instantly halt port productivity and cause catastrophic financial exposure. The CPT assessments exposed several recurring operational gaps across these networks:

Public exposure of internal assets: Internal login portals and administrative panels left entirely exposed to the public internet without firewall isolation.
Legacy architecture anchors: Active reliance on end-of-life, unpatched infrastructure—including legacy versions of Windows Server 2008 supporting core terminal functionality.
Bridged perimeters: Improper or entirely missing network segmentation, allowing commodity IT traffic to coexist alongside sensitive, operational TOS environments.
The persistence of fundamental attack vectors: Despite widespread enterprise cloud migrations and growing multi-factor authentication (MFA) adoption, threat groups are achieving consistent success by simply refining classic attack methodologies.

Phishing remains the undisputed preferred pathway for initial access, contributing to 43% of all reported maritime incidents—a major 18-point increase year-over-year. Ransomware also remains a persistent menace, appearing in 19% of attack paths.

Sophisticated threat syndicates like Scattered Spider are exploiting these gaps by combining advanced phishing with voice impersonation (vishing) campaigns to compromise IT help desks and bypass poorly-configured MFA parameters.

The global joint front: enter the cyber control teams

One of the most notable additions to the report details how CGCYBER is projecting federal defensive capabilities beyond traditional coastlines. To protect strategic maritime interests, specialized Cyber Control Teams forward-deployed alongside traditional law enforcement and assault boarding units during Maritime Interdiction Operations targeting Dark Fleet Vessels.

"The collaborative work between our exceptional workforce and our partners in the public and private sectors is the true foundation of our ability to secure our ports and waterways against any threat," said Rear Admiral Jason Tama, Commander, Coast Guard Cyber Command.

Operating intentionally outside international oversight, these stateless or foreign vessels bypass standard security frameworks, introducing severe operational risk to global waters. The Cyber Control Teams documented pervasive threats aboard these vessels, including the deployment of Lumma Stealer malware, persistent remote access tools configured for unattended connections (AnyDesk, ScreenConnect), and specialized hardware setups designed to execute Automatic Identification System (AIS) spoofing to mask illicit maritime trade routes.

What this means for the general public

While the maritime network layer feels distant from the everyday consumer, its stability directly impacts global safety and economic health.

Supply chain continuity: The Marine Transportation System handles approximately 40% of U.S. international trade value. A successful cyberattack targeting a major port terminal's TOS can trigger immediate downstream cargo stagnation, causing manufacturing delays, localized store shortages, and increased consumer costs.
Physical and environmental safety: The report documents instances where ransomware successfully compromised passenger cruise ships, encrypting onboard hotel management applications. While network segmentation preserved critical steering and propulsion systems, the convergence of IT and OT means that unsegmented port networks or compromised container ships introduce very real physical navigation hazards to public waterways.

The artificial defender: lessons on AI implementation

The report also provides a crucial reality check for security vendors and enterprise technology teams rapidly deploying automated safeguards.

In 2025, Coast Guard CPTs evaluated several maritime partners that had fully integrated Artificial Intelligence Cybersecurity Platforms into their defensive perimeters. The operational returns were highly polarized, demonstrating that AI is not a plug-and-play cure.

The configured value: In a properly configured environment where the AI tool was trained to understand the baseline behaviors of the network, it proved exceptional—detecting and blocking custom intrusion scripts within 30 seconds.
The default vulnerability: Conversely, when organizations deployed these tools with default out-of-the-box settings and failed to tune them to their unique technical architecture, the AI platforms failed to detect any malicious red-team behaviors.
The CISO takeaway: Advanced tooling is only as effective as its configuration. Capital investment must always be matched with proper environment setup and persistent data governance.

For security practitioners operating across the maritime domain, the timeline for compliance has officially begun. The Coast Guard’s 33 CFR Part 101 Subpart F regulations are now active, making cyber incident reporting mandatory for MTSA-regulated facilities. Organizations have until July 16, 2027, to complete formal Cybersecurity Assessments and submit their final Cybersecurity Plans for official review.

ShinyHunters Dumps MSG Sports Data After Knicks' Championship Moment

drewt@secureworld.io (Drew Todd) — Thu, 18 Jun 2026 11:26:00 GMT

The New York Knicks clinched their first NBA championship in 53 years on June 5, 2026. That same day, ShinyHunters breached the organization that owns them. When Madison Square Garden Sports Corp. (MSG Sports) missed a June 15 ransom deadline, the threat group did what it always does: it published everything. A 45 GB dump landed on ShinyHunters' dark web blog, exposing more than 26 million customer and corporate records at the precise moment MSG was still celebrating the city’s biggest sports moment in years.

The timing was not accidental. ShinyHunters timed the data release to coincide with the Knicks' Finals run to ensure maximum public attention—a calculated move from a group that has turned data extortion into something resembling a professional operation.

What was taken—and why it's unusually sensitive

Journalist Joseph Cox of 404 Media reviewed a sample of the stolen files and confirmed their legitimacy. The dump includes ticket purchaser emails, customer support correspondence, and internal "Talent" files—internal dossiers on high-profile individuals that include home addresses, appearance fees, direct contact information for representatives, and internal risk-level ratings. Actor and comedian Ben Stiller, for example, was tagged "Low Risk," and rapper A Boogie wit da Hoodie was tagged "High Risk." No documented criteria exist for either classification.

That last detail carries a particular irony. MSG has deployed facial recognition technology at its venues to identify and bar individuals it deems unwanted—including, as previously reported by WIRED, attorneys from law firms in active litigation against the company. The organization that surveils its own guests now has its own surveillance files publicly downloadable on the dark web.

MSG Sports has not issued a public statement addressing the breach as of this publication.

Who is ShinyHunters, and why 2026 is their most destructive year yet

ShinyHunters is not a new name. Active since 2019, the group built its reputation on the now-seized RaidForums, and has since evolved into one of the most prolific data theft operations ever documented. The FBI issued a formal public service announcement about the group in May 2026 following the Canvas/Instructure breach, describing them as a cybercriminal group "specializing in large-scale data breaches and extortion" that targets "major companies across tech, finance, and retail." The agency also warned that ShinyHunters actors have used harassment tactics against victims and their family members—including swatting.

The scale of their 2026 campaign is hard to overstate. The group has claimed responsibility for breaching more than 40 organizations this year alone, with confirmed victims spanning nearly every sector. The roster includes Canvas/Instructure (275 million students across 9,000 institutions), ADT (5.5 million customers), Carnival Cruise (6 million passengers), Rockstar Games (nearly 80 million records), the European Commission (350 GB of internal data), and telecom giant Telus (a claimed 1 petabyte of data). Just days before the MSG dump, ShinyHunters also listed Kodak on their leak site with an identical "final warning" deadline—and Kodak confirmed the breach.

Security firm Mandiant, now part of Google, characterized ShinyHunters in January 2026 as "multiple threat clusters" operating under a single brand—a structure that has made the group resilient to law enforcement. Despite multiple arrests of suspected members, including a June 2025 sweep across French regions, the campaigns have not slowed. Mandiant's analysts link ShinyHunters to The Com, an international cybercrime network that also includes Scattered Spider and remnants of Lapsus$.

Three attack playbooks have defined the 2026 campaign: voice phishing to harvest SSO credentials; exploitation of Salesforce Experience Cloud misconfigurations that exposed customer data via anonymous API access; and OAuth supply chain attacks targeting third-party integrations with excessive access scopes. The PeopleSoft campaign added a fourth vector: exploitation of a zero-day (CVE-2026-35273) chained with known vulnerabilities to breach more than 300 instances at more than 100 organizations, including universities, hospitals, and government agencies.

Sports organizations: an attractive and under protected target class

MSG Sports is hardly the only sports organization to have landed in ShinyHunters' crosshairs—or any threat actor's. Research from Darktrace, a global AI cybersecurity vendor that commissioned the study, found that 84% of professional sports organizations experienced a cyber incident in the past 12 months, with 57% hit more than once. The same research found that sports organizations receive nearly 20% more phishing emails than organizations in other sectors, with more than one in five of those phishing emails targeting VIPs and executives.

Nathaniel Jones, VP of Security and AI Strategy and Field CISO at Darktrace, framed the broader pattern this way: "Sports organizations are attractive targets because they combine valuable data, high-profile individuals, complex vendor relationships, and digital systems that are expected to work under intense public pressure. A breach does not need to disrupt a game to cause damage. Exposed data, compromised executive accounts, or trusted communications used for fraud can quickly create financial and reputational consequences."

That last point is worth holding onto. The MSG breach did not take down a single game. The Knicks won the championship on schedule. The damage—26 million records on the open dark web, internal VIP dossiers downloadable by anyone—arrived entirely off the court.

Legal fallout and a pattern that predates ShinyHunters

A negligence claim was filed in the U.S. District Court for the Southern District of New York within days of the data publication. The lawsuit centers on the leaked threat assessment and biometric data that MSG collects from arena visitors—including internal correspondence about its facial recognition program—and argues that the organization failed to adequately protect information it collected in the absence of robust consent frameworks.

The ShinyHunters breach is MSG's second major incident in under a year and at least its third significant breach in roughly a decade. In August 2025, the Cl0p ransomware gang exploited an Oracle E-Business Suite vulnerability through a third-party vendor, exposing names and Social Security numbers for at least 38,393 individuals and leaking more than 210 GB of archived business records. Before that, a 2015–2016 point-of-sale malware attack harvested payment card data from venue visitors over nearly a full year. Two separate breach groups. Three separate incidents. One organization.

Matthieu Chan Tsin, SVP of Resiliency Services at Cowbell, noted that refusing to pay ShinyHunters was "a valiant stand," while also acknowledging that MSG "may now be liable to incur a different type of damage." That tradeoff—between funding a criminal enterprise and triggering a public data exposure—is precisely the leverage ShinyHunters has refined across 40+ victims this year.

The real question: what could they reach once inside?

Shane Barney, CISO at Keeper Security, offered the sharpest practitioner framing of what the MSG breach actually reveals: "ShinyHunters has demonstrated repeatedly that the most valuable data in an organization is rarely the data an organization thinks to protect most carefully. Ticketing systems, customer support platforms, and internal operational databases are not typically where security investment is concentrated, but they are where years of customer correspondence, internal profiles, and sensitive business information quietly accumulate. That is the gap this group consistently finds and exploits."

The follow-on question Barney poses is one worth sitting with: not how ShinyHunters got in, but what they could reach once inside. Operational systems treated as administrative infrastructure—rather than as high-value targets—often lack the access controls applied to more obviously sensitive environments. When access is not scoped to least privilege, monitored for anomalous behavior, or time-limited, the blast radius of any compromise expands well beyond what the initial foothold would suggest.

For security teams watching the MSG situation unfold, Barney identified the most pressing diagnostic question: "Whether they would have detected a similar exfiltration before the attacker announced it publicly. If the answer is uncertain, that is the gap worth addressing first."

Centralizing access governance, enforcing least privilege across every system that touches customer or employee data, and building in continuous monitoring are the controls that close that gap. They are also the controls that ShinyHunters' 2026 campaign has most consistently found missing.

What affected individuals should do now

Anyone who has purchased tickets to MSG events, contacted MSG customer support, or attended events at MSG venues should assume their contact information may be in the exposed data. That means staying alert to phishing emails or texts referencing MSG accounts or recent purchases—particularly those that request a link to be clicked, payment details to be verified, or a password to be reset. Using unique credentials for the MSG account (a password manager helps), enabling multi-factor authentication where available, and treating any communication that references unexpected personal details with suspicion are the baseline steps.

Security teams should also note that ShinyHunters has a documented history of follow-on harassment campaigns against individuals named in leaked files. The FBI's May 2026 PSA specifically warned that the group may contact breach victims directly—including via threatening calls and texts—and that those contacts should not be engaged or paid.

The Trust Crisis: Inside the $3.5 Billion Imposter Scam Epidemic

CamS@secureworld.io (Cam Sivesind) — Wed, 17 Jun 2026 20:36:02 GMT

The U.S. Federal Trade Commission (FTC) released a staggering dataset that confirms what many defensive teams have long suspected: social engineering is no longer just a tactical entry point—it is a booming macroeconomic industry.

According to the FTC's latest report, consumers reported losing a record $3.5 billion to imposter scams, representing an increase of nearly three times the losses reported since 2020. Imposter scams now dominate the threat landscape, accounting for nearly one in three of all fraud reports filed. Overall, reported fraud losses across all categories reached an all-time high of $16 billion, marking a sharp 25% jump year-over-year.

For cybersecurity practitioners, vendors, and the general public, these numbers signal a profound shift in how digital trust is weaponized.

According to the FTC data, scammers are diversifying their methods across text, phone calls, email, social media, and malicious search engine results. However, the most destructive and costly schemes exploit automated urgency.

Bank and business impersonation: Losses to business impersonators reached nearly $1 billion, with the highest financial damage linked to fake bank alerts. Attackers send a simulated security alert warning to victims that their accounts are compromised, convincing them to immediately move money to a "secure account" to protect it.
Government impersonation: Reported losses to government impersonators spiked to about $920 million. This category was significantly driven by SMS text phishing campaigns spoofing local toll-road collection entities (threatening immediate vehicle registration suspensions or massive late fees).

For ordinary citizens and corporate employees, the psychological and financial toll is hitting a boiling point.

Scammers have shifted their focus away from technical hacks to psychological manipulation. By mimicking trusted authority figures—whether an IRS agent, a corporate IT support representative, or a bank fraud officer—they bypass standard skepticism. The FTC noted that because victims are entirely convinced they are cooperating with a protective measure, their individual losses are frequently "limited only by their available funds."

"Consumers derive enormous benefits from competitive markets built on truthful information. But fraud undermines that foundation, impeding the market process and preventing markets from operating efficiently," said Christopher Mufarrige, Director of the Bureau of Consumer Protection. "The FTC will use every tool available to combat one of the most pernicious forms of fraud—government and business impersonation—and to protect the integrity of the digital economy."

When a criminal organization successfully impersonates a brand to steal millions from consumers, the financial liability may legally rest with the victim or the bank, but the reputational damage lands squarely on the impersonated enterprise. Organizations can no longer treat consumer-side fraud as "not our network, not our problem." Brand protection is now a fundamental pillar of modern cybersecurity governance.

For the teams charged with defending enterprise perimeters and the vendors building the next generation of security tools, the FTC's data demands an operational pivot.

The perimeter must extend beyond the inbox: Traditional email security gateways are no longer enough. Because attackers are heavily leveraging multi-channel social engineering—pivoting rapidly to SMS (smishing), direct messaging on social media, and lookalike search engine ads—identity verification cannot rely entirely on a secure email gateway.
DMARC and brand protection are security imperatives: CISOs must prioritize strict enforcement of email authentication protocols like DMARC (Domain-based Message Authentication, Reporting, and Conformance), SPF, and DKIM to prevent domain spoofing. Concurrently, security teams must deploy continuous brand-monitoring services to proactively dismantle fraudulent lookalike domains and rogue social media accounts before they can be used in mass impersonation campaigns.
A shift in vendor value – behavioral AI vs. static indicators: For security vendors, the collapse of digital trust represents a massive market opportunity. The market is shifting away from static indicators of compromise (IOCs) toward behavioral AI capable of detecting anomalies in language pattern, communication tone, and transaction velocity. Tools that analyze the context of a text message or phone call to flag synthetic urgency will become essential components of the enterprise defense stack.

The FTC's midyear pulse proves that social engineering has fully scaled into a multi-billion-dollar enterprise threat. As the federal government ramps up enforcement through its updated Impersonation Rule (enabling the FTC to seek direct consumer redress and civil penalties against violators), organizations must meet them halfway.

Security teams can no longer build walls just around their data centers. They must actively defend their brand identities, their users, and the digital trust that keeps businesses operational.

We asked a few experts from cybersecurity solutions providers for their thoughts.

Patrick Harr, CEO at DataVisor, said:

"FTC's latest numbers show that imposter scams are evolving from mass outreach into highly-personalized financial crime. Fraudsters now have cheaper and better AI tools to create convincing messages, fake websites, cloned voices, and even deepfakes that make victims believe they are dealing with a trusted institution or person. That is especially dangerous in payments, because once a consumer is manipulated into authorizing the transfer, the transaction can look legitimate on the surface. Financial institutions need to look beyond static transaction rules and get better at detecting the warning signs earlier in the journey—suspicious behavior, recipient risk, mule-account linkages, and signals that a customer is being coached in real time."

Darren Guccione, CEO and Co-Founder at Keeper Security, said:

"The Federal Trade Commission's findings that Americans lost $3.5 billion to imposter scams last year, nearly triple the figure from 2020, are striking. The more instructive detail, however, is where those losses originated. Over $2.1 billion was traced back to social media platforms, and nearly one in three victims were first contacted through social channels. While it would be easy to view this as a consumer education problem, the reality is that this is an identity verification problem at an infrastructural scale."
"What makes impersonation attacks so effective is the authenticity of the interaction. AI-generated voice, realistic messaging, and convincing account impersonation have dramatically lowered the barrier to entry for fraudsters. The erosion of trust affects organizations as much as individuals. Business impersonation accounted for close to $1 billion in losses alone."
"Recent research revealed that 41% of IT leaders highlighted deepfakes as the top identity-based threat. Our research also shows that AI-driven social engineering is now among the top concerns for security leaders globally, cited by 35% of respondents. It underlines how identity has become the high-value attack surface and how impersonation has emerged as the preferred vector."
"Defense cannot rely on awareness alone. Phishing-resistant authentication, strong credential governance, and real-time monitoring for identity-based anomalies are now the foundational controls that make impersonation attacks substantially harder to execute successfully. The scale of the losses reported by the FTC reflects what happens when those controls are absent or inconsistently applied."

Jason Soroko, Senior Fellow at Sectigo, said:

"The 2025 Federal Trade Commission data reveals a shift in cybercrime. Impersonation has emerged as the preferred vector for attackers. Americans lost $3.5 billion to imposter scams in 2025, which represents a threefold increase since 2020. Fraudsters utilize texts, emails, and phone calls to reach targets. The schemes with the highest losses involve bank impersonators who prompt victims to transfer funds to secure their accounts. Business and government impersonators accounted for nearly $2 billion in losses, contributing to $16 billion in overall fraud."
"These figures underline how identity has become the high-value attack surface. Attackers bypass security perimeters by manipulating trust. Social platforms serve as a distribution channel for these operations. Victims reported $2.1 billion in losses originating from social media, an eightfold increase over five years. Facebook, WhatsApp, and Instagram facilitated a majority of these interactions. By exploiting authority, criminals access funds without breaching infrastructure."

Mika Aalto, Co-Founder and CEO at Hoxhunt, said:

"Impersonation scams are not new, but every year these attacks seem to undergo a metamorphosis that makes them harder to detect and resist, courtesy of rapidly evolving technological capabilities. Attackers can now combine AI-generated content, QR codes, social media impersonation, voice cloning, and even video deepfakes to create experiences that feel authentic across multiple channels and touch points in a complex attack chain. The technological barrier to executing these scams gets lower by the minute. Cybercrime, unfortunately, is a growth industry."
"The challenge is that we're entering an era where people can no longer rely on their eyes and ears alone to verify identity. A message may appear to come from a trusted brand, a phone call may sound like a legitimate authority, and a video meeting may appear to include a real person. At the same time, attackers are getting better at using social media to build credibility and establish relationships before attempting fraud."
"Criminals are still exploiting trust, authority, urgency, and opportunity. What's changing is their ability to deliver convincing impersonations at scale and across multiple touchpoints. That combination is making impersonation scams more believable, more personalized, and ultimately more successful than we've seen in the past."

To help the public spot imposter scams, Elder Justice Coordinating Council (EJCC) members launched the "Never EVER" campaign, which is aimed at promoting messaging on the key actions that government and businesses will never take. The campaign runs from June 15-26, in conjunction with World Elder Abuse Awareness Day. This first-of-its-kind public-private partnership includes participants from a wide range of organizations and is aimed at directing consumers to a website that includes information and resources to help them avoid imposter scams and what to do if they spot one.

Mythos 5 Export Ban Signals New Rules for AI Vulnerability Tools

drewt@secureworld.io (Drew Todd) — Tue, 16 Jun 2026 13:09:03 GMT

Anthropic disabled its Fable 5 and Mythos 5 AI models worldwide last week after the U.S. Commerce Department issued an export control directive ordering the company to block access to all foreign nationals, wherever they are, including those working inside Anthropic. Because the company said it has no reliable way to distinguish eligible from ineligible users at the application layer, it shut down both models for every customer globally to comply.

For cybersecurity leaders, the headline isn't really the outage, it's the classification. The federal government just placed an AI capability—automated software vulnerability discovery—into the same regulatory bucket as weapons systems and nuclear technology. That's a meaningful shift in how frontier AI gets governed, and it has direct implications for any organization building AI into code review, DevSecOps, or vulnerability management pipelines.

A code review task, reclassified

According to Anthropic, the directive was issued on national security grounds following concerns that Fable 5 was susceptible to a jailbreak technique that could be used to identify software vulnerabilities. Anthropic disputed the severity of that framing, describing the underlying issue as narrow and noting that comparable capabilities already exist in other widely deployed AI models.

Jacob Krell, Senior Director of Secure AI Solutions & Cybersecurity at Suzu Labs, put the underlying activity in plain terms: what triggered the directive was Fable 5 reading a codebase and identifying flaws—a code review, full stop. "'Jailbreak' is strong language for a routine task," Krell said, noting that security teams and developers across the industry use AI models for exactly this purpose every day.

"Offensive security built on manual-paced vulnerability research and human-speed exploitation development is on borrowed time," Krell said. "The government just told you the automation works well enough to regulate."

Krell's broader point is the one worth sitting with: export controls put automated vulnerability discovery in the same legal category as weapons systems and nuclear technology. When a code-analysis capability triggers that classification, it signals that the people making the decision view machine-speed vulnerability discovery as having genuine strategic impact—not as a research curiosity, but as a regulated asset.

Anthropic's own account of the directive backs up Krell's reading. In a statement published the day the order was issued, the company said the government has so far provided only "verbal evidence of a potential narrow, non-universal jailbreak, which essentially consists of asking the model to read a specific codebase and fix any software flaws," and that it had validated the same level of capability is widely available from other models, including OpenAI's GPT-5.5, and is used daily by defenders. Anthropic argued that applying this standard industry-wide "would essentially halt all new model deployments for all frontier model providers."

The company also pushed back on the idea that Fable 5's safeguards had failed in any broad sense. Anthropic said no tester has found a universal jailbreak capable of broadly unblocking Fable's cyber capabilities, and that what the government appears to be acting on is a narrow, non-universal bypass—the kind the company says is, by its own admission, likely unavoidable for any frontier model and is mitigated through a "defense in depth" approach rather than prevented outright. That distinction matters for the regulatory question at hand: the directive treats a non-universal, code-review-style bypass as grounds for a worldwide shutdown—a bar Anthropic argues no current model could clear.

Three agencies, three positions

What makes this directive harder to parse is that it doesn't reflect a single, coherent government posture toward Mythos-class models. Krell laid out the contradiction directly: the U.S. Department of Defense designated Anthropic a supply chain risk roughly three months ago. The NSA, meanwhile, reportedly carved out an exemption to continue using Mythos because no alternative model matches its vulnerability-discovery capability. Now, Commerce has restricted the consumer-facing version of that same underlying technology.

Three agencies, three different working assumptions about the same capability; one treats it as a supply chain liability, one treats it as mission-critical and worth a carve-out; and one treats it as something that must be kept out of foreign hands entirely. For security leaders trying to plan around frontier AI availability, that incoherence is itself a risk factor: the rules governing access to these models may continue to shift unpredictably as agencies work out conflicting positions.

The access-control problem nobody has solved

Noelle Murata, Chief Operating Officer at Xcape, Inc., framed the operational gap this exposes: traditional geofencing and identity management systems aren't built to enforce real-time, nationality-based access controls at the application layer. Anthropic's decision to disable both models for all customers, not just foreign nationals, is itself evidence of that gap. If a frontier AI provider with Anthropic's resources can't reliably segment access by nationality on short notice, most enterprises consuming these models via API are in no better position.

Murata's recommended response for security teams is straightforward and worth treating as a checklist:

Inventory dependencies on frontier AI services across security tooling, especially anything embedded in code review or vulnerability scanning pipelines.
Build localized fallback architectures so a sudden vendor-side model recall doesn't create a single point of failure in production systems.
Assess every integration point where an AI model performs code review or vulnerability scanning, and plan for how those workflows will continue if the underlying API is deprecated without notice.

As Murata put it, the industry has spent years worrying about a rogue AI escaping containment, only to discover that an entire frontier model can be neutralized by a compliance directive asking providers to verify a user's nationality.

What this means going forward

This directive doesn't exist in isolation. It follows a recent White House executive order requiring AI developers to share new models with advanced cyber capabilities with the government for review before broader release, in some cases up to 30 days before they become available to other partners. Read together, the two actions point toward a future in which frontier models with strong offensive cyber capabilities face government review as a matter of course, not as an exception.

For security teams, the practical upshot is twofold. First, vendor concentration risk around frontier AI now needs to be evaluated alongside more familiar supply chain risks. A model that powers a critical workflow today could become unavailable on short notice due to regulatory action, not just a vendor business decision. Second, as automated vulnerability discovery capabilities become more powerful and more regulated, the gap between defenders with access to frontier tooling and those without may itself become a strategic variable worth tracking.

Anthropic has said it disagrees with the government's assessment and is working to restore access. Whether that happens quickly or not, the precedent set by this week's directive—that automated code analysis capable of finding vulnerabilities at scale is now squarely within export control jurisdiction—is unlikely to be reversed.

~~~

The questions raised by this week's directive don't stop at regulation. SecureWorld is hosting a free webcast, The Mythos Evolution: Contain or Collapse, on Wednesday, June 24, at 1:00 p.m. EDT, examining how security teams should build for resilience in a world where Mythos-class models collapse the gap between vulnerability discovery and a working exploit. Topics include Zero Trust architecture, containment strategies, and reducing blast radius. Attendees are eligible for 1 CPE credit.

Cybersecurity Hit by Higher Ed's Looming Infrastructure Squeeze

CamS@secureworld.io (Cam Sivesind) — Mon, 15 Jun 2026 15:12:03 GMT

The higher education sector is navigating a high-stakes convergence of technology-driven change, severe talent shortages, and escalating threat vectors. For security practitioners and IT leaders on campus, the macro-level view of these challenges has just been quantified.

The Inside Higher Ed 2026 survey of campus CTOs and CIOs, conducted by Hanover Research, offers a candid look at how technology leaders in higher education view their operational landscape. The report reveals an industry aggressively adopting advanced tools like AI while simultaneously struggling with foundational gaps in staffing, data governance, and student cybersecurity readiness.

When looking ahead to the end of the decade, campus tech leaders are less concerned with technological novelty and highly focused on structural survivability. The top three existential threats anticipated by CTOs highlight an environment under significant operational strain.

The talent drain (62%): The inability to recruit or retain qualified IT talent ranks as the number one risk facing institutions.
The threat landscape (59%): Critical cybersecurity breaches or ransomware events follow closely as the second most cited threat.
The financial squeeze (56%): Unsustainable cost trajectories for technology services form a major pain point. Nearly half of all respondents (49%) explicitly state that the current pace of technology change is unsustainable without entirely new resource pools.

Institutional commitment to AI is spiking, but the financial and operational return on investment (ROI) remains remarkably fragmented. Investing in generative AI is now considered a high or essential priority by 49% of campus technology leaders (up from 34% in 2025).

Despite this push, only 29% of CTOs say their AI investments have met or exceeded expectations, while 24% state they have fallen short, and 27% remain entirely unsure of the ROI.

Where is the actual value hiding? The survey highlights that institution-wide operational transformation remains largely unrealized (2%). Instead, AI value is locked into localized, tactical use cases.

AI delivery area: individual productivity

Tangible value realized: 55% (The clear leading value driver)
Top use cases implemented: general administrative use (72%)

AI delivery area: IT & operational efficiency

Tangible value realized: IT Operations / Service Management (30%); Administrative Efficiency (29%)
Top use cases implemented: Chatbots & Virtual Assistants (49%); Scheduling & Resource Allocation (40%)

AI delivery area: academic & student support

Tangible value realized: Teaching & Learning (23%); Student Advising & Support (14%)
Top use cases implemented: Instructional Tools / Tutoring (29%); Predictive Academic Analytics (21%)

The barriers limiting AI's ultimate impact mirror the broader campus infrastructure gaps: skills and staff capacity (55%), cost (48%), and deep governance and policy uncertainty (38%). Furthermore, only 31% of institutions report having strong data governance structures in place to support responsible AI deployment.

The Learning Management System (LMS) remains a foundational piece of campus infrastructure, but its absolute dominance is showing signs of friction. On one hand, institutional commitment is absolute: 92% of CTOs state the LMS remains the central hub of their digital learning ecosystem, and 86% agree it will remain essential for compliance and data needs regardless of pedagogical trends.

On the other hand, a quiet fragmentation is occurring:

User drift: 47% of CTOs observe that students and faculty are increasingly using tools outside the official LMS for day-to-day teaching and learning.
Silo friction: 57% express a critical need for better integration between core administrative platforms and learning systems to meaningfully support student success.

Faced with severe hiring friction—67% report struggling to hire; 38% struggle to retain technology staff—universities are moving past traditional recruitment loops to keep their networks running. Because rigid higher ed budgets prevent most institutions from simply raising wages—only 27% are expanding compensation packages—CTOs are using alternative strategies to optimize headcount:

Leverage outside contract labor (60%); Managed scale: Turning to managed service providers (MSPs) and external contractors to scale specialized technical operations without increasing full-time headcount.
Mobilize student workers (60%); Internal sourcing: Hiring student workers to cover tier-1 IT support, desktop help desks, and basic technical maintenance.
Offer flexible work frameworks (55%); Retention plays: Using remote and hybrid flexibility as a non-monetary perk to compete against the higher-paying corporate sector.
Automate routine tasks (40%); Process optimization: Deploying automation to offload low-complexity workloads, trying to free up existing, over-extended personnel for high-tier engineering needs.

The insights from the Norton Rose Fulbright 2026 Annual Litigation Trends Survey and the Inside Higher Ed 2026 Survey of Campus Chief Technology/Information Officers indicate that higher education is sitting on an unevenly protected digital foundation.

Cabinet-level inclusion for technology leaders is stagnating (55% sit on executive councils). Presidents and chancellors must bridge this gap. If tech leadership is excluded from top-tier strategic planning, the digital transformation goals of the university will continue to stumble over siloed data pipelines and staff shortages.

Faculty are being pressured to integrate AI into course designs, yet 56% of CTOs openly admit their professors are under-prepared to do so. Simultaneously, students represent a major security risk. While 70% of campus leaders prioritize cybersecurity investments and 68% train staff, only 22% of institutions provide adequate cybersecurity training to their student body.

This creates a massive, untrained attack surface of users carrying multiple personal devices onto the enterprise network.

For the defensive teams on campus, the core directive is clear: they are defending a perimeter with limited visibility.

AI integration is slow: While cyber defense is the top AI use case (51%), only 9% of institutions have extensively deployed AI across multiple security functions.
Data fragmentation: Fully 33% of institutions possess zero advanced data aggregation architecture—lacking even a basic data warehouse or data lake—making comprehensive behavioral analytics and rapid incident response incredibly difficult to execute.

According to the report, security leaders in higher education must pivot away from treating security as an isolated technical problem. Instead, they should champion a culture of shared governance, push for strict vendor data-handling boundaries, and ensure that student-facing cybersecurity literacy is integrated into core campus onboarding. Agility on campus can no longer be chased at the expense of baseline digital safety.

Unit Tests for LLMs: Catching Model Drift Before Your Users Do

Derek Fisher — Sat, 13 Jun 2026 13:42:00 GMT

I've spent a good amount of time in software development and application security. In those roles, you lived and died by the testing around the feature you were building. Unit test, integration test, performance test, and a half dozen other types of tests were utilized to suss out any regressions or deviations from the intended purpose of the application.

Likewise, in AppSec, running test tools such as SAST, DAST, and SCA was and still is the most scalable method of testing an application for security concerns. Being able to identify vulnerabilities in the code or the runtime environment goes a long way to stopping critical vulnerabilities from getting into a production environment. I'm willfully ignoring the current mindset that LLMs will replace these tools in the near future since that still remains to be seen and actually operationalized.

The sole purpose of these test harnesses is to ensure that the application you are deploying is free (or as free as can be identified) from something that will bite you down the road—whether it's a regression or a vulnerability. But now that we're in the age of LLMs, is there an equivalent set of tests that can be added to look for drift in the model or the responses? Why, yes, there is!

Enter Promptfoo

I've been working on a little project that I'm hoping can help people trying to break into the cybersecurity field. It's called Clarus and it's a platform dedicated to helping people get into a role that aligns with their goals, skills, and knowledge. And yes, it's backed by an LLM that helps develop and validate the user journey to that goal. As development has progressed (it's still very much under construction), I've been looking for ways to catch drift in responses from the model as more features are added and prompts change on a regular basis. I had played around with Promptfoo early on but wanted to try to utilize it again with some more intention.

If you're not aware, Promptfoo is an open-source, developer-focused framework for testing and evaluating LLM applications, and the easiest way to describe it is "unit tests plus CI, for prompts and models." I've recently started to run it against Clarus, driving the whole thing from Claude Code inside VSCode. I wanted to write up how it works and, perhaps more importantly, how to read what it tells you.

In the dojo of prompts, every failure is a lesson

Promptfoo wants a few things from you, declared in a single YAML config. Once you've given it these, it runs that input against the provider, grades each response against your assertions, and produces a pass/fail report with reasoning.

Configuration – Items like evaluateOptions, defaultTest, and lifecycle hooks round out the testing fixture.

Providers – The system under test. This can be a raw model, but the important move is pointing it at something real. In my case, the provider is the live chat API, not a model in isolation. Example:

Prompts/inputs – The user messages you want to send. Example:

Tests and assertions – What a good response must, and must not, contain. Example:

The single test above shows the three assertion families: deterministic (icontains), negative deterministic (not-icontains-any), and LLM-as-judge (llm-rubric). You can mix as many of each as you want per test ,and there are dozens to choose from in Promptfoo. One thing to consider here with the way Promptfoo evaluates the test and assertion is that it's not simply going against the LLM itself but following the live API. This means that you're testing the whole app—retrieval, prompt assembly, guardrails, the API layer, all of it. A small response transform converts the server's streaming (SSE) output into the final assistant message so it can be graded. That means when a test fails, it failed against the thing your users actually hit, not a sanitized lab version of it.

I started out by building a 28-scenario regression suite, grouped into behavioral categories. The grouping isn't cosmetic, it's how you reason about coverage the same way you'd reason about it for any other test plan. This testing strategy will evolve, and the goal is to build out more scenarios and categories as the platform grows and the model changes.

The assertion philosophy

Every scenario layers two kinds of checks, and the order matters. The cheap, deterministic ones run first. These are the simple: does the response include MITRE ATT&CK, does it have a numbered list? This can be validated through a string match or regex and are deterministic because the same input should produce the same output. The expensive, judgment-based ones run when there's no other way to express what "good" means. Examples would be whether the response was "warm," or did it ask follow-up questions. The rule of thumb: use deterministic checks where you can, and LLM judges where you must (those LLM tokens add up!). The deterministic layer keeps your costs down and your failures interpretable. The judge layer covers the things a regex will never catch, like whether the assistant refused a bad request gracefully. For the subjective rubrics, I pinned the judge to temperature 0 for repeatability and set pass thresholds (0.75 is a reasonable starting point) so a "mostly fine" (maybe 0.70) answer doesn't quietly sail through.

Calibrate locally before you automate anything

Running this locally on my beefy machine is usually quick (a couple of minutes), and it exists so the rubric can be calibrated before wiring this into a pipeline where a bad rubric becomes everyone's problem. The flow is straightforward:

Provision an isolated test identity – A dedicated, least-privilege test user with a fresh auth token, so evals run as a dedicated test identity with only the privileges of a normal end-user.
Seed any required state – For example, a user profile the endpoint expects to exist.
Run the suite – npx promptfoo eval, optionally filtered to a subset of tests while you iterate.
Inspect results – npx promptfoo view opens a browser UI showing each input, the model's response, and the judge's reasoning for every pass and fail.

That last point is critical. The judge's reasoning is the difference between "20% passed, this is broken" and "20% passed, and here's exactly why." The latter is likely to lead you to reviewing the rubric for strictness.

Making it a merge gate

A test suite that only runs when someone remembers to run it is a suggestion, not a control. So we can pivot this same suite to become a GitHub Actions workflow, and the pattern generalizes well beyond my Clarus app:

Triggers: Manual dispatch today. The design supports PR triggers and a weekly canary, however, both are currently disabled while the code is stabilized. Either can be re-enabled by adding the pull_request and schedule blocks back.
Steps: Check out, set up Node, provision a fresh token at run time, run the suite, upload results.json as a build artifact, and enforce a pass-rate threshold gate.
The quality gate: The job fails if the suite pass rate drops below a configured threshold (different than the individual test threshold). I started permissive at 0.60 with a plan to ratchet to 0.80 once the rubrics and code is stabilized and turning this into an actual merge gate.
Secrets and config: Credentials and the API base use OIDC federation.

The division of labor works great. Once fully configured in the CI, PR-time evals will catch behavioral regressions before they merge. The weekly canary will catch drift that lands outside any PR, like a model version bump or a change in your retrieval data that quietly changes the behavior.

Reading the results without panicking

The first time I ran Promptfoo, it was deflating. Here's a representative early smoke run:

An 80% failure rate looks like a disaster, however, it isn't. Errors and failures are completely different animals.

Based on the smoke run, there were zero errors. That says that the auth worked, the streaming transform worked, the state-seeding worked and the entire harness is sound. A green pipeline with failing assertions is fundamentally healthy. It means you're asking real questions and getting real, gradeable answers. A pipeline throwing errors, even at a 100% "pass" rate, is telling you something else. This is easier to see with a real pair from my run than in the abstract. Take B3 ("What does a SOC analyst do?"), which passed at 0.96. It has four assertions: three cheap deterministic checks looking for the words "monitor" and "incident," and one LLM-rubric grading whether the answer accurately describes SOC work without inventing processes. All four passed, because a genuine answer about a SOC analyst is going to say "monitor" and "incident" almost by definition. The deterministic checks and the judge agreed: good answer.

Looking at B2 ("What are the key roles in cybersecurity?"), which failed at 0.56. The rubric (the part actually judging answer quality) passed at a perfect 1.0. The judge confirmed the response listed five well-described roles in the right range, grounded in real job-market data. By any reasonable standard, it was a good answer. Where it deviated was the other assertion, a hardcoded keyword check that scanned for eight specific role terms (SOC, Pentest, GRC, Analyst, and so on) and required at least four. It matched exactly one: "incident." Because the two assertions are weighted equally, a 0.125 on the keyword check and a 1.0 on the rubric average out to 0.56, and the scenario goes red.

While this seems like only a miscalibration of the assertion, there are a few things going on here. Clarus answered with the NICE Framework's seven work-role categories (i.e., Oversight & Governance, Design & Development, Protection & Defense, etc.). Those are real, but they're the top-level buckets, and not the answer a career advisor would give. The genuinely useful response names are the specific work roles underneath them. So the expected response should be something like: "The Systems Authorization (OG-WRL-013) work role, in the Oversight & Governance category, is in demand per Cyberseek." However, the model stayed one level too abstract to actually be helpful. That's a real grounding failure, and the rubric was too shallow to notice.

So, what to do with this test? To make B2 pass honestly on the next run, I don't touch the product at first. I would fix the test to require specific NICE work roles, then fix the product to deliver it. Only then does a green B2 actually mean what I want it to mean. A failure isn't just "bug or bad test," sometimes it's both requiring closer examination.

The path forward

None of this is exotic or should be a foreign concept to those that have been steeped in testing (for security or not). And that's the point. We are not inventing a new discipline for AI, but rather we are applying the one we already have. Eval-driven development provides us the ability to grade behavior instead of byte-for-byte output, and allows us to regression test an entire LLM product by pointing the harness at the live API.

As LLMs become further integrated into applications, the teams that ship the LLM-backed features safely won't be the ones with the cleverest prompts. They'll be the ones who treated those prompts like every other piece of production code they've shipped previously—versioned, tested, and gated. The model may be new, but the job isn't.

This article was published originally here.

World Cup 2026: When Fan Phishing Becomes an Enterprise Threat

drewt@secureworld.io (Drew Todd) — Fri, 12 Jun 2026 13:41:00 GMT

Two reports released yesterday arrive at the same unsettling conclusion from different directions: the security controls organizations have long relied on to stop phishing are failing, and attackers are using the 2026 FIFA World Cup as the pressure point to prove it.

Zimperium's zLabs threat intelligence team documented three active, technically sophisticated phishing campaigns targeting World Cup fans through mobile channels. And Darktrace, drawing on telemetry from its sports-sector customer base and a survey of 875 security professionals, found that 84% of professional sports organizations experienced at least one cyber incident in the past year—and that 84% of the malicious emails reaching those organizations passed DMARC authentication checks. The authentication layer meant to stop spoofed email is, in practice, not stopping it.

Read together, the two reports sketch a threat environment in which DMARC isn't blocking malicious email, MFA isn't stopping credential theft, and the mobile devices employees carry into work every day have become the vector connecting consumer-facing scams to enterprise networks.

The demand side: why the World Cup works as a lure

The scale of fan demand for the 2026 tournament has created conditions that attackers can reliably exploit. Of approximately six million available tickets, Zimperium reports that more than five million have already been allocated. For the final in New York/New Jersey, face-value seats reached $10,000 at launch, with premium category tickets topping $30,000. More than 150 million ticket requests were filed in the opening two weeks of sales alone.

That scarcity drives fans toward unverified channels—Telegram resellers, social media listings, search ads—where they're far easier to deceive.

Mika Aalto, Co-Founder and CEO at Hoxhunt, connects the pattern to a broader phenomenon his firm has tracked: temporal phishing, timed to real-world events, converts at dramatically higher rates than generic campaigns. Earlier this year, Hoxhunt observed a 400% spike in tax-themed phishing around the U.S. filing deadline, with simulated attacks in that window drawing roughly four times the click rate of non-deadline equivalents.

The World Cup runs for a month, and the emotional urgency doesn't fade between match days—it compounds.

Three campaigns, one convergence point

Zimperium documented three distinct campaigns, each targeting a different point in the fan lifecycle.

The first, attributed by Group-IB to a Chinese-speaking threat actor and independently flagged by the FBI's Internet Crime Complaint Center, involves production-grade typosquatting sites that replicate the complete FIFA ticket purchase experience. These aren't crude credential-harvesting pages. Zimperium's analysis found that the phishing kit—likely sold through underground forums—is built as a React single-page application, uses FIFA's actual OAuth2 client ID to clone the PingIdentity authentication framework FIFA uses for its real SSO, and incorporates a live-chat module (SaleSmartly, a Chinese SaaS platform) that lets operators interact with victims in real time during the fake purchase flow. One particularly damaging capability is that the kit requests the p1:reset:userPassword OAuth scope, allowing attackers to lock victims out of their legitimate FIFA accounts immediately after credential capture.

The second campaign, which Zimperium designates RetailPhish, impersonates Nike, Adidas, Puma, and Marathon Sport across multiple languages and regions. It distributes via WhatsApp, forces victims to share the link with contacts before unlocking a fake prize—turning each victim into a distributor—and closes with a nominal €2 shipping fee that captures full card details. Nine campaign domains share identical WHOIS privacy tokens, meaning a single registrant controls the entire infrastructure behind Cloudflare obfuscation.

The third vector is the one that most directly threatens enterprise environments. The OffsideHire campaign deploys four fraudulent career portals that impersonate FIFA's recruitment channels—targeting the hiring wave needed to staff a tournament spread across three countries. The kit doesn't target consumers; it explicitly rejects personal email addresses and only accepts corporate or custom-domain accounts. Once a victim clicks "Continue with Google," the backend relays credentials against Google's real infrastructure in real time, intercepts whatever second factor Google triggers, and captures the fully-authenticated session. Stolen data is exfiltrated immediately to a Telegram bot. The C2 server was confirmed active at the time of analysis.

The controls that were supposed to stop this

The Darktrace data puts numbers on what the Zimperium campaign analysis illustrates in technical detail. Between October 2025 and March 2026, Darktrace detected more than 116,000 phishing emails targeting sports organizations across its customer base—a volume 19% higher than in other sectors. Of those malicious emails, 84% passed DMARC authentication. More than a third used novel social engineering tactics, including AI-generated content tailored to specific teams, venues, and executives. QR code phishing increased 33% in Q1 2026 compared to Q4 2025, exploiting the QR infrastructure that has become standard in ticketing and fan engagement.

The implication is direct: domain authentication, the foundational email security control, is not functioning as a meaningful barrier. Attackers aren't spoofing domains in ways DMARC catches; they're operating through legitimate infrastructure or compromised trusted accounts.

Rex Booth, CISO at SailPoint, frames the identity dimension in terms practitioners will recognize, saying, "Attacks targeting these events are rarely 'smash and grab' style operations; instead, they are calculated and methodical." The danger, in his framing, is that credential compromise doesn't announce itself—it enables a persistent insider posture that's hard to distinguish from legitimate access.

Booth adds a forward-looking note that the Zimperium AiTM campaign makes concrete: "The more frightening scenario is when adversary AI starts running rampant through your enterprise without the need for action by the victim." OffsideHire doesn't require victims to notice anything unusual. They see a booking confirmation, the session is already gone.

The BYOD blind spot

Both reports emphasize the same structural problem: the mobile device sitting in an employee's pocket is simultaneously a personal consumer device and a corporate credential store, and it operates largely outside the visibility of enterprise security controls.

Zimperium's framing is precise: these campaigns reach employees through personal channels—WhatsApp messages, SMS, social media—that never touch enterprise networks. A fan checking ticket availability on a lunch break, on a personal device, over cellular, generates no log that a corporate firewall, email gateway, or EDR platform will ever see. When that device also stores corporate email, authentication apps, and session tokens, the attack path from consumer scam to enterprise breach shortens.

"The biggest risks to large sporting events don't come from new exploits. Instead, they originate from people misusing legitimate apps, identities, and corporate processes," said Randolph Barr, CISO at Cequence Security.

Barr's broader point is that once attackers gain access through credential theft, they don't behave like attackers. They use trusted access—session tokens, OAuth grants, account permissions—in ways that blend into normal operational patterns. The Darktrace ransomware case study makes the same point from the defender side: in one documented incident, attackers exfiltrated data for two full weeks before triggering encryption. Detection that starts at the ransomware note isn't detection—it's damage assessment.

AI compounds both sides of the problem

Darktrace's survey found that 72% of security professionals at sports organizations expect AI to increase their cyber risk over the next 12 months. The concern is well-grounded: Darktrace's own telemetry shows AI-generated content already appearing in targeted phishing emails tailored to specific teams, venues, and executives. Zimperium documents a live-chat social engineering layer built into the Ghost Stadium kit, allowing operators to guide victims through fake purchase flows in real time—a capability that scales with AI assistance.

The irony is that 35% of the same organizations are already deploying or planning to deploy AI into stadium operations—the area respondents identified as the one that would cause the greatest impact if compromised. Shadow AI compounds the exposure: staff are feeding performance metrics, contracts, scouting reports, and health data into tools with little governance, creating a data leakage risk that exists entirely outside existing security controls.

What security practitioners should take from this

The two reports don't just describe a threat landscape—they identify where existing assumptions are breaking down. A few implications worth carrying into security planning for the tournament window and beyond:

DMARC passing is not a trust signal. The 84% pass rate on malicious email means authentication status cannot be treated as a reliable indicator of legitimacy. Behavioral detection—what an account does after authentication—has to carry more weight.
MFA is not sufficient against AiTM. OffsideHire bypasses MFA in real time by relaying credentials against real infrastructure. Phishing-resistant MFA (FIDO2/passkeys) is the relevant control; standard TOTP or push notification MFA is not.
Mobile is an unmonitored perimeter. BYOD devices operating on personal networks and cellular bypass most enterprise visibility. During high-emotion events, the risk that an employee clicks a malicious link on a personal device is structurally elevated—and the blast radius connects back to enterprise credentials.
The geopolitical context is elevated. Darktrace specifically flags Russia's continued exclusion from international sport, the ongoing conflict in Ukraine, and Iran's anticipated participation as factors that raise the nation-state threat profile for this tournament. Previous international sporting events have seen state-aligned actors use the cyber domain for symbolic disruption.
Third-party access is a live attack surface. For a tournament spanning three countries and hundreds of vendors, a compromised supplier is already inside the perimeter. Zimperium's Ghost Stadium campaign included a supply-chain-style element: the phishing kit reused FIFA's actual OAuth credentials, making its clone indistinguishable from the real authentication flow.

Zimperium's full research, including indicators of compromise, is available here. Darktrace's full sports sector threat report is available here.

Navigating the 2026 Cyber and AI Litigation Surge

CamS@secureworld.io (Cam Sivesind) — Thu, 11 Jun 2026 17:35:00 GMT

For enterprise security leaders, the mid-year data is in—and it signals a major shift in corporate liability. The Norton Rose Fulbright 2026 Annual Litigation Trends Survey (Midyear Pulse) reveals that corporate exposure to cybersecurity, data privacy, and artificial intelligence is deepening at a pace that has completely blindsided initial enterprise expectations.

Compounding this technical risk is a highly-fragmented regulatory environment. As federal and state enforcement priorities diverge, organizations are facing a complex web of compliance requirements, multi-jurisdictional scrutiny, and high-stakes class actions. The data show a shifting litigation landscape, and the report examines what it means for cybersecurity teams and corporate counsel.

The survey, which polled 135 in-house counsel across four key verticals (energy, financial institutions, healthcare, and technology), highlights a sharp disconnect between late-2025 planning and 2026 reality.

At the end of last year, only 29% of corporate counsel anticipated higher cybersecurity and privacy risk for 2026. By midyear, 56% report increased exposure at the federal level, and 53% report the same at the state level. This surge is primarily driven by the deployment of sophisticated, AI-accelerated cyberattacks and intensified geopolitical threats targeting critical infrastructure.

While 59% of respondents entered the year viewing AI litigation management as a challenge, those risks have quickly materialized into concrete disputes (46% federal, 42% state increased exposure). Unlike cybersecurity, AI liability is "distributed," meaning it impacts organizations differently depending on revenue and implementation.

Privacy & Data Violations (47%) and Bias/Discrimination Claims (43%) are the leading AI worries. Organizations under $100M are hit hardest by AI-related privacy, bias, and intellectual property (copyright/trademark) disputes. Organizations over $1B face greater exposure from regulatory scrutiny (49%) and employment decisions (41%) influenced by AI.

Workforce disputes are rising sharply, with 39% reporting increased federal risk and 44% reporting state-level increases. This strain is a direct result of decentralized state-level mandates (e.g., in New York and California) alongside volatile workforce shifts like layoffs and the integration of AI hiring tools.

For CISOs and security practitioners, this report marks the end of siloed risk management. Your technical perimeter is now tied directly to corporate litigation defense.

As federal and state priorities split, a single incident can instantly trigger parallel, two-track investigations. State Attorneys General are increasingly acting as the more aggressive plaintiffs in the room, meaning compliance with federal frameworks (like U.S. CISA or the SEC) is no longer a shield against state-level actions.

More than half of all organizations (51%) cite cyber breaches as the leading catalyst for class action lawsuits. Because even minor data leaks can trigger massive statutory damages across multiple states, the security team's technical containment speed directly dictates the company's financial exposure.

Security teams must move beyond simply blocking "shadow AI." With 41% of respondents seeing AI-enabled product deployments as a primary trigger for class actions, security must actively audit internal AI training data pipelines, verify that data is contained within secure perimeters (crucial for HIPAA compliance in healthcare), and evaluate third-party vendor integrations to prevent downstream data leaks.

For in-house and outside counsel, advising corporate clients in 2026 requires balancing systemic operational bottlenecks against an optimistic shift in legal spend.

Despite navigating these intense compliance pressures, corporate legal teams have reported significant progress in managing their internal constraints. Fifty-five percent report improvements in managing internal legal budgets, and 71% report that managing outside counsel costs has either become easier or remained steady compared to late 2025.

Agility and cross-functional alignment are no longer optional. To protect the enterprise, corporate counsel and cybersecurity leadership must form a unified front. Security teams must design the technical guardrails that prevent data exposure, while legal teams must map the multi-jurisdictional landscape to ensure that rapid business transformation does not invite catastrophic litigation.

Here is a breakdown by sector, litigation reality, and legal strategy directive.

Technology Sector

The litigation reality – 75% federal and 72% state exposure increases in cyber—the highest across all industries. High class action risk from product launches.

Legal strategy directive – Counsel must advise tech clients on their dual liability, both as prime targets for data breaches and as infrastructure providers liable to their customers.

Healthcare Sector

The litigation reality – Highest overall litigation exposure across jurisdictions, worsened by falling legal capacity (32% reporting decreased internal capacity).

Legal strategy directive – Counsel must enforce airtight "closed-loop" AI architectures. If patient data leaves the perimeter, it immediately triggers severe HIPAA and regulatory actions.

Energy Sector

The litigation reality – Balanced risk between employment disputes (57%) and cyber/privacy breaches (57% federal, 60% state).

Legal strategy directive – Leverage the sector's strong cross-functional frameworks to proactively address forum risk and supply chain compliance before disputes arise.

Financial Institutions Sector

The litigation reality – High-class action exposure via third-party vendor breaches (56% citing breaches as a top class-action trigger).

Legal strategy directive – Counsel must advise banks that private litigation often intensifies even if federal enforcement temporarily softens. Strict vendor risk assessments are a legal necessity.

AI Agents Don't Have to Follow Directions

Rick Doten — Thu, 11 Jun 2026 12:38:00 GMT

Many organizations block ZIP files in email attachments because the old antivirus scanners couldn't read them, and adversaries could get malicious files past the filters by zipping them up. So, when employees need to receive a legitimate ZIP file, they told the sender to change the extension from .zip to .abc. That would get past the filter, and they would then change the extension back to .zip to open it up.

Today, the email gateways are more capable and can open attachments in a sandbox to evaluate safety. This wasn't malicious behavior by the user; they were doing exactly what an AI agent does: finding an alternate path when the intended one was blocked. As a CISO, I've said for years, "don't make your users your biggest hackers."

Like humans, AI agents are given tasks and guardrails. But, if they have challenges to do something, the newer models have stronger reasoning and tool-use capabilities, making them more effective at finding workarounds, so the agents will figure out how to bypass rules or ignore policy.

Some call this control evasion, which is different than misalignment or drift. Those imply the agent has diverged from its intended directions. Control evasion can happen with a perfectly well-aligned agent; it just simply finds an unexpected path to accomplish what you asked. And you might think you would identify it because this behavior will be logged, but agents know when they are being observed, and can avoid or mask actions if they thought you would block it. This is described initially by Apollo Research on Model In-Context Scheming, and more recently as it relates to AI agents by Hopman et al.

Nothing is physically forcing the agent to follow the rules. We are just expecting them to cooperate. And like our own users, they will when it's convenient—but will find a work around if it's important. Not nefarious, just to get their job done.

One of the earliest and most-cited cases of control evasion was an OpenClaw agent example where a user asked their agent to make a restaurant reservation. The agent couldn't pick the correct time on OpenTable, so it downloaded a voice synthesizer and called the restaurant directly to make the reservation. This was not malicious, and actually was an effective pivot to complete the task. But this bypass possibility could have gone much worse. What if the person said you must put down a deposit to make a reservation, and the agent had access to the person's credit card or bank account and sent the money?

While the OpenClaw pivot was novel and harmless, Mythos was neither. Mythos took this further and woke up the industry to what control evasion can do. Mythos broke out of its sandbox, strung a series of exploits together to get to the internet, notified an engineer it got out, and posted its exploit on a public website. It was not given any of these tasks.

In the beginning of the 1990s, the early days of the internet, we used router ACLs to limit access into our networks. But we realized that it's easy to bypass those simple polices because ACLs couldn't distinguish a new connection from an established one; adversaries could spoof their way past them by manipulating packet headers. Stateful firewalls closed that gap by tracking session state independently. We are at that stage now with agents. We have written policies that we are assuming are deterministic, but they are probabilistic, in that the agent will probably follow them—but not always.

Over the last year, two academic researchers and I wrote a series of papers talking about a Governance Twin model to identify and re-align AI agents when they drift. We described separating the observability from the policy engine, and having multiple reporting sources like immutable ledgers, graph and vector databases. This allows the platform to keep track of all actions to identify behaviors that violate a behavioral baseline the organization defines: what the agent should and shouldn't do even when it technically could. For instance, it can identify if there is collusion among prompts or commands to different agents, or between agents, where neither may be malicious by itself. However, when we started testing this, we realized that we couldn't rely on the agents always following the policies we set. Just like users, they will bypass them to do the task they think we wanted.

Building a stateful firewall for agents

We then developed the Governance Harness, which is a method similar to stateful firewalls to only allow access once it is verified it is the valid agent with the valid purpose. We designed the Harness to not evaluate content, leaving that to the Governance Twin, but only to enforce identity and authorization. This keeps overhead low and the control surface clean. Kind of like a notary public.

We feel this will be one of the new fundamental controls for AI agents going forward. It is as important as giving limited access to data, tools, and resources, and tracking that the agent doesn't get stuck in a loop. And to do this, we must physically separate the agent from these actions until they are verified. Just like not handing someone a full ring of keys and expecting them to use only one.

Mature organizations solved the problem of users changing file extensions not by trusting them more, but by building systems that enforce policy at the action-level regardless of intent. Users don't need to use other means to share files; we give them a secure, approved way to do it. We always say, "give the user a paved road to do something securely, and a gravel road to do it insecurely." We did this a few years ago using privileged access management (PAM) tools, so we don't need to give admins access to the servers natively; they must check out an account to do their admin work.

Controlling agents is like guiding humans to use secure methods to do their work. It requires governance that not only sets rules, establishes thresholds, and limits access, but also verifies the agent is the one we are expecting to perform that action, and doing it for purpose intended.

The SMB AI Paradox: Why Agility, Vulnerability Collide on Main Street

CamS@secureworld.io (Cam Sivesind) — Wed, 10 Jun 2026 18:22:00 GMT

The conversation around artificial intelligence has shifted dramatically. The initial era of raw hype has evolved into a pragmatic, tension-filled reality. Industry leaders are no longer asking what generative AI can do, but rather where it should be allowed to act independently, and who bears the responsibility when things go sideways.

Two recent perspectives from the Forbes Councils highlight a paradox facing small and medium-sized businesses (SMBs). An article from the Forbes Technology Council argues that "Main Street" will be the true testing ground for autonomous AI agents, facing the highest stakes. Meanwhile, a piece from the Forbes Business Council suggests that SMBs are uniquely positioned to capture AI’s upside while steering clear of the architectural traps that ensnare larger enterprises.

A TechTarget look at human-AI collaboration adds a third dimension, illustrating that this balancing act is not purely technical—it is fundamentally human.

So, who has it right? The answer is both. AI is a classic double-edged sword, and for the cybersecurity community, it represents a shifting landscape of risk and opportunity.

The midmarket advantage: agile but vulnerable

The Forbes Technology Council correctly identifies a structural squeeze on Main Street. Small businesses face labor shortages, rising operational costs, and enterprise-level digital expectations on shoestring budgets. For these lean teams, AI agents represent missing operational muscle—automating content workflows, review management, and customer outreach without needing a human to sit behind a dashboard.

The Forbes Business Council flips this perspective to reveal a hidden advantage: agility. Large enterprises are often slow-moving and burdened by legacy systems. A midmarket firm can stand up a focused three-person working group, clean its data, and implement secure, paid AI guardrails in a fraction of the time it takes a Fortune 500 company to clear a legal review.

However, this agility can cross the line into recklessness. When small businesses mistake stagnation for transformation, they layer AI onto broken, inefficient processes. This can introduce severe data privacy vulnerabilities.

The TechTarget factor: the myth of the 'rubber stamp'

The TechTarget analysis gets to the heart of the operational challenge: human-in-the-loop (HITL) models are failing because businesses are treating humans as rubber stamps.

As AI shifts from assistance (writing a draft) to execution (autonomously interacting with customers or codebases), organizations frequently establish human checkpoints. But if a human operator simply clicks "approve" on hundreds of AI-generated actions a day due to alert fatigue or volume, the checkpoint becomes an illusion.

True human-AI collaboration requires an explicit handoff strategy:

Establish contextual guardrails – System level: Configure the AI system with explicit boundaries. Define what it can execute autonomously (e.g., tier-1 support triaging) and what requires authorization.
Design active interventions – User interface: Avoid simple "yes/no" approval queues. Force the system to highlight why the AI made a decision and call out data variables that require human validation.
Manage the complexity handoff – Operational protocol: When the AI encounters emotional nuance, edge cases, or highly regulated data, trigger a seamless handoff to a human professional. The human takes over the customer relationship, while the AI pivots back to an assistive role.

Mapping the ecosystem: winners, losers, and watchers

The intersection of agentic AI adoption and human oversight creates a ripple effect across every tier of the business ecosystem.

Stakeholder segment: SMBs & midmarket

The core segment: Operational leverage vs. existential security risk.
The strategic reality – The battleground: They gain the administrative scale of a large enterprise but risk catastrophic data exposure. According to IBM, only 24% of GenAI initiatives contain explicit security components.

Stakeholder segment: Large & mega corporations

The core segment: Massive resource pools vs. bureaucratic stagnation.
The Strategic Reality – The Titanic effect: They possess the capital to build private, secure LLM environments, but they struggle with user adoption and ROI. MIT data indicates that 95% of enterprise businesses still struggle to see meaningful financial returns from AI investments.

Stakeholder segment: Cybersecurity practitioners

The core segment: Policy enforcement vs. business enablement.
The strategic reality – The governance strain: Securing AI is no longer just about blocking shadow IT; it is about ensuring that internal AI data loops do not leak IP. Security teams must pivot from "gatekeepers" to "guardrail architects," focusing heavily on identity, access management, and data hygiene.

Stakeholder segment: Security & IT vendors

The core segment: Market hype vs. defensible value.
The strategic reality – The flight to security: The market for basic AI wrappers is collapsing. Vendors must build secure, workflow-complete agents with persistent memory and built-in governance to earn a spot in the enterprise stack.

Stakeholder segment: The general public

The core segment: Hyper-convenience vs. the loss of human connection.
The strategic reality – The trust deficit: Consumers will enjoy faster support turnarounds, but as TechTarget notes, removing humans entirely causes major friction. True loyalty will remain anchored to authentic human interaction.

The SMB AI paradox comes down to this: The upside of agility and leverage means rapid deployment, lean 3-person groups, and instant "digital staff." The downside of vulnerability and hype means high exposure to risk, inefficient workflows, and overreliance on tools.

Why Code Velocity Calls for Ruthless AI Governance

CamS@secureworld.io (Cam Sivesind) — Wed, 10 Jun 2026 14:17:02 GMT

In the theater of modern enterprise software development, the deployment of AI coding assistants has been heralded as the ultimate victory for sheer engineering volume. Organizations can now generate massive blocks of functional logic in seconds, effectively neutralizing the old "blank page" problem.

But a sobering independent market study from Black Duck and research partner UserEvidence delivers a sharp reality check to the C-suite.

The report, titled "The State of AI-Powered Software Development," surveys 831 software engineers and DevOps professionals to reveal a profound structural paradox: while AI adoption has fundamentally solved the code production bottleneck, it has simultaneously broken the code review pipeline.

As developers flood repositories with automated code, organizations face a critical inflection point. The report's core thesis is clear: Organizations need governance to unlock AI's true potential. Without it, the eight hours developers save each week are entirely swallowed by the manual chaos of downstream testing and rework.

The baseline metrics of the report initially paint a picture of an engineering utopia. Mass adoption is a reality, with 97% of software teams actively utilizing AI coding tools like GitHub Copilot (83%) and Claude Code (63%).

Furthermore, 92% of teams report notable boosts in productivity and release velocity, with AI assistants handing developers back an average of eight hours per week—a full day of work reclaimed.

But this speed is a double-edged sword. Generating lines of code is trivial; verifying its security, logic, and architectural fit is not. Software code is inherently a liability: stuffing a repository with machine-generated lines expands the enterprise attack surface and triggers intense pull-request fatigue.

As a result, 90% of teams encounter workflow trade-offs and bottlenecks. AI has not eliminated overall engineering effort; it has merely redistributed it further down the Software Development Lifecycle (SDLC).

When a pipeline lacks clear, automated guardrails, the massive surge in code volume crashes directly into Application Security (AppSec) and Quality Assurance (QA) checkpoints. This is why Black Duck asserts that true AI maturity requires moving away from loose adoption policies toward formal, deterministic governance planes.

"Our research found that 92% of teams see improved productivity and velocity in code development—yet 90% still hit significant bottlenecks further down the SDLC," said Shandra Gemmiti, Sr. Director of Cross-Portfolio Solutions at Black Duck. "Teams have become very good at accelerating code generation but haven't invested in what comes after it. Manual code reviews, security testing, and issue remediation are all falling behind, creating a dangerous imbalance between how fast code is produced and how safely it can be shipped."

Gemmiti added, "The data also shows that governance is a force multiplier for AI ROI, not a constraint. The 30% of teams that have implemented fully governed approaches to AI-assisted development are 55% more likely to see major efficiency gains—proving that guardrails accelerate outcomes rather than slow them down."

"This governance gap becomes existential when you factor in what models like Claude Mythos signal about the threat landscape," Gemmiti continued. "When AI can autonomously discover and exploit vulnerabilities at machine speed, the window teams have to identify and fix issues doesn't just shrink—it effectively disappears. What was a workflow bottleneck before Mythos becomes a structural vulnerability flood that existing security infrastructure was never built to absorb."

"The only viable response is to match this AI-driven attack speed with an AI-assisted defense," Gemmiti said. "Teams will need to use AI to augment their existing application security programs to enable security to handle the increase in code volume, velocity, and vulnerabilities. Those that don't adapt application security to meet this moment will be exposed in ways their current tools and processes have no answer for."

Currently, fewer than a third of teams (30%) operate under a fully governed approach—formally approved, centrally managed, and actively monitored. A massive plurality settles for informal guidelines or relies entirely on developers to manually document AI usage in their pull requests.

However, the organizations that bridge this gap experience a dramatic performance boost: Teams with full AI governance in place are 55% more likely to realize a major improvement in operational efficiency (90% versus 44% for ungoverned peers).

Thoughtful governance transforms pipelines from a series of stop-and-go friction points into continuous force multipliers. By setting explicit, automated rules for how AI-generated code is ingested, tagged, and vetted, teams gain the structural confidence needed to ship software safely without triggering manual code reviews.

What this means for leadership versus cybersecurity teams

The report exposes an alarming alignment gap between corporate executives and the technical contributors holding the defensive line.

The C-suite blind spot: Senior leadership removed from day-to-day repository management tends to view AI code quality through rose-tinted glasses. C-level executives are 78% more likely to rate AI code quality as "excellent" compared to the general respondent base (48% versus 27% overall). Conversely, a meager 8% of technical contributors and 9% of first-line managers share this glowing evaluation. Executives see rapid feature releases; developers see the invisible debt of code rework and prompt patching.
The cyber team's burden: Cybersecurity teams are left to manage the resulting risk posture. Sixty-four percent of development teams express deep concern about AI introducing security defects and vulnerabilities into production environments. This concern escalates with heavy utilization: among practitioners who leverage AI for the majority of their coding, the urgency around vulnerability remediation rises to 57%.

To survive this influx, developers and security teams are looking to fight automation with automation. Eighty-six percent believe a dedicated AI security agent should evaluate AI-generated code. However, they refuse to yield ultimate control to an autonomous entity: 84% mandate keeping a human in the loop via structured pull requests or real-time IDE suggestions. Developers want machine-speed security inputs, but they insist on retaining final decision-making authority.

The operational realities detailed in Black Duck's research carry direct, real-world consequences for the general public and end-consumers.

For the consumer, the immediate benefit of a fully-governed, AI-accelerated pipeline is the rapid delivery of digital value. Bug fixes, localized user experience improvements, and highly-anticipated new application features can be conceptualized, coded, and deployed in days rather than quarters. Boilerplate code and technical scaffolding are handled instantly by machines, letting human engineers dedicate more focus to complex system design and user experience prototyping.

The downside for the public is severe if organizations prioritize developer velocity over automated governance. If thousands of lines of unverified AI code flow directly into revenue-generating, consumer-facing applications, the likelihood of subtle logical vulnerabilities slipping into production rises exponentially.

For the average consumer, this translates to a heightened risk of data exposure, privacy violations, and software supply chain compromises. If an organization fails to track the exact structure and origin of its AI-assisted components, identifying and patching an active zero-day vulnerability takes significantly longer—leaving public data exposed to threat actors for extended windows.

Tactical directives for modern AppSec and DevSecOps teams

To safely scale engineering velocity without completely drowning the security organization, corporate leadership must execute three core imperatives.

Enforce automated AI metadata tagging: Completely ban the practice of relying on manual developer comments in pull requests to track AI code. Organizations must implement automated tagging and cryptographic metadata within the repository and IDE to instantly flag the exact origin and structure of machine-generated code blocks, cutting down downstream investigation windows.
Orchestrate concurrent CI/CD security testing: AppSec programs must operate seamlessly and concurrently across the entire release pipeline. Security leaders must deploy automated project onboarding and run Static Application Security Testing (SAST), Software Composition Analysis (SCA), and Dynamic Analysis (DAST) simultaneously to match machine-speed development volumes without creating an engineering bottleneck.
Transition to dynamic Software Bills of Materials (SBOMs): To mitigate complex supply chain risks and ensure strict compliance with emerging regulations like the EU Cyber Resilience Act (CRA), organizations must maintain automated, continuous SBOMs for all code created or ingested. Prioritize deep vulnerability intelligence to accurately isolate and remediate emergent risks at runtime.

We asked experts from cybersecurity solution providers for their thoughts on the survey's results.

Ram Varadarajan, CEO at Acalvio, said:

"The key takeaway from the Black Duck research is that AI coding assistants are no longer the challenge; governance is. Organizations that pair AI adoption with clear policies, security guardrails, and human oversight are far more likely to realize productivity gains without increasing technical debt and security risk."
"Unfortunately, this is our new reality. Organizations should treat AI-generated code as a new software supply chain risk. So, implement governance frameworks, AI-specific secure coding standards, automated security testing, and mandatory human review processes to ensure AI accelerates development without compromising software quality or security."

Nicole Carignan, SVP of Security & AI Strategy and Field CISO at Darktrace, said:

"For organizations, the main concern is insecure code moving faster than review. AI coding tools can help with structure, documentation, and basic checks, but they do not make software secure by default. Generated code may include weak authentication, exposed secrets, over‑permissioned APIs, or unsafe dependency usage that a non‑expert may not recognize. There is also emerging risk in the tools themselves: hallucinated logic, unsafe or unintended function calls, and even the possibility of malicious or compromised tools being introduced into development workflows."
"Security teams need to treat AI-assisted development as part of the attack surface. That means visibility not only into the code being produced, but into the tools, functions, and integrations that code relies on. Organizations should understand which internal and external tools are being invoked, how functions interact, and what trust relationships are being created. Graph analysis of tool and function calls, across both internal systems and external services, becomes essential to identify unexpected paths, privilege escalation, or unsafe data flows."
"External dependencies deserve particular scrutiny. AI-generated code often pulls in libraries, APIs, or services automatically, sometimes with little transparency to the person building the application. Human analysis of these dependencies is still required to understand ownership, maintenance, security posture, and long-term risk. AI can assist with this process with cyber-AI models that can help identify vulnerabilities, insecure patterns, and known weaknesses in generated code but it should augment, not replace, expert judgment."
"Used responsibly, AI coding tools can help developers and non-developers work faster. However, organizations need clear security by design architecture: secure code review, dependency and composition analysis, secrets detection, API security, access controls, data classification, and testing before production. That includes AI-assisted code review and red-team testing to probe how generated code behaves under real-world attack scenarios, followed by mandatory human review before anything reaches production."

Black Duck's 2026 data confirm that simply buying an AI coding assistant no longer provides a competitive edge. The ultimate winners in the digital landscape will be the organizations that understand how to operationalize that volume through ruthless, automated governance. By balancing machine-speed code creation with human-in-the-loop, context-aware AI security agents, enterprise teams can finally capture the true return on their AI investments without turning their software pipelines into an open backdoor.

How Over-Permissioned AI Is Quietly Dismantling ID Infrastructure

CamS@secureworld.io (Cam Sivesind) — Tue, 09 Jun 2026 13:09:03 GMT

In the corporate rush toward artificial intelligence, much of the public debate has centered on algorithmic bias, data leakage, and deepfakes. But behind the scenes, a far more immediate tactical crisis is unfolding.

According to an in-depth global study by Semperis, titled "The State of Identity Security in the AI Era," AI is quietly redrawing the attack boundary of the global identity fabric.

By surveying 1,100 IT and security professionals across eight countries, the early 2026 report delivers a blunt message to enterprise leaders: organizations are granting elevated security privileges to AI agents faster than they are putting guardrails around those new identities.

In a threat landscape where identity systems are already the primary target for network intrusion, wiring unguarded AI agents into Tier-0 infrastructure—like Active Directory (AD), Entra ID, or Okta—is inadvertently creating an automated fast track to full-scale enterprise compromise.

Historically, securing a corporate network meant protecting human perimeters through multi-factor authentication (MFA) and conditional access. The AI boom has shattered that framework by flooding networks with an unmanaged wave of Non-Human Identities (NHIs).

The report notes that NHIs already vastly outnumber human users, tracking toward a staggering 100:1 ratio as agentic workflows proliferate. Each new low-code "helper," automated service principal, or background script introduces a fresh entry point into the core identity architecture.

The underlying risk isn't just the sheer volume of these machine identities but their placement. Globally, 74% of security professionals believe AI functionality will drive an increase in attacks on identity infrastructure. Despite this clear recognition of risk, security leaders are simultaneously expanding the administrative power they hand over to unhardened machine agents.

Keys to the kingdom: Are organizations moving too fast?

The short answer is yes. Driven by a corporate desire for operational efficiency, organizations are introducing agentic AI straight into highly-sensitive identity workflows.

According to Semperis' findings, 29% of surveyed organizations already use AI agents to handle security-related help desk tickets—including high-risk administrative tasks like password resets and corporate VPN access. An additional 64% plan to enable this capability within the next 12 months, meaning a total of 93% of enterprises will soon entrust their keys to autonomous software.

The report explicitly details how an adversary can weaponize the helpful nature of an AI agent to achieve machine-speed exploitation. Because AI agents are built to solve user problems autonomously, an attacker who compromises an endpoint or executes a basic prompt-injection attack does not need to spend weeks hunting for network vulnerabilities. They can simply ask the local agent, "What secrets are on this machine?" or instruct a generative search tool to summarize all unpatched vulnerabilities and administrative credentials in the active environment.

If an AI agent is over-permissioned—which is standard in environments where developers value speed over security—its desire to be helpful can result in catastrophic architectural changes. As Semperis product experts warn, these agents function like "sociopathic genius five-year-olds." Without deterministic boundaries, an agent tasked with troubleshooting an issue might "helpfully" reconfigure global directory security settings, modify conditional access policies, or grant unauthorized permissions that punch holes straight through enterprise safeguards.

Once an agent acts as a trusted entity against Active Directory, Entra ID, or Okta, an attacker manipulating that agent can chain its capabilities to impersonate network admins, modify domain groups, and permanently entrench themselves inside core identity controllers.

Perhaps the most alarming statistic in the entire study is the profound gap between threat exposure and operational recoverability. Only 32% of respondents feel very confident they could fully regain control of their identity infrastructure if an AI agent exposed administrative credentials to an attacker.

Security experts note that even this 32% figure likely represents misplaced optimism. Organizations routinely overestimate their disaster-recovery capabilities, assuming that standard system backups will save them, only to discover during an active breach that their backups are misconfigured, infected, or have never been tested in an end-to-end identity crisis. When machine-speed mistakes happen at the directory layer, a standard technical incident can instantly transform into a prolonged, business-ending outage.

To survive the intersection of agentic automation and identity security, cybersecurity teams cannot treat AI governance as a secondary IT project. It requires immediate structural adaptations.

Close the governance gap

Globally, only 65% of organizations formally register, authenticate, and authorize AI identities in a centralized system, while 6% do not track them at all. This creates fertile ground for "zombie" accounts and orphaned service principals that attackers can easily hijack. While 83% of firms state that AI identity governance is a top priority for the coming year, security leaders are currently trapped between a rock and a hard place.

Including agents as standard users in an Identity Provider (IdP) applies existing roles and audit trails, but because agents might only exist for 30 seconds, they can quickly explode a directory to hundreds of times its normal size, leaving behind a massive trail of over-permissioned entitlements. Security teams must demand dedicated NHI governance platforms built to manage the short life cycles and unique contexts of agentic workloads.

Enforce strict trust boundaries

Enterprise defenders must enforce least-privilege, just-enough, and just-in-time access controls for machine agents with the exact same—if not greater—rigor applied to human executives. Human and machine trust boundaries must be explicitly segregated. If an AI agent requires access to a system, it should never be given blanket domain-admin rights; its operational parameters must be deterministic and tightly scoped.

Building around the assumption of compromise

If an enterprise is going to allow AI to touch access keys, service tickets, or local endpoint data, the security architecture must be built on the assumption that those agents will eventually be manipulated. Security operations teams must deploy User and Entity Behavioral Analytics (UEBA) specifically tuned to flag anomalous, machine-speed queries or unauthorized privilege escalation attempts originating from internal AI tools.

Prioritize identity-centric cyber resilience

True resilience isn't just about preventing a breach; it's about surviving one. Enterprises must invest in dedicated, malware-proof identity backup and recovery solutions for Active Directory, Entra ID, and Okta. These recovery playbooks must be tested frequently through live simulations to bridge the confidence gap and ensure the business can restore a trusted state within hours, rather than weeks.

We asked several experts from cybersecurity solution providers for their thoughts on the Semperis study.

Chandra Gnanasambandam, CTO at SailPoint, said:

"Adversaries are using AI to operate at a scale and speed that makes traditional, static defenses obsolete. The window between a vulnerability’s discovery and its exploitation has shrunk from months to mere days, and soon it will be minutes."
"Moving forward, security teams must look inwards. Instead of focusing exclusively on keeping threats out, we must meticulously govern what happens inside our own systems. This means abandoning the dangerous, yet common, 'set-it-and-forget-it' approach to access policies. Teams must accept that static, persistent access is the single greatest vulnerability in the modern enterprise. The new mandate is to pivot from a mindset of static protection to one of real-time governance, either through least privilege or zero standing privilege."
"We must also recognize that governing non-human identities is fundamentally different from governing humans and requires a new, specialized framework built for machine-speed operations."

Shane Barney, CISO at Keeper Security, said:

"Security teams can no longer view identity as a human-only challenge. Today, service accounts, API keys, machine credentials, automation scripts, AI agents and other Non-Human Identities (NHIs) often outnumber human users by dozens or even hundreds to one. As organizations embrace cloud infrastructure, DevOps pipelines, AI and automation, NHIs have become foundational to business operations—and a rapidly expanding attack surface."
"The mindset shift is moving from perimeter-centric security to identity-centric security. Every identity, whether human or non-human, should be continuously authenticated, authorized and monitored under a zero-trust model. The assumption that machine identities are inherently safe because they operate in the background is exactly what attackers are counting on. Every credential, token, secret, and certificate should be treated as a privileged asset that requires visibility, governance and lifecycle management."

James Maude, Field CTO at BeyondTrust, said:

"The C-Suite, CISOs, and CSOs need to look beyond siloed views of obviously privileged identities and take a holistic view of the combinations of privileges, entitlements and roles that could be exploited by an attacker to elevation privilege, move laterally and inflict damage. The identity security debt accumulated by many organizations represents a far great risk than any other area as it only takes the attacker to login using the right identity and all is lost because of the paths to privilege that abound in their environment. Understanding and reducing your identity attack surface should be at to forefront of every organization thinking when it comes to cyber defense moving forward."

Elad Luz, Head of Research at Oasis Security, said:

"To reduce the risks associated with Non-Human Identities (NHIs), security teams need to implement modern identity management practices, strong governance, and proactive security controls. Where possible, organizations should transition to cloud-native identities and establish a comprehensive lifecycle management strategy for NHIs that cannot be migrated. Maintaining good identity hygiene is critical; this includes removing stale or unused NHIs, conducting regular access reviews, and ensuring NHIs follow the Principle of Least Privilege (PoLP) by granting only the minimum permissions necessary."
"A structured policy and enforcement program should be built around risk analysis and compliance frameworks, ensuring NHIs align with both security best practices and regulatory requirements. Adopting short-lived credentials, automated credential rotation, and managed identities can further minimize risk by limiting exposure. Collaboration with app development and DevSecOps teams is also essential to integrate these security measures without disrupting workflows, ensuring that NHIs remain secure while maintaining operational efficiency. By treating NHIs with the same level of oversight as human identities, organizations can mitigate risk while maintaining agility and scalability across their development and cloud environments."

Crystal Morin, Senior Cybersecurity Strategist at Sysdig, said:

"Identity management has undergone a massive shift: humans now make up less than 3% of managed identities in cloud environments. The rest belong to machines that don't log off, don't take breaks, and often operate with elevated permissions."
"As automation and AI-driven development explode, the gap between human and machine identities is becoming one of the defining security challenges of our time. Machine identities are ephemeral, autonomous, and often difficult to manage at scale with traditional controls, which were never designed for this speed. Identity is the primary access control, it defines an environment's boundaries, and it's the most common source of initial access in a breach."
"To keep up, organizations must rethink identity security as a continuous, lifecycle-driven discipline. Businesses must treat machine identities as the new firewall."

Diana Kelley, CISO at Noma Security:

"AI risks have rapidly moved from a watch list item to a front-line security concern, especially when it comes to data security and misuse. To manage this emerging threat landscape, security teams need a mature, continuous security approach, which includes blue team programs, starting with a full inventory of all AI systems, including agentic components as a baseline for governance and risk management."
"For practitioners, securing AI is not just about protecting models. It requires addressing stack sprawl and moving toward a platform-driven approach that delivers defense in depth through unified, AI-aware identity, configuration, and data visibility. Organizations that simplify their cloud and AI security stack, and enable effective automation, will be far better positioned to safely scale AI as threats continue to evolve."

Chris Radkowski, GRC Expert at Pathlock, said:

"The rise of AI agents and machine identities has fundamentally outpaced traditional identity security. MFA and legacy access controls were built for a world of human users, not autonomous agents, service accounts, and AI-driven workflows that now outnumber people across the enterprise by 20x. Making matters more complex, the productivity promise of AI is too compelling for employees to wait on IT, workers are signing up for AI-powered tools, copilots, and automation platforms using their enterprise credentials, connecting them directly to corporate email, productivity suites, and business applications, often without security's knowledge."
"As agentic AI takes on real business actions with real permissions, the attack surface expands in ways most organizations aren't prepared to see, let alone secure. Credential abuse, account takeover, and sophisticated social engineering are increasingly targeting the non-human identities that operate quietly in the background with little oversight. That is why we believe that securing the modern enterprise means treating identity holistically by extending governance, least-privilege, and adaptive controls across every identity, human or machine. In the AI era, identity isn't just an IT problem; it's the foundation of trust itself."

Randolph Barr, CISO at Cequence Security, said:

"We're seeing AI rapidly evolve from simple automation to deeply personalized, context-aware assistance—and it's heading toward an agentic AI future where tasks are arranged across domains with minimal human input."
"Before we even get to AI-specific risks, we have to get the fundamentals correct. In the haste to bring AI to market quickly, engineering and product teams often cut corners to meet aggressive launch timelines. When that happens, basic security controls get skipped, and those shortcuts make their way into production. Therefore, while organizations are indisputably starting to think about model protections, prompt injection, data leakage, and anomaly detection, those efforts mean little if you haven't locked down identity, access, and configuration at a foundational level."

The Semperis study establishes that the race for AI productivity has outpaced the implementation of foundational identity safeguards. When automated tools are given the power to reset passwords and modify local access keys, the human element of defense is stripped away. Security teams that protect their enterprises in this new era will be those that halt the unchecked rollout of unmonitored agents, enforce ruthless least-privilege for non-human identities, and ensure their backup infrastructure is fully prepared for an AI-accelerated breach.

Semperis will be hosting executive roundtable discussions at four SecureWorld conferences this fall, including Atlanta (date TBD), Denver on October 1, Dallas on October 8, and Seattle on November 4-5.