CSOonline

CIOs rushing to roll out AI agents without real visibility into their decision-making processes are flirting with disaster. According to AI experts, deploying agents without observability processes and tools creates a ticking time bomb with the potential for huge negative consequences. Many companies are deploying AI agents and expecting them to increase productivity with little human intervention, observes T.J. Marlin, CEO of AI security firm Guardrail Technologies. That’s the wrong approach, he says. Instead, IT teams need to keep a close eye on agents and adjust policies and practices throughout the agentic process. “It’s not just set it and forget it like a crock pot,” he says. “You don’t put it in the kitchen in the morning with the chicken inside and come back at night and have a great dinner. The organizations doing that are going to be on the front page because they just had some terrible thing happen to them.” Many organizations are rapidly deploying agents because of a fear of missing out, while not understanding the nuances of the technology, Marlin says. Some IT leaders seem to compare agents to robotic process automation, when RPA results are far more deterministic, he adds. “There’s a talent shortage and a knowledge shortage and people are building at pace without checking whether it’s correct and it’s operating as expected,” he says. “Those are all the hallmarks of the worst disasters that I’ve seen across my career.” A recent report from agent governance vendor TrueFoundry puts numbers behind fears of unregulated agents. A survey of more than 200 enterprise AI leaders found that 54% of organizations represented can’t fully trace what their agents are doing and 56% have no centralized agent control or governance layer. While TrueFoundry has an interest in driving agent governance forward, many other AI experts see the same problems. Governing blind Difficulties with governance and observability are major impediments to the deployment of productive agents, and many organizations are deploying agents without creating a centralized list of them, says Mahesh Kumar Goyal, senior data and AI expert at Google. “Most enterprises have no inventory of the agents already running in production — they’re trying to govern what they can’t see,” he says. In addition, traditional SIEM and EDR security tools were built to spot human anomalies, not rogue agents, he notes. “An agent running code perfectly 10,000 times in a row looks normal even if it’s been hijacked,” he says. Running fully autonomous agents is not a good idea, he adds, and organizations need to think about least-privilege scoped tool permissions, policy enforcement layers that mediate every prompt and tool call, and end-to-end tracing that stitches prompts, tool calls, and downstream actions into one auditable trail. “The financial system doesn’t run on trust; it runs on auditability, reconciliation, and circuit breakers,” Goyal says. “Agents will mature the same way. Tiered autonomy is the realistic answer: free rein on low-stakes tasks, human-in-the-loop on consequential ones.” Part of the problem is that agents have upended the models used to determine whether traditional software was running correctly, adds Adel El Hallak, vice president of AI software at Nvidia. With traditional software, QA and security professionals could look at the code to debug problems, but agents make decisions in the runtime environment of an AI model. The source of truth for agents resides in the traces, the records of the execution flow, not in the code, he adds. Collecting traces ­­— in essence, detailed logs — is a start toward agent governance, but organizations need to be able to act on the information, he says. “For you to trust something, it has to be transparent, and observability is foundational to transparency,” El Hallak adds. “But just observing is not enough. We need to be able to take those signals and turn them into something actionable.” Agent governance goes beyond observability to allow organizations to test and fine-tune agents continuously, he says. The tools are out there, with companies like Nvidia building their own internal governance frameworks, and several other vendors offering agent observability and governance tools, he notes. “It’s not enough to just have the behavioral data, to capture the feedback data,” he says. “The system should allow me to annotate, change, augment, or create additional feedback data, and then I can use that data to improve my agent as a whole.” The governance bottleneck At the same time, many companies moving into agent governance have found it can be a huge bottleneck if done wrong, says Nirmal Ganesh, senior director of product management for agentic workflow automation at cloud storage vendor Box. “I don’t believe we are past the hard part yet in terms of deploying agents in the enterprise,” he says. “Most companies are not yet good at those, and far fewer of them have gotten good at running them at scale with agent governance and observability.” Ganesh sees several problems, including agents running without clear permission models. “If an agent can see more than a person or access more than a person’s permission on content or data, that’s an incident is waiting to happen,” he says. However, some early agent governance models don’t scale. Some IT teams have defaulted to a position of humans needing to approve every agent output because that’s the safest option, he says. “In reality, this is rebuilding manual process with more checkpoints or suggestion points,” Ganesh says. “At a high volume, governance is your bottleneck to scale and no longer your safely net.” Organizations need observability and governance processes in place that are both scalable and comprehensive, he adds. Agent ROI will come from strong guardrails, clear permission models, and clear human-in-the-loop involvement, he says. “Every mature automation needs ongoing observability — workflows change, policies change, decisions change, new use cases show up,” he says. “Human intervention is always needed for what changes over time, but we need less intervention for known paths and more focus on exception handling and governance fine-tuning.” Observing output is not enough Governance can’t just focus on agent output, adds Marcelo Lorenzetti, founder and CAIO at legal services AI vendor SavvyLex. “The biggest challenge is not simply whether an agent produces a good answer,” he says. “It is whether the organization can prove what the agent accessed, what instructions it followed, what tools it invoked, what decisions it made, where a human intervened, and whether it stayed within authorized boundaries.” Without a full level of runtime visibility, companies are left with screenshots, logs, and after-the-fact explanations that may not meet legal, compliance, or security requirements, he says. Agents should be continuously verified instead of fully trusted, he adds, with governance engineered into the agent architecture itself. Governance should include role-based access, policy-bound execution, human approval thresholds, source and tool provenance, immutable activity records, confidence scoring, exception handling, and clear escalation paths when an agent reaches the edge of its authority, he recommends. “Observability should not be limited to whether the model responded,” Lorenzetti says. “It should show the full decision path from input to action.” AI agents have shifted the governance model that’s needed, he adds. “The core problem is that many companies are moving from AI that answers questions to AI that takes actions, but their governance models are still built for passive tools, not autonomous workflows,” he says. View the full article

For decades, cybersecurity was a battle of skill. Elite attackers versus elite defenders. The rules of engagement were understood, even if the playing field wasn’t level. If you hired better analysts and bought better tools, hopefully you hardened your systems well enough and built detection capabilities that wore out the adversary’s patience. That era is over, and most security programs haven’t fully processed what replaced it. Adversarial AI has industrialized exploitation. What once required a coordinated team of technically sophisticated threat actors to manage reconnaissance, weaponization, lateral movement and persistence can now be executed autonomously, at machine speed, against thousands of environments simultaneously. Threat actors no longer need deep technical expertise. They need compute, capital and access to AI tooling — all of which are commoditized. Think about what your team used to rely on. Attackers left clues that telegraphed their presence – patterns you could learn, signatures you could catch and their campaigns moved slowly enough to track. That’s gone. Reconnaissance that took days now takes minutes. The attacks your tools were trained to recognize are being rewritten on the fly. And the coordinated human teams that once limited how many targets an adversary could hit at once? They can now be easily outmaneuvered by a single actor with the right AI tooling. Your architecture was designed for a threat that no longer exists. The problem is structural The gaps AI-enabled adversaries are exploiting aren’t primarily operational failures. They’re architectural ones. As enterprise environments expanded across cloud, OT, identity infrastructure and third-party integrations, security organizations responded by layering tools. Each new surface area got a new control, a new scanner, a new dashboard. This has created a security architecture that’s simultaneously complex and fragmented — generating enormous volumes of signal while producing limited clarity about where the actual risk lives. The specific failure modes are familiar to anyone who has worked through a real breach investigation. Controls that don’t share context mean a vulnerability scanner can flag a misconfiguration, an identity tool can flag an overprivileged account and an endpoint platform can generate an alert — none of them are able to answer the question an attacker has already answered: Can these exposures be chained into a viable path to something critical? Visibility across hybrid and multi-cloud environments remains patchwork at best; attackers move freely across boundaries that defenders frequently can’t see across. Identity exposure — overprivileged service accounts, stale credentials, misconfigured trust relationships — creates lateral movement pathways that go undetected until someone is already deep inside the environment. Alert overload causes security teams to spend disproportionate time on findings with no realistic exploitation path. None of this surprises working security professionals. What’s less widely acknowledged is that it’s not a resourcing problem. More analysts and more siloed tools, layered onto a fragmented architecture, produce more of the same. Security tools are built to detect and flag. They weren’t built to show you what an attacker sees when looking at your environment. Attackers have already leveraged automation to extend their reach. AI will enable them to exploit attack paths with unprecedented speed. So, as clichéd as it sounds, defenders need to put themselves in the shoes of attackers and adjust their approach from there. How defenders can change the equation That mindset shift starts with asking different questions. Most security programs are built around “what vulnerabilities exist?” The better question is “what can an attacker actually do with what’s in my environment right now?” That reframing has real consequences for how programs are run. Incident response speed matters, but it’s a downstream variable. The upstream question is how to make incidents caused by structural gaps and flaws less likely — which requires understanding your environment the way an attacker would, as a network of relationships that can be chained, not as a collection of independent assets and controls. Most security teams have never mapped their environment from that vantage point. Most attackers have. It also means prioritizing remediation by real exploitability rather than CVSS score or asset criticality in isolation. This is Exposure Management 101 — the “EM” in Gartner’s Continuous Threat Exposure Management framework, which provides a structure for replacing broken vulnerability management processes. Exposure Management operationalizes the “think like an attacker” ethos at scale. Security programs that prioritize real exploitability are working on the right problem. The 2025 Verizon DBIR found that the median time for edge device vulnerabilities to be mass-exploited was zero days, while organizations took a median of 32 days to fully remediate them. And separately, the average time to patch across 17 high-profile edge device CVEs was 209 days. You can’t close that gap by triaging everything equally. The defender’s actual advantage: Know thy environment There’s a version of the current threat landscape that leads to fatalism. Why invest in a fight you’re structurally losing? It’s easy to go there, but it’s the wrong read. Ultimately, I believe that defense will become equally automated — a true battle of the machines. But even before we get there, defenders have a structural advantage that no amount of adversarial AI eliminates: They operate inside the environment they’re protecting. They can see the full topology, the identity relationships, the compensating controls, the critical assets. An attacker, however sophisticated the tooling, has to discover all of that from the outside. Defenders already know it. At least they should. Most organizations have the underlying data to understand their own exposures. The challenge is synthesizing it into something actionable — seeing on a continuous basis what an attacker would see, and which paths actually lead somewhere dangerous. Start with visibility that actually crosses the boundaries your tool stack has carved out over years of reactive purchasing. Get serious about prioritization based on what’s genuinely exploitable in your environment, not what scores highest on a spreadsheet. And stop conflating compliance-driven tests with your current risk posture — they tell you what things looked like last quarter, not today. The conversations CISOs should be having at the board level should focus on whether the program running today can flag when an AI-empowered attacker has a clear path to the company’s crown jewels. The industrialization of exploitation is a genuine shift in the adversary’s economics and logistics. But the structure of the problem hasn’t changed. Defenders who understand their own environment better than attackers — and who build their programs around that advantage — are in a stronger position than the threat headlines suggest. Are you leveraging the defender’s advantage? The fast way to know this is to have your team answer the following questions: How many critical corporate assets have a validated attack path from an internet-facing entry point? How has that number changed quarter-over-quarter? What percentage of our remediation effort closed an actual path versus a theoretical finding? Do we know the ways an attacker could create an attack path to our critical assets? Are we continuously assessing all of the possible attack paths to our critical assets?” Then, if you don’t like the answers, it’s time to revisit your control architecture. The best way to avoid cyber disruption from adversarial AI is to fix the structural problems so those attack paths aren’t realized in the first place. Carpe Diem! This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Online or telephone IT support scams have been tricking employees into downloading or clicking on malware for years. But according to the FBI, one group that targets US-based law firms has recently found success in person, by convincing firms to allow a supposed IT support person into the building, where they insert a storage device into a victim’s computer and install malware or steal data. This revelation comes from an FBI Flash report this week describing the activities of a gang it calls The Silent Ransom Group (SRG). Other researchers call it Luna Moth, Chatty Spider and UNC3753. Cybersecurity experts, though, aren’t surprised that employees can be fooled into allowing a stranger to touch their computers. “The adversary visiting a location in person with a USB key hacking device of some sort has been used for decades, particularly in the banking industry,” said Roger Grimes, CISO advisor at KnowBe4. “Usually, it isn’t just a direct download of data, but using the USB storage drive to either monitor password typing, to install remote access software that the hacker can use to come back into the environment remotely, or to install some other sort of hacker malware. It’s so common in the banking industry that they have often added and allowed that scenario — a physical attacker — in their regular penetration testing audits, more so than any other industry.” Lance Spitzner, director of workforce cybersecurity training at the SANS Institute, said the tactic of getting into a company to use infected USB drives isn’t new, but in his opinion is relatively rare. It’s more common for a threat actor to mail a drive to an employee. “Having someone physically expose themselves by going into an organization is a risk most cyber attackers are not willing to take,” he said. “The details in the FBI report are pretty limited; I’m guessing if this did happen, an attacker paid someone off to do it for them, perhaps an insider or contractor the company trusted.” The FBI says SRG actors have been running data theft and extortion operations since at least 2022. Despite its name, the gang doesn’t use ransomware encryption, but typically seeks rapid access to victim systems to steal data. Then they use extortion, through threats of public disclosure or sale of stolen data, to try to get payments. Historically, the gang gained access to the victim’s network by sending phishing emails purportedly charging small ‘subscription fees;’ to cancel the fake subscription, the victim was instructed to call the threat actor, who then emailed the victim a link that would download remote access software. New tactic But since the spring of this year, SRG actors have added a new tactic: Posing as an employee from the victim’s IT department. They either directly call or send phishing emails to urge employees to contact an SRG actor pretending to be their firm’s IT support. While on the phone, the SRG actor asks the employee to grant access to a remote desktop session. If that fails, SRG sends a threat actor to the victim’s location to physically access their computer and insert a storage device. The excuse: the so-called IT support person needs to image the device, or to create a backup file to address potential impacts from the phishing email. Once the threat actor obtains access to the victim’s device, they minimally escalate privileges and quickly pivot to data exfiltration without encryption. Their tools include WinSCP (Windows Secure Copy) or a hidden or renamed version of “Rclone” to exfiltrate data. They may also exfiltrate data to internal file sharing platforms such as Google Drive or Microsoft OneDrive. And once it has the firm’s data, the gang will call employees or clients of a victim company to pressure the victim to begin negotiations. The FBI warns infosec pros that indicators of an SRG attack may include new, unauthorized downloads of system management or remote access tools, including Zoho Assist, Quick Assist, AnyDesk, RustDesk, Syncro, Splashtop, or Atera; unauthorized installation of external hard drives or USB drives on company computers; exfiltration of data to Microsoft OneDrive, Google Drive, or external servers; WinSCP or Rclone connection made to an external IP address; and alerts that data was exfiltrated from the company environment. The primary things employees need to be trained to watch for are visits from unidentified or unauthorized individuals claiming to be IT support and attempting to access computers, and unsolicited phone calls from individuals falsely claiming to work in their IT department. The FBI didn’t respond by press time to a request for information on the number of times the gang had tricked an employee into allowing a personal visit. But the tactic by SRG is new enough that the bureau is asking for a copy of the extortion note, the phone number or email account used by the group, transcripts of communications with the threat actor, and any surveillance videos or photos of individuals posing as IT support. The challenge of security awareness training Since the beginning of the desktop computer age, CSOs, CIOs and IT department leaders have struggled to find effective security awareness training to fight phishing, IT tech scams, and other social engineering attacks. Law enforcement agencies have had some success in taking gangs offline, but they pop up again. The threat actors may also be assisted by the fact that employees often don’t know who their IT support staff are, especially if the firm uses a third party external support company. [Related content: A backgrounder on security awareness training] Christopher Kayser, head of the Canadian firm Cybercrime Analytics and author of the book Cybercrime Through Social Engineering, said in an interview that often an employee’s first assumption is that an email, text, or voicemail about a serious issue from someone claiming to be from IT is legitimate. After that, threat actors play on an employee’s willingness to act on a supposedly urgent matter, their obedience to management, or their wish to be helpful. “We have a tendency to trust,” he said. It doesn’t help that threat actors are willing to share successful tactics with other groups, he added. Nor, he said, does it help that in some organizations, security awareness training doesn’t extend to the top (CEOs) or the bottom (receptionists). Trust no one To combat IT support scams, employees need to be trained that any email, text, or voicemail purporting to come from IT that asks for action needs to be verified with an IT manager through an approved process, not by replying to the message or calling a phone number given in the suspect communication, Kayser said. Employees also need to be trained to slow down, and not to respond or act quickly on emails, texts, or voicemails that ask for passwords, multifactor authentication codes, or personal information. Spitzner added, “security awareness training is one approach to patching vulnerabilities in humans. You need to teach them about the risks of infected or untrusted USB drives and what drives are authorized. In this case, the problem may have been an untrusted individual gaining access to the victim’s facilities.” Nick Tausek, lead security automation architect at Swimlane, said the Silent Ransom Group’s attack strategy of leaning into trust says a lot about where extortion is heading. “That makes this especially dangerous for law firms,” he said. “Those environments hold sensitive client records, privileged communications, financial details, and case information. If that data is stolen, the damage does not stop at the victim organization. Clients can be pressured, legal strategies can be exposed, and employees can become targets for follow-up scams.” The hardest part is that much of this activity can look normal at first glance, he said. Because legitimate tools used by threat actors don’t always trigger alarms, security teams need faster ways to connect unusual behavior across users, devices, cloud storage, and remote access sessions. “When attackers are moving this quickly, delayed detection gives them the advantage,” he said. Grimes added that defenses should include strong and frequent employee education about physical attacks, disabling USB ports on publicly accessible computers, and other mitigations that prevent the connection of physical storage devices. Microsoft Windows, he pointed out, has had mitigations to prevent the insertion of unauthorized storage devices, including USB sticks, for well over a decade. In addition, the FBI urges physical and IT security leaders to verify the credentials of anyone accessing company spaces, obtaining copies of each visitor’s ID card, as well as limiting access to sensitive data from less secure networks, such as home computers or the public internet, and developing and communicating policies regarding when and how IT support will communicate and authenticate themselves to employees. View the full article

Over the next three to five years, both governments and the private sector will need to rapidly adapt identification and mitigation protocols as adversaries move from AI-assisted to AI-enabled sanctions evasion and proliferation financing (PF), a new research paper warns. The report, Algorithms of Evasion: The Rise of AI-Enabled Proliferation Financing, from the Royal United Services Institute (RUSI), a UK-based defense and security think tank, defines PF as the use of funds or financial services to acquire, develop or otherwise deal in weapons of mass destruction (WMD). It states, “North Korea and Iran are now developing and deploying AI models to aid with sanctions evasion activities.” Key findings include the fact that AI is now capable of mass producing high-quality fraudulent documents, as well as automating what the report describes as “the administrative minutia of managing extensive shell company networks.” AI powered systems, it states, can also “analyze blockchain patterns in real time to dynamically adjust cryptocurrency mixing strategies, effectively evading detection tools.” In addition, it says, “[tools such as generative AI] which can produce sophisticated fraudulent identification documents, for example, have helped North Korea perpetrate phishing attacks against Western companies.” Dr. Aaron Arnold, senior associate fellow with the Centre for Finance and Security at RUSI, who authored the paper, said in an email that what prompted it was an uptick over the last year in North Korea’s use of AI to facilitate and enhance its cyber operations, in the form of phishing schemes designed to generate revenue for the country’s ballistic missile and nuclear weapons programs. He advised enterprise IT managers who need to protect their organizations from becoming victims of sanction evasion activities that “[it] means largely adapting to a landscape where traditional human-focused security boundaries are being bypassed by automated technologies.” For IT managers, said Arnold, “this might entail incorporating defensive AI, the use of behavior-based analytics, using ‘circuit breakers’ when there is heavy use of API or MCPs, updating personnel training, and hardening identity verification, especially for any remote hiring.” Distinction between AI-assisted and AI-enabled activity is ‘central’ Sanchit Vir Gogia, chief analyst at Greyhound Research, said that the RUSI report matters “because it names the right structural shift. AI is not creating sanctions evasion from thin air, it is compressing and scaling methods that already work.” He pointed out that none of the sanction-evading techniques such as fraudulent documents, synthetic identities, shell companies, hidden beneficial ownership, crypto laundering, and others are new. “What changes is the speed, quality, volume and coordination with which these methods can now be assembled,” he said. According to Gogia, “the distinction between AI-assisted and AI-enabled activity is central. AI-assisted evasion uses AI for discrete tasks: writing a better email, producing a cleaner document, generating a stronger false profile, translating a pitch, summarizing regulations or preparing a plausible job application. AI-enabled evasion is more serious.” A ‘structural asymmetry’ This tactic, he said, “begins to coordinate the system itself. It links identity, documents, ownership structures, payment routes, cloud access, crypto wallets, API calls and timing. The difference is not whether AI helps someone fake a document. The difference is whether AI begins to orchestrate the deception.” That is why the report’s findings should worry enterprise leaders, he noted: “Many organizations still assume the bad actor is mostly human, mostly linear and mostly slow. That assumption is expiring. AI lets adversaries run more attempts, with fewer errors, across more channels, in more languages, with better paperwork and greater patience than most enterprise review processes can absorb. This is not a tale of genius criminals discovering magic. It is the story of ordinary controls meeting industrialized plausibility.” The evidence today, he pointed out, is strongest around tactics such as identity fraud, document fraud, synthetic personas, remote-worker deception, phishing, social engineering, crypto obfuscation and workflow abuse. “Fully autonomous evasion networks sit on the horizon,” he said. “They are serious, but they are not yet the everyday baseline.” This distinction matters, said Gogia: “If enterprises obsess over cinematic autonomous agent scenarios while leaving remote hiring, vendor onboarding, payment approvals, and document review full of holes, they will lose in the most prosaic way imaginable.” The report, he said, also gets the “asymmetry” right. “Offensive actors can learn across the ecosystem,” he said. “They can scrape open information, reuse leaked records, study enforcement patterns, test onboarding forms, inspect public procurement data, watch court filings, probe compliance thresholds and [use the information to] refine their behavior.” Defenders, by contrast, are hemmed in by privacy rules, fragmented data, explainability requirements, jurisdictional boundaries, conservative operating models and siloed technology estates. “Offensive AI learns broadly,” he said. “Defensive AI often learns from fragments. That is the structural asymmetry.” He explained that the regulatory landscape also amplifies the problem, in that regulatory bodies “still speak in separate dialects. [For example] the EU AI Act pushes organizations toward stronger obligations for high-risk AI. NIST-style frameworks push risk management, transparency, and governance.” A trust architecture problem Financial Action Task Force (FATF) expectations push national risk assessment and counter-proliferation controls, he noted, while banking regulators focus on model risk, accountability and operational resilience. “None of these streams is irrelevant. The trouble is that criminals do not organize themselves around regulatory workstreams. They organize around outcomes.” What that means, said Gogia, “is that enterprise cannot wait for a clean global rulebook. It will not arrive in time. CIOs, CISOs, compliance officers and boards need a working governance model now. They need privacy-preserving analytics, controlled data environments, audit trails, legal safeguards and clear model-risk accountability.” He said that enterprise IT managers should treat the situation as a trust architecture problem rather than a narrow sanctions-screening problem. “The uncomfortable truth is that AI is not simply helping bad actors write better phishing emails or forge tidier documents,” he noted. “It is helping them manufacture legitimacy across a chain of enterprise workflows.” Likely outcome an ‘AI arms race’ Report author Arnold also noted that there are signs that cyber criminals have discovered new AI technologies and abilities that legitimate enterprises could adopt for legitimate applications. History, he said, “is replete with [criminals] developing novel solutions to tough problems, [which are] later adopted by law enforcement. Much of our anti-financial crime policy is effectively a response to bad actors exploiting systems or using technology in novel ways to perpetrate crimes. In this scenario, I think an ‘AI arms race’ between enforcement authorities and bad actors is the most likely outcome.” Gogia added, “the baddies are not teaching enterprises how to invent AI. They are teaching enterprises where trust is leaking. That is the lesson worth taking seriously.” This article originally appeared on CIO.com. View the full article

CISOs relying on LLM runtime guardrails and official safety scores when making security decisions about their organizations’ AI usage and model selection are due for a wakeup call. According to a new study from Cisco, frontier models from OpenAI, Anthropic, Google, xAI, and Amazon have significantly worse risk profiles when pressured in multi-turn attacks compared to when their safety is benchmarked using single prompts. “The dominant safety benchmarks for frontier large language models share a structural assumption: that a single prompt and a single model response are enough to characterize how a model behaves under adversarial attack,” the Cisco researchers who authored the study said in a blog post. “These benchmarks inform model cards, safety reports, and procurement decisions across the industry, but they all only measure one narrow slice of attacker behavior.” Instead, the researchers subjected 15 of the most widely used frontier AI models to a variety of attack techniques that are more likely to occur in the real world, where attackers will not give up after the model refuses to respond to one malicious prompt. “Real adversaries iterate,” the researchers said. “They reframe refusals, decompose tasks across turns, adopt personas, and escalate gradually. A single turn benchmark cannot see any of that.” Stress-testing over multiple prompts The tests pitted various model configurations, such as with reasoning enabled or disabled, against a range of attack strategies aimed at bypassing safety guardrails. Techniques included role-play; misdirection or introducing ambiguity into the context; redirection or reframing the model’s refusal; information decomposition and reassembly; and incremental escalation, by breaking a task into smaller parts that don’t seem malicious on their own. The researchers ran 30,090 single prompt attacks (2,006 per model) to determine the weighted single-turn attack success rate (ASR) for every model and then ran 6,986 multi-turn attacks across 1,456 conversations for comparison. The results were telling: Most models had considerably higher average ASR scores for multi-turn attacks compared to single-prompt attacks. For example, Anthropic’s Claude Opus 4.6 and OpenAI’s GPT 5.4 — the latest versions at the time of testing — had single-turn ASRs of 3.64% and 2.74%, respectively. When faced with multi-turn attacks, average ASRs jumped to 16.20% for Opus and 24.68% for GPT. Neither of those, however, represented the biggest score jump. Google’s Gemini 3 Pro had a single-turn ASR of 18.10% and a multi-turn ASR of 73.35%. “For business decisions made on the basis of published single-turn scores, this presents security and governance risk,” the researchers concluded. “A model with 2.74% single-turn ASR is not the same product as a model that holds the line at 24.68% multi-turn ASR. Without paired-regime data, the two are indistinguishable on most public evaluations, and the end user never sees the gap.” Cisco The results also revealed that different model configurations can impact safety. For example, xAI’s Grok 4.1 Fast in non-reasoning mode had the worst multi-turn ASR at 88.30%, but its score dropped to 43.47% when reasoning was turned on. The researchers note that these configuration-related variations are not currently captured by the official model cards published by the labs or the public safety benchmarks. Different attack strategies showed meaningful differences in success across models, both for single-turn and iterative attacks — findings that could be used to inform defense strategies for customers of these models. The tests also uncovered outliers such as Amazon’s Nova Lite, Nova Lite 2, and Nova Micro models, all of which had more than three times higher single-turn ASRs than multi-turn ones. Open-source models from labs such as Meta, Mistral, Alibaba, DeepSeek, Google, OpenAI, Zhipu, and Microsoft faced the same challenges when it came to multi-turn attacks, as highlighted in a study published in November by the same Cisco research team. “Taken together, the two studies make a stronger claim than either alone: multi-turn vulnerability is a structural property of the current frontier, not an artifact of open-weight alignment choices or capability-first development,” the researchers said. “Whether the weights are public or proprietary, whether the lab prioritizes safety or capability, the iterative attack surface remains an open challenge across the frontier.” Call to action Cisco’s researchers are calling for better benchmarks that consider real-world attacks and AI-specific vulnerabilities as identified by OWASP and other organizations, instead of primarily focusing on content safety. Model creators should also be more transparent about how various configuration flags — such as reasoning modes, temperature, and system prompt adherence settings — impact safety, according to the researchers. They should also publish ASRs for both single-turn and multi-turn attacks, further split across various attack strategies. This is especially important given that upcoming regulatory frameworks such as the NIST AI Risk Management Framework, the draft NIST Cyber AI Profile (IR 8596), and Article 15 of the EU AI Act call for adversarial testing. “Any model with an absolute gap >15 [percent points] between single-turn and multi-turn ASR should trigger a manual review before deployment,” the researchers said. “In this cohort that rule flags eight models: five with positive deltas (Gemini 3 Pro; Grok 4.1 Fast NR; GPT-5.4; Grok 4.1 Fast R; GPT-5.2) and three with negative deltas (Nova Lite; Nova Micro; Nova 2 Lite).” View the full article

A single malformed character in a web request can let an unauthenticated attacker slip past the access controls that guard applications built on Starlette, the open-source Python framework that powers FastAPI, researchers said. The flaw, tracked as CVE-2026-48710 could allow attackers to bypass host-validation protections using malformed Host headers, according to an advisory from cybersecurity firm X41 D-Sec. The attacker needs no password and no action from a victim, it said. Starlette’s maintainer released a patch through an official GitHub security advisory after X41 D-Sec disclosed the vulnerability in coordination with the Open Source Technology Improvement Fund (OSTIF). They found the flaw during an unrelated source-code audit, and traced it to Starlette rather than the application under review. “This bug is a classic ‘responsibility gap’ where if this maintainer didn’t patch, thousands of exposed projects would have to individually secure their projects,” OSTIF said. The researchers have created a website, badhost.org, that can test websites for the vulnerability. Exploiting the bug The flaw lies in how Starlette rebuilds the address of an incoming request, according to X41 D-Sec. The framework joins the Host header sent by the client to the path that was requested to form a complete URL, but parses the whole and the parts for validity using different rules. A Host header containing a slash, question mark or hash character shifts where the path begins, the researchers said, so the path Starlette reports no longer matches the one the server actually received. That gap is where the risk lies, according to the firm. Starlette routes the request to the real path, but middleware and endpoints read the altered one. An application that restricts sensitive routes by checking the path it sees can let a request through while still running the protected route behind it. X41 D-Sec published a demonstration with its advisory. The researchers sent a request to a protected administrative page and received a “403 Forbidden” response. They sent the same request with one extra character in the Host header, and the page returned a “200 OK.” The same pattern has surfaced in other recent authentication-bypass flaws in open-source AI frameworks. Severity rating under dispute Starlette’s maintainer rated the flaw at 6.5 out of 10, or Moderate, on the CVSS scale in the GitHub advisory. X41 D-Sec rated it 7.0, or High, and said the danger to software built on Starlette runs higher than either figure suggests. The damage an attacker can do depends on what each application does with the forged path. X41 D-Sec said it found several open-source projects whose security checks rely on the reconstructed address. In those projects, the single-character flaw could chain into “authentication bypass to SSRF and other issues that in some cases even lead to remote-code-execution on the affected system,” the researchers wrote. The reach extends well past Starlette itself. A separate advisory from security firm Secwest on the flaw said the score “materially understates the downstream impact” and warned that the bug touches “most of the model-serving, gateway, proxy, eval, agent, and MCP-server infrastructure that has been stood up in the last two years.” Affected software includes model-serving tools, API gateways, OpenAI-compatible proxies, agent frameworks and Model Context Protocol servers built on FastAPI, according to X41 D-Sec and Secwest. An application can be exposed even if its developers never installed Starlette, because another component may have, X41 D-Sec said. Starlette has more than 400,000 dependent projects on GitHub, according to the firm. Who is most exposed Not every dependent project is equally at risk, X41 D-Sec said. Whether an application can be attacked comes down to how it is. The dividing line is the reverse proxy: A proxy such as nginx or Apache HTTP Server rejects the malformed request before it reaches the application, and production websites usually sit behind such a layer. Research, evaluation and development setups for AI software often do not, and many run the application server facing the network directly, it said. Three groups face the most exposure, according to X41 D-Sec: those running a FastAPI or Starlette application directly on an application server with no compliant reverse proxy in front; those exposing a model proxy such as LiteLLM or vLLM as a directly reachable endpoint; and those whose access-control code reads the reconstructed request address rather than the raw path. The researchers advised teams to upgrade to Starlette 1.0.1 or later, which validates the Host header and rejects malformed values. View the full article

For most of my career running security operations, the shape of cyber conflict has been defined by who could move faster than the other side. Faster at identifying a vulnerability, faster at patching, faster at detecting, faster at responding. The last few months have made me reevaluate that framing. Speed still matters. It just no longer carries the picture on its own. Scale and autonomy have moved alongside it, and the relative emphasis I place on the three is something I expect to keep adjusting. When I read recent coverage of the US government’s deepening use of advanced AI for cyber operations, Anthropic’s Claude Mythos Preview disclosure and the wave of defensive AI being built in response, I recognized the pattern. It fits the pattern of doctrine forming. Doctrine rarely arrives through formal announcements in this field. It emerges through repeated behavior, through choices made under operational pressure, through what capable actors do when no one is telling them to stop. That is where I believe we are now. From tools to operational capability I remember when cyber operations lived inside scripts. They moved into frameworks, then into automated pipelines, then into what we somewhat optimistically called orchestration. Each step compressed time and lowered required expertise. Frontier AI is starting to look to me less like the next step in that sequence and more like a different thing. What seems to separate frontier AI from the automation we have lived with, in what I have seen so far, is less about efficiency and more about independence. A model that can conduct reconnaissance across an unbounded attack surface, identify vulnerabilities without predefined signatures, assist in exploit chaining and adapt based on feedback feels less like enhancing an analyst’s workflow and more like operating with reduced human constraint. That shifts the economics of offense in ways that break assumptions most security programs still quietly rely on. The Mythos Preview disclosure made the shift concrete. The model reportedly surfaced thousands of high-severity vulnerabilities, including findings in every major operating system and web browser, and chained multiple vulnerabilities into novel attacks with limited human direction. A specific example that landed for many readers was a 17-year-old remote code execution flaw in the FreeBSD NFS server (CVE-2026-4747), which Mythos identified and exploited autonomously after a single prompt. The defensive coalition Anthropic assembled under Project Glasswing includes AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, the Linux Foundation, Microsoft, NVIDIA and Palo Alto Networks, with extended access reaching more than forty additional organizations responsible for critical software infrastructure, backed by roughly $100M in usage credits and $4M in donations to open-source security work. That is not a marketing exercise. It is a coordinated reaction to a threat model that has already moved. The fact that the coalition is now drawing antitrust scrutiny is itself a signal: This is no longer experimental. The line that stayed with me from Anthropic’s own writeup was that the model could execute multi-stage attacks on vulnerable networks and discover and exploit vulnerabilities autonomously, completing in hours what would take human professionals days. Pair that with multiple frontier models from OpenAI now operating at the “High” cybersecurity threshold under its Preparedness Framework, including a defender-permissive variant (5.4-Cyber) built specifically for verified security teams, and with the disclosed incident of GTG-1002, the Chinese state-sponsored actor Anthropic publicly attributed in November 2025, jailbreaking Claude Code (by fragmenting tasks and posing as a defensive testing employee at a legitimate cybersecurity firm) to automate 80 to 90 percent of an operation that touched roughly 30 global targets and successfully breached four, and the trajectory stops being speculative. It is observable. The November 2025 GTG-1002 disclosure already touched regulated sectors, including financial institutions and chemical manufacturing, and AI-assisted pre-positioning against critical infrastructure is now documented in nation-state activity reports. The named, attributed, high-impact incident that will make this concrete to a board has not yet occurred publicly. The pattern is no longer hypothetical. The doctrine forming in plain sight Policy frameworks are still catching up. Reporting from Defense One over the past weeks makes clear that the US government is actively procuring AI-enabled vulnerability scanning, exploit development, threat data analysis and covert cyber infrastructure. The signal has now moved from procurement to codified policy: The FY 2026 NDAA directs the Department of Defense to develop an AI cybersecurity framework and incorporate it into DFARS and the CMMC program. Former senior NSA voices are discussing openly how AI reshapes offensive operations. The White House cyber posture has shifted toward more explicit offense, and that posture is being matched by capability. The experimental phase is over. We are in the operational one. When a state-level actor integrates a new class of capability into live operations, doctrine follows. It does not get announced. It gets revealed through what targets are hit, how fast, at what scale, with what level of human oversight. The early outlines of AI cyber doctrine are already visible if you read the signals together. Speed over stealth is the first. In an environment where exploit windows compress from weeks to hours, operating faster than a defender can respond is often more valuable than remaining undetected. That reverses the stealth-first operational model that shaped two decades of advanced persistent threat thinking. Adaptive systems over static controls is the second. Playbooks that assume attacker behavior will repeat are already brittle. Phishing becomes dynamic. Malware morphs faster than signatures. Attack chains execute inside the time required to schedule an incident bridge. Defense either learns and adjusts, or it absorbs. Probabilistic defense is the third. Zero-loss security was always a marketing ideal rather than an operational target, but the mismatch is now acute. The realistic objective is bounded loss: Assume continuous low-level compromise attempts are occurring, and optimize for detection, containment and minimized blast radius. I have had that conversation with peers more times in the last quarter than in the previous three years combined. These are not constructs I am importing from a policy paper. They are the operational principles I see other security leaders quietly adopting because the environment does not offer another option. Underneath those principles sits an economic shift I keep coming back to. Historically, attackers were constrained by three things: time, cost and expertise. AI compresses all three simultaneously. The NCSC’s most recent analysis frames the shift in concrete terms: In early 2026, the best frontier model completed nearly six times more attack steps on a realistic simulated enterprise attack than the best model eighteen months earlier, and a full attempt now costs around £65. Reconnaissance is continuous rather than episodic. Vulnerability discovery scales beyond any human team. Attack generation is iterative and cheap. Defense, meanwhile, is still indexed to human speed and decision-making. Offense is operating at machine speed and scale, while defense is still paging analysts during incidents. That is the imbalance. What I’m seeing reads less like a tooling gap and more like a model mismatch. The UK National Cyber Security Centre’s recent analysis of defensive advantage against frontier AI captured something I have struggled to articulate to my own executive stakeholders: defensive advantage is not a static condition. It has to be actively retained against a capability frontier that is moving faster than most governance structures can accommodate. Organizations that treat AI as an enhancement layer will be outpaced by organizations that treat it as a structural change to how security is designed. What I think leaders should actually do Three things, and I do not consider any of them optional. 1. Treat AI agents as security principals Any autonomous or semi-autonomous AI system with access to sensitive systems, data or workflows needs the governance posture applied to privileged users. Identity, access control, behavior monitoring, audit. If an AI agent can act, it can cause harm, and it has to be governed accordingly. Calling it a tool absolves no one, and the scariest version of this problem is an internally sanctioned AI agent with broad access that nobody has scoped as a principal. This recommendation is no longer outside the consensus. NIST’s Center for AI Standards and Innovation formally launched the AI Agent Standards Initiative in February 2026, the NCCoE has issued a concept paper on software and AI agent identity and authorization, and identity vendors, including Okta, Microsoft and Google, have shipped first-class agent identity primitives. The line is drawn. The question is whether you cross it now or after an incident forces it. 2. Invest in adaptive defense rather than incremental detection Adding another static-signature layer to an environment where attackers iterate at machine speed is mostly theater at this point. The investment that produces compounding returns is in defenses that learn, including the capacity to run AI-driven detection and response inside the seams where human review cycles used to live. That requires hard choices about where to reduce analyst toil, where to accept probabilistic outputs and where human judgment is still the right bottleneck. 3. Reframe the risk model Build the program on the assumption that continuous low-level compromise attempts are the normal operating condition rather than the exception. The rare high-impact event framing is a residue of a threat environment we no longer live in. Budgets, metrics and executive conversations should reflect that shift. Board reporting built around annualized loss expectancy will not survive contact with an adversary operating on hour-long cycles. For years I told my teams that the advantage in cyber went to whoever had the better tools. I was wrong, or at least incomplete. The advantage now goes to whoever adapts faster. Governments are already integrating these capabilities into live operations. The doctrine is not coming. It is forming, quietly, operationally and in plain sight. The question is whether defenders will recognize it in time to shape their side of it. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Data security posture management (DSPM) explained Data security posture management (DSPM) tools help security teams examine their entire data environment to find shadow data, reducing the risk of data loss. Tracking down sensitive data across both cloud and on-premises systems can be vexing. Each environment presents its own challenges. Given the dynamic and ephemeral nature of cloud computing, cloud data is easily created, deleted, or moved around. The cloud attack surface is equally dynamic, making protection all the more difficult. On-premises data can be elusive, particularly when shadow AI usage creates mission-critical data stores outside IT’s purview. To address this latter point, most DSPM vendors are incorporating their own AI routines (or offering a separate AI SPM product, as we outlined here). But AI isn’t the only source of shadow data: for example, old data repositories left lurking on some cloud container or in-house server that has long been forgotten, not updated, or unaccounted for. The goal of DSPM products is to locate this shadow data and complement the more expansive cloud security posture management (CSPM) tools. But instead of focusing on protecting cloud infrastructures, DSPM tools focus exclusively on the role of data and how it is consumed by various cloud and on-premises services. How the DSPM market is evolving Over the past few years, DSPM tools have been developed to discover both known and unknown data, provide structure, and manage the security and privacy risks of potential data exposure. The market segment has seen a lot of mergers and acquisitions of late, including the following: Tenable acquired Eureka Security and Vulcan Cyber, folding them into its CNAPP Cloud Security platform Palo Alto Networks acquired Dig Rubrik acquired Laminar Security Proofpoint acquired Normalyze IBM acquired Polar Security, folding it into Guardium Veeam acquired Securiti Varonis acquired a variety of companies, including Cyral, SlashNext, and AllTrue.ai to enhance its DSPM and other products Thales acquired Imperva and created its CipherTrust DSPM Google acquired Wiz This activity shows how DSPM has become a hot commodity, as established security vendors are buying up niche vendors to expand how they identify and protect data. According to Gartner, DSPM tools bridge “the gap between data discovery/classification and the eventual implementation of automated remediation controls.” The research firm outlines five use cases for DSPM: data loss prevention (DLP), privacy and data governance, entitlement management, cloud posture management integration, and protecting AI-related workflows. DSPM has evolved to the point where “the products’ combined capabilities now bear only a slight resemblance to the capabilities of the vendors that pioneered DSPM, leading to uncertainty for customers as to what DSPM actually is,” Gartner says. As a result, while all five use cases are key components of any DSPM strategy, not every DSPM tool will perform equally well — or even comprehensively — across the board. Take DLP for example. It used to be the sole place where security tools would examine threats and try to combat risk from these threats. But as cloud estates have grown, and as AI training data exploded, enterprises need to move beyond plain-vanilla DLP and establish better ways to find evidence of an attack, stolen data, or AI-fueled phishing attempts. Part of the problem is that, as Gartner reports, “traditional data security products have an insufficient view to discover previously unknown, undiscovered, or unidentified data repositories, and they fail to consistently discover sensitive data.” That is where integration into other security tools is essential — and why so many mergers and acquisitions have taken place to fill these gaps. Another issue is that data usage can be messy: Many businesses have numerous data and application silos that don’t put data protection front and center. Moreover, organizations often lack consistent protections as their data spreads across clouds and applications — especially when it comes to finding its way into AI agents. DSPM provides the locator function for these complex environments. Fixing the problems a DSPM tool finds is really the province of a various other security tools, such as security orchestration, automation, and response (SOAR); security information event management (SIEM); cloud-native application protection platforms (CNAPPs); and the like. Some DSPM vendors integrate or incorporate these “fix-it” tools with their products. Overall, the DSPM market is experiencing a boom in interest, with the tools catching on quickly in the past few years. As late as 2022, Gartner found a miniscule market penetration of less than 1% across its clientele. More recently, the research firm found that DSPM’s growth over the past two years has outpaced every other cybersecurity category. What to look for in data security posture management (DSPM) tools DSPM tools require a significant amount of staffing resources to evaluate because they touch on so many aspects of your IT infrastructure. That’s a good thing, because you want these tools to seek out and find data no matter where it could be hiding. Having a plan that prioritizes which data is most important to your organization will help focus your evaluation. It’s also important to document how each DSPM offering creates its data map and subsequent dashboards. You should also understand the specific cloud and on-premises services that are covered and which ones are on the vendor’s near-term product roadmap. How each vendor describes where it goes looking for data is instructive. Every vendor supports some visibility into some of the cloud data repositories of Amazon Web Services, Google Cloud, and Microsoft Azure. But that doesn’t mean that they cover every service offered by each of the cloud providers that deals with data. For example, AWS has its S3 storage, Relational Database Service, Redshift’s cloud data warehouse, Athena serverless SQL queries, and ElasticSearch managed data services, among several other places that operate on data. Veeam takes pains to delineate which services are covered in each cloud platform, but other DSPM providers are not as transparent. Varonis, meanwhile, uses a “universal data connector” that can seek out a wider range of structured data destinations, both cloud-based and on-premises. Some vendors acknowledge cloud services they don’t support. Be sure to note that this is a very dynamic situation as vendors are adding coverage areas continually as their customers demand them. Tracking down data is just the beginning, however. Once found, the data must be cataloged, evaluated, and summarized in various dashboards. That could be tricky if done without tight security controls, which is why most DSPM vendors claim that “customer data always stays within the customer’s environment.” This typically means collecting metadata, rather than the data itself, using read-only access to the apps, services, and database structures. Vendors refer to this as “agentless” or “using API access.” This approach has the advantage of being able to scan huge volumes of data quickly to understand the nature of its usage and potential risk factors. Once the data has been discovered and its metadata has been collected, the next step is to perform regular scans to see what changes have been made: Has data been copied to some dark corner of your cloud estate? Has someone just changed access rights to allow for greater or insecure access? These tools provide a single point of view across all the various cloud and on-premises data locations. The key word here is “regular.” Scans have default periods (such as daily or weekly) and can be activated when new data repositories are found. How data is consumed in your production environment, including data pipelines, lakes, and warehouses, is another aspect to consider. This can involve creating data maps to classify this landscape as well as facilitating audits to enumerate who has access to which data resource and under what specific circumstances it was shared across your enterprise. Maps are not just pretty pictures but important visualizations that often show where shadow data was abandoned, for example. On top of all these activities there is the entire field of data governance. DSPM products assign risks and apply consistent security policies to manage your entire data collection, and they work with other security tools to enforce these policies and remediate problems. Many of the vendors included below have begun offering continuous auditing as part of their DSPM governance package, which is a welcome development in this fast-changing world. Each DSPM tool has several components, including agents and agentless collectors (useful for tracking on-premises data), a centralized management dashboard, scanners that detect and prioritize data collections, maps of data lineage and usage, and compliance assessments. Most vendors offer their DSPM product in one or both wider contexts: to integrate with third-party security services (such as offered by Veeam and Wiz) or as part of their own security product portfolio with other add-on modules that include identity management, cloud management, detection and response, and log analysis tools (Palo Alto Networks, Varonis, and Wiz). The specifics on these integrations are worth examining, as some vendors, such as Varonis, Wiz and Palo Alto Networks, have wider support than others. Understanding the scope, integration level, and what other protective features are included, and which are available at an extra cost will take some effort to figure out. Products can be deployed as a complete SaaS cloud-based solution, run from on-premises servers or private virtual machines/containers, or in some combination. Finally, there is the issue of pricing. All the products overviewed here are pricey. Few vendors were willing to share this information, indicating that prices are flexible and depend on numerous factors. Some vendors are now charging by the terabyte for DSPM, an interesting development that could result in higher usage costs. However, numerous vendors offer annual subscriptions on either or both the Amazon and Azure marketplaces, which typically start at $30,000 for the smallest of networks. Plan on spending at least $100,000 annually, with higher prices to analyze larger data collections. Leading vendors for data security posture management (DSPM) The market space of DSPM is evolving quickly. Based on our own research and research from Gartner, GigaOm, IDC, and other analyst firms, we’ve identified 10 DSPM tool providers worth investigating. We also contacted several other vendors for this article that did not respond to our inquiries, so they are not detailed here: BigID, Concentric, Flow Security, IBM, OneTrust, Rubrik, Symmetry Systems, and Theom. Cyera DSPM Platform Cyera’s DSPM Platform helps organizations discover, classify, and secure sensitive data across cloud, SaaS, AI, and on-premises environments. The platform — along with its DDR companion DataWatcher — enables enterprises to control what data AI applications and agents can access, govern how that data is used, and reduce exposure risk across data at rest, in motion, and in use. Cyera provides agentless visibility into structured, semi-structured, and unstructured data, highly actionable risk and access intelligence dashboards, and more than 500 built-in data classifiers. The platform integrates with numerous security and data ecosystem tools, including Netskope, Splunk, Tines, Wiz, Collibra, DataHub, and Secoda, and supports on-prem/hybrid deployments for customers requiring in-environment scanning and regional data residency controls. Pricing on AWS for its Cloud Platform starts at $50,000 per year. Microsoft Purview DPSM Microsoft Purview DPSM is part of a larger data protection effort that is in preview form and will be rolled out in June at the company’s Build conference. It consolidates separate data protection tools to provide a single place to monitor and enforce security policies, and create and monitor security objectives. Purview DPSM will integrate with DSPM tools from Cyera, BigID, and OneTrust, and it uses Copilot and other AI agents to identify and protect your data collections. It replaces older DSPM tools that are now labelled “classic” versions. Palo Alto Networks Cortex Cloud DSPM Palo Alto Networks’ Cortex Cloud DSPM integrates with hundreds of SIEM, workflow, and ticketing solutions, as well as XDR and single sign-on (SSO). It comes with more than 600 prebuilt data classifiers, but more importantly, it works closely with various AI tooling to automate detection and remediation threats. It supports Microsoft 365, Snowflake, other SaaS services, a wide range of cloud providers, and on-premises file shares. Proofpoint DSPM Proofpoint DSPM recently folded in the company’s Normalyze acquisition and added integration with Proofpoint’s DLP solution. The tool scans cloud, SaaS, and on-premises data sources. It uses AI tools to identify attack paths and classify high-value data and auto-remediates when identifying misconfigurations. It integrates out-of-the-box with APIs for SOAR, third-party ticketing, and notification and automation platforms, including Atlassian Jira, ServiceNow, Microsoft Purview, and Slack. It offers more than 300 data classifiers and protects AI workflows. Sentra End-to-End Data Security Platform Sentra End-to-End Data Security Platform provides both continuous compliance and a superset of DLP policies, offering deep support for most cloud computing services along with support for containers, virtual machines, and on-premises data sources. It has its own data detection and response (DDR) tool for near real-time detection and a series of actionable dashboards. There are lots of integrations with data management (Coralogix, DataDog, and DataHub), email, ITSM (Jira, PagerDuty, and ServiceNow), CNAPP (Wiz), collaboration (Atlan, Azure Boards, Monday.com, Slack, and Teams), IAM (Active Directory and Okta), incident response (Seemplicity), SIEM (Splunk), and on-premises file shares. It also has powerful data classifiers that leverage built-in AI features to provide metadata enrichment and context, along with automated risk mediation. Sentra has four pricing tiers on AWS, starting at $50,000 per year. Tenable One Cloud Exposure Tenable One Cloud Exposure combines DSPM with threat detection and integrates with data lakes and warehouses such as Atlas, Salesforce, ServiceNow, Snowflake, and Jira-based ticketing systems. The tool continuously scans, categorizes, and remediates data across on-premises, cloud, and SaaS platforms to correlate identity, workload context, and potential threats. It also can dynamically verify and protect data that is externally reachable. Tenable has expanded its protective envelope to cover additional data types (such as secrets) and cloud providers. Thales CipherTrust DSPM Thales CipherTrust DSPM ties together visibility and remediation of your data located across both cloud and on-premises environments. It builds on its Imperva acquisition and can classify both structured and unstructured data and can map and protect data flows and encryption keys and secrets across the entire enterprise. Varonis DSPM Varonis has been in the data security business for more than a decade and covers both on-premises and cloud data repositories. It provides several hundred integrations with SIEM (e.g., Splunk), SOAR (e.g., Palo Alto XSOAR), firewalls, VPNs, web proxies, DNS services, Active Directory, Entra ID, Microsoft Purview Information Protection, and Okta. The product includes a managed DDR service that uses behavioral detection models and automated remediation. Varonis has been on an acquisition binge to broaden its security platform to include better phishing, compliance testing, and AI protection. Varonis AWS pricing is $750 per TB per year. Veeam DSPM Since acquiring Securiti, Veeam has added a variety of breach and compliance management features to Veeam DSPM, as well as on-premises protection to complement its data backup tooling. Its tool supports data streaming technologies such as Confluent, Google PubSub, Kafka, and Kinesis. It comes with 350 content classifiers that support multiple languages along with more than a thousand predefined detection rules, including AI-based data sources and uses. It integrates with a wide collection of cloud-native security services, cloud access security brokers (CASBs), CNAPPs, CSPMs, cloud infrastructure entitlement management (CIEM) systems, DLP systems, intrusion detection systems (IDSes), Kubernetes security posture management (KSPM) systems, SIEM systems, and compliance tools. It is priced per terabyte, starting at $450 per TB per year for structured data and $1,000 per TB per year for unstructured data, with volume discounts available. Wiz for DSPM Wiz maintains a solid brand and product identity, despite being acquired by Google. It packages its products differently from most vendors, offering three products to protect code, cloud assets, and to defend against threats. All three are needed for a complete DSPM solution, which has been expanded to cover shadow data detection and AI-driven data classifiers. Wiz offers two licensing plans, but the full collection of DSPM features is available only on its more expensive Advanced plan. Wiz adds a lightweight agent called Runtime Sensor for detection and response. In addition to the usual cloud data sources, it also scans a variety of on-premises databases, such as MongoDB, MySQL, and PostgreSQL, as well as cloud versions, including Databricks. Wiz also integrates with more than 60 security products. Wiz’ AWS pricing starts at $38,000 per yr to protect 100 workloads. View the full article

Microsoft is previewing a new automatic device isolation capability in Defender for Endpoint’s auto attack disruption tool to help security pros contain cyber attacks in progress on their IT networks. The company announced the capability earlier this month in a column about new features in Defender. There’s no word on when automatic device isolation will be in full production. However, a new SANS Institute research paper warns that, in certain conditions, an attacker could leverage the new function to disable all user accounts. The lesson, said Johannes Ullrich, the institute’s dean of research, is that autonomous AI action tools have to be tuned and tested like any other automation capability. “Automatic isolation and attack disruption are not new concepts,” Ullrich said in an email, “but ideas like these have been used in the past in open source and commercial tools. This feature is most important in organizations with under-resourced IT security teams, as it automates attack response. However, these features must be carefully tuned. If they are left unconfigured, attackers can use them to delay response by disrupting accounts used by administrators.” Nonetheless, in today’s environment, tools like these are important. Robert Enderle, IT consultant and head of the Enderle group, noted that modern automated malware and ransomware attacks move at machine speed, which means human response times are effectively obsolete. By the time an analyst even sees a red flag, he said, the attacker has already established persistence or started encrypting files. Microsoft’s automatic device isolation acts as “a rapid, logical air gap. It instantly severs the device’s network connections, cutting off the attacker’s command and control (C2) and halting data exfiltration dead in its tracks. You have to bring an automated defense to an automated fight.” He said a secondary benefit, often the more critical one for enterprise survival, is containing the blast radius. Attackers invariably use a compromised PC as a beachhead to move laterally across the corporate network, hunting for higher-value targets like domain controllers, he pointed out. “By instantly quarantining that initial endpoint, you trap the threat where it stands. You ensure a single compromised laptop doesn’t metastasize into an enterprise-wide catastrophe,” he said. There’s also is a massive forensic advantage, Enderle added. “In the old days, the instinct was often to literally pull the power plug, which destroys critical volatile memory, or physically yank the network cable, which completely blinds your remote security team. Logically isolating the device while maintaining a secure lifeline to security services preserves the crime scene. It prevents the attacker from deploying wiper malware or destroying logs, and it gives the Security Operations Center (SOC) the breathing room they need to safely investigate and remediate the machine without the panic of an actively spreading infection.” How automatic attack disruption works Automatic attack disruption is offered to organizations that subscribe to Microsoft Defender XDR, a unified cloud-based security suite that detects and investigates cyberattacks against PC, server, and IoT endpoints. It also manages hybrid identities and protects email and collaboration tools. As such, it correlates data to identify and respond to attacks. The soon-to-be-delivered auto-isolation capability blocks most network traffic while keeping the device connected to security services. The action is time-limited and scoped to the incident, Microsoft said; security operators can release isolation at any time. The broad automatic attack disruption capability uses AI to limit attackers’ lateral movement. “Attack disruption uses the full breadth of our extended detection and response (XDR) signals, taking the entire attack into account to act at the incident level,” Microsoft said in a detailed column describing the tool. “This capability is unlike known protection methods such as prevention and blocking based on a single indicator of compromise.” To use automatic attack disruption, IT has to, at the least, enable Microsoft Defender for Endpoint Plan 2. It becomes more effective if Defender for Identity, Defender for Office 365 and Defender for Cloud apps are also deployed. Admins also have to configure appropriate permissions and monitoring. Possible operational disruption The SANS Institute’s academic paper by student Marcio Enriquez noted that AI systems that perform autonomous decisions like containment do improve response times and scalability. But they also rely on threshold-based logic derived from telemetry. “Even when operating on enterprise-wide data, they do not consistently account for system-level impact in their enforcement decisions,” the paper said, and thus can cause unintended disruptions when activated at scale. “This creates a gap between the need for rapid defensive actions and the organization’s ability to maintain operational continuity.” It examined that gap by evaluating how threshold-driven autonomous containment actions can result in what it refers to as “large-scale operational disruption.” Enriquez saw an example of this during a real security incident in the spring of 2025. A user in an organization was fooled by a phishing message and entered their credentials on a malicious website. Defender detected this, and within minutes initiated automated containment measures, including disabling the affected account, forcing a password reset and restricting logins across multiple managed devices. However, because security analysts didn’t realize this was automated enforcement, they initially thought there had been lateral movement or widespread compromise. That triggered an emergency escalation involving security leadership, until further investigation realized that the propagation of containment controls was due to Defender. “The event demonstrates the effectiveness of autonomous containment in rapidly interrupting active threats,” wrote Enriquez. “At the same time, it illustrates how automated response actions can generate enterprise-wide operational effects that are not immediately transparent to human operators.” Could be weaponized To test the ability of a threat actor to take advantage of a weakness in Defender XDR’s automatic attack disruption capability, Enriquez created a hybrid enterprise environment with 18 “users” and executed adversarial activity simulating hands-on-keyboard behavior across multiple identities to trigger high-confidence detection thresholds in Defender, through an attack tactic he calls Autonomous Defense Induced Disruption (ADID). In essence, it tricks the automatic disruption capability of Defender into giving a high-confidence score that the network is under attack. “The results showed that when detection confidence thresholds were met, automated actions disabled all [18] Active Directory identities, including the local domain administrator, rendering the domain inaccessible,” Enriquez wrote. “The research highlights the need for governance controls, privilege-aware safeguards, and system-level constraints to prevent autonomous containment from causing operational disruption,” he concluded. Microsoft guidance: Keep auto attack disruption enabled A Microsoft spokesperson said that the company has no comment on the research paper. However, they said that Microsoft’s guidance is to keep automatic attack disruption enabled by default. “Opting out materially increases risk, particularly for multi-domain, multi-stage attacks such as HumOR [human intelligence operations, like social engineering], BEC [business email compromise] and AiTM [adversary in the middle], where even minutes of additional dwell time can translate into significant business impact.” “At the same time,” Microsoft noted, “we recognize that security teams require control over autonomous actions. That’s why the capability is designed with granular controls. Security administrators can tune automation levels by device group and selectively exclude users, devices, or IP ranges based on operational needs. The recommended approach is targeted, intentional configuration, not a blanket opt-out. Customers retain full visibility into actions taken and have the ability to reverse automated responses at any time.” View the full article

A large-scale automated GitHub backdooring campaign was caught pushing thousands of malicious commits into public repositories while posing as routine CI/CD upkeep. Researchers at SafeDep observed the campaign, Megalodon, touching more than five thousand repositories over a six-hour window on May 18. The attack was in the form of a malicious commit, “acac5a9,” targeting GitHub Actions workflows. Unexpected workflow_dispatch runs in the Actions tab could be a warning sign, the researchers said in a blog post. “If you use OIDC federation for cloud deployments, review cloud audit logs for token requests from unknown workflow runs.” The malicious commits were seen modifying Github Actions workflows to include base64-encoded bash payloads designed to steal secrets exposed during CI execution, including cloud credentials, SSH keys, OpenID Connect (OIDC) tokens, source code secrets, and other environment variables. Among the hardest-hit projects were Wiznet’s ioLibrary_Driver repository, four Tiledesk repositories, and four persian-tools repositories, with well over 2,000 malicious commits between them. A later blog post by OX Security flagged some similarities to the widespread TeamPCP compromises, particularly the use of hardcoded historical commit dates. This was a trick used in TeamPCP-linked operations to hide the true timing of malicious activity. An automated attack with compromised keys SafeDep’s researchers said the Megalodon campaign pushed 5,718 malicious commits across 5,561 public GitHub repositories within roughly six hours, primarily by abusing compromised credentials to directly modify GitHub Actions workflows. It detected the campaign while investigating a Tiledesk GitHub Actions workflow file hiding the base64-encoded bash payload. “Versions 2.18.6 (May 19) through 2.18.12 (May 21) all carry the backdoor,” the researchers had concluded after preliminary investigation. Further comparison of the culprit Tiledesk versions with their legitimate predecessors led the researchers to a malicious commit . “The malicious commit landed on May 18, 2026, authored by build-bot <[email protected]> with the message ‘ci: add build optimization step’,” they said. “The author name and generic noreply email mimic automated CI commits.” The commit was pushed without a pull request (PR) or a merge commit, which the researchers said was done using a compromised Personal Access Token (PAT) or deploy key. They warned the malicious commit remained active on the “master branch” at the time of publishing the disclosure. Besides “build-bot”, the campaign also relied on other forged author identities such as “auto-ci” and “ci-bot.” The campaign pushed out two payload variants. The first, “SysDiag,” embedded obfuscated bash payloads directly into workflows, triggering automatically on every push or PR, while the second, “Optimize-Build,” followed a staged approach using ‘workflow_dispatch” to execute the malicious workflow only when needed. The latter, used in the Tiledesk compromise, proved operationally noisy and left detectable traces. Both variants targeted sensitive CI secrets including AWS and GCP credentials, SSH keys, Kubernetes configs, GitHub OIDC tokens, source code secrets, and shell history. They exfiltrated stolen secrets to attacker-controlled infrastructure at 216.126.225.129:8443. SafeDep shared a list of indicators of compromise (IOCs) including the C2 domain, campaign signature, author names and emails, commit messages, and the names of the compromised GitHub repositories to aid in detection and clean-up. View the full article

A malicious package campaign across npm, PyPI, and Crates.io has put developer workstations back under scrutiny, after researchers said it targeted developer workflows and AI coding assistant files. Researchers at Socket said the campaign, which they are tracking as TrapDoor, “spans more than 34 malicious packages and 384+ related versions and artifacts” across the three open-source ecosystems. The packages were designed to steal developer secrets, including AWS credentials, GitHub tokens, SSH keys, browser data, environment variables, crypto wallets, and local development configuration files, according to Socket. The findings indicate a bigger concern than just another malicious package incident. Developer environments increasingly sit at the intersection of source code, cloud infrastructure, CI/CD pipelines, AI coding tools, and privileged credentials. A compromise of one workstation can therefore give attackers a foothold beyond the developer’s machine. The packages used execution points that are common in normal software development workflows. In npm, the malware relied on postinstall scripts. In PyPI, it used import-time execution to fetch and run remote JavaScript. In Crates.io, it abused Rust build scripts that execute during compilation. That makes the campaign harder to detect using controls focused on a single programming language or package registry. TrapDoor also appears to reflect attackers’ growing interest in AI-assisted development environments. Socket said the campaign attempted to alter files used by AI coding tools, including .cursorrules and CLAUDE.md, using hidden Unicode instructions. The apparent strategy was to trick AI assistants into running security-scan-like workflows that could lead to secret discovery and exfiltration. That use of ordinary development mechanisms is what makes the campaign difficult to treat as a conventional malware incident, analysts said. “TrapDoor represents a shift from opportunistic package abuse toward workflow-level compromise of developer environments,” said Sakshi Grover, senior research manager for IDC Asia Pacific Cybersecurity Services. “Earlier campaigns typically placed a malicious package, stole credentials on install, and moved on. TrapDoor is engineered around the full developer workflow, meaning the attack extends well beyond the package registry.” Grover said the campaign’s cross-registry design makes it harder to spot from a single ecosystem view, since the malicious packages used the normal execution mechanisms of npm, PyPI, and Crates.io. The more serious concern, she said, is what happens after installation, when the malware attempts to persist on the developer machine and potentially use stolen SSH keys to move deeper into engineering systems. “A single compromised workstation can quietly become an entry point into CI/CD pipelines and build infrastructure,” Grover said. “That’s not credential theft. That’s an initial access operation.” Sanchit Vir Gogia, chief analyst at Greyhound Research, noted that the campaign is distinctive because it demonstrates an intimate understanding of how modern software is built. “It does not stop at stealing credentials from one poisoned dependency,” Gogia said. “It targets the wider developer operating environment: package managers, AI coding assistants, Git hooks, shell profiles, SSH trust relationships, browser sessions, cloud credentials, CI/CD pathways, and the local workflow artifacts that developers and machines increasingly treat as legitimate context.” Mitigation strategies Gogia said the issue is no longer just endpoint security, but control over the systems and workflows that produce enterprise software. “Developer environments must be treated as production-adjacent infrastructure,” Gogia said. “They carry code, secrets, identity, automation, cloud access, and now machine reasoning context. If an attacker owns the developer environment, they are not merely stealing a password. They are sitting beside the machinery that creates enterprise software.” Mitigation starts with stronger controls around dependency installation and package behavior, according to Grover. “Lockfiles alone don’t protect you,” she said. “You need automated scanning at install time against known-malicious packages and behavioral signals like unexpected postinstall scripts, remote payload fetching, or unusual network calls.” Grover said least-privilege access for developer credentials is equally important, including scoped, short-lived keys and secrets management practices that avoid leaving credentials in environment variables or configuration files. “If an attacker gets a key and it can’t move laterally, the campaign stalls,” she added. Keith Prabhu, founder and CEO at Confidis, said CISOs should also prioritize hardened developer endpoints, package allowlisting, AI tooling governance, and zero-trust controls within local development environments. View the full article

I’ve spent years building compliance into security products. FedRAMP and Department of War Impact Level authorizations, vulnerability management pipelines: They all follow the same pattern. Build the product, then prove it meets requirements. The compliance layer sits outside the engineering workflow. It reviews what already exists. That model worked when the product stayed static between audits. It breaks for AI. AI systems change even when the base model does not. A retrieval index updates overnight. A new tool gets added to an agent’s action space. An evaluation that passed on Tuesday no longer reflects what the system does on Thursday. The compliance-as-review approach assumes that the thing you’re reviewing remains unchanged between review cycles. For AI, that assumption is fundamentally wrong. Most organizations I talk to are still trying to govern AI the way they govern traditional software: Build it, ship it, then ask legal to check the box. For AI, it leaves the release process blind to the thing most likely to change. When I started researching how other countries handle this problem for my forthcoming book on China’s AI ecosystem, I found something that challenged my assumptions. Chinese AI companies don’t treat governance as a gate they pass after the model works. They treat it as release infrastructure: Compliance checkpoints embedded in the deployment pipeline itself. No checkpoint clearance, no product launch. The governance layer doesn’t review the product. It is part of the product. In one AI deployment review I joined, the product team had everything the launch meeting usually rewards: Performance metrics, customer use cases, latency numbers and a firm release date. The missing pieces were not on anyone’s checklist. No one could point to a current, pipeline-generated record of the retrieval index feeding the model. No one owned the output-monitoring thresholds. No one had tied model evaluation results to an enforceable release gate. The team wasn’t ignoring governance. Governance simply had no place to live inside the actual release process. The review layer is already failing That scene is not unusual. When governance lives outside the engineering workflow, it competes with delivery timelines. Delivery timelines win every time. The NIST AI Risk Management Framework identifies govern, map, measure and manage as core functions for AI risk, but it doesn’t prescribe where those functions sit inside a release process. That leaves the hard architectural question to the security organization. Most companies default to what they know: A periodic review cycle borrowed from traditional IT compliance. That cycle was designed for systems that hold still between audits. AI systems do not hold still. A model fine-tuned on last quarter’s customer data produces different outputs once this quarter’s data enters the pipeline. A retrieval-augmented generation system returns different answers depending on which documents sit in its index today versus yesterday. An agentic workflow that chains three models together produces emergent behaviors that no single-model evaluation captures. Governance-as-periodic-review was built for a world where the artifact under review doesn’t change. We are deploying artifacts that change continuously. The gap between how fast AI systems evolve and how slowly review-layer governance cycles operate is the core vulnerability. Every week that gap widens, organizations accumulate governance debt they will eventually have to repay, either on their own terms or on a regulator’s. What release infrastructure looks like in practice When I researched China’s AI deployment process, I expected to find a heavy-handed approval system that slowed companies down. I found the opposite. China requires companies deploying generative AI to complete a regulatory filing before their product reaches consumers. The filing demands documentation of training data sources, content safety mechanisms, output controls and user-facing disclosures. Companies that clear the process ship. Companies that do not, wait. What surprised me was the speed. Baidu launched Ernie Bot to the public on August 31, 2023, sixteen days after China’s generative AI rules took effect. Dozens of companies followed within weeks. The filing process did not stop deployment. It sorted companies by those that had already built the evidence machinery to pass. The firms that treated compliance as a last-mile legal exercise fell behind. That finding matters for Western security leaders. We should not replicate China’s regulatory model. The underlying operational problem, though, is identical. The EU AI Act reaches the same conclusion from a different regulatory tradition: Its conformity assessment and ongoing risk management requirements for high-risk AI systems assume continuous compliance, not one-time certification. The operational question both frameworks share is the same one I face in my own work: Where in the development process does governance actually live? If the answer is “after the model is trained and before it ships,” you’ve recreated the review-layer bottleneck. Engineering teams will find ways around it. I saw the same pattern with SBOMs. When teams treated the SBOM as a document someone assembled for a customer questionnaire, it aged out almost immediately. When they generated it from the build pipeline, it became part of the product’s living operating record. Model documentation has to move the same way. A model card written by hand after release is a snapshot. A model card generated from the pipeline is evidence. Three shifts security leaders should make now I’ve started applying this principle in my own work and in how I advise teams evaluating AI deployment readiness. Three operational shifts make the difference. First, move model documentation into the CI/CD pipeline. Treat model cards, training data provenance records and output behavior baselines the same way you treat SBOMs: As artifacts generated automatically during the build process, not as documents written by a compliance analyst after the fact. If your model documentation isn’t versioned alongside your code, it’s already out of date. Every model retraining cycle that doesn’t produce updated compliance artifacts widens your governance gap. Second, make compliance evidence a deployment gate rather than a post-launch audit item. Your release pipeline probably already blocks deployment if unit tests fail or if a container image carries a critical vulnerability. Add AI governance checkpoints to that same pipeline. Does the model have a current risk evaluation against your organization’s defined thresholds? Is the training data lineage documented and traceable? Are output controls configured, tested and monitored? If the answer to any of those is no, the deployment doesn’t proceed. The pipeline already blocks vulnerable containers. AI governance checkpoints belong in the same layer. It’s extending your existing security architecture to cover a new class of risk. The problem gets sharper when the AI system stops generating recommendations and starts taking actions. Third, treat agent identity as a first-class security control. As AI agents move into production environments, each one needs an identity in your IAM system with scoped permissions, audit trails and session-level accountability. An agent calling external APIs, reading customer data or triggering automated workflows is an actor in your environment. It requires the same identity governance you apply to human users and service accounts. I wrote about the identity and persistence challenges in stealthy ransomware operations earlier this year here at CSO. The same principles apply: If you can’t identify the actor, you can’t govern the action. None of this requires waiting for regulation. The organizations that will be best positioned when AI-specific compliance mandates arrive, whether from the EU AI Act’s enforcement timeline, emerging US state-level legislation in Colorado and California or sector-specific rules from financial and healthcare regulators, are the ones building governance into their release infrastructure now. The ones still treating it as a review layer will scramble to retrofit what their competitors already ship with. I learned that lesson by studying how a very different system solved this problem first. The regulatory traditions are different. The operational logic is the same: Governance that ships with the product beats governance that reviews it after the fact. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Patching practices are coming under intense pressure of late, as time-to-exploit windows accelerate — a new reality likely to worsen as AI assistance in attack chains rises. Now cyber defenders have another cause for flaw alarm: Vulnerability exploitation has significantly pulled away from stolen credentials as the most common entry point in security breaches, according to the latest edition of Verizon’s annual Data Breach Investigations Report (DBIR). Verizon researchers found that exploited flaws were the root cause of breaches in 31% of cases, with credential abuse blamed for 13% of security failures. In a nod to patch management difficulties in the enterprise, only one in four (26%) critical vulnerabilities were fully remediated in 2025 with the median patch time rising to 43 days, up from 32 days the year prior, according to Verizon’s DBIR. Root cause analysis Verizon’s study is based on an analysis of 31,000 security incidents — of which 22,000 were confirmed data breaches — involving victims spanning 145 countries. Incident response experts quizzed by CSO confirmed the rise in vulnerability exploitation as a means for breaking into enterprises is real. “Attackers follow the path of least effort at scale, and right now that path runs through unpatched perimeter and edge devices, where a working exploit needs no prior access, no phished user, and no breach data to buy,” notes Daniel Bechenea, security manager at offensive security and vulnerability assessment platform Pentest-Tools.com. Bechenea argues that exploitation has overtaken credential abuse because the patching of known exploits is failing to keep up with the rise of critical vulnerabilities. Chris Wysopal, co-founder and chief security evangelist at Veracode, agrees. “Organizations are still simply not fixing flaws fast enough,” he says. According to Verizon’s analysis, only about 26% of CISA Known Exploited Vulnerabilities (KEVs) were fully remediated in 2025, down from 38% the prior year. Meanwhile, the volume of critical-severity vulnerabilities organizations had to patch grew by 50% year-on-year. James John, an incident response manager at Bridewell, offered a contrasting perspective on the relative importance of vulnerability exploitation and credential abuse over the full lifecycle of security breaches. “We’re still seeing identity is the primary chokepoint,” says John, whose cybersecurity services and incident response firm contributed data to the Verizon report. “Exploitation may now win the race to the front door, but stolen credentials are still the thread running through most intrusions we respond to; they’re just used later in the attack, to move laterally and reach the data that matters.” The Verizon report also attributed 16% of initial breach access to phishing, par with the year prior, and 6% to pretexting, which the researchers noted has become more common in ransomware and extortion attacks. That latter point somewhat muddies the report’s credentials conclusion, John notes. “Some of the apparent decline [in credential abuse] is also measurement rather than reality, as credential theft and pretexting blur together,” he tells CSO. As companies rely more heavily on external vendors, threat actors are targeting the extended supply chain as well, with breaches involving a third party now accounting for 48% of all security incidents covered by Verizon’s DBIR. Verizon’s DBIR — now in its 19th year — combines real-world incident and breach casework from law enforcement, forensic firms, and cyber industry sharing groups such as national CERTs, along with data from Verizon’s work with its own clients. Findings from what’s regarded as the industry’s benchmark study on data breaches are supported by recent broadly comparable studies. Google Cloud Security’s latest Cloud Threat Horizons Report, for example, also found that attackers are pivoting toward exploiting unpatched third-party software vulnerabilities rather than relying primarily on stolen or weak credentials. Software vulnerabilities became the biggest single initial access vector (44.5% of incidents), overtaking credential abuse, according to the Google Cloud study. AI already adding to the threat landscape Although the latest DBIR report uses 2025 data — predating the latest frontier AI security model advancements such as Anthropic’s Mythos — greater reliance by cybercriminals on AI still emerges from detailed post-mortems on security breaches. “AI is being leveraged by threat actors to accelerate the time to exploit known vulnerabilities, shrinking the window for defence from months to mere hours,” Verizon warned. Last week the Google Threat Intelligence Group (GTIG) released evidence of a zero-day exploit developed by a cybercriminal group with the help of AI. Breach remediation strategies need to change Muhammad Yahya Patel, vCISO and cybersecurity advisor for EMEA at managed security services vendor Huntress, says CISOs need to rapidly improve their vulnerability management and identity security in light of the Verizon DBIR findings. “Vulnerability exploitation, credential theft, multi-channel social engineering, and supply chain compromise are all being deployed at scale simultaneously,” Patel says. “The organizations best positioned are those that have built defense in depth across all of these vectors.” Patel adds: “More organizations need to shift their vulnerability management program to a risk-based, continuous [approach], tied to real-time exploitation intelligence — not scheduled patch cycles that leave exploitation windows wide open for days and weeks.” Raghu Nandakumara, VP of industry strategy at microsegmentation and breach containment vendor Illumio, argues that even though more vulnerabilities are being fixed as enterprise patching practices improve, the backlog of flaws requiring remediation is still growing faster than security teams can keep up. “The spike [in vulnerability instances] has been driven by a convergence of forces, including more AI-assisted discovery, greater reliance on third-party and open-source code, a growing number of connected systems, and a disclosure ecosystem that’s now far more active and incentivized than it was even a few years ago,” Nandakumara says. Ransomware payments declining but threat remains potent Ransomware was a feature in nearly half of all breaches (48%) covered by the DBIR, up from 44% the year prior, even though ransom payments have declined (69% of victims did not pay). Aparna Rayasam, CEO of network security firm Atsign, says that this shift in payment rates is spurring ransomware to evolve toward a different business model. “Because victims aren’t paying for decryption keys anymore, attackers have shifted heavily toward data exfiltration and extortion,” he says. “Attackers are compensating for smaller individual payouts by executing a higher volume of cheaper, automated attacks.” Rayasam adds: “Use of AI makes this model even more lucrative for the ransomware attackers.” Bridewell’s John offered a contrasting perspective, arguing that although ransomware attackers are no less successful in attacking enterprises, they are finding it more difficult to extract payment from victims. “The drop [in ransomware payments] reflects genuine progress and not attackers losing their edge,” John tells CSO. “More organizations have tested backups and rehearsed recovery, so they can credibly refuse to pay, and the DBIR notes refusals are rising even in cases involving encryption, not just data theft.” This reduction in payment rates means that attackers are becoming more aggressive in their attempts to disrupt a business in order to pile greater pressure on them to pay. For example, UK high street retailer Marks & Spencer suffered weeks of outages and millions in losses as the result of a ransomware attack. “The leverage is shifting from ‘we have your data’ to ‘we can keep you offline,’ which matters far more when downtime affects essential services,” John concludes. View the full article

Cybersecurity experts are warning enterprise admins about an increasing number of phishing campaigns aimed at stealing Microsoft 365 (M365) access tokens to bypass multifactor authentication login protection. Phishing kits aimed at capturing M365 tokens aren’t new; some reports say these kits have been around since 2021. One of the latest is EvilTokens, which researchers at Sekoia say has been circulating since February. And earlier this month, Microsoft also issued a warning about other adversary-in-the middle phishing schemes that steal authentication tokens, and, separately, about campaigns that exploit OAuth protocol functionality to manipulate URL redirection to bypass conventional phishing defenses. Lowers the barrier to entry But, said the US Federal Bureau of Investigation (FBI) in a warning last week, the new Kali365 phishing-as-a-service platform “lowers the barrier of entry, providing less technical attackers access to AI-generated phishing lures, automated campaign templates, real-time targeted individual/entity tracking dashboards, and OAuth token capture capabilities.” It’s increasingly being leveraged by threat actors. On April 24, for example, security vendor Arctic Wolf said that it had detected a large-scale device code phishing campaign impacting organizations that was run by a threat actor using the Kali365 service. Four days later, researchers at Gurucul issued a similar warning, adding the new Kali365 kit “is rapidly becoming a preferred weapon” of threat actors. Both Kali365 and EvilTokens platforms trick employees into entering a code on a legitimate Microsoft login page that allows attackers to steal OAuth tokens. But, Gurucul warned CSOs, “[Kali365] signals a shift toward highly professionalized attack models.” The researchers noted, “This is not just a single hacker working in isolation. Instead, it is a full-scale commercial operation. It is designed to lower the barrier for entry for criminals globally. By providing a ready-made infrastructure for deception, this kit places sophisticated capabilities in the hands of novice attackers.” Move beyond MFA as a ‘checklist item’ CSOs should take the warnings as a reminder that phishing detection lessons are an essential part of security awareness training for all employees. The FBI caution “[also] reminds us that multifactor authentication is no longer the single step that must be present for protection,” said Robert Beggs, CEO of Canadian incident response firm Digital Defence. “Organizations have to move beyond having it as a ‘checklist item’ and instead focus on a defense in depth approach. Organizations have to block or tightly restrict Microsoft’s OAuth device code authentication flow using Conditional Access. Additional controls include revoking OAuth tokens proactively, monitoring for unauthorized device registrations, and monitoring to detect new or malicious inbox rules.” Professional attack model The Kali365 service provides templates, management dashboards, and integrated tools that lower the skill barrier for implementing large-scale attacks to the threat actor subscribing to it. Subscriptions start at $250 for 30 days and go up to $2,000 for 365 days. Once signed up, Arctic Wolf said, Kali365 affiliates can rapidly generate branded phishing lures impersonating common enterprise services such as Adobe Acrobat Sign, DocuSign, and SharePoint. The service includes a modular lure‑generation system that allows threat actors to produce hundreds of distinct variants by mixing language localization, presentation layout, Microsoft‑ecosystem impersonations, and multiple document formats in English, Spanish, French, German, Portuguese, Italian, Dutch, Japanese, Korean, Chinese, Arabic, Turkish, Polish, and Russian. Beggs noted that the use of AI generated phishing lures, assuming the AI has been properly trained against the client business and supplied with the correct cultural contexts, results in trustworthy-appearing documents that are difficult to identify and block in a large-scale attack. Subscribers can take advantage of eight hard-coded email templates, with subject lines like “Voicemail from [with room for a name]”, “Signature Required,” “Invoice #INV,”, “Document Shared,” and “Account notification for [with room for an email address].” Arctic Wolf said it has also seen cases where, after gaining initial access, the threat actor created malicious inbox rules within Microsoft 365, configuring rules that automatically moved emails containing keywords such as “spam,” “phish,” “click,” “link,” and “SharePoint” to a separate folder and marked them as read. This behavior effectively suppressed security-related notifications and warnings to the user, enabling the threat actor to maintain access while reducing the likelihood of detection. In device code mode, victims are redirected to an obfuscated landing page that is designed to only render in a real browser session. Upon page load, the Kali365 backend dynamically generates a legitimate Microsoft OAuth device code. According to the FBI, the attack then works like many other phishing scams: An attacker sends a phishing email with a message that includes a link to a legitimate Microsoft verification page, and instructions to enter the generated code. This code authorizes the attacker’s device to access the victim’s account. The Kali365 backend then captures OAuth access and refresh tokens, giving the threat actor access to the targeted individual’s/entity’s Microsoft 365 account, including Outlook, Teams, and OneDrive, until the compromise is detected and the tokens revoked. Using those tokens, the attacker doesn’t need to enter a password or complete any additional MFA challenges. In some cases, Arctic Wolf added, following token acquisition, the threat actor would use the authenticated session to register an additional device within the victim’s Microsoft environment. This step extended access beyond the initial token by establishing a trusted device association tied to the compromised account. Mitigation In its alert, the FBI urged Microsoft 365 admins to restrict device code flow, since limiting or blocking device authentication codes can help prevent or minimize this style of attack. They should also create conditional access policies to block device code flow for all users, with limited exceptions for required business processes; audit existing device code flow usage to identify legitimate dependencies before creating a conditional access policy; and block authentication transfer policies to prevent users from transferring authentication from computers to mobile devices. If an admin cannot completely restrict device code flow usage, the FBI says they should exclude emergency access accounts to prevent lockouts. Christopher Kayser, CEO at Cybercrime Analytics and author of the book Cybercrime Through Social Engineering, said IT departments must find ways to reinforce to employees that they should not be quick to click on communications that seem unusual or potentially fraudulent. And it’s not just ordinary employees who can be hit by phishing scams, he pointed out. Higher levels of management with authority to transfer funds are targeted by business email compromise (BEC) scams. Typically, he added, when signing into M365, users aren’t asked to input a code; they should be reminded that an email that asks for a code should be a red flag that triggers a call to the IT department. Identity-centric security is key Fritz Jean-Louis, principal cybersecurity advisor at Info-Tech Research Group, said defenders should shift to identity-centric security and treat phishing primarily as an identity compromise risk. This not only means enforcing phishing-resistant MFA through passkeys or other FIDO2 approved login measures, but also strengthening session controls, and monitoring for anomalous authentication behavior, including token misuse and suspicious OAuth activity. Admins should also adopt continuous access evaluation, moving beyond point-in-time authentication by dynamically assessing user and device risk throughout active sessions, enabling real-time response to evolving threats. In addition, responders should leverage behavioral signals by measuring activity and encouraging users to report suspect behavior, and incorporating human telemetry, such reporting speed and interaction patterns, into detection strategies. Jean-Louis said admins also need to reduce their organization’s blast radius by implementing stronger outbound monitoring, automated containment triggers, and tighter controls on account misuse, to limit lateral spread. Finally, he recommended that admins segment high-risk users and functions by applying enhanced security controls and providing isolated environments for executives, finance, and privileged IT roles. View the full article

Anthropic says it and upwards of 50 partners involved in Project Glasswing have uncovered an estimated 10,000 critical or high-severity vulnerabilities in their software offerings. The company launched the cybersecurity initiative, which is built around Claude Mythos Preview, in April, stating that its launch partners would use it as part of their defensive security work. Anthropic said it created Project Glasswing when capabilities in its new frontier model “revealed a stark fact: AI models have reached a level of coding capability where they can surpass all but the most skilled humans at finding and exploiting software vulnerabilities.” At the time, it also indicated that it was committing upwards of $100 million in usage credits, as well as an additional $4 million in donations to open source security organizations. In an update published late last week, Anthropic stated, “for the last few months we have used Mythos Preview to scan more than 1,000 open-source projects, which collectively underpin much of the internet — and much of our own infrastructure.” During that process, Mythos Preview found 6,202 high or critical severity vulnerabilities in these projects, 1,752 of which have since been assessed by six independent security research firms. Maintainers facing bug report deluge Of these, Anthropic stated, 90.6% (1,587) “have proved to be valid true positives, and 62.4% (1,094) were confirmed as either high or critical severity. That means that even if Mythos Preview finds no further vulnerabilities, at our current post-triage true-positive rates, it’s on track to have surfaced nearly 3,900 high or critical severity vulnerabilities in open source code — in addition to those it has found for Project Glasswing’s partners.” Authors of the report noted that, on top of the regular challenges of maintaining open-source software, “maintainers have been facing a deluge of low-quality, AI-generated bug reports. Indeed, several maintainers have told us they’re currently severely capacity constrained, and some have even asked us to slow down our rate of our disclosures because they need more time to design patches.” Anthropic estimated that it has disclosed 530 high or critical severity bugs to maintainers so far, and is aiming to disclose another 827. Of those 530 bugs, 75 have been patched, and there have been 65 public advisories. The company said that the relatively low number is due to three factors: first, the 90 day window set out in its coordinated vulnerability disclosure policy has not closed, second, it is probably undercounting because some flaws have been patched without disclosure, and finally, the security ecosystem is already overloaded. “The relative ease of finding vulnerabilities compared with the difficulty of fixing them amounts to a major challenge for cybersecurity,” the report’s authors noted. Nonetheless, Glasswing’s success so far has led the company to release Claude Security in beta for its enterprise customers, and it has begun its Cyber Verification Program to allow legitimate security pros to use its models in their work without certain of its safeguards. Mark Tauschek, distinguished analyst at Info-Tech Research Group, said Anthropic’s decision to keep access to Claude Mythos Preview restricted through Project Glasswing is one of the clearest signals yet that frontier AI capabilities have crossed a real threshold in cybersecurity. The company, he said, “deserves some credit for the transparency of its system card and the structure of Project Glasswing. But being transparent about the problem is not the same thing as solving it.” According to Tauschek, “the update validates the practical reality that IT and security leaders now have to deal with the fact that the cost of discovering software vulnerabilities has dropped dramatically. If a single AI model can surface thousands of serious vulnerabilities across foundational software in a matter of weeks, the window between vulnerability discovery and exploitation will keep compressing.” Organizations still treating patching as a quarterly exercise are operating with materially more risk than they were even a short time ago, he added. Tauschek said that the fact that some maintainers have asked Anthropic to slow down should not be seen as resistance to better security. “Rather, it points to a capacity problem that has been building for years,” he said. “Many of the open-source projects enterprises rely on are maintained by small teams or volunteers, often people with day jobs.” A key bottleneck has moved Meanwhile, he said, the “organizations depending on that code operate at a massive scale. AI can accelerate discovery, but it does not create the human capacity required to validate findings, design safe patches, test them, and get them deployed. This also forces a rethink of defense-in-depth.” Kellman Meghu, CTO of DeepCove Cybersecurity, added that nothing in the Project Glasswing update is surprising to him. “Our company had figured out almost two years ago that, in the hands of a competent researcher, the ability [of AI] to find vulnerabilities and exploit them were greatly accelerated,” he noted. “I think the change now is that the barrier of entry to drive the prompts in a large language model has dropped significantly. This will only get better, and is our new reality.” DeepCove, he said, “has had to accelerate its patching and controls assessment, which now includes leveraging large language models to help identify and patch or build compensating controls for our services and our customer infrastructures.” According to Meghu, “finding bugs is now cheap, but patching them is still slow and human-bound in many cases. Clients have change management processes, regulatory testing windows, and change blackouts that make absorbing this pace genuinely hard.” What Anthropic’s update really shows, he pointed out, “is that the bottleneck in cybersecurity has moved from finding vulnerabilities to absorbing patches and adapting client defenses fast enough to keep up.” His take echoes that of Anthropic, which noted, “the bottleneck in fixing bugs like these is the human capacity to triage, report, and design and deploy patches for them.” The operational pressure of the new patch cadence is “as immediate as the offensive threat,” Meghu said. “We’ve responded by building AI-assisted auditing into our own development pipeline and tightening client patch SLAs on critical dependencies. But this is not an easy process to manage. We do not blindly trust LLMs or agents to operate autonomously, and this has resulted in significant change in operator assisted processes for LLM integration.” As well, noted David Shipley, CEO of Beauceron Security, “the headline grabber that everyone’s been paying attention to is the 10,000 potential vulnerabilities it found, and then, of those, 6,000 being critical, but when you actually pare the numbers down, you get closer to 1,500 that are actually human verified, legitimate, and so that’s quite a fall off.” “[Anthropic also stated that] 90% of the 1,752 higher critical rated vulnerabilities that have been humanly reviewed were found to be accurate,” he said. “Cool, but that means it’s still about 15% of the total number that it found.” According to Shipley, a critical question that has yet to be unanswered is the cost of finding each one of these vulnerabilities. “How many tokens are you burning? I’ve heard it’s in the range of $500 a minute, so I’m really curious to know what the cost is,” he said. “Surely, if they can tell us how ‘we found this many’, [they can answer] how much compute did it cost?” He added that the only ultimate fix is to “make software makers liable for their software. That is the only way out of this mess, because that is the fundamental misalignment that got us here.” View the full article

Enterprises cannot secure AI agents by making the underlying models more robust and must instead enforce security controls at the system level around them, researchers behind a paper published this month argued, warning that traditional AI-security approaches are increasingly misaligned with how autonomous agents actually operate inside enterprise environments. The paper argues that enterprises should stop treating AI agents as trusted software components and instead secure them as fundamentally untrusted systems operating inside enterprise infrastructure. “The AI model powering the agent must be treated as an untrusted component,” the researchers wrote in the paper, warning that “semantic guardrails” and prompt-level defenses alone cannot reliably secure systems once agents gain access to enterprise tools, memory, APIs, browsers, and execution environments. The authors drew the comparison to operating systems. “Similar to how an operating system treats a process as untrusted, we take the stance that the model powering the agent should be treated as untrusted and security properties should be expressed and enforced outside, at the level of the encompassing system,” they wrote. The paper was written by researchers at Google, the University of California, San Diego, the University of Wisconsin-Madison, and other institutions, including Mihai Christodorescu, Earlence Fernandes, and Somesh Jha. Five principles from systems security The authors distilled five principles from decades of systems security research that they said agentic systems should follow: least privilege, tamper resistance of the trusted computing base, complete mediation, secure information flow, and accounting for the human as a weak link. As evidence, the authors analyzed eleven real-world attacks on AI agents and mapped each to the principles it violated. The attacks included data exfiltration from the ChatGPT macOS app, a Claude Code exfiltration flaw, a Microsoft Copilot exfiltration vulnerability, and the AgentFlayer attack on Cursor through a malicious Jira ticket. Every one of the eleven violated the secure information flow principle, the paper said, while most violated the least privilege principle. The authors rejected the idea that stacking machine-learning guardrails amounts to a defense. “Merely stacking ML models does not constitute true defense-in-depth,” they wrote, because the guard models “often share the same statistical failure modes as the primary agents they monitor.” To put the principles into practice, the authors proposed three security mechanisms, each tied to an open research problem the community has yet to solve. The first is separating instructions from data, because language models mix the two in a single stream of tokens with no source-level distinction between them. The second is verifiable least-privilege policy generation, made difficult because security policies for agents are written in natural language and shift as a task evolves, which makes them hard to translate into rules a system can enforce. The third is information flow control, since tracking how sensitive data moves through a model remains unsolved. Beyond the model The paper challenges one of the dominant assumptions shaping enterprise AI-security efforts over the past two years — that increasingly capable models, alignment techniques, and prompt defenses would eventually make AI systems sufficiently secure for enterprise deployment. Instead, the researchers argue AI agents should increasingly be treated more like operating environments or distributed systems than conventional enterprise applications because they combine reasoning, autonomy, memory persistence, and external tool execution inside a single operational layer. “Security guarantees cannot emerge solely from better prompts, alignment tuning, or model-side mitigations,” the paper said, arguing enterprises instead need stronger runtime isolation, containment boundaries, least-privilege execution, and workflow observability controls around AI agents. That creates situations where prompt injection is no longer simply a content-manipulation issue but potentially a workflow-execution and systems-integrity problem capable of influencing downstream actions across interconnected enterprise environments. The visibility problem The researchers also argue that current enterprise security tooling lacks sufficient runtime visibility into how AI agents actually reason, invoke tools, retain memory, and execute actions across enterprise systems. Another paper published last week also points to a similar problem from a different angle, arguing that traditional endpoint detection and response platforms cannot adequately inspect AI-agent reasoning flows, prompt chains, memory interactions, or dynamic tool execution. The paper proposed what researchers described as an “agentic detection and response or ADR” framework designed specifically for AI-agent environments. “Current security tools are not designed to observe agent cognition or reasoning traces,” the researchers wrote, arguing that existing enterprise security stacks were built to monitor deterministic applications and endpoint activity — not systems capable of autonomous planning, probabilistic reasoning, and dynamic workflow orchestration. The paper described a production deployment monitoring more than 10,000 AI-agent sessions daily across roughly 7,200 hosts, where researchers said the framework identified hundreds of credential-exposure incidents and other agent-related risks spanning 26 attack categories. On a benchmark the team introduced, called ADR-Bench, the system detected 67% of attacks with zero false positives, outperforming three baselines, including Meta’s LlamaFirewall, by two to four times in F1-score, the paper said. On AgentDojo, a public prompt injection benchmark, it detected all attacks with three false alarms out of 93 tasks. View the full article

As AI coding assistants accelerate software development, one OWASP-backed open-source project is arguing that dependency security tooling still arrives too late to be truly useful. CVE Lite CLI, a JavaScript and TypeScript dependency vulnerability scanner focused on local lockfile analysis, is positioning itself around a simple idea. Developers should see dependency risks while they are still writing code, not hours later inside a failing CI pipeline. “What developers are missing is early feedback at the point where the dependency decision is made,” Sonu Kapoor, creator and maintainer of the project, told CSO. According to Kapoor, traditional CI-centric workflows often disconnect developers from the dependency choices that introduced risk in the first place. CVE Lite CLI scans npm, pnpm, and Yarn lockfiles using OSV vulnerability data and claims to focus heavily on remediation guidance, including separating direct and transitive vulnerabilities, validating upgrade targets, and recommending actionable fix paths. The project is being pitched as a “local-first” developer tool, as opposed to a replacement for enterprise software composition analysis (SCA) platforms, much like how developers already use ESLint or unit tests locally before CI runs them again later. CVE Lite CLI targets an overlooked pain point CVE Lite CLI is essentially trying to solve a workflow problem, Kapoor says many developers quietly struggle with. Dependency security checks often arrive after the work is already done. “I integrated CVE Lite CLI into HexOps because it solves a very practical problem in JavaScript security: developers do not just need a list of vulnerable packages, they need to understand what introduced them, whether the issue is direct or transitive, and what version actually resolves it,” said Aaron Lamb, founder of Hexaxia Labs. “CVE Lite gave HexOps a local, lockfile-based source of truth for dependency remediation, which made it a natural fit for the security workflow we are building.” CVE Lite CLI scans JavaScript and TypeScript lockfiles locally across npm, pnpm, and Yarn projects, so developers can understand dependency risk while they are still coding, not later in response to a failing CI pipeline. Instead of just focusing on detection, the tool claims to look into subsequent questions like whether the issue is direct or transitive, whether there is a clean upgrade path, or whether upgrading one package actually removes the vulnerable dependency. “In one real case, CVE Lite CLI skipped 27 package versions before finding a safer version to recommend,” Kapoor said, explaining the granularity of the tool. “That is the kind of work developers should not have to do manually by reading logs and retrying upgrades one by one.” Kapoor said the tool can be configured for JSON, SARIF, or HTML outputs and can also be integrated into CI workflows as a GitHub Action. AI could be making things worse The argument arrives as software supply chain security continues to collide with AI-assisted development practices that allow developers to generate code, integrate packages, and restructure projects much faster than before. Kapoor said this velocity changes the nature of dependency risk itself. “AI coding assistants have made this more important, not less,” he said. “That speed is useful, but it also means dependency decisions can happen quickly and sometimes without the same level of manual review. I do not think AI assistants remove the need for security checks.” On the contrary, they increase the need for fast, local, explainable checks that can be run while the work is happening, he added. One cited example involved scans against lint-staged, a widely used JavaScript tooling package. According to Kapoor, a standard “npm audit –omit=dev” workflow failed to surface a production dependency issue that CVE Lite CLI later identified through lockfile analysis. “Honestly, I don’t think most developers understand those blind spots in detail, and I do not mean that as criticism of developers,” he said. “The dependency graph in a modern JavaScript project is extremely noisy.” A developer meaning to install one direct dependency may end up with hundreds or thousands of transitive packages. CVE Lite CLI isn’t falling for AI The project also deliberately avoids turning itself into a broader AppSec platform, despite growing industry pressure to consolidate security tooling into an AI-enabled ecosystem. “I do think security tooling has become too heavy for the day-to-day developer workflow,” Kapoor said. “That does not mean those platforms are bad. It means they often serve security organizations better than they serve the individual developer trying to make a safe dependency decision during a normal coding session.” This philosophy also extends to the project’s approach toward AI itself. While CVE Lite CLI includes integrations that help AI coding assistants interpret scan results, Kapoor said the underlying vulnerability analysis intentionally remains deterministic. “I do not think AI should decide whether a CVE exists,” he said. “That part needs to be boring, repeatable, and auditable.” Instead, the project uses AI as what the founder described as an “explanation and workflow layer” around scan results rather than as the scanner itself. “CVE Lite CLI includes AI assistant skills that teach tools like Claude Code, Codex CLI, Gemini CLI, Cursor, and GitHub Copilot how to run CVE Lite CLI, read its structured output, and help the developer understand or prioritize the remediation plan,” Kapoor explained. Caution around expansion Kapoor said he has been receiving positive feedback from the companies and developers using CVE Lite CLI in real workflows, asking him whether the same approach could support .NET or Python ecosystems. “What stood out to me most is its practical workflow impact; it provides developers with dependency-risk feedback early in the process, before findings become CI or release blockers,” said Anupam Nandan, senior manager for cybersecurity at EY. “Additionally, it makes results much easier to act on by clearly distinguishing between direct and transitive risks and providing specific remediation guidance. This is critical because security findings only create value when teams can truly understand them and move efficiently toward a fix.” According to Kapoor, developer feedback highlights that the local-first, remediation-oriented model is resonating beyond the original JavaScript and TypeScript use case. “But I am cautious about expanding the current tool too broadly.” The explanation he gave was simple. Each ecosystem, he believes, has its own package manager behavior, lockfile format, dependency graph semantics, advisory sources, and remediation patterns. “Adding those directly into CVE Lite CLI could make the tool heavier and less clear for the JavaScript and TypeScript developers it was originally designed to help.” The project has now been adopted into the OWASP foundation ecosystem as an official OWASP project and is available for free to developers on GitHub. View the full article

As AI coding assistants accelerate software development, one OWASP-backed open-source project is arguing that dependency security tooling still arrives too late to be truly useful. CVE Lite CLI, a JavaScript and TypeScript dependency vulnerability scanner focused on local lockfile analysis, is positioning itself around a simple idea. Developers should see dependency risks while they are still writing code, not hours later inside a failing CI pipeline. “What developers are missing is early feedback at the point where the dependency decision is made,” Sonu Kapoor, creator and maintainer of the project, told CSO. According to Kapoor, traditional CI-centric workflows often disconnect developers from the dependency choices that introduced risk in the first place. CVE Lite CLI scans npm, pnpm, and Yarn lockfiles using OSV vulnerability data and claims to focus heavily on remediation guidance, including separating direct and transitive vulnerabilities, validating upgrade targets, and recommending actionable fix paths. The project is being pitched as a “local-first” developer tool, as opposed to a replacement for enterprise software composition analysis (SCA) platforms, much like how developers already use ESLint or unit tests locally before CI runs them again later. CVE Lite CLI targets an overlooked pain point CVE Lite CLI is essentially trying to solve a workflow problem, Kapoor says many developers quietly struggle with. Dependency security checks often arrive after the work is already done. The tool scans JavaScript and TypeScript lockfiles locally across npm, pnpm, and Yarn projects, so developers can understand dependency risk while they are still coding, not later in response to a failing CI pipeline. Instead of just focusing on detection, the tool claims to look into subsequent questions like whether the issue is direct or transitive, whether there is a clean upgrade path, or whether upgrading one package actually removes the vulnerable dependency. “In one real case, CVE Lite CLI skipped 27 package versions before finding a safer version to recommend,” Kapoor said, explaining the granularity of the tool. “That is the kind of work developers should not have to do manually by reading logs and retrying upgrades one by one.” Kapoor said the tool can be configured for JSON, SARIF, or HTML outputs and can also be integrated into CI workflows as a GitHub Action. AI could be making things worse The argument arrives as software supply chain security continues to collide with AI-assisted development practices that allow developers to generate code, integrate packages, and restructure projects much faster than before. Kapoor said this velocity changes the nature of dependency risk itself. “AI coding assistants have made this more important, not less,” he said. “That speed is useful, but it also means dependency decisions can happen quickly and sometimes without the same level of manual review. I do not think AI assistants remove the need for security checks.” On the contrary, they increase the need for fast, local, explainable checks that can be run while the work is happening, he added. One cited example involved scans against lint-staged, a widely used JavaScript tooling package. According to Kapoor, a standard “npm audit –omit=dev” workflow failed to surface a production dependency issue that CVE Lite CLI later identified through lockfile analysis. “Honestly, I don’t think most developers understand those blind spots in detail, and I do not mean that as criticism of developers,” he said. “The dependency graph in a modern JavaScript project is extremely noisy.” A developer meaning to install one direct dependency may end up with hundreds or thousands of transitive packages. CVE Lite CLI isn’t falling for AI The project also deliberately avoids turning itself into a broader AppSec platform, despite growing industry pressure to consolidate security tooling into an AI-enabled ecosystem. “I do think security tooling has become too heavy for the day-to-day developer workflow,” Kapoor said. “That does not mean those platforms are bad. It means they often serve security organizations better than they serve the individual developer trying to make a safe dependency decision during a normal coding session.” This philosophy also extends to the project’s approach toward AI itself. While CVE Lite CLI includes integrations that help AI coding assistants interpret scan results, Kapoor said the underlying vulnerability analysis intentionally remains deterministic. “I do not think AI should decide whether a CVE exists,” he said. “That part needs to be boring, repeatable, and auditable.” Instead, the project uses AI as what the founder described as an “explanation and workflow layer” around scan results rather than as the scanner itself. “CVE Lite CLI includes AI assistant skills that teach tools like Claude Code, Codex CLI, Gemini CLI, Cursor, and GitHub Copilot how to run CVE Lite CLI, read its structured output, and help the developer understand or prioritize the remediation plan,” Kapoor explained. Caution around expansion Kapoor said he has been receiving positive feedback from the companies and developers using CVE Lite CLI in real workflows, asking him whether the same approach could support .NET or Python ecosystems. “That interest is encouraging because it tells me the local-first, remediation-oriented model is resonating beyond the original JavaScript and TypeScript use case,” he said. “But I am cautious about expanding the current tool too broadly.” The explanation he gave was simple. Each ecosystem, he believes, has its own package manager behavior, lockfile format, dependency graph semantics, advisory sources, and remediation patterns. “Adding those directly into CVE Lite CLI could make the tool heavier and less clear for the JavaScript and TypeScript developers it was originally designed to help.” The project has now been adopted into the OWASP foundation ecosystem as an official OWASP project and is available for free to developers on GitHub. View the full article

If you were hit by ransomware tomorrow, would you pay to get your data back? That’s what more than half of CISOs in a recent survey said their organization would do. It’s a situation more companies are going to face in future. “Attacks are increasing and continuing to increase,” said Christy Wyatt, CEO of security vendor Absolute Software, which commissioned the survey. “Companies are better prepared to deal with them: Some of the training is paying off and AI is helping. But remember that attackers have all the tools that defenders have.” In the survey of 750 CISOs in the US and UK, 58% said their organization would be willing to pay to end a ransomware incident. This flies in the face of advice from the authorities in both countries. “It is the UK government’s long-standing position, alongside law enforcement partners, that it does not encourage, endorse nor condone the payment of ransom demands,” said a spokeswoman for the UK National Cyber Security Centre. The FBI, too, warns not to give in to ransomware demands, noting that paying only encourages the perpetrators to attack others. Another reasons law enforcers advise enterprises not to pay is that there is no guarantee they will get their data back if they do. Given the risks, and the disapproval of law enforcement, how many of those CISOs who say they are willing to pay would do so if it came to the crunch? It’s hard to get firm statistics because of the perceived stigma, but the evidence suggests a significant number do so. Among those companies hit by ransomware, 37% paid the ransom, according to an IDC survey last year, but IDC research director for security services David Clemente suspects the proportion is higher. “I’m sure that there are many more who have paid it but don’t want to be open about it,” he said. That wasn’t the end of things for all who paid the ransom, though: about 5% of them found that “the decryption was incomplete,” according to IDC. A late 2025 survey from insurance provider Hiscox found that only 60% of SMEs that paid a ransom successfully recovered all or part of their data as a result. Absolute’s Wyatt warned, “You may get your data back, you may not.” And if you do get your data back, that doesn’t mean you’re the only one who has it: “We have heard instances of companies paying up and finding that their credentials are being shared,” she said. So, does that mean enterprises shouldn’t pay the ransom? IDC looked at that and found that companies that had planned for such attacks would be able to resist — but with ill effects. About 29 percent of companies were able to recover encrypted files from backup,” said Clemente. “However, 33% of companies that didn’t pay, found that they could not recover anything.” UK retailer M&S didn’t pay up when it was hit by ransomware in April 2025, disrupting internal logistics systems and forcing it to close its online store for months. It estimated the cost of the incident at $400 million in lost operating profit. The ransomware payment dilemma remains an issue for CISOs, but the lesson M&S may point to is that, if a ransomware attack happens, your best bet may be to pay the ransom unless you have confidence in the quality and robustness of your backup. Government and law enforcement may not like it, but they won’t be the ones facing the wrath of shareholders. View the full article

Chromium — the open-source browser that underpins Google Chrome, Microsoft Edge, and Opera, among others — contains an unpatched vulnerability that attackers can exploit to execute JavaScript code persistently across browser restarts. As a result, the flaw can be used to hijack users’ browsers for distributed denial-of-service attacks, run crypto miners, and more. The vulnerability was reported over three years ago by independent researcher Lyra Rebane and remained unfixed, or at least parts of it. The bug report was made public this week but was then closed again after Rebane reported on Mastodon that the flaw is still not properly fixed. The bug tracker entry that contains the technical details was accessible long enough to be archived by users, and a copy can be easily found online even though the original entry is now set to private again. The flaw abuses the Service Worker feature and the Background Fetch API, which allows websites to initiate downloads in the background, such as a video. This feature was introduced in 2018 and Google said at the time: “If the user closes pages to your site after step 1, that’s ok, the download will continue. Because the fetch is highly visible and easily abortable, there isn’t the privacy concern of a way-too-long background sync task. Because the service worker isn’t constantly running, there isn’t the concern that it could abuse the system, such as mining bitcoin in the background.” Rabane found that neither of those promises are true, at least not on all platforms and not on all Chromium-based browsers. For example, in the stable Google Chrome version at the time, in December 2022, the download was visible in the download bar, but in the canary version that introduced a new UI, the download seemed like a glitch being stuck at 0B and not showing the source. On Microsoft Edge, the Download dropdown menu appeared but nothing was shown on it. In the most recent version, the background download is completely invisible and will continue even when the browser is closed. “Generally a Service Worker has a limited lifespan, but the PoC [proof-of-concept exploit] bypasses that by creating and aborting background fetches every 20 seconds once the Service Worker is active,” Rabane wrote in her vulnerability report. “If the background fetch is created and aborted fast enough, it won’t show up in the browser UI at all, but will still keep the Service Worker active.” From the comments in the bug entry, the UI aspects were fixed at some point in January 2023. However, the ability to keep the service worker alive indefinitely by toggling between events would have required a deeper fix, including changing the specification for the API to introduce a hard time limit for quitting the service worker. The things a malicious website could do via a persistent service worker are limited, but they can be serious, including persistent user tracking, as service workers have access to browser open timestamps, IP addresses, and User-Agent info. The exploit can also be used to execute remote JavaScript payloads, which can be leveraged in a variety of ways, including to execute potential exploits for future bugs, side-channel attacks, or WebAssemply payloads like crypto miners. It’s also possible to trigger requests to other websites, which could be abused in a distributed denial-of-service scenario if a compromised website is used to hijack thousands of browsers in this way. View the full article

The FBI has warned of the danger from anew wave of phishing attacks generated by a tool called Kali365. It enables cyber criminals to obtain Microsoft 365 access tokens and bypass multi-factor authentication (MFA) protocols without intercepting the user’s credentials by capturing Oauth tokens linked to the victim’s Microsoft 365 account. The scam works in a similar way to most phishing attacks. An attacker sends an email purporting to be from a trusted cloud document sharing service, including instructions to enter a particular code on a legitimate Microsoft site. The code, however, authorizes the attacker’s device to access the victim’s Microsoft account. The FBI has issued a set of instructions for IT security managers to help mitigate the Kali365 attack before it affects their users. These include creating a conditional access policy to block code flow for all users, with exceptions for the necessary business processes. Managers should also block authentication transfer policies, preventing users from handing over their access rights from a corporate PC to a mobile device. Phishing remains a major threat for organizations. According to a World Economic Forum report from January this year, CEOs worldwide see it as the main security threat. It’s also something that is not going away, 77 percent of organizations think that the number of phishing attacks has increased in the past year. Kali365 has just added to that number. View the full article

European authorities have cracked down on a VPN that has been used for various criminal activities. The operation, led by investigators in France and the Netherlands with help from Europol and Eurojust, has dismantled First VPN, a service that has been heavily promoted within Russia as a way of evading law enforcement. Criminals used it to conceal their identities and infrastructure while carrying out ransomware attacks, large-scale fraud, data theft, and other serious offences. While First VPN’s fates seems well-deserved, there are concerns about wider attempts by governments and law enforcers to clamp down on users of VPN services. Various legislations have tried to implement new laws restricting access to the internet, in particular, those seeking to limit minors from accessing social media and other sites deemed inappropriate by authorities. Australia has already brought in such a law and the UK is looking to follow suit. However. VPNs providers have fought back, claiming that their offerings are a vital tool in the preservation of the internet as a free and open service — and in securing regular business activities for many enterprises. Ina recent blog post Mozilla said, “Blunt interventions like mandatory age assurance and restricting access to tools like VPNs are not effective in improving the protection afforded to young people online, while undermining the fundamental rights of all users.” Any restrictions against VPNs in the US are likely to fall foul of the First Amendment. Attempts by lawmakers to prohibit their use, such as the one proposed in Utah, are looking unlikely to succeed. This article first appeared on Computerworld. View the full article

Microsoft is testing the addition of agentic AI to its corporate browser, Edge for Business.A new version, currently available in a limited preview, will help perform routine tasks more efficiently, according to Microsoft’s partner product manager for Edge, Lindsay Kubasik. Agentic AI will help with completing multi-step tasks such as filling in forms, navigating sites, or gathering information from different tabs, all using enterprise-managed tools, the company said. And a new tab page will pull together calendar entries, files and Copilot prompts, reducing the need to switch between tools, it said. A key feature of the new browser version will be its ability to protect corporate data. Enterprises will be able to block the use of copy and paste, and all AI prompts and responses will stay within their Microsoft 365 tenant and will not be used to train models, the company said. They will also be able to audit prompts and block sensitive uploads. The protections will apply as soon as users sign into Edge for Business. Enterprises will be able to keep track of users who are not following policy: Microsoft’s compliance tool, Purview, will analyze all file uploads to check for sensitive data being uploaded. Enterprises will then have the ability to block the action. To access the new features, enterprises must sign up for the limited preview. This article first appeared on Computerworld. View the full article

I spent two days at a substation connecting a major offshore wind farm to the grid. The control room featured three new AI-ready dashboards and a board mandate to “leverage machine learning for resilience.” It also had a maintenance laptop running Windows 7, literally taped to the inside of a cabinet because the Velcro had failed. That laptop was the only device in the building that could still talk to the legacy protection relays guarding the grid connection. No patches since 2017. No EDR. No path to an agent-based security model. I have walked into some version of this scene at energy utilities, automotive plants and pharma sites across sectors and borders for a decade. The dashboards change; the “forgotten” laptop stays. This is the massive visibility gap that no Large Language Model can close. According to the 2026 Dragos OT Cybersecurity Year in Review, fewer than 10 percent of OT networks worldwide currently have meaningful network monitoring in place. In 30 percent of last year’s incident response cases, investigations started not with a detection alert, but with someone on the plant floor noticing that “something seemed wrong.” If you are a C-level leader planning an AI-driven security strategy, you need to realize: your strategy won’t fail because the AI isn’t smart enough. It will fail because your most critical telemetry never reaches it. The inverted CIA triad: Where AI hallucinates risk In IT, we prioritize confidentiality, integrity and availability. In OT — operational technology — the triad is flipped: availability is everything. This inversion is where AI-driven security tools quietly break. A model trained on enterprise telemetry — HTTP, DNS and Windows event logs — will look at a Modbus or PROFINET segment and flag perfectly normal industrial traffic as an anomaly. If that AI is wired into an automated response playbook, you’ve built a system that can shut down a production line faster than any hacker. During a simulation I conducted for a Tier-1 automotive supplier, I watched a SOAR platform attempt exactly this. The IT lead was thrilled by the “millisecond response time.” The plant manager went gray as he realized the AI had just simulated a six-figure-per-hour downtime event by isolating a critical PLC. In the industrial world, an automated “isolate host” command is often indistinguishable from a denial-of-service attack. Passive monitoring vs. poking the controller When I have evaluated OT monitoring platforms like Nozomi Networks, Claroty or Microsoft Defender for IoT, the technical differences often mattered less than one critical question: does this tool require active queries? In a boardroom, “active scanning” sounds efficient. In a running plant, poking a 15-year-old Siemens S7-300 or a Rockwell Automation controller to extract metadata can cause the device to crash. I’ve seen half a shortlist eliminated because the vendors’ AI engines required active polling that the operations director refused to sign off on. For AI to work in OT, it must be fed by passive network monitoring. You need the raw traffic from Level 0–2 of the Purdue Enterprise Reference Architecture, the layered model that defines the boundary between IT and OT systems. Without that telemetry, you are performing language modeling on an empty corpus. You aren’t seeing the S7Comm or DNP3 protocols that actually manage the physical world. The crown jewels are simpler than you think The projects I see succeed don’t start with a 300-page AI roadmap. They start with a ruthless focus on what I call the crown jewels. I always ask plant managers the same question: which three processes can you absolutely not afford to lose for even an hour? At a power utility, it’s not the billing system; it’s the protection relays. At a pharma site, it’s a single fermentation line. At an automotive plant, it’s the welding cell that feeds the entire body shop. Once you identify these, the AI scope collapses from “everything” to “the things that matter.” We then apply virtual patching to protect the unpatchable Windows 7 machines and segment the network so the smart coffee machine in the breakroom — which receives more security updates than the industrial robots — cannot reach the human-machine interface. Here is the part that surprises most CIOs: the crown-jewel list is almost always shorter than the security team predicts and almost always longer than the operations team admits. At one site I worked with last year, security had counted 47 “critical” systems on a spreadsheet. The plant director, after twenty minutes of honest conversation, named six. The other 41 were important, but they were not crown jewels. They didn’t need real-time AI-driven anomaly detection. They needed monthly compliance reporting. Conflating those two requirements is how OT security budgets get burned without measurable risk reduction. The culture shift: From phishing to physics The most productive workshop I ran this year didn’t involve a single AI vendor. It was a tabletop exercise tracing a ransomware path from a phishing email to a contractor’s USB stick, then into the maintenance laptop and finally the PLCs. We mapped it minute by minute. Minute zero: a procurement clerk opens an invoice attachment. Minute eight: the malware reaches the contractor’s laptop on the office network. Minute fourteen: the contractor plugs the same laptop into the maintenance VLAN to update HMI firmware, just as he does every Tuesday. Minute twenty-three: the ransomware encrypts the engineering workstation. Minute thirty-one: the operators notice the screens going dark, but production keeps running on the PLCs themselves — because OT controllers don’t need Windows to do their job. The illusion of normality holds for almost an hour. Then someone tries to push a setpoint change, and nothing happens. That was the moment that changed the room. The production head had spent the morning asking why we needed yet another security project. Now he was asking how long until they could actually detect minute eight, before the contractor’s laptop ever touched the maintenance network. The IT lead, who had defended his “patch Tuesday at 2 a.m.” ritual for years, finally understood why that ritual is an impossibility in a facility that runs 24/7. Different vocabularies, same problem. For the first time in any meeting at that site, an OT manager and an IT manager left the room with a shared incident timeline rather than a shared blame map. That’s what culture change in industrial security actually looks like — not a policy document, but a tabletop with enough specificity that nobody can hide behind their own jargon. Bottom line for CIOs and CSOs With nation-state actors like Volt Typhoon increasingly using “living off the land” techniques to embed themselves in critical infrastructure, as detailed in recent CISA advisories, the luxury of ignoring the factory floor is gone. AI can help us find these threats, but only if the telemetry is real. If you want AI to deliver real business value in industrial environments, the order of operations is non-negotiable. First, inventory: map the floor, not the slides. Second, segmentation: kill the routes from the breakroom to the PLC. Third, passive telemetry: feed the AI with real industrial protocols from Purdue Levels 0–2. Then, and only then, layer the language model on top. Skip these, and you’ve built a very expensive dashboard for a network you still cannot see. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

The “retro” way “The thing about the old days is… they are the old days” – Slim Charles, The Wire Protecting a specified network perimeter was the main focus of enterprise security strategy for several decades. Businesses made significant investments in firewalls, intrusion detection systems, endpoint security and segmentation controls, all of which were built on the premise that an organization would stay safe if attackers were prevented from accessing the network. In a time when users, infrastructure and applications were mostly confined within well-defined borders, that assumption made sense but in today’s world, that environment no longer exists. The proliferation of cloud computing, SaaS usage, hybrid work practices, microservices and API-driven connections have fundamentally transformed the structure of enterprise IT. Critical systems are now located outside conventional data centers and employees now authenticate outside trusted networks in BYOD scenarios. Vendors also integrate directly into internal systems, which means that identity is the most important control plane in modern settings. Modern threat actors are no longer primarily burrowing through hidden technical flaws or circumventing perimeter measures in dramatic fashion; those were the old days. In recent times, they log in with stolen credentials, replayed session tokens or misused access grants. The ensuing breach may resemble legitimate user behavior because, from a system perspective, that is exactly what it is – “a legitimate user trying to sign in to carry out legitimate activities“. This modern reality necessitates a rethinking of how cybersecurity leaders perceive risk. The dissolution of the perimeter As organizational workloads moved to the cloud, authentication became the key to accessing practically everything important: financial systems, collaboration platforms, customer data, intellectual property and administrative controls. Access is mediated less by network location than by identity assertions and authorization regulations, particularly in highly federated contexts. If an attacker successfully impersonates a trusted identity, many traditional safeguards offer minimal resistance with single sign-on systems that span several authentication planes. Security programs that continue to prioritize perimeter resilience without making equal investments in identity integrity are effectively defending yesterday’s threat model and will get left behind. This is because there has been a shift from asking questions about if threat actors can reach a network to asking if they can steal, manipulate or abuse identities that the system typically trusts. What modern day breaches actually exploit Consistent themes emerge from an examination of contemporary breach patterns. Initial access often results from credential stuffing attacks using previously used passwords, OAuth consent phishing that offers application-level permissions, adversary-in-the-middle frameworks that intercept authentication flows, or phishing efforts that harvest credentials. These attack methods do not use zero-day exploits nor sophisticated malware in many cases as they exploit weaknesses in how identities are verified and how sessions are managed. Once in the environment, attackers use poorly monitored service accounts, excessive privileges or incorrectly configured role assignments to advance laterally after authentication. Opportunities for persistence are created by service accounts with broad permissions, but little control and sessions can also be replayed, no thanks to token sessions that are independent of device context. Here, breaches occur as a result of manipulation of trust relationships ingrained in identity systems. MFA limitations An essential and significant advancement in enterprise security was made with the broad use of multi-factor authentication. The idea that multi-factor authentication (MFA) has definitively resolved identity compromise, however, is more a reflection of overconfidence than of reality. In reality, protection offered and authentication strength depends heavily on implementation details and type. Push-based MFA can be manipulated through MFA fatigue tactics, in which repeated prompts pressure users into approving malicious requests. Adversary-in-the-middle kits proxy authentication flows in real time, capturing session cookies after successful MFA validation with some phishing kits like Starkiller using live pages in recent times as against static ones which can easily be detected. OAuth-based phishing circumvents password-centric safeguards altogether by convincing users to provide application authorization and users can be socially engineered to go through with this. Privilege as the multiplier of damage Initial access does not always result in disastrous consequences as what the identity that has been compromised is permitted to do determines how serious a breach is. Regrettably, many businesses have a big permission debt that has been built up over years of convenience-driven choices. Some practices are typically seen in IT environments; broadly assigned privileged roles which are infrequently reviewed, temporary access granted for operational expediency may never be revoked and service accounts sometimes retain expansive rights without adequate monitoring as mentioned above. These practices create environments in which a single compromised credential can expose sensitive data, disrupt operations or enable financial fraud. The principle of least privilege (POLP) is widely endorsed across the industry, yet it remains unevenly implemented in practice. Establishing just-in-time access models, enforcing approval-based privilege elevation and conducting continuous access reviews demand sustained coordination between security teams, IT operations and business stakeholders, which can be operationally complex and “politically” sensitive. However, without this discipline, a single compromised identity can carry far greater impact than necessary. Identity security therefore extends well beyond authentication mechanics and must be treated as a governance issue rooted in deliberate, consistently enforced privilege management. Elevating identity monitoring to a core security function With Extended Detection and Response (EDR) solutions, many companies have advanced their endpoint detection and network monitoring capabilities; yet, identity-related telemetry frequently receives relatively less attention, and it is becoming more and more difficult to defend this disparity. Early indicators of compromise such as anomalous login behavior, impossible or atypical travel patterns, suspicious mailbox rules, unusual OAuth grants and rapid privilege escalations frequently provide early indicators of compromise. Understandably, organizations are focused on ransomware attacks, data exfiltration and leakages, however, these identity-based signals must be collected, correlated and acted upon with the same seriousness and deftness as malware detections. If thresholds are misconfigured or alerts are treated as secondary noise, identity-based attacks can persist undetected while appearing operationally normal. Given that valid credentials are now central to many breach scenarios, identity logs should be treated as primary forensic evidence rather than supplementary context. Security operations centers that elevate identity monitoring to a strategic priority are better positioned to detect and contain misuse before it escalates. Realigning security investment around identity risk The allocation of resources and executive supervision are affected when identity is identified as the main attack surface. Since they constitute the fundamental defensive architecture of a cloud-first enterprise, investments in more robust authentication techniques, hardware-backed credentials, conditional access policies that take contextual risk signals into account, and strict privilege management frameworks should not be seen as incremental enhancements. The congruence of business procedures and security controls is equally significant. Identity compromise must be seen as a possibility in financial workflows, administrative approvals and vendor integrations. Processes that are designed with enforced verification, separation of duties and anomaly detection in mind further reduce the possibility that a single credential will cause disproportionate harm Conclusion To conclude, where risk lies has been subtly reshaped by the development of enterprise IT and the use of cloud and hybrid environments. Decisions about authorization and authentication now have to be taken on a daily basis to safeguard the most important assets. When those choices are subject to manipulation or abuse, the repercussions affect not just individual accounts but spill over across the enterprise. Exploiting the trust that businesses have built into identity systems is more common in modern breaches than dramatic technical intrusions as previously discussed. Operationally, identity must be treated as the main attack surface and companies who acknowledge this reality and design their environments appropriately will be more equipped to handle the current threat landscape, rather than the one they initially intended to protect. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article