CSOonline

The US authorities NSA, FBI, and CISA warn that Russian hackers have recently carried out a number of attacks on critical infrastructure in North America and Europe. Hackers are reportedly breaking into networks using vulnerable and misconfigured routers, making it extra important to install the latest security patches. The most vulnerable are infrastructure related to energy, communications, healthcare, industry, the economy, and defense. Authorities in Australia, the UK, Canada, New Zealand, Estonia, Finland, France, and Italy support the warning, reports Bleeping Computer. View the full article

RabbitMQ has patched two access control vulnerabilities affecting the widely used open-source message broker that could expose enterprise application data and, in some deployments, allow attackers to gain complete control over the messaging infrastructure. The flaws, discovered by Miggo Security, exposed OAuth secrets to unauthenticated attackers, letting low-privileged users potentially spy on other tenants. “RabbitMQ is the plumbing that moves data between services inside modern applications: orders, payments, authentication events, internal notifications,” Miggo researchers explained in a report shared with CSO ahead of its publication on Monday. “RabbitMQ is downloaded more than 15 million times a year, and the scale makes it a high-value target.” Affecting RabbitMQ releases dating back to version 3.13.0, introduced in early 2024, the flaws have now been fixed in all supported versions. Obsolete endpoint leaked OAuth configurations The more severe issue, tracked as CVE-2026-57219, allows anyone with network access to RabbitMQ’s management interface to receive the broker’s OAuth client secret without authentication. The flaw stems from an obsolete management endpoint “GET/api/auth” that returned RabbitMQ’s OAuth configuration, which includes the broker’s confidential OAuth client secret, to anyone who queried it. In deployments using confidential OAuth clients with providers such as Microsoft Entra ID, Auth0, Keycloak, or UAA, attackers could exchange the leaked secret for an administrator token and gain complete control over the broker. The problem was assigned a high severity score of CVSS 8.7 out of 10, and was fixed in the versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6. RabbitMQ reportedly addressed the issue by removing the obsolete endpoint altogether, instead delivering OAuth configuration through an authenticated bootstrap mechanism that no longer exposes the client secret over HTTP. According to Miggo, successful exploitation could allow attackers to access or modify messages, create users, alter broker configuration, and effectively compromise the messaging layer supporting enterprise applications. The company recommended organizations to upgrade immediately, rotate any exposed OAuth client secrets after patching, and ensure the management interface is never exposed to untrusted networks. Broadcom, whose Tanzu division maintains RabbitMQ, did not immediately respond to CSO’s request for comment. Authorization bypass for reconnaissance The second vulnerability, CVE-2026-57221, is an authorization bypass affecting RabbitMQ’s passive queue and exchange declaration operations. Although attackers need valid credentials for exploitation, even accounts with no assigned permissions can discover whether queues and exchanges exist and retrieve metadata such as message counts and active consumers because the permission check is skipped. Miggo noted the flaw does not expose message contents or allow tampering, but it can leak valuable operational intelligence in shared environments. Attackers could map applications, monitor workload activity, and gather reconnaissance for subsequent attacks against other tenants sharing the same virtual host, the researchers added. RabbitMQ fixed the issue by ensuring passive queue and exchange declarations now enforce the same authorization checks as other operations. Because there is no configuration workaround or WAF mitigation for this flaw, organizations were advised to upgrade to a patched release and isolate tenants into separate virtual hosts until patching can be completed. Miggo said the vulnerabilities are the first CVEs discovered by its autonomous security research platform, VulnHunter, before being validated by its security team and disclosed to RabbitMQ maintainers, who reportedly confirmed the issues and released patches. View the full article

RabbitMQ has patched two access control vulnerabilities affecting the widely used open-source message broker that could expose enterprise application data and, in some deployments, allow attackers to gain complete control over the messaging infrastructure. The flaws, discovered by Miggo Security, exposed OAuth secrets to unauthenticated attackers, letting low-privileged users potentially spy on other tenants. “RabbitMQ is the plumbing that moves data between services inside modern applications: orders, payments, authentication events, internal notifications,” Miggo researchers explained in a report shared with CSO ahead of its publication on Monday. “RabbitMQ is downloaded more than 15 million times a year, and the scale makes it a high-value target.” Affecting RabbitMQ releases dating back to version 3.13.0, introduced in early 2024, the flaws have now been fixed in all supported versions. Obsolete endpoint leaked OAuth configurations The more severe issue, tracked as CVE-2026-57219, allows anyone with network access to RabbitMQ’s management interface to receive the broker’s OAuth client secret without authentication. The flaw stems from an obsolete management endpoint “GET/api/auth” that returned RabbitMQ’s OAuth configuration, which includes the broker’s confidential OAuth client secret, to anyone who queried it. In deployments using confidential OAuth clients with providers such as Microsoft Entra ID, Auth0, Keycloak, or UAA, attackers could exchange the leaked secret for an administrator token and gain complete control over the broker. The problem was assigned a high severity score of CVSS 8.7 out of 10, and was fixed in the versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6. RabbitMQ reportedly addressed the issue by removing the obsolete endpoint altogether, instead delivering OAuth configuration through an authenticated bootstrap mechanism that no longer exposes the client secret over HTTP. According to Miggo, successful exploitation could allow attackers to access or modify messages, create users, alter broker configuration, and effectively compromise the messaging layer supporting enterprise applications. The company recommended organizations to upgrade immediately, rotate any exposed OAuth client secrets after patching, and ensure the management interface is never exposed to untrusted networks. Broadcom, whose Tanzu division maintains RabbitMQ, did not immediately respond to CSO’s request for comment. Authorization bypass for reconnaissance The second vulnerability, CVE-2026-57221, is an authorization bypass affecting RabbitMQ’s passive queue and exchange declaration operations. Although attackers need valid credentials for exploitation, even accounts with no assigned permissions can discover whether queues and exchanges exist and retrieve metadata such as message counts and active consumers because the permission check is skipped. Miggo noted the flaw does not expose message contents or allow tampering, but it can leak valuable operational intelligence in shared environments. Attackers could map applications, monitor workload activity, and gather reconnaissance for subsequent attacks against other tenants sharing the same virtual host, the researchers added. RabbitMQ fixed the issue by ensuring passive queue and exchange declarations now enforce the same authorization checks as other operations. Because there is no configuration workaround or WAF mitigation for this flaw, organizations were advised to upgrade to a patched release and isolate tenants into separate virtual hosts until patching can be completed. Miggo said the vulnerabilities are the first CVEs discovered by its autonomous security research platform, VulnHunter, before being validated by its security team and disclosed to RabbitMQ maintainers, who reportedly confirmed the issues and released patches. View the full article

Jurassic Park wasn’t really about dinosaurs. It was about arrogant people building systems they believed were controllable. “Life finds a way” is probably the most famous line from the entire franchise. Ian Malcolm’s warning that no matter how sophisticated the technology becomes, no matter how expensive the fences are, and no matter how confident the operators feel, nature eventually escapes containment. And in every movie, it does. The dinosaurs always get out. The systems fail. Eventually, the humans lose control. What makes Jurassic Park fascinating is that despite advanced monitoring, complex containment systems and sophisticated operational controls, the outcome never really changes. At its core, the story is about people mistaking visibility for control. Cybersecurity has the same problem. For years, security teams have operated under the assumption that with enough tooling, governance, process, maturity and spend, we can build environments that are effectively secure. Maybe not perfect, but secure enough that compromise becomes rare and manageable. But attackers find a way. Given enough time, skill or motivation, they eventually identify the weakness nobody considered. The overlooked privilege. The dependency nobody mapped. The misconfiguration hiding behind layers of dashboards, process, and compliance reporting. We are already seeing this play out. Nation-state attacks are becoming increasingly sophisticated, while AI-driven exploit discovery is beginning to compress vulnerability research from weeks into minutes. The raptors are learning faster now. Mistaking visibility for control That does not mean prevention no longer matters. The fences in Jurassic Park still slowed the dinosaurs down. They created friction. They reduced exposure. Modern security controls do the same thing. But the failure in Jurassic Park was never simply that the fences broke. It was that the entire system assumed the fences represented certainty. Cybersecurity often makes the same mistake. The industry has become incredibly good at demonstrating preparedness in controlled environments. Dashboards. Compliance reports. Tabletop exercises. RTO metrics. Recovery attestations. Jurassic Park had dashboards too. The problem is that visibility is often mistaken for survivability. Organizations can prove they monitored the environment, documented the process, and ran the exercise, while still having very little confidence that the business could continue operating during a genuine systemic failure. Most organizations still operate with an implicit belief that compromise is exceptional rather than inevitable. Disaster recovery plans, business continuity workshops, and annual tabletop exercises are treated as evidence of resilience. In reality, many of them are carefully controlled simulations of a world that no longer exists. Traditional disaster recovery was designed for an era where infrastructure changed slowly, applications were relatively static, and dependencies were limited enough that recovery assumptions could remain valid for months or even years. That world is gone. AI killed it. Environments now evolve constantly. Cloud infrastructure changes daily. AI-assisted development accelerates release cycles. Applications rely on sprawling third-party ecosystems. APIs connect systems in ways many organizations do not fully understand. Entire workloads appear and disappear dynamically. The environment you tested last quarter may no longer exist today. And yet many resilience programs still operate as if annual or quarterly testing provides meaningful confidence. Most companies do not really test resilience. They test optimism. The backup fallacy And nowhere is this overconfidence more obvious than backups. Somewhere along the way, organizations confused “having backups” with “being resilient.” Those are not remotely the same thing. A backup simply proves you stored a copy of something at a specific point in time. It does not prove you can survive. Most recovery models were designed in the late 90s and early 2000s for relatively static systems and predictable infrastructure. The core philosophy has barely evolved since then, even as environments have become increasingly distributed, ephemeral, and interconnected. Restoring data is not the same as restoring operations. Restoring infrastructure is not the same as restoring business functionality. Modern application are complex and rely on ephemeral elements, third party components and applications as well as complex data flows not just data sets. Very few organizations continuously validate whether they can recover full feature-function applications, maintain operational workflows, preserve data integrity, reconnect dependencies, restore permissions correctly, or continue operating under active attack conditions. We built incredibly sophisticated telemetry for understanding how we die. We built almost none for proving we can survive. That gap is becoming impossible to ignore. The recent rise of continuous resilience testing and recovery validation is not accidental. It reflects a growing realization that recovery assumptions themselves may no longer be trustworthy. Static resilience models are struggling to survive dynamic infrastructure. This is where resilience starts becoming an engineering problem rather than a compliance exercise. When restoration assumptions fail Because the real question is no longer, “How quickly can we restore the application?” The real question is, “What happens if we cannot restore it?” Jurassic Park repeatedly explored exactly this scenario. The real panic never started when the fences failed. It started when the operators realized they could not regain control quickly enough. Businesses now face the same risk. What happens if AWS experiences a prolonged outage? What happens if Azure Identity Services fail globally? What happens if Stripe, Salesforce, Slack, or Microsoft 365 disappear for days rather than hours? Many organizations do not actually have business continuity strategies for those situations. They have restoration assumptions. Twenty years ago, most organizations directly owned large portions of their operational stack. Today, companies increasingly rent critical business capability from a relatively small number of providers. Identity. Infrastructure. Communications. Payments. Collaboration. Customer operations. The efficiency gains are enormous. So is the concentration risk. Resilience as an engineering discipline Historically, business continuity planning assumed localized disruption. A building burned down. A regional data center failed. A storm impacted an office. The internet itself was not the dependency. Today, entire businesses are built on tightly interconnected SaaS and cloud ecosystems where operational survivability depends on third parties remaining continuously available. We optimized organizations for efficiency, automation, integration, and scale. Not necessarily survivability. That is why resilience needs to evolve beyond annual tabletop exercises and static recovery plans. True resilience is not a binder sitting on a shelf. It is not a workshop performed once a year. It is not a recovery document written against an environment that changed six months ago. It is a continuous understanding of the environment itself. It requires live telemetry, operational visibility, dependency awareness, continuous validation, and the ability to adapt under changing conditions. Adapting to chaos The survivors in Jurassic Park only succeeded once they stopped pretending the environment was fully controllable and instead adapted to the reality in front of them. Cybersecurity needs to make the same shift. Attackers will keep adapting. AI will accelerate faster than most governance models can handle. Complexity will continue to outpace our assumptions about control. The organizations that survive will not necessarily be the ones with the tallest fences. They will be the ones who understand their environments deeply enough to continue operating when control is lost. The goal was never to eliminate chaos. It was to survive long enough to adapt to it. Because resilience is not about preventing chaos. It is about operating through it. Because eventually, one way or another, life finds a way. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Jurassic Park wasn’t really about dinosaurs. It was about arrogant people building systems they believed were controllable. “Life finds a way” is probably the most famous line from the entire franchise. Ian Malcolm’s warning that no matter how sophisticated the technology becomes, no matter how expensive the fences are, and no matter how confident the operators feel, nature eventually escapes containment. And in every movie, it does. The dinosaurs always get out. The systems fail. Eventually, the humans lose control. What makes Jurassic Park fascinating is that despite advanced monitoring, complex containment systems and sophisticated operational controls, the outcome never really changes. At its core, the story is about people mistaking visibility for control. Cybersecurity has the same problem. For years, security teams have operated under the assumption that with enough tooling, governance, process, maturity and spend, we can build environments that are effectively secure. Maybe not perfect, but secure enough that compromise becomes rare and manageable. But attackers find a way. Given enough time, skill or motivation, they eventually identify the weakness nobody considered. The overlooked privilege. The dependency nobody mapped. The misconfiguration hiding behind layers of dashboards, process, and compliance reporting. We are already seeing this play out. Nation-state attacks are becoming increasingly sophisticated, while AI-driven exploit discovery is beginning to compress vulnerability research from weeks into minutes. The raptors are learning faster now. Mistaking visibility for control That does not mean prevention no longer matters. The fences in Jurassic Park still slowed the dinosaurs down. They created friction. They reduced exposure. Modern security controls do the same thing. But the failure in Jurassic Park was never simply that the fences broke. It was that the entire system assumed the fences represented certainty. Cybersecurity often makes the same mistake. The industry has become incredibly good at demonstrating preparedness in controlled environments. Dashboards. Compliance reports. Tabletop exercises. RTO metrics. Recovery attestations. Jurassic Park had dashboards too. The problem is that visibility is often mistaken for survivability. Organizations can prove they monitored the environment, documented the process, and ran the exercise, while still having very little confidence that the business could continue operating during a genuine systemic failure. Most organizations still operate with an implicit belief that compromise is exceptional rather than inevitable. Disaster recovery plans, business continuity workshops, and annual tabletop exercises are treated as evidence of resilience. In reality, many of them are carefully controlled simulations of a world that no longer exists. Traditional disaster recovery was designed for an era where infrastructure changed slowly, applications were relatively static, and dependencies were limited enough that recovery assumptions could remain valid for months or even years. That world is gone. AI killed it. Environments now evolve constantly. Cloud infrastructure changes daily. AI-assisted development accelerates release cycles. Applications rely on sprawling third-party ecosystems. APIs connect systems in ways many organizations do not fully understand. Entire workloads appear and disappear dynamically. The environment you tested last quarter may no longer exist today. And yet many resilience programs still operate as if annual or quarterly testing provides meaningful confidence. Most companies do not really test resilience. They test optimism. The backup fallacy And nowhere is this overconfidence more obvious than backups. Somewhere along the way, organizations confused “having backups” with “being resilient.” Those are not remotely the same thing. A backup simply proves you stored a copy of something at a specific point in time. It does not prove you can survive. Most recovery models were designed in the late 90s and early 2000s for relatively static systems and predictable infrastructure. The core philosophy has barely evolved since then, even as environments have become increasingly distributed, ephemeral, and interconnected. Restoring data is not the same as restoring operations. Restoring infrastructure is not the same as restoring business functionality. Modern application are complex and rely on ephemeral elements, third party components and applications as well as complex data flows not just data sets. Very few organizations continuously validate whether they can recover full feature-function applications, maintain operational workflows, preserve data integrity, reconnect dependencies, restore permissions correctly, or continue operating under active attack conditions. We built incredibly sophisticated telemetry for understanding how we die. We built almost none for proving we can survive. That gap is becoming impossible to ignore. The recent rise of continuous resilience testing and recovery validation is not accidental. It reflects a growing realization that recovery assumptions themselves may no longer be trustworthy. Static resilience models are struggling to survive dynamic infrastructure. This is where resilience starts becoming an engineering problem rather than a compliance exercise. When restoration assumptions fail Because the real question is no longer, “How quickly can we restore the application?” The real question is, “What happens if we cannot restore it?” Jurassic Park repeatedly explored exactly this scenario. The real panic never started when the fences failed. It started when the operators realized they could not regain control quickly enough. Businesses now face the same risk. What happens if AWS experiences a prolonged outage? What happens if Azure Identity Services fail globally? What happens if Stripe, Salesforce, Slack, or Microsoft 365 disappear for days rather than hours? Many organizations do not actually have business continuity strategies for those situations. They have restoration assumptions. Twenty years ago, most organizations directly owned large portions of their operational stack. Today, companies increasingly rent critical business capability from a relatively small number of providers. Identity. Infrastructure. Communications. Payments. Collaboration. Customer operations. The efficiency gains are enormous. So is the concentration risk. Resilience as an engineering discipline Historically, business continuity planning assumed localized disruption. A building burned down. A regional data center failed. A storm impacted an office. The internet itself was not the dependency. Today, entire businesses are built on tightly interconnected SaaS and cloud ecosystems where operational survivability depends on third parties remaining continuously available. We optimized organizations for efficiency, automation, integration, and scale. Not necessarily survivability. That is why resilience needs to evolve beyond annual tabletop exercises and static recovery plans. True resilience is not a binder sitting on a shelf. It is not a workshop performed once a year. It is not a recovery document written against an environment that changed six months ago. It is a continuous understanding of the environment itself. It requires live telemetry, operational visibility, dependency awareness, continuous validation, and the ability to adapt under changing conditions. Adapting to chaos The survivors in Jurassic Park only succeeded once they stopped pretending the environment was fully controllable and instead adapted to the reality in front of them. Cybersecurity needs to make the same shift. Attackers will keep adapting. AI will accelerate faster than most governance models can handle. Complexity will continue to outpace our assumptions about control. The organizations that survive will not necessarily be the ones with the tallest fences. They will be the ones who understand their environments deeply enough to continue operating when control is lost. The goal was never to eliminate chaos. It was to survive long enough to adapt to it. Because resilience is not about preventing chaos. It is about operating through it. Because eventually, one way or another, life finds a way. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Picture the moment after an AI issue is reported. A security analyst is reviewing a ticket reporting that an internal AI tool produced the wrong recommendation in a live business workflow. The risk is not theoretical anymore. Someone wants to know whether this is a security incident, a model issue, a privacy issue, a vendor issue or just “something the AI did.” The risk register has a line item for inaccurate output, and it may even have a severity rating. What it does not have is an answer to the question everyone is now asking: who has the authority to stop this thing? That is the gap many AI governance programs still need to close. Organizations are getting better at identifying AI risks, documenting them and assigning them to governance categories. What they are often less prepared for is the operational moment when an AI risk becomes a real event that has to be investigated, contained and explained. In security programs, that distinction matters. A risk register can document concerns, but it cannot preserve evidence, notify leadership, assess impact or decide whether an AI system should keep running. Security leaders do not need another spreadsheet that says AI can fail; they need an executable response model for what happens when it does. The list is not the response Risk registers are useful because they create visibility. They help organizations name risks, compare severity, assign ownership and communicate concerns to leadership. In early AI adoption, visibility matters because many organizations are still discovering where AI is being used, what data is involved and which business processes may be affected. But a risk register is not a control. Security teams already understand this in other domains. A list of vulnerabilities is not a vulnerability management program, and a list of third-party risks is not a vendor risk management function. The list is only the beginning of the work. AI risk creates the same problem. A risk entry that says “model output may be inaccurate” does not define who monitors output quality, what level of error is acceptable, what evidence should be preserved or who can pause the system. A risk entry that says “sensitive data may be exposed” does not explain whether prompts are logged, whether outputs are reviewed, whether the vendor can use submitted data or whether the event should trigger privacy, legal or security escalation. This is where AI governance can look stronger than it actually is. The organization may have a policy, a committee, an intake form and a risk register, but those artifacts do not automatically create operational readiness. When something happens, the real test is whether the organization knows what to do next. AI incidents do not always look like breaches Part of the challenge is that AI incidents do not always look like traditional cybersecurity incidents. A breach has familiar patterns: unauthorized access, data exfiltration, malware, credential compromise or suspicious activity in a system. AI failures can be messier because they may appear first as a bad recommendation, a misleading summary, an unsafe automation, a flawed classification or an output that quietly changes a decision. That does not make them less important. An AI tool used in a security workflow could misclassify an alert. A generative AI assistant could expose sensitive information in a response. A model embedded in a business process could drift over time and produce unreliable recommendations. A vendor-managed AI feature could change behavior after an update that the organization did not fully review. Security teams need a practical way to sort these events. Not every AI error should be treated as a full security incident. Still, every organization using AI in meaningful workflows should know how AI-related events are reported, triaged and escalated. Without that structure, teams may lose time debating ownership while the impact continues. The first step is defining what counts as an AI incident. That definition should be broad enough to capture security, privacy, safety, operational and compliance concerns, but specific enough that employees know when to report something. A confusing chatbot answer may not require the same response as a data exposure event, but both should have a path for review. Evidence has to exist before the investigation Incident response depends on evidence. That is obvious in cybersecurity, but it is often overlooked in AI governance conversations. If an organization cannot reconstruct what happened, who used the system, what data was involved and what output was produced, it will struggle to investigate the event or defend its response. AI systems can complicate that evidence trail. Prompts may not be logged. Outputs may not be retained. Vendor tools may provide limited visibility. Model versions may change. Users may copy AI-generated content into other systems without preserving its source. Business teams may treat AI output as a recommendation rather than a system event. Security leaders should push for evidence requirements before AI systems move into production. At a minimum, organizations should know what logs are available, how long they are retained, who can access them and whether they are sufficient for investigation. For higher-risk use cases, teams may also need records of model version, prompt history, output history, user actions, data sources and downstream decisions. This does not mean every AI interaction needs heavy surveillance. Monitoring should be proportional to risk, and organizations still need to respect privacy, legal and workforce considerations. The point is simpler: if the AI system matters enough to influence real work, it matters enough to leave an evidence trail when something goes wrong. Ownership cannot be implied AI ownership is often fragmented. A business unit may sponsor the use case, a data science team may configure the model, IT may manage the platform, security may assess risk, and a vendor may provide the underlying capability. Everyone is involved, but no one may be fully accountable after deployment. That ambiguity becomes dangerous during an incident. If an AI tool begins producing unreliable output, the organization needs to know who owns the system, who owns the business process and who owns the decision to continue or stop use. A governance committee can provide oversight, but it usually cannot serve as the operational owner of every deployed AI capability. Security programs should insist on named ownership for AI systems, especially those used in sensitive or high-impact workflows. Ownership should include responsibility for monitoring, exceptions, user guidance, vendor coordination and incident escalation. It should also include decision rights, because accountability without authority is just a name in a spreadsheet. The hardest question is often pause authority. Who can suspend, restrict, roll back or retire an AI system when risk exceeds tolerance? If that question is not answered before deployment, the organization may be forced to answer it under pressure. Security leaders need an AI response playbook An AI response playbook does not need to be complicated, but it does need to be real. It should explain how employees report AI concerns, how the event is triaged, what evidence is preserved, who investigates, when legal or privacy teams are involved, and who can make operational decisions. It should also define when executive leadership needs to be notified. The playbook should reflect the type of AI system involved. A low-risk internal productivity tool may require a lightweight review path. An AI system supporting security operations, regulated decisions, customer communication, healthcare workflows or financial processes needs stronger monitoring and escalation. The response model should fit the risk of the use case. This is where security can add discipline without turning AI governance into bureaucracy. Security teams already know how to build escalation paths, preserve evidence, run incident reviews and improve controls after failures. The opportunity is to extend that operating muscle into AI governance before incidents force the issue. Organizations should also conduct post-incident reviews for meaningful AI events. The goal should not be blame; it should be learning. Did the monitoring work? Was the owner clear? Was the evidence sufficient? Did the vendor respond? Were users confused about acceptable use? Did the organization know who could make the decision? Governance has to be executable AI governance is often discussed as a policy, ethics or compliance challenge. It is all of those things, but once AI systems enter production, it also becomes a security execution challenge. Risk has to be monitored, events have to be investigated and someone has to be able to act. That is why the next maturity step is not simply better documentation. Organizations need governance that works when a system is live, a decision is time-sensitive and the facts are incomplete. In that moment, the risk register may help explain what the organization expected, but it will not run the response. Security leaders should not wait for AI governance to arrive fully formed from somewhere else in the enterprise. They should help shape the operating model now, while many organizations are still early enough to correct course. The goal is not to own every AI risk; it is to ensure AI risk can be managed once AI becomes operational. A risk register can tell leaders what might go wrong. An incident response plan tells people what to do when it does. For AI governance to matter in security programs, organizations need both. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Picture the moment after an AI issue is reported. A security analyst is reviewing a ticket reporting that an internal AI tool produced the wrong recommendation in a live business workflow. The risk is not theoretical anymore. Someone wants to know whether this is a security incident, a model issue, a privacy issue, a vendor issue or just “something the AI did.” The risk register has a line item for inaccurate output, and it may even have a severity rating. What it does not have is an answer to the question everyone is now asking: who has the authority to stop this thing? That is the gap many AI governance programs still need to close. Organizations are getting better at identifying AI risks, documenting them and assigning them to governance categories. What they are often less prepared for is the operational moment when an AI risk becomes a real event that has to be investigated, contained and explained. In security programs, that distinction matters. A risk register can document concerns, but it cannot preserve evidence, notify leadership, assess impact or decide whether an AI system should keep running. Security leaders do not need another spreadsheet that says AI can fail; they need an executable response model for what happens when it does. The list is not the response Risk registers are useful because they create visibility. They help organizations name risks, compare severity, assign ownership and communicate concerns to leadership. In early AI adoption, visibility matters because many organizations are still discovering where AI is being used, what data is involved and which business processes may be affected. But a risk register is not a control. Security teams already understand this in other domains. A list of vulnerabilities is not a vulnerability management program, and a list of third-party risks is not a vendor risk management function. The list is only the beginning of the work. AI risk creates the same problem. A risk entry that says “model output may be inaccurate” does not define who monitors output quality, what level of error is acceptable, what evidence should be preserved or who can pause the system. A risk entry that says “sensitive data may be exposed” does not explain whether prompts are logged, whether outputs are reviewed, whether the vendor can use submitted data or whether the event should trigger privacy, legal or security escalation. This is where AI governance can look stronger than it actually is. The organization may have a policy, a committee, an intake form and a risk register, but those artifacts do not automatically create operational readiness. When something happens, the real test is whether the organization knows what to do next. AI incidents do not always look like breaches Part of the challenge is that AI incidents do not always look like traditional cybersecurity incidents. A breach has familiar patterns: unauthorized access, data exfiltration, malware, credential compromise or suspicious activity in a system. AI failures can be messier because they may appear first as a bad recommendation, a misleading summary, an unsafe automation, a flawed classification or an output that quietly changes a decision. That does not make them less important. An AI tool used in a security workflow could misclassify an alert. A generative AI assistant could expose sensitive information in a response. A model embedded in a business process could drift over time and produce unreliable recommendations. A vendor-managed AI feature could change behavior after an update that the organization did not fully review. Security teams need a practical way to sort these events. Not every AI error should be treated as a full security incident. Still, every organization using AI in meaningful workflows should know how AI-related events are reported, triaged and escalated. Without that structure, teams may lose time debating ownership while the impact continues. The first step is defining what counts as an AI incident. That definition should be broad enough to capture security, privacy, safety, operational and compliance concerns, but specific enough that employees know when to report something. A confusing chatbot answer may not require the same response as a data exposure event, but both should have a path for review. Evidence has to exist before the investigation Incident response depends on evidence. That is obvious in cybersecurity, but it is often overlooked in AI governance conversations. If an organization cannot reconstruct what happened, who used the system, what data was involved and what output was produced, it will struggle to investigate the event or defend its response. AI systems can complicate that evidence trail. Prompts may not be logged. Outputs may not be retained. Vendor tools may provide limited visibility. Model versions may change. Users may copy AI-generated content into other systems without preserving its source. Business teams may treat AI output as a recommendation rather than a system event. Security leaders should push for evidence requirements before AI systems move into production. At a minimum, organizations should know what logs are available, how long they are retained, who can access them and whether they are sufficient for investigation. For higher-risk use cases, teams may also need records of model version, prompt history, output history, user actions, data sources and downstream decisions. This does not mean every AI interaction needs heavy surveillance. Monitoring should be proportional to risk, and organizations still need to respect privacy, legal and workforce considerations. The point is simpler: if the AI system matters enough to influence real work, it matters enough to leave an evidence trail when something goes wrong. Ownership cannot be implied AI ownership is often fragmented. A business unit may sponsor the use case, a data science team may configure the model, IT may manage the platform, security may assess risk, and a vendor may provide the underlying capability. Everyone is involved, but no one may be fully accountable after deployment. That ambiguity becomes dangerous during an incident. If an AI tool begins producing unreliable output, the organization needs to know who owns the system, who owns the business process and who owns the decision to continue or stop use. A governance committee can provide oversight, but it usually cannot serve as the operational owner of every deployed AI capability. Security programs should insist on named ownership for AI systems, especially those used in sensitive or high-impact workflows. Ownership should include responsibility for monitoring, exceptions, user guidance, vendor coordination and incident escalation. It should also include decision rights, because accountability without authority is just a name in a spreadsheet. The hardest question is often pause authority. Who can suspend, restrict, roll back or retire an AI system when risk exceeds tolerance? If that question is not answered before deployment, the organization may be forced to answer it under pressure. Security leaders need an AI response playbook An AI response playbook does not need to be complicated, but it does need to be real. It should explain how employees report AI concerns, how the event is triaged, what evidence is preserved, who investigates, when legal or privacy teams are involved, and who can make operational decisions. It should also define when executive leadership needs to be notified. The playbook should reflect the type of AI system involved. A low-risk internal productivity tool may require a lightweight review path. An AI system supporting security operations, regulated decisions, customer communication, healthcare workflows or financial processes needs stronger monitoring and escalation. The response model should fit the risk of the use case. This is where security can add discipline without turning AI governance into bureaucracy. Security teams already know how to build escalation paths, preserve evidence, run incident reviews and improve controls after failures. The opportunity is to extend that operating muscle into AI governance before incidents force the issue. Organizations should also conduct post-incident reviews for meaningful AI events. The goal should not be blame; it should be learning. Did the monitoring work? Was the owner clear? Was the evidence sufficient? Did the vendor respond? Were users confused about acceptable use? Did the organization know who could make the decision? Governance has to be executable AI governance is often discussed as a policy, ethics or compliance challenge. It is all of those things, but once AI systems enter production, it also becomes a security execution challenge. Risk has to be monitored, events have to be investigated and someone has to be able to act. That is why the next maturity step is not simply better documentation. Organizations need governance that works when a system is live, a decision is time-sensitive and the facts are incomplete. In that moment, the risk register may help explain what the organization expected, but it will not run the response. Security leaders should not wait for AI governance to arrive fully formed from somewhere else in the enterprise. They should help shape the operating model now, while many organizations are still early enough to correct course. The goal is not to own every AI risk; it is to ensure AI risk can be managed once AI becomes operational. A risk register can tell leaders what might go wrong. An incident response plan tells people what to do when it does. For AI governance to matter in security programs, organizations need both. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

At Amazon Web Services (AWS), artificial intelligence is already compressing security work that once took months into minutes. In the old world, human red teams would find vulnerabilities, write reports, refine those reports, and eventually hand them to defenders, who would then begin building detections or fixes, Steve Schmidt, chief security officer at Amazon, tells CSO. That process could take “two, four, six, eight, 10 months,” Schmidt says. “Now with proper application of AI, we can have the detections built for the problems the red team finds in 15 minutes-ish,” he says. “I think the outside is about four hours.” That kind of workflow offers a glimpse of what AI could make possible for the most sophisticated security organizations: AI agents testing systems, other agents generating defenses, and human security engineers validating results and refining the feedback loop. But it also raises a more uncomfortable question for the rest of the cybersecurity industry: What happens to organizations that cannot build anything close to that? The concern has become significant enough that the Trump administration recently directed agencies to expand access to AI-enabled cybersecurity capabilities for resource-constrained organizations, including rural hospitals, community banks, and local utilities. The order reflects a growing fear that AI could deepen a divide that has existed in cybersecurity for years: the divide between organizations with money, expertise, and engineering depth, and those struggling to keep pace with basic security demands. Yet security leaders and practitioners suggest the impact of AI will be more complicated than a simple widening gap. Some experts say AI is merely adding a new layer to a long-standing security poverty problem. Others argue AI could democratize capabilities once reserved for elite organizations. Still others see today’s divide as real, but potentially temporary, as models become cheaper, more open, and easier to run. The class divide was already here For Matt Warner, co-founder and CEO of Blumira, the premise that AI is creating a cybersecurity class divide misses a key point: The divide already exists. “I would go even a step further and say that there has been a class divide for the last 10 to 15 years,” Warner tells CSO. What AI changes, he argues, is not necessarily the existence of the divide but how stark it becomes. Larger organizations have money, people, and time to experiment with AI. Smaller organizations often do not. “The big differences that we’re seeing, especially from where we sit in the world, is the difference is getting starker in having the resources to leverage AI and the time to leverage AI more than anything else,” Warner says. That distinction matters because many smaller organizations are already overwhelmed. Warner pointed to resource-constrained local governments and small or midmarket organizations that are still far behind large enterprises in basic IT and security maturity. “I can find you a county in Michigan with two IT people for 2,000 employees,” Warner says. “Those people don’t have time to leverage AI and even learn how to use AI because they’re mostly just trying to put out fires.” That problem is not unique to AI. Smaller organizations have long struggled to patch systems, prioritize vulnerabilities, monitor environments, and respond to incidents with limited staff. AI may help eventually, but only if those organizations have enough capacity to adopt it. Wendy Nather’s framework gets an AI layer Anton Chuvakin, security advisor in the office of the CISO for Google Cloud, sees the AI divide as part of a much older problem. “I feel like it sends me back to when Wendy Nather invented the security poverty line,” Chuvakin tells CSO, referring to Nather’s 2011 concept describing organizations that lack the money, expertise, capability, or influence to implement effective security. Chuvakin is skeptical that AI fundamentally changes that model. “I don’t think AI necessarily breaks that model,” he says. “I think it just adds another dimension.” Cybersecurity has always been shaped by unequal access to top talent, tools, and services, Chuvakin argues. Large organizations could afford better SIEM deployments, advanced DLP programs, threat hunters, application security experts, and incident response retainers. Smaller organizations often could not. AI may become another scarce resource, but Chuvakin cautions against overstating the role of model cost alone. In his view, the bigger structural issue may be talent rather than tokens. “Prices for people won’t drop, but prices for LLMs may drop,” he believes. That means the organizations with the greatest advantage may not simply be those that can afford the most expensive models. They may be the ones that can afford the people who know how to use them — and, as the frontier-access debate below suggests, that talent gap may prove more durable than any gap in model access itself. AI creates new costs — and new uncertainties Nather herself, now senior research initiatives director at 1Password, sees AI affecting every dimension of the security poverty line: money, expertise, capability, and influence. The financial challenges are not limited to whether an organization can pay for an AI tool. In some cases, organizations that cannot afford enterprise licensing may end up making tradeoffs around privacy. “If an organization can’t afford an enterprise license for the models they’re using, then they can’t keep their data private,” Nather tells CSO. “So, they have to give up privacy because they can’t afford privacy.” That’s a new twist on an old dimension of the poverty line: It’s not just that under-resourced organizations lack a capability, but that the capability they can afford comes bundled with a risk wealthier organizations don’t have to accept. Token-based pricing adds another problem: unpredictability. “At this point, nobody knows how much they’re going to burn in tokens at any given time,” she says. That makes budgeting difficult for organizations that cannot absorb surprise costs. Nather also warns that usage-based pricing is controlled by providers and can change over time, leaving customers with limited leverage. “The charging practice is in the hands of the providers, and they can change it at any time,” she says. For organizations already operating below the security poverty line, that uncertainty could make AI adoption harder, even if the technology itself becomes more capable. Access to frontier models may be a temporary divide Dave Baggett, SVP/GM of the security suite at Kaseya, agrees there is security class divide dynamic playing out today, particularly around access to frontier models. “There’s definitely a haves and have-nots issue around Mythos specifically because most people don’t have it,” Baggett tells CSO. But he doesn’t think the divide will have a long-term impact. Open-weight models, quantization, mixture-of-experts architectures, and increasingly powerful commodity hardware, he argues, are closing the gap faster than most people expect. While not every organization will build a frontier model, he says, more organizations may be able to run capable models locally or use cheaper systems that approximate what today’s elite models can do. “What it says for finding vulnerabilities is at that point, open-source people can run this stuff,” Baggett says. “Then you’re back to having a symmetrical opportunity where the defenders who are writing the open source can run the same tools the attackers would and have them fix the issues.” His bottom line is that the divide may be real but short-lived. “Right now, there certainly is a have, have-not schism, but it may not be there for long,” Baggett says — a view Chuvakin shares, though he frames it in terms of the model market rather than open source specifically. “I don’t think it’s the lowering prices example, but it’s more like you’re a top-tier model maker, I’m a second-tier model maker. My model in a year would do what your model did a year ago,” Chuvakin says. The real advantage is operational depth Schmidt’s description of AI use at AWS points to another kind of divide: not access to AI, but the ability to operationalize it. AWS uses multiple models for different tasks, Schmidt says. One model may discover vulnerabilities, while other models validate results or help build defenses. Humans remain accountable for evaluating what the systems produce. “Because we believe really strongly in human accountability for the use of AI from end to end, we still have humans take a look at what the systems come up with to determine whether they are reasonable and appropriate,” he says. That workflow requires more than a model. It requires corporate data, secure infrastructure, feedback loops, security engineers, data scientists, and AI specialists who can work together. Schmidt also pushes back on the idea that running AI locally on powerful consumer hardware is a substitute for production-grade security infrastructure. “Often the value of the model is also dependent on its proximity to data so that the model can ingest, use, and reason about data,” he says. “As a security person, I do not want that to be on your laptop.” Experimentation on a laptop is useful, Schmidt says, but it is not the same as a secure production environment. “I want the data to be somewhere safe that I can control, that I can see, that I can reason about, not sitting on your laptop,” he says. “Experimentation in there, awesome. That’s great. But it is not a production infrastructure component.” That distinction may define the emerging AI security gap. Many organizations may be able to access AI tools. Far fewer may be able to safely integrate them into real security workflows. The democratization argument Phil Venables, a partner at Ballistic Ventures and former CISO of Google Cloud, takes the most optimistic view. Asked whether AI is widening the gap between well-resourced and under-resourced security organizations, Venables tells CSO, “No, I actually think it’s the exact opposite.” The reason, he argues, is that AI packages expertise and automation in ways that can be delivered broadly. “One of the fantastic things about AI, and we’re already starting to see this, is [that it’s] a great democratizer of capabilities,” he says. “AI packages up expertise and automation capabilities at a level beyond what prior waves of technology have done, and it makes it available at scale into organizations that have not previously been able to afford these things.” He points to red teaming as an example. Nearly every organization would like a world-class red team, but few can afford one. “Pretty much every organization on the planet would love to have a world-class red team to constantly test their security to find and fix things before attackers do,” Venables says. “But very few organizations have ever been able to afford to build a high-end red team.” AI agents, he argues, could make that kind of capability available more economically. The same pattern could apply to insider threat; third-party risk; software security; governance, risk and compliance; and security operations. “So even the smallest and resource-constrained organizations can now have access to a higher-end capability,” he maintains. Venables does see a danger zone, however: under-resourced security teams inside organizations with aggressive AI ambitions. Those teams may struggle to keep up as the rest of the business adopts AI rapidly. But for many small and midsize organizations, he believes AI could improve access to security capabilities they never had before. A divide over AI — or over readiness? For elite organizations, AI is already becoming a force multiplier. Security teams with deep engineering talent, mature data infrastructure, and strong governance can use AI to accelerate testing, detection engineering, vulnerability discovery, and risk management. For smaller organizations, the picture is less clear. AI may eventually package scarce expertise into affordable services. Open models may reduce dependence on expensive frontier systems. But organizations below the security poverty line still face familiar constraints: too few people, too little time, limited expertise, unpredictable costs, and weak leverage over vendors. The emerging divide may therefore be less about who has access to AI and more about who can turn AI into durable security outcomes. That makes the question facing cybersecurity more complicated than whether AI will create haves and have-nots. The industry already had them. The real question is whether AI becomes another technology that rewards the organizations already best positioned to use it — or the first major security advance in years that helps those below the poverty line finally catch up. View the full article

At Amazon Web Services (AWS), artificial intelligence is already compressing security work that once took months into minutes. In the old world, human red teams would find vulnerabilities, write reports, refine those reports, and eventually hand them to defenders, who would then begin building detections or fixes, Steve Schmidt, chief security officer at AWS, tells CSO. That process could take “two, four, six, eight, 10 months,” Schmidt says. “Now with proper application of AI, we can have the detections built for the problems the red team finds in 15 minutes-ish,” he says. “I think the outside is about four hours.” That kind of workflow offers a glimpse of what AI could make possible for the most sophisticated security organizations: AI agents testing systems, other agents generating defenses, and human security engineers validating results and refining the feedback loop. But it also raises a more uncomfortable question for the rest of the cybersecurity industry: What happens to organizations that cannot build anything close to that? The concern has become significant enough that the Trump administration recently directed agencies to expand access to AI-enabled cybersecurity capabilities for resource-constrained organizations, including rural hospitals, community banks, and local utilities. The order reflects a growing fear that AI could deepen a divide that has existed in cybersecurity for years: the divide between organizations with money, expertise, and engineering depth, and those struggling to keep pace with basic security demands. Yet security leaders and practitioners suggest the impact of AI will be more complicated than a simple widening gap. Some experts say AI is merely adding a new layer to a long-standing security poverty problem. Others argue AI could democratize capabilities once reserved for elite organizations. Still others see today’s divide as real, but potentially temporary, as models become cheaper, more open, and easier to run. The class divide was already here For Matt Warner, co-founder and CEO of Blumira, the premise that AI is creating a cybersecurity class divide misses a key point: The divide already exists. “I would go even a step further and say that there has been a class divide for the last 10 to 15 years,” Warner tells CSO. What AI changes, he argues, is not necessarily the existence of the divide but how stark it becomes. Larger organizations have money, people, and time to experiment with AI. Smaller organizations often do not. “The big differences that we’re seeing, especially from where we sit in the world, is the difference is getting starker in having the resources to leverage AI and the time to leverage AI more than anything else,” Warner says. That distinction matters because many smaller organizations are already overwhelmed. Warner pointed to resource-constrained local governments and small or midmarket organizations that are still far behind large enterprises in basic IT and security maturity. “I can find you a county in Michigan with two IT people for 2,000 employees,” Warner says. “Those people don’t have time to leverage AI and even learn how to use AI because they’re mostly just trying to put out fires.” That problem is not unique to AI. Smaller organizations have long struggled to patch systems, prioritize vulnerabilities, monitor environments, and respond to incidents with limited staff. AI may help eventually, but only if those organizations have enough capacity to adopt it. Wendy Nather’s framework gets an AI layer Anton Chuvakin, security advisor in the office of the CISO for Google Cloud, sees the AI divide as part of a much older problem. “I feel like it sends me back to when Wendy Nather invented the security poverty line,” Chuvakin tells CSO, referring to Nather’s 2011 concept describing organizations that lack the money, expertise, capability, or influence to implement effective security. Chuvakin is skeptical that AI fundamentally changes that model. “I don’t think AI necessarily breaks that model,” he says. “I think it just adds another dimension.” Cybersecurity has always been shaped by unequal access to top talent, tools, and services, Chuvakin argues. Large organizations could afford better SIEM deployments, advanced DLP programs, threat hunters, application security experts, and incident response retainers. Smaller organizations often could not. AI may become another scarce resource, but Chuvakin cautions against overstating the role of model cost alone. In his view, the bigger structural issue may be talent rather than tokens. “Prices for people won’t drop, but prices for LLMs may drop,” he believes. That means the organizations with the greatest advantage may not simply be those that can afford the most expensive models. They may be the ones that can afford the people who know how to use them — and, as the frontier-access debate below suggests, that talent gap may prove more durable than any gap in model access itself. AI creates new costs — and new uncertainties Nather herself, now senior research initiatives director at 1Password, sees AI affecting every dimension of the security poverty line: money, expertise, capability, and influence. The financial challenges are not limited to whether an organization can pay for an AI tool. In some cases, organizations that cannot afford enterprise licensing may end up making tradeoffs around privacy. “If an organization can’t afford an enterprise license for the models they’re using, then they can’t keep their data private,” Nather tells CSO. “So, they have to give up privacy because they can’t afford privacy.” That’s a new twist on an old dimension of the poverty line: It’s not just that under-resourced organizations lack a capability, but that the capability they can afford comes bundled with a risk wealthier organizations don’t have to accept. Token-based pricing adds another problem: unpredictability. “At this point, nobody knows how much they’re going to burn in tokens at any given time,” she says. That makes budgeting difficult for organizations that cannot absorb surprise costs. Nather also warns that usage-based pricing is controlled by providers and can change over time, leaving customers with limited leverage. “The charging practice is in the hands of the providers, and they can change it at any time,” she says. For organizations already operating below the security poverty line, that uncertainty could make AI adoption harder, even if the technology itself becomes more capable. Access to frontier models may be a temporary divide Dave Baggett, SVP/GM of the security suite at Kaseya, agrees there is security class divide dynamic playing out today, particularly around access to frontier models. “There’s definitely a haves and have-nots issue around Mythos specifically because most people don’t have it,” Baggett tells CSO. But he doesn’t think the divide will have a long-term impact. Open-weight models, quantization, mixture-of-experts architectures, and increasingly powerful commodity hardware, he argues, are closing the gap faster than most people expect. While not every organization will build a frontier model, he says, more organizations may be able to run capable models locally or use cheaper systems that approximate what today’s elite models can do. “What it says for finding vulnerabilities is at that point, open-source people can run this stuff,” Baggett says. “Then you’re back to having a symmetrical opportunity where the defenders who are writing the open source can run the same tools the attackers would and have them fix the issues.” His bottom line is that the divide may be real but short-lived. “Right now, there certainly is a have, have-not schism, but it may not be there for long,” Baggett says — a view Chuvakin shares, though he frames it in terms of the model market rather than open source specifically. “I don’t think it’s the lowering prices example, but it’s more like you’re a top-tier model maker, I’m a second-tier model maker. My model in a year would do what your model did a year ago,” Chuvakin says. The real advantage is operational depth Schmidt’s description of AI use at AWS points to another kind of divide: not access to AI, but the ability to operationalize it. AWS uses multiple models for different tasks, Schmidt says. One model may discover vulnerabilities, while other models validate results or help build defenses. Humans remain accountable for evaluating what the systems produce. “Because we believe really strongly in human accountability for the use of AI from end to end, we still have humans take a look at what the systems come up with to determine whether they are reasonable and appropriate,” he says. That workflow requires more than a model. It requires corporate data, secure infrastructure, feedback loops, security engineers, data scientists, and AI specialists who can work together. Schmidt also pushes back on the idea that running AI locally on powerful consumer hardware is a substitute for production-grade security infrastructure. “Often the value of the model is also dependent on its proximity to data so that the model can ingest, use, and reason about data,” he says. “As a security person, I do not want that to be on your laptop.” Experimentation on a laptop is useful, Schmidt says, but it is not the same as a secure production environment. “I want the data to be somewhere safe that I can control, that I can see, that I can reason about, not sitting on your laptop,” he says. “Experimentation in there, awesome. That’s great. But it is not a production infrastructure component.” That distinction may define the emerging AI security gap. Many organizations may be able to access AI tools. Far fewer may be able to safely integrate them into real security workflows. The democratization argument Phil Venables, a partner at Ballistic Ventures and former CISO of Google Cloud, takes the most optimistic view. Asked whether AI is widening the gap between well-resourced and under-resourced security organizations, Venables tells CSO, “No, I actually think it’s the exact opposite.” The reason, he argues, is that AI packages expertise and automation in ways that can be delivered broadly. “One of the fantastic things about AI, and we’re already starting to see this, is [that it’s] a great democratizer of capabilities,” he says. “AI packages up expertise and automation capabilities at a level beyond what prior waves of technology have done, and it makes it available at scale into organizations that have not previously been able to afford these things.” He points to red teaming as an example. Nearly every organization would like a world-class red team, but few can afford one. “Pretty much every organization on the planet would love to have a world-class red team to constantly test their security to find and fix things before attackers do,” Venables says. “But very few organizations have ever been able to afford to build a high-end red team.” AI agents, he argues, could make that kind of capability available more economically. The same pattern could apply to insider threat; third-party risk; software security; governance, risk and compliance; and security operations. “So even the smallest and resource-constrained organizations can now have access to a higher-end capability,” he maintains. Venables does see a danger zone, however: under-resourced security teams inside organizations with aggressive AI ambitions. Those teams may struggle to keep up as the rest of the business adopts AI rapidly. But for many small and midsize organizations, he believes AI could improve access to security capabilities they never had before. A divide over AI — or over readiness? For elite organizations, AI is already becoming a force multiplier. Security teams with deep engineering talent, mature data infrastructure, and strong governance can use AI to accelerate testing, detection engineering, vulnerability discovery, and risk management. For smaller organizations, the picture is less clear. AI may eventually package scarce expertise into affordable services. Open models may reduce dependence on expensive frontier systems. But organizations below the security poverty line still face familiar constraints: too few people, too little time, limited expertise, unpredictable costs, and weak leverage over vendors. The emerging divide may therefore be less about who has access to AI and more about who can turn AI into durable security outcomes. That makes the question facing cybersecurity more complicated than whether AI will create haves and have-nots. The industry already had them. The real question is whether AI becomes another technology that rewards the organizations already best positioned to use it — or the first major security advance in years that helps those below the poverty line finally catch up. View the full article

At Amazon Web Services (AWS), artificial intelligence is already compressing security work that once took months into minutes. In the old world, human red teams would find vulnerabilities, write reports, refine those reports, and eventually hand them to defenders, who would then begin building detections or fixes, Steve Schmidt, chief security officer at AWS, tells CSO. That process could take “two, four, six, eight, 10 months,” Schmidt says. “Now with proper application of AI, we can have the detections built for the problems the red team finds in 15 minutes-ish,” he says. “I think the outside is about four hours.” That kind of workflow offers a glimpse of what AI could make possible for the most sophisticated security organizations: AI agents testing systems, other agents generating defenses, and human security engineers validating results and refining the feedback loop. But it also raises a more uncomfortable question for the rest of the cybersecurity industry: What happens to organizations that cannot build anything close to that? The concern has become significant enough that the Trump administration recently directed agencies to expand access to AI-enabled cybersecurity capabilities for resource-constrained organizations, including rural hospitals, community banks, and local utilities. The order reflects a growing fear that AI could deepen a divide that has existed in cybersecurity for years: the divide between organizations with money, expertise, and engineering depth, and those struggling to keep pace with basic security demands. Yet security leaders and practitioners suggest the impact of AI will be more complicated than a simple widening gap. Some experts say AI is merely adding a new layer to a long-standing security poverty problem. Others argue AI could democratize capabilities once reserved for elite organizations. Still others see today’s divide as real, but potentially temporary, as models become cheaper, more open, and easier to run. The class divide was already here For Matt Warner, co-founder and CTO of Blumira, the premise that AI is creating a cybersecurity class divide misses a key point: The divide already exists. “I would go even a step further and say that there has been a class divide for the last 10 to 15 years,” Warner tells CSO. What AI changes, he argues, is not necessarily the existence of the divide but how stark it becomes. Larger organizations have money, people, and time to experiment with AI. Smaller organizations often do not. “The big differences that we’re seeing, especially from where we sit in the world, is the difference is getting starker in having the resources to leverage AI and the time to leverage AI more than anything else,” Warner says. That distinction matters because many smaller organizations are already overwhelmed. Warner pointed to resource-constrained local governments and small or midmarket organizations that are still far behind large enterprises in basic IT and security maturity. “I can find you a county in Michigan with two IT people for 2,000 employees,” Warner says. “Those people don’t have time to leverage AI and even learn how to use AI because they’re mostly just trying to put out fires.” That problem is not unique to AI. Smaller organizations have long struggled to patch systems, prioritize vulnerabilities, monitor environments, and respond to incidents with limited staff. AI may help eventually, but only if those organizations have enough capacity to adopt it. Wendy Nather’s framework gets an AI layer Anton Chuvakin, security advisor in the office of the CISO for Google Cloud, sees the AI divide as part of a much older problem. “I feel like it sends me back to when Wendy Nather invented the security poverty line,” Chuvakin tells CSO, referring to Nather’s 2011 concept describing organizations that lack the money, expertise, capability, or influence to implement effective security. Chuvakin is skeptical that AI fundamentally changes that model. “I don’t think AI necessarily breaks that model,” he says. “I think it just adds another dimension.” Cybersecurity has always been shaped by unequal access to top talent, tools, and services, Chuvakin argues. Large organizations could afford better SIEM deployments, advanced DLP programs, threat hunters, application security experts, and incident response retainers. Smaller organizations often could not. AI may become another scarce resource, but Chuvakin cautions against overstating the role of model cost alone. In his view, the bigger structural issue may be talent rather than tokens. “Prices for people won’t drop, but prices for LLMs may drop,” he believes. That means the organizations with the greatest advantage may not simply be those that can afford the most expensive models. They may be the ones that can afford the people who know how to use them — and, as the frontier-access debate below suggests, that talent gap may prove more durable than any gap in model access itself. AI creates new costs — and new uncertainties Nather herself, now senior research initiatives director at 1Password, sees AI affecting every dimension of the security poverty line: money, expertise, capability, and influence. The financial challenges are not limited to whether an organization can pay for an AI tool. In some cases, organizations that cannot afford enterprise licensing may end up making tradeoffs around privacy. “If an organization can’t afford an enterprise license for the models they’re using, then they can’t keep their data private,” Nather tells CSO. “So, they have to give up privacy because they can’t afford privacy.” That’s a new twist on an old dimension of the poverty line: It’s not just that under-resourced organizations lack a capability, but that the capability they can afford comes bundled with a risk wealthier organizations don’t have to accept. Token-based pricing adds another problem: unpredictability. “At this point, nobody knows how much they’re going to burn in tokens at any given time,” she says. That makes budgeting difficult for organizations that cannot absorb surprise costs. Nather also warns that usage-based pricing is controlled by providers and can change over time, leaving customers with limited leverage. “The charging practice is in the hands of the providers, and they can change it at any time,” she says. For organizations already operating below the security poverty line, that uncertainty could make AI adoption harder, even if the technology itself becomes more capable. Access to frontier models may be a temporary divide Dave Baggett, SVP/GM of the security suite at Kaseya, agrees there is security class divide dynamic playing out today, particularly around access to frontier models. “There’s definitely a haves and have-nots issue around Mythos specifically because most people don’t have it,” Baggett tells CSO. But he doesn’t think the divide will have a long-term impact. Open-weight models, quantization, mixture-of-experts architectures, and increasingly powerful commodity hardware, he argues, are closing the gap faster than most people expect. While not every organization will build a frontier model, he says, more organizations may be able to run capable models locally or use cheaper systems that approximate what today’s elite models can do. “What it says for finding vulnerabilities is at that point, open-source people can run this stuff,” Baggett says. “Then you’re back to having a symmetrical opportunity where the defenders who are writing the open source can run the same tools the attackers would and have them fix the issues.” His bottom line is that the divide may be real but short-lived. “Right now, there certainly is a have, have-not schism, but it may not be there for long,” Baggett says — a view Chuvakin shares, though he frames it in terms of the model market rather than open source specifically. “I don’t think it’s the lowering prices example, but it’s more like you’re a top-tier model maker, I’m a second-tier model maker. My model in a year would do what your model did a year ago,” Chuvakin says. The real advantage is operational depth Schmidt’s description of AI use at AWS points to another kind of divide: not access to AI, but the ability to operationalize it. AWS uses multiple models for different tasks, Schmidt says. One model may discover vulnerabilities, while other models validate results or help build defenses. Humans remain accountable for evaluating what the systems produce. “Because we believe really strongly in human accountability for the use of AI from end to end, we still have humans take a look at what the systems come up with to determine whether they are reasonable and appropriate,” he says. That workflow requires more than a model. It requires corporate data, secure infrastructure, feedback loops, security engineers, data scientists, and AI specialists who can work together. Schmidt also pushes back on the idea that running AI locally on powerful consumer hardware is a substitute for production-grade security infrastructure. “Often the value of the model is also dependent on its proximity to data so that the model can ingest, use, and reason about data,” he says. “As a security person, I do not want that to be on your laptop.” Experimentation on a laptop is useful, Schmidt says, but it is not the same as a secure production environment. “I want the data to be somewhere safe that I can control, that I can see, that I can reason about, not sitting on your laptop,” he says. “Experimentation in there, awesome. That’s great. But it is not a production infrastructure component.” That distinction may define the emerging AI security gap. Many organizations may be able to access AI tools. Far fewer may be able to safely integrate them into real security workflows. The democratization argument Phil Venables, a partner at Ballistic Ventures and former CISO of Google Cloud, takes the most optimistic view. Asked whether AI is widening the gap between well-resourced and under-resourced security organizations, Venables tells CSO, “No, I actually think it’s the exact opposite.” The reason, he argues, is that AI packages expertise and automation in ways that can be delivered broadly. “One of the fantastic things about AI, and we’re already starting to see this, is [that it’s] a great democratizer of capabilities,” he says. “AI packages up expertise and automation capabilities at a level beyond what prior waves of technology have done, and it makes it available at scale into organizations that have not previously been able to afford these things.” He points to red teaming as an example. Nearly every organization would like a world-class red team, but few can afford one. “Pretty much every organization on the planet would love to have a world-class red team to constantly test their security to find and fix things before attackers do,” Venables says. “But very few organizations have ever been able to afford to build a high-end red team.” AI agents, he argues, could make that kind of capability available more economically. The same pattern could apply to insider threat; third-party risk; software security; governance, risk and compliance; and security operations. “So even the smallest and resource-constrained organizations can now have access to a higher-end capability,” he maintains. Venables does see a danger zone, however: under-resourced security teams inside organizations with aggressive AI ambitions. Those teams may struggle to keep up as the rest of the business adopts AI rapidly. But for many small and midsize organizations, he believes AI could improve access to security capabilities they never had before. A divide over AI — or over readiness? For elite organizations, AI is already becoming a force multiplier. Security teams with deep engineering talent, mature data infrastructure, and strong governance can use AI to accelerate testing, detection engineering, vulnerability discovery, and risk management. For smaller organizations, the picture is less clear. AI may eventually package scarce expertise into affordable services. Open models may reduce dependence on expensive frontier systems. But organizations below the security poverty line still face familiar constraints: too few people, too little time, limited expertise, unpredictable costs, and weak leverage over vendors. The emerging divide may therefore be less about who has access to AI and more about who can turn AI into durable security outcomes. That makes the question facing cybersecurity more complicated than whether AI will create haves and have-nots. The industry already had them. The real question is whether AI becomes another technology that rewards the organizations already best positioned to use it — or the first major security advance in years that helps those below the poverty line finally catch up. View the full article

At Amazon Web Services (AWS), artificial intelligence is already compressing security work that once took months into minutes. In the old world, human red teams would find vulnerabilities, write reports, refine those reports, and eventually hand them to defenders, who would then begin building detections or fixes, Steve Schmidt, chief security officer at AWS, tells CSO. That process could take “two, four, six, eight, 10 months,” Schmidt says. “Now with proper application of AI, we can have the detections built for the problems the red team finds in 15 minutes-ish,” he says. “I think the outside is about four hours.” That kind of workflow offers a glimpse of what AI could make possible for the most sophisticated security organizations: AI agents testing systems, other agents generating defenses, and human security engineers validating results and refining the feedback loop. But it also raises a more uncomfortable question for the rest of the cybersecurity industry: What happens to organizations that cannot build anything close to that? The concern has become significant enough that the Trump administration recently directed agencies to expand access to AI-enabled cybersecurity capabilities for resource-constrained organizations, including rural hospitals, community banks, and local utilities. The order reflects a growing fear that AI could deepen a divide that has existed in cybersecurity for years: the divide between organizations with money, expertise, and engineering depth, and those struggling to keep pace with basic security demands. Yet security leaders and practitioners suggest the impact of AI will be more complicated than a simple widening gap. Some experts say AI is merely adding a new layer to a long-standing security poverty problem. Others argue AI could democratize capabilities once reserved for elite organizations. Still others see today’s divide as real, but potentially temporary, as models become cheaper, more open, and easier to run. The class divide was already here For Matt Warner, co-founder and CTO of Blumira, the premise that AI is creating a cybersecurity class divide misses a key point: The divide already exists. “I would go even a step further and say that there has been a class divide for the last 10 to 15 years,” Warner tells CSO. What AI changes, he argues, is not necessarily the existence of the divide but how stark it becomes. Larger organizations have money, people, and time to experiment with AI. Smaller organizations often do not. “The big differences that we’re seeing, especially from where we sit in the world, is the difference is getting starker in having the resources to leverage AI and the time to leverage AI more than anything else,” Warner says. That distinction matters because many smaller organizations are already overwhelmed. Warner pointed to resource-constrained local governments and small or midmarket organizations that are still far behind large enterprises in basic IT and security maturity. “I can find you a county in Michigan with two IT people for 2,000 employees,” Warner says. “Those people don’t have time to leverage AI and even learn how to use AI because they’re mostly just trying to put out fires.” That problem is not unique to AI. Smaller organizations have long struggled to patch systems, prioritize vulnerabilities, monitor environments, and respond to incidents with limited staff. AI may help eventually, but only if those organizations have enough capacity to adopt it. Wendy Nather’s framework gets an AI layer Anton Chuvakin, security advisor in the office of the CISO for Google Cloud, sees the AI divide as part of a much older problem. “I feel like it sends me back to when Wendy Nather invented the security poverty line,” Chuvakin tells CSO, referring to Nather’s 2011 concept describing organizations that lack the money, expertise, capability, or influence to implement effective security. Chuvakin is skeptical that AI fundamentally changes that model. “I don’t think AI necessarily breaks that model,” he says. “I think it just adds another dimension.” Cybersecurity has always been shaped by unequal access to top talent, tools, and services, Chuvakin argues. Large organizations could afford better SIEM deployments, advanced DLP programs, threat hunters, application security experts, and incident response retainers. Smaller organizations often could not. AI may become another scarce resource, but Chuvakin cautions against overstating the role of model cost alone. In his view, the bigger structural issue may be talent rather than tokens. “Prices for people won’t drop, but prices for LLMs may drop,” he believes. That means the organizations with the greatest advantage may not simply be those that can afford the most expensive models. They may be the ones that can afford the people who know how to use them — and, as the frontier-access debate below suggests, that talent gap may prove more durable than any gap in model access itself. AI creates new costs — and new uncertainties Nather herself, now senior research initiatives director at 1Password, sees AI affecting every dimension of the security poverty line: money, expertise, capability, and influence. The financial challenges are not limited to whether an organization can pay for an AI tool. In some cases, organizations that cannot afford enterprise licensing may end up making tradeoffs around privacy. “If an organization can’t afford an enterprise license for the models they’re using, then they can’t keep their data private,” Nather tells CSO. “So, they have to give up privacy because they can’t afford privacy.” That’s a new twist on an old dimension of the poverty line: It’s not just that under-resourced organizations lack a capability, but that the capability they can afford comes bundled with a risk wealthier organizations don’t have to accept. Token-based pricing adds another problem: unpredictability. “At this point, nobody knows how much they’re going to burn in tokens at any given time,” she says. That makes budgeting difficult for organizations that cannot absorb surprise costs. Nather also warns that usage-based pricing is controlled by providers and can change over time, leaving customers with limited leverage. “The charging practice is in the hands of the providers, and they can change it at any time,” she says. For organizations already operating below the security poverty line, that uncertainty could make AI adoption harder, even if the technology itself becomes more capable. Access to frontier models may be a temporary divide Dave Baggett, SVP/GM of the security suite at Kaseya, agrees there is security class divide dynamic playing out today, particularly around access to frontier models. “There’s definitely a haves and have-nots issue around Mythos specifically because most people don’t have it,” Baggett tells CSO. But he doesn’t think the divide will have a long-term impact. Open-weight models, quantization, mixture-of-experts architectures, and increasingly powerful commodity hardware, he argues, are closing the gap faster than most people expect. While not every organization will build a frontier model, he says, more organizations may be able to run capable models locally or use cheaper systems that approximate what today’s elite models can do. “What it says for finding vulnerabilities is at that point, open-source people can run this stuff,” Baggett says. “Then you’re back to having a symmetrical opportunity where the defenders who are writing the open source can run the same tools the attackers would and have them fix the issues.” His bottom line is that the divide may be real but short-lived. “Right now, there certainly is a have, have-not schism, but it may not be there for long,” Baggett says — a view Chuvakin shares, though he frames it in terms of the model market rather than open source specifically. “I don’t think it’s the lowering prices example, but it’s more like you’re a top-tier model maker, I’m a second-tier model maker. My model in a year would do what your model did a year ago,” Chuvakin says. The real advantage is operational depth Schmidt’s description of AI use at AWS points to another kind of divide: not access to AI, but the ability to operationalize it. AWS uses multiple models for different tasks, Schmidt says. One model may discover vulnerabilities, while other models validate results or help build defenses. Humans remain accountable for evaluating what the systems produce. “Because we believe really strongly in human accountability for the use of AI from end to end, we still have humans take a look at what the systems come up with to determine whether they are reasonable and appropriate,” he says. That workflow requires more than a model. It requires corporate data, secure infrastructure, feedback loops, security engineers, data scientists, and AI specialists who can work together. Schmidt also pushes back on the idea that running AI locally on powerful consumer hardware is a substitute for production-grade security infrastructure. “Often the value of the model is also dependent on its proximity to data so that the model can ingest, use, and reason about data,” he says. “As a security person, I do not want that to be on your laptop.” Experimentation on a laptop is useful, Schmidt says, but it is not the same as a secure production environment. “I want the data to be somewhere safe that I can control, that I can see, that I can reason about, not sitting on your laptop,” he says. “Experimentation in there, awesome. That’s great. But it is not a production infrastructure component.” That distinction may define the emerging AI security gap. Many organizations may be able to access AI tools. Far fewer may be able to safely integrate them into real security workflows. The democratization argument Phil Venables, a partner at Ballistic Ventures and former CISO of Google Cloud, takes the most optimistic view. Asked whether AI is widening the gap between well-resourced and under-resourced security organizations, Venables tells CSO, “No, I actually think it’s the exact opposite.” The reason, he argues, is that AI packages expertise and automation in ways that can be delivered broadly. “One of the fantastic things about AI, and we’re already starting to see this, is [that it’s] a great democratizer of capabilities,” he says. “AI packages up expertise and automation capabilities at a level beyond what prior waves of technology have done, and it makes it available at scale into organizations that have not previously been able to afford these things.” He points to red teaming as an example. Nearly every organization would like a world-class red team, but few can afford one. “Pretty much every organization on the planet would love to have a world-class red team to constantly test their security to find and fix things before attackers do,” Venables says. “But very few organizations have ever been able to afford to build a high-end red team.” AI agents, he argues, could make that kind of capability available more economically. The same pattern could apply to insider threat; third-party risk; software security; governance, risk and compliance; and security operations. “So even the smallest and resource-constrained organizations can now have access to a higher-end capability,” he maintains. Venables does see a danger zone, however: under-resourced security teams inside organizations with aggressive AI ambitions. Those teams may struggle to keep up as the rest of the business adopts AI rapidly. But for many small and midsize organizations, he believes AI could improve access to security capabilities they never had before. A divide over AI — or over readiness? For elite organizations, AI is already becoming a force multiplier. Security teams with deep engineering talent, mature data infrastructure, and strong governance can use AI to accelerate testing, detection engineering, vulnerability discovery, and risk management. For smaller organizations, the picture is less clear. AI may eventually package scarce expertise into affordable services. Open models may reduce dependence on expensive frontier systems. But organizations below the security poverty line still face familiar constraints: too few people, too little time, limited expertise, unpredictable costs, and weak leverage over vendors. The emerging divide may therefore be less about who has access to AI and more about who can turn AI into durable security outcomes. That makes the question facing cybersecurity more complicated than whether AI will create haves and have-nots. The industry already had them. The real question is whether AI becomes another technology that rewards the organizations already best positioned to use it — or the first major security advance in years that helps those below the poverty line finally catch up. View the full article

Members of the European Parliament (MEPs) have failed to block a proposal extending the mass scanning of private communications, a measure they have previously rejected twice. This time too, more votes were cast against the proposal than in favor, but due to the absence of numerous MEPs on the eve of the summer recess, the motion to reject did not attain the necessary absolute majority. The proposal passed by default. Similarly, an amendment to require warrants for the scanning received more votes in favor than against, but failed to attain the necessary absolute majority to pass. The so-called Chat Control 1.0 law will now be extended through 2028. According to its supporters, the measure can be seen as a vital component in the fight against the sexual abuse of children, while opponents see it as a move to restrict privacy. This has been a long-running battle within the European Union. Last November, the European Commission put a halt to proposals for large-scale monitoring and proposed a voluntary approach. This has now changed. Under the new measure, service providers will be able to scan private messages without a warrant. This affects direct messages on platforms including Discord, Skype, Instagram, Snapchat, and Xbox, as well as emails sent via Google’s Gmail and Apple’s iCloud. Encrypted services like WhatsApp remain unaffected. “Today’s vote on the interim regulation was a setback, but the political battle over the permanent ‘Chat Control 2.0’ is just getting started. The resistance we saw in Parliament today was so strong that finding a majority for permanent, suspicionless mass scanning in future negotiations is a complete pipe dream,” wrote Patrick Beyer, a long-standing critic of the proposal and a former MEP himself. In November, he warned that enterprises could be affected by the measure. “For a corporation, a ‘false positive’ could mean that confidential internal documents, code, or strategic plans are flagged and sent to external authorities or police forces without the company’s knowledge.” Discussions on a permanent solution to the issue are continuing, with some firmly entrenched views on both sides. “The core dispute between the EU Parliament, member state governments, and the EU Commission remains the scanning of private chats: should it be indiscriminate, or targeted at criminal suspects?” wrote Beyer. View the full article

Members of the European Parliament (MEPs) have failed to block a proposal extending the mass scanning of private communications, a measure they have previously rejected twice. This time too, more votes were cast against the proposal than in favor, but due to the absence of numerous MEPs on the eve of the summer recess, the motion to reject did not attain the necessary absolute majority. The proposal passed by default. Similarly, an amendment to require warrants for the scanning received more votes in favor than against, but failed to attain the necessary absolute majority to pass. The so-called Chat Control 1.0 law will now be extended through 2028. According to its supporters, the measure can be seen as a vital component in the fight against the sexual abuse of children, while opponents see it as a move to restrict privacy. This has been a long-running battle within the European Union. Last November, the European Commission put a halt to proposals for large-scale monitoring and proposed a voluntary approach. This has now changed. Under the new measure, service providers will be able to scan private messages without a warrant. This affects direct messages on platforms including Discord, Skype, Instagram, Snapchat, and Xbox, as well as emails sent via Google’s Gmail and Apple’s iCloud. Encrypted services like WhatsApp remain unaffected. “Today’s vote on the interim regulation was a setback, but the political battle over the permanent ‘Chat Control 2.0’ is just getting started. The resistance we saw in Parliament today was so strong that finding a majority for permanent, suspicionless mass scanning in future negotiations is a complete pipe dream,” wrote Patrick Beyer, a long-standing critic of the proposal and a former MEP himself. In November, he warned that enterprises could be affected by the measure. “For a corporation, a ‘false positive’ could mean that confidential internal documents, code, or strategic plans are flagged and sent to external authorities or police forces without the company’s knowledge.” Discussions on a permanent solution to the issue are continuing, with some firmly entrenched views on both sides. “The core dispute between the EU Parliament, member state governments, and the EU Commission remains the scanning of private chats: should it be indiscriminate, or targeted at criminal suspects?” wrote Beyer. View the full article

Security company CrowdStrike has identified five new prompt injection techniques that could leave enterprises at risk. Prompt injections attacks exploit the growing use of AI within organizations . They work by tricking LLMs into accepting instructions that a human operator would recognize as dubious. The five new types of attack that CrowdStrike has added to its prompt injection taxonomy are: Trigger-Activated Rule Addition in which an attacker adds a new rule that looks innocuous at first, but can be triggered later to cause strange behavior within the model. Cognitive Token Suppression,a way to circumvent built-in safety measures by shifting the model’s linguistic choices away from established refusal patterns. Algorithmic Payload Decomposition,or delivering a message in multiple stages each of which appears innocent but that, when combined, can be assembled into a single command that is more threatening. Special Token Injection, an attack that can be compared to the embedding of counterfeit “control switches” within normal instructions. Attackers look to introduce confusion that tricks the model into elevating untrusted user content to the status of a high-priority system directive. Unwitting User Context-Data Injection, an exploit that draws on the boundary between trusted data and executable instructions, tricking the user into introducing malicious instructions as part of the context data for the LLM. The prompt may be harmless: The malicious instruction is hidden inside the surrounding context data. It works when a user uploads a document, forwards an email or adds content that is later processed by AI. Security teams can guard against such attacks in several ways, CrowdStrike said, including threat modeling every place that model context can originate, expanding testing, and extending detection engineering to include composite attacks. View the full article

Security company CrowdStrike has identified five new prompt injection techniques that could leave enterprises at risk. Prompt injections attacks exploit the growing use of AI within organizations . They work by tricking LLMs into accepting instructions that a human operator would recognize as dubious. The five new types of attack that CrowdStrike has added to its prompt injection taxonomy are: Trigger-Activated Rule Addition in which an attacker adds a new rule that looks innocuous at first, but can be triggered later to cause strange behavior within the model. Cognitive Token Suppression,a way to circumvent built-in safety measures by shifting the model’s linguistic choices away from established refusal patterns. Algorithmic Payload Decomposition,or delivering a message in multiple stages each of which appears innocent but that, when combined, can be assembled into a single command that is more threatening. Special Token Injection, an attack that can be compared to the embedding of counterfeit “control switches” within normal instructions. Attackers look to introduce confusion that tricks the model into elevating untrusted user content to the status of a high-priority system directive. Unwitting User Context-Data Injection, an exploit that draws on the boundary between trusted data and executable instructions, tricking the user into introducing malicious instructions as part of the context data for the LLM. The prompt may be harmless: The malicious instruction is hidden inside the surrounding context data. It works when a user uploads a document, forwards an email or adds content that is later processed by AI. Security teams can guard against such attacks in several ways, CrowdStrike said, including threat modeling every place that model context can originate, expanding testing, and extending detection engineering to include composite attacks. View the full article

Security leaders have made strong progress in visibility. Most organizations can now identify vulnerabilities across their applications, dependencies and development pipelines with far more consistency than in the past. Yet a fundamental imbalance remains: Vulnerabilities are being discovered faster than they can be remediated. That imbalance is growing. Today, 82% of organizations carry security debt, defined as accumulated vulnerabilities that have remained unresolved for more than a year. At the same time, the share of vulnerabilities defined as both “severe” and “likely to be exploited” continues to increase. This combination has real consequences. Vulnerabilities are not just accumulating; they persist in production environments long enough to be discovered and used. Among my fellow CISOs, the conversation has shifted. The challenge now is to translate this reality into a business case that resonates with executive leadership and drives investment in remediation capacity. Here are six ways to do this. Treat security debt like financial debt Security debt behaves much like financial debt. It accumulates over time, compounds when left unmanaged and creates ongoing costs for the business. Those costs show up in delayed releases, emergency remediation efforts, audit findings and incident response. Managing it effectively requires the same discipline applied to financial risk. That means measuring total and critical debt, setting reduction targets and tracking progress over time. It also means distinguishing between acceptable and unacceptable levels of risk, rather than treating all vulnerabilities as equal. I believe security debt should be visible at the executive level. Leadership teams routinely track financial performance, operational resilience and service reliability. Security debt belongs in the same category. It reflects the organization’s exposure and its ability to manage that exposure over time. Frame remediation capacity as a business constraint Most organizations have a strong awareness of vulnerabilities. The limiting factor is the ability to address them. Remediation capacity determines whether security debt grows or shrinks. When the volume of new findings exceeds the organization’s ability to fix them, the backlog expands and exposure increases. This dynamic persists regardless of how effective detection tools are. In my experience, it’s important to quantify this constraint. That includes showing the gap between findings and fixes, identifying where high-risk vulnerabilities remain open and demonstrating how long they persist. These data points make it clear that incremental efficiency improvements will not close the gap on their own. Presenting remediation capacity in operational terms helps align the discussion with executive priorities. Leaders understand constraints in engineering throughput, cloud spend and service availability. Remediation capacity should be treated in the same way. Focus on exploitable risk in critical systems Security debt becomes meaningful when it is tied to business impact. Not all vulnerabilities carry the same level of risk. The ones that matter most share two characteristics. They are likely to be exploited, and they exist in applications that are important to the business. Traditional severity scoring does not fully capture this. The Common Vulnerability Scoring System (CVSS) remains useful. Still, it does not reflect whether a vulnerability is reachable, whether it sits in a critical system or whether exploit techniques are readily available. A practical approach is to layer exploitability and business context onto existing scoring models. This creates a focused set of high-risk vulnerabilities that require immediate attention. In many environments, this represents a relatively small percentage of total findings, but it accounts for a large portion of potential impact. By concentrating on this subset, organizations can direct resources where they have the greatest effect. This approach also makes it easier to communicate risks in business terms. Prioritize crown-jewel applications Risk is not distributed evenly across applications. Every organization has systems that are more critical than others. These may include customer-facing platforms, revenue-generating services or applications that process sensitive data. Compromise in these areas has a disproportionate impact on the business. Focusing remediation efforts on these crown-jewel applications improves outcomes quickly. Our research found that 11.3% of flaws have high severity and high exploitability. It ensures that the most important systems receive the highest level of protection and reduces the likelihood of high-impact incidents. Clear targets help reinforce this focus. Over a defined period, organizations can reduce critical security debt, shorten the lifespan of high-risk vulnerabilities and maintain strict thresholds for exposure in key systems. These targets translate security activity into business outcomes that leadership can understand and support. Establish metrics that reflect risk Metrics play a central role in shaping behavior. Many organizations continue to rely on the number of vulnerabilities discovered or resolved. While these metrics provide useful context, they do not indicate whether risk is increasing or decreasing. More effective measures focus on exposure. These include the number of critical or exploitable vulnerabilities in key systems, the average age of those vulnerabilities and trends over time. Together, these metrics provide a clearer picture of how risk is evolving. Linking these measures to organizational objectives strengthens accountability. Security debt reduction can be incorporated into OKRs, with specific targets for reducing critical debt, lowering vulnerability age and maintaining acceptable thresholds in high-risk applications. Formalizing risk acceptance is also important. High-risk vulnerabilities that remain open should require business approval and defined timelines. This ensures that risk is acknowledged and managed deliberately. Increase investment in remediation capacity Improving security outcomes requires sustained investment in the ability to act. Remediation capacity can be expanded in several ways. Organizations can allocate dedicated engineering time for security work, integrate remediation into development workflows and adopt automation to reduce manual effort. AI-assisted fixes and automated guidance can help teams address vulnerabilities more efficiently without disrupting development velocity. Preventing new security debt is equally important. Policies such as requiring high-risk vulnerabilities to be resolved before release help limit the introduction of additional exposure. Over time, this reduces the overall burden on remediation teams. These changes do not slow innovation. They create conditions for delivering software safely and consistently. Align the business around risk reduction Security debt affects more than the security function. It influences resilience, regulatory posture and the organization’s ability to deliver software with confidence. CISOs play a central role in aligning stakeholders around this issue. By framing security debt in terms of business impact, capacity constraints and measurable outcomes, they can shift the conversation from technical backlog management to enterprise risk reduction. This alignment is critical for securing investment. When leadership understands the relationship between remediation capacity and business risk, decisions about funding, prioritization and trade-offs become clearer. Security debt will continue to exist. What matters is how effectively it is managed and measured. For example, a good target should be doubling fix capacity through tooling investment, not just headcount. Organizations that measure, govern and actively invest in reducing it are better positioned to control risk at scale. Those that do not will continue to see exposure grow, even as their visibility improves. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Security leaders have made strong progress in visibility. Most organizations can now identify vulnerabilities across their applications, dependencies and development pipelines with far more consistency than in the past. Yet a fundamental imbalance remains: Vulnerabilities are being discovered faster than they can be remediated. That imbalance is growing. Today, 82% of organizations carry security debt, defined as accumulated vulnerabilities that have remained unresolved for more than a year. At the same time, the share of vulnerabilities defined as both “severe” and “likely to be exploited” continues to increase. This combination has real consequences. Vulnerabilities are not just accumulating; they persist in production environments long enough to be discovered and used. Among my fellow CISOs, the conversation has shifted. The challenge now is to translate this reality into a business case that resonates with executive leadership and drives investment in remediation capacity. Here are six ways to do this. Treat security debt like financial debt Security debt behaves much like financial debt. It accumulates over time, compounds when left unmanaged and creates ongoing costs for the business. Those costs show up in delayed releases, emergency remediation efforts, audit findings and incident response. Managing it effectively requires the same discipline applied to financial risk. That means measuring total and critical debt, setting reduction targets and tracking progress over time. It also means distinguishing between acceptable and unacceptable levels of risk, rather than treating all vulnerabilities as equal. I believe security debt should be visible at the executive level. Leadership teams routinely track financial performance, operational resilience and service reliability. Security debt belongs in the same category. It reflects the organization’s exposure and its ability to manage that exposure over time. Frame remediation capacity as a business constraint Most organizations have a strong awareness of vulnerabilities. The limiting factor is the ability to address them. Remediation capacity determines whether security debt grows or shrinks. When the volume of new findings exceeds the organization’s ability to fix them, the backlog expands and exposure increases. This dynamic persists regardless of how effective detection tools are. In my experience, it’s important to quantify this constraint. That includes showing the gap between findings and fixes, identifying where high-risk vulnerabilities remain open and demonstrating how long they persist. These data points make it clear that incremental efficiency improvements will not close the gap on their own. Presenting remediation capacity in operational terms helps align the discussion with executive priorities. Leaders understand constraints in engineering throughput, cloud spend and service availability. Remediation capacity should be treated in the same way. Focus on exploitable risk in critical systems Security debt becomes meaningful when it is tied to business impact. Not all vulnerabilities carry the same level of risk. The ones that matter most share two characteristics. They are likely to be exploited, and they exist in applications that are important to the business. Traditional severity scoring does not fully capture this. The Common Vulnerability Scoring System (CVSS) remains useful. Still, it does not reflect whether a vulnerability is reachable, whether it sits in a critical system or whether exploit techniques are readily available. A practical approach is to layer exploitability and business context onto existing scoring models. This creates a focused set of high-risk vulnerabilities that require immediate attention. In many environments, this represents a relatively small percentage of total findings, but it accounts for a large portion of potential impact. By concentrating on this subset, organizations can direct resources where they have the greatest effect. This approach also makes it easier to communicate risks in business terms. Prioritize crown-jewel applications Risk is not distributed evenly across applications. Every organization has systems that are more critical than others. These may include customer-facing platforms, revenue-generating services or applications that process sensitive data. Compromise in these areas has a disproportionate impact on the business. Focusing remediation efforts on these crown-jewel applications improves outcomes quickly. Our research found that 11.3% of flaws have high severity and high exploitability. It ensures that the most important systems receive the highest level of protection and reduces the likelihood of high-impact incidents. Clear targets help reinforce this focus. Over a defined period, organizations can reduce critical security debt, shorten the lifespan of high-risk vulnerabilities and maintain strict thresholds for exposure in key systems. These targets translate security activity into business outcomes that leadership can understand and support. Establish metrics that reflect risk Metrics play a central role in shaping behavior. Many organizations continue to rely on the number of vulnerabilities discovered or resolved. While these metrics provide useful context, they do not indicate whether risk is increasing or decreasing. More effective measures focus on exposure. These include the number of critical or exploitable vulnerabilities in key systems, the average age of those vulnerabilities and trends over time. Together, these metrics provide a clearer picture of how risk is evolving. Linking these measures to organizational objectives strengthens accountability. Security debt reduction can be incorporated into OKRs, with specific targets for reducing critical debt, lowering vulnerability age and maintaining acceptable thresholds in high-risk applications. Formalizing risk acceptance is also important. High-risk vulnerabilities that remain open should require business approval and defined timelines. This ensures that risk is acknowledged and managed deliberately. Increase investment in remediation capacity Improving security outcomes requires sustained investment in the ability to act. Remediation capacity can be expanded in several ways. Organizations can allocate dedicated engineering time for security work, integrate remediation into development workflows and adopt automation to reduce manual effort. AI-assisted fixes and automated guidance can help teams address vulnerabilities more efficiently without disrupting development velocity. Preventing new security debt is equally important. Policies such as requiring high-risk vulnerabilities to be resolved before release help limit the introduction of additional exposure. Over time, this reduces the overall burden on remediation teams. These changes do not slow innovation. They create conditions for delivering software safely and consistently. Align the business around risk reduction Security debt affects more than the security function. It influences resilience, regulatory posture and the organization’s ability to deliver software with confidence. CISOs play a central role in aligning stakeholders around this issue. By framing security debt in terms of business impact, capacity constraints and measurable outcomes, they can shift the conversation from technical backlog management to enterprise risk reduction. This alignment is critical for securing investment. When leadership understands the relationship between remediation capacity and business risk, decisions about funding, prioritization and trade-offs become clearer. Security debt will continue to exist. What matters is how effectively it is managed and measured. For example, a good target should be doubling fix capacity through tooling investment, not just headcount. Organizations that measure, govern and actively invest in reducing it are better positioned to control risk at scale. Those that do not will continue to see exposure grow, even as their visibility improves. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Microsoft is warning defenders about a new backdoor that blurs the line between espionage malware and wipers. In a technical analysis published on Thursday, Microsoft Threat Intelligence detailed GigaWiper, a Golang-based implant first observed in October 2025 intrusions that combines remote administration capabilities with multiple disk-wiping and ransomware routines. Rather than building a new destructive tool from scratch, the operators assembled GigaWiper from several existing malware families, embedding them as modular commands inside a single backdoor. “GigaWiper is particularly notable for its makeup,” Microsoft researchers said. “The consolidation of multiple destructive capabilities into a modular backdoor reflects a notable shift in wiper malware, which are typically designed purely to destroy rather than to extort and carry real-world consequences.” Malware capabilities of the backdoor included multiple disk wiping logics, an irreversible Crucio ransomware encryption, persistence, and RabbitMQ and Redis-based communication. A backdoor for destruction on demand According to Microsoft, GigaWiper exists in two forms. A standalone wiper and a larger backdoor whose command set embeds the standalone wiping functionality alongside numerous administrative features. Written in Go, the malware supports 20 command codes that enable operators to execute PowerShell commands, manage Windows services and processes, manipulate the registry, capture screenshots, record displays, clear event logs, and remotely control infected systems through a Virtual Network Computing (VNC)-like capability. Persistence is established through a scheduled task posing as a “OneDrive Update,” while command-and-control (C2) relies on RabbitMQ for receiving instructions and Redis for returning command output. This architecture allows attackers to quietly maintain access and selectively activate destructive functionality when an objective has been achieved, the researchers added. The backdoor combines three malware families Microsoft researchers found that GigaWiper integrates destructive code from multiple malware families instead of relying on a single wiping mechanism. These integrations show up in the form of separate commands that the backdoor supports. One command performs raw physical disk wiping by overwriting drives and removing partition metadata. Another borrows from the Crucio ransomware family, encrypting files with randomly generated keys that are intentionally never stored, making recovery impossible despite presenting itself like ransomware. A third command recreates the functionality of FlockWiper, implementing secure multi-pass wiping in Go to permanently erase data on Windows systems. “We tied GigaWiper to both Crucio and FlockWiper based on code analysis, shared execution flow, function naming, and unique strings,” the researchers said. “Crucio’s code was the base for GigaWiper command 3, and FlockWiper was re-coded in Golang and updated for GigaWiper command 12,” they noted, referring to the 20 listed commands the backdoor supports. The standalone wiper was implemented as command 1 from the list. Microsoft recommended hardening endpoints and identities, enabling behavioral detection and endpoint detection and response (EDR) capabilities, and using attack surface reduction controls to limit compromise risks. The company also urged defenders to maintain offline or otherwise resilient backups, as destructive malware like GigaWiper is designed to irreversibly wipe or encrypt data. To support detection, the researchers shared a list of indicators of compromise (IOCs), which included FlockWiper and Crucio file hashes and a couple of C2 IP addresses. View the full article

Microsoft is warning defenders about a new backdoor that blurs the line between espionage malware and wipers. In a technical analysis published on Thursday, Microsoft Threat Intelligence detailed GigaWiper, a Golang-based implant first observed in October 2025 intrusions that combines remote administration capabilities with multiple disk-wiping and ransomware routines. Rather than building a new destructive tool from scratch, the operators assembled GigaWiper from several existing malware families, embedding them as modular commands inside a single backdoor. “GigaWiper is particularly notable for its makeup,” Microsoft researchers said. “The consolidation of multiple destructive capabilities into a modular backdoor reflects a notable shift in wiper malware, which are typically designed purely to destroy rather than to extort and carry real-world consequences.” Malware capabilities of the backdoor included multiple disk wiping logics, an irreversible Crucio ransomware encryption, persistence, and RabbitMQ and Redis-based communication. A backdoor for destruction on demand According to Microsoft, GigaWiper exists in two forms. A standalone wiper and a larger backdoor whose command set embeds the standalone wiping functionality alongside numerous administrative features. Written in Go, the malware supports 20 command codes that enable operators to execute PowerShell commands, manage Windows services and processes, manipulate the registry, capture screenshots, record displays, clear event logs, and remotely control infected systems through a Virtual Network Computing (VNC)-like capability. Persistence is established through a scheduled task posing as a “OneDrive Update,” while command-and-control (C2) relies on RabbitMQ for receiving instructions and Redis for returning command output. This architecture allows attackers to quietly maintain access and selectively activate destructive functionality when an objective has been achieved, the researchers added. The backdoor combines three malware families Microsoft researchers found that GigaWiper integrates destructive code from multiple malware families instead of relying on a single wiping mechanism. These integrations show up in the form of separate commands that the backdoor supports. One command performs raw physical disk wiping by overwriting drives and removing partition metadata. Another borrows from the Crucio ransomware family, encrypting files with randomly generated keys that are intentionally never stored, making recovery impossible despite presenting itself like ransomware. A third command recreates the functionality of FlockWiper, implementing secure multi-pass wiping in Go to permanently erase data on Windows systems. “We tied GigaWiper to both Crucio and FlockWiper based on code analysis, shared execution flow, function naming, and unique strings,” the researchers said. “Crucio’s code was the base for GigaWiper command 3, and FlockWiper was re-coded in Golang and updated for GigaWiper command 12,” they noted, referring to the 20 listed commands the backdoor supports. The standalone wiper was implemented as command 1 from the list. Microsoft recommended hardening endpoints and identities, enabling behavioral detection and endpoint detection and response (EDR) capabilities, and using attack surface reduction controls to limit compromise risks. The company also urged defenders to maintain offline or otherwise resilient backups, as destructive malware like GigaWiper is designed to irreversibly wipe or encrypt data. To support detection, the researchers shared a list of indicators of compromise (IOCs), which included FlockWiper and Crucio file hashes and a couple of C2 IP addresses. View the full article

Check Point Software CTO Jonathan Zanger met with CSO Spain during the software company’s Engage 2026 user conference last week in Paris. At the event, Check Point executives and representatives discussed how the company is dealing with various types of threats, how it is adopting AI securely, and how Check Point and others can leverage AI for their own benefit. “That’s why I believe 2026 is a fascinating year to work in this field. Every technological change drastically affects cybersecurity,” Zanger told CSO Spain. “I think we’re currently witnessing the biggest change since the advent of the internet. So, without a doubt, we’re facing significant transformations.” What follows CSO Spain’s discussion with Zanger, edited for length and clarity. How are AI agents changing the way we detect and stop cyber threats? What new risks are they creating? I’ll try to answer on several levels. The first is how we operate differently as a cybersecurity company protecting our clients. We’ve always had teams of experts monitoring threats, identifying malicious actors, and creating new defenses for our products. Consequently, whenever we detected an APT group, we investigated it and created signatures to protect against it. Or when we saw a suspicious network used by threat actors, we identified its location and blocked it. While it’s true that, in many ways, we were always limited by the number of talented people capable of gathering that intelligence and turning it into actionable defenses, what has AI allowed us to do? Dramatically scale this operation. Could you give an example? We’ve always had red teams testing our products to ensure their security. And we’ve always valued those teams highly because they made our products significantly more secure. Now, those teams are incredibly powerful thanks to AI, working 20 times more efficiently. What do we have now? A combination of people and AI agents, with around 300 instances continuously monitoring and testing our systems. This is what allows us to deliver better cybersecurity and scale our capabilities. But it’s clear that malicious actors are using AI to carry out their operations… That’s right. Just as it helped us scale our operations, it’s also helped them. We’re now seeing a proliferation of smaller, faster threat groups and malicious actors, capable of conducting phishing campaigns with less expertise than before. Consequently, we’re seeing more people entering the field of offensive cybersecurity. So, perhaps the final piece of the puzzle is that organizations are adopting AI systems, and now we have a new challenge: How are we going to protect them? In this context, what security challenges arise when AI agents can access and operate enterprise systems? In your opinion, what should organizations prepare for? Systems used to be deterministic: Given the same input, they produced a predictable output, which made them easier to protect. With AI agents, this changes, as they understand natural language, handle ambiguity, and their behavior isn’t always predictable, requiring a new approach to cybersecurity. Furthermore, something very important must be considered: AI depends on the systems it’s connected to. There’s a tension between security teams, who seek to limit these connections to reduce risks, and those promoting AI, who want to integrate it throughout the organization to gather information from any area. In other words, the more connections AI has, the greater the attack surface and the security risk. How is generative AI making it easier for attackers to create cyberattacks? From your perspective, what are the most important defenses today? AI has transformed software development, making it much faster and more accessible. But what’s happening? Cybercriminals are exploiting this same capability, allowing them to escalate attacks like phishing, ransomware, malware, and vulnerability exploitation, increasing both the speed and volume of threats. What do you recommend doing in this scenario? Defenders must also embrace AI. Detection and response are no longer enough when an attack can cause damage in seconds, so prevention plays a key role. While attackers maintain a certain advantage because they only need to hit once and are not subject to regulations, defenders have a differentiating factor: collaboration between teams, organizations, and security companies, which helps to level the playing field. But you can’t deny that many AI platforms still have vulnerabilities… That’s right, because innovation often advances faster than security. That’s why I recommend incorporating a layer of security from the very beginning of any AI project and not assuming that a platform is secure simply because it comes from a reputable vendor. How can AI platforms be used securely in the face of the expanding attack surface? What do you consider to be the most significant risk? Throughout the evolution of systems, innovation, and organizations, security hasn’t always been a priority from the outset of product development. We see this because we investigate different platforms, especially AI platforms, to assess their security. This has allowed us to uncover serious vulnerabilities in every AI platform we’ve analyzed over the past year, as well as in all major AI development tools. Now, I’m not criticizing anyone here, because their job is to launch innovative products quickly. But I do believe security gaps exist. That’s why I think that, in many cases, this is the role of organizations like ours: to work with companies to ensure that when they use this innovative technology, they do so in a way that protects their data, safeguards their employees, and doesn’t increase their risk. Would you share any lessons you’ve learned from adopting AI? Absolutely. The lesson I take away is that when you adopt AI, whatever the use case, you must do so by incorporating a layer of security. And don’t assume a platform is secure just because it comes from an innovative AI company. In your opinion, what are the most important innovations in security platforms today? And how do they help customers and organizations stay protected? I’d like to identify three major areas where AI is transforming cybersecurity. The first is the use of AI to strengthen defense operations. Just as it has revolutionized software development, AI is changing how security teams work, enabling them to detect vulnerabilities, assess security posture, implement changes, and respond to threats more quickly, efficiently, and scalably. The second area is the protection of the AI ​​applications and agents themselves. As these technologies are integrated into corporate networks, the challenge arises of ensuring they do not become a new attack vector or expose sensitive information. This is a very recent field, driven by the rapid adoption of generative AI, in which there is still ample room for innovation. Finally, I want to emphasize the need to defend against increasingly rapid and sophisticated AI-driven attacks. To this end, I advocate combining advanced models capable of detecting zero-day vulnerabilities and anomalous behavior with AI systems that simulate the behavior of an ethical attacker. This way, organizations can anticipate cybercriminals, identify their attack surface, and strengthen their defenses before an incident occurs. The final question concerns the needs of small and medium-sized organizations, which want AI systems to be more transparent and easier to audit when they help detect or respond to threats. What are your thoughts on this? I believe explainability is a crucial part of what we must offer our clients as cybersecurity advocates. There’s always a tension between blocking something immediately and, at the same time, being able to explain why it was blocked. People like to understand what happened, and this presents a delicate balance. Therefore, my perspective is that we should automatically block as many threats as possible, without requiring human intervention, but we must also enable humans to understand what happened and modify the future behavior of the protection mechanisms. Víctor Manuel Fernández attending Engage 2026 as a guest of Check Point Software. View the full article

Check Point Software CTO Jonathan Zanger met with CSO Spain during the software company’s Engage 2026 user conference last week in Paris. At the event, Check Point executives and representatives discussed how the company is dealing with various types of threats, how it is adopting AI securely, and how Check Point and others can leverage AI for their own benefit. “That’s why I believe 2026 is a fascinating year to work in this field. Every technological change drastically affects cybersecurity,” Zanger told CSO Spain. “I think we’re currently witnessing the biggest change since the advent of the internet. So, without a doubt, we’re facing significant transformations.” What follows CSO Spain’s discussion with Zanger, edited for length and clarity. How are AI agents changing the way we detect and stop cyber threats? What new risks are they creating? I’ll try to answer on several levels. The first is how we operate differently as a cybersecurity company protecting our clients. We’ve always had teams of experts monitoring threats, identifying malicious actors, and creating new defenses for our products. Consequently, whenever we detected an APT group, we investigated it and created signatures to protect against it. Or when we saw a suspicious network used by threat actors, we identified its location and blocked it. While it’s true that, in many ways, we were always limited by the number of talented people capable of gathering that intelligence and turning it into actionable defenses, what has AI allowed us to do? Dramatically scale this operation. Could you give an example? We’ve always had red teams testing our products to ensure their security. And we’ve always valued those teams highly because they made our products significantly more secure. Now, those teams are incredibly powerful thanks to AI, working 20 times more efficiently. What do we have now? A combination of people and AI agents, with around 300 instances continuously monitoring and testing our systems. This is what allows us to deliver better cybersecurity and scale our capabilities. But it’s clear that malicious actors are using AI to carry out their operations… That’s right. Just as it helped us scale our operations, it’s also helped them. We’re now seeing a proliferation of smaller, faster threat groups and malicious actors, capable of conducting phishing campaigns with less expertise than before. Consequently, we’re seeing more people entering the field of offensive cybersecurity. So, perhaps the final piece of the puzzle is that organizations are adopting AI systems, and now we have a new challenge: How are we going to protect them? In this context, what security challenges arise when AI agents can access and operate enterprise systems? In your opinion, what should organizations prepare for? Systems used to be deterministic: Given the same input, they produced a predictable output, which made them easier to protect. With AI agents, this changes, as they understand natural language, handle ambiguity, and their behavior isn’t always predictable, requiring a new approach to cybersecurity. Furthermore, something very important must be considered: AI depends on the systems it’s connected to. There’s a tension between security teams, who seek to limit these connections to reduce risks, and those promoting AI, who want to integrate it throughout the organization to gather information from any area. In other words, the more connections AI has, the greater the attack surface and the security risk. How is generative AI making it easier for attackers to create cyberattacks? From your perspective, what are the most important defenses today? AI has transformed software development, making it much faster and more accessible. But what’s happening? Cybercriminals are exploiting this same capability, allowing them to escalate attacks like phishing, ransomware, malware, and vulnerability exploitation, increasing both the speed and volume of threats. What do you recommend doing in this scenario? Defenders must also embrace AI. Detection and response are no longer enough when an attack can cause damage in seconds, so prevention plays a key role. While attackers maintain a certain advantage because they only need to hit once and are not subject to regulations, defenders have a differentiating factor: collaboration between teams, organizations, and security companies, which helps to level the playing field. But you can’t deny that many AI platforms still have vulnerabilities… That’s right, because innovation often advances faster than security. That’s why I recommend incorporating a layer of security from the very beginning of any AI project and not assuming that a platform is secure simply because it comes from a reputable vendor. How can AI platforms be used securely in the face of the expanding attack surface? What do you consider to be the most significant risk? Throughout the evolution of systems, innovation, and organizations, security hasn’t always been a priority from the outset of product development. We see this because we investigate different platforms, especially AI platforms, to assess their security. This has allowed us to uncover serious vulnerabilities in every AI platform we’ve analyzed over the past year, as well as in all major AI development tools. Now, I’m not criticizing anyone here, because their job is to launch innovative products quickly. But I do believe security gaps exist. That’s why I think that, in many cases, this is the role of organizations like ours: to work with companies to ensure that when they use this innovative technology, they do so in a way that protects their data, safeguards their employees, and doesn’t increase their risk. Would you share any lessons you’ve learned from adopting AI? Absolutely. The lesson I take away is that when you adopt AI, whatever the use case, you must do so by incorporating a layer of security. And don’t assume a platform is secure just because it comes from an innovative AI company. In your opinion, what are the most important innovations in security platforms today? And how do they help customers and organizations stay protected? I’d like to identify three major areas where AI is transforming cybersecurity. The first is the use of AI to strengthen defense operations. Just as it has revolutionized software development, AI is changing how security teams work, enabling them to detect vulnerabilities, assess security posture, implement changes, and respond to threats more quickly, efficiently, and scalably. The second area is the protection of the AI ​​applications and agents themselves. As these technologies are integrated into corporate networks, the challenge arises of ensuring they do not become a new attack vector or expose sensitive information. This is a very recent field, driven by the rapid adoption of generative AI, in which there is still ample room for innovation. Finally, I want to emphasize the need to defend against increasingly rapid and sophisticated AI-driven attacks. To this end, I advocate combining advanced models capable of detecting zero-day vulnerabilities and anomalous behavior with AI systems that simulate the behavior of an ethical attacker. This way, organizations can anticipate cybercriminals, identify their attack surface, and strengthen their defenses before an incident occurs. The final question concerns the needs of small and medium-sized organizations, which want AI systems to be more transparent and easier to audit when they help detect or respond to threats. What are your thoughts on this? I believe explainability is a crucial part of what we must offer our clients as cybersecurity advocates. There’s always a tension between blocking something immediately and, at the same time, being able to explain why it was blocked. People like to understand what happened, and this presents a delicate balance. Therefore, my perspective is that we should automatically block as many threats as possible, without requiring human intervention, but we must also enable humans to understand what happened and modify the future behavior of the protection mechanisms. Víctor Manuel Fernández attending Engage 2026 as a guest of Check Point Software. View the full article

A security hole within AI dev tools has allowed attackers to escape sandboxes by misleading the humans in the loop who were supposed to knowingly approve the tool’s actions, according to cybersecurity research firm Wiz. “We discovered GhostApproval, a systematic vulnerability pattern affecting six of the top AI coding assistants: Amazon Q Developer, Anthropic Claude Code, Augment, Cursor, Google Antigravity, and Windsurf [now known as Devin Desktop],” the Wiz report said. “In each case, a malicious repository can trick the agent into accessing arbitrary files outside the workspace sandbox, potentially achieving remote code execution on the developer’s machine.” The first report of the hole came earlier this month from Cato Networks, but was limited to one platform, Cursor, whereas Wiz found that its impact was far wider. The underlying security problem, symbolic links (symlinks), is well known and has been leveraged for decades. But GhostApproval, Wiz noted, goes well beyond their historic use as an attack vector. Symbolic links are special files that act as shortcuts to other files or directories. In attacks, they typically resolve to a target outside of the intended control sphere, which allows a threat actor to operate on unauthorized files in a less- or uncontrolled environment, outside of a secure sandbox, or even an air-gapped system. “In several cases,” Wiz noted, “the agent’s internal reasoning explicitly recognizes the dangerous target, yet the confirmation prompt shown to the user conceals this information entirely. This is CWE-451 – UI misrepresentation of critical information – layered on top of the symlink vulnerability. The user approves what they believe is a harmless local edit. The agent then writes to a sensitive file outside of the project workspace.” Wiz said it reported the issue to the six vendors initially impacted; AWS, Cursor and Google “fixed the issue promptly,” Augment and Windsurf/Devin “acknowledged receipt but went silent,” and Anthropic had already fixed the problem before it was contacted by Wiz. Potentially massive exposure But analysts and consultants said the AI dev tool problem that Wiz described illustrates a far greater security risk: enterprises are trusting these tools and the information they report far too much, which is what may give attackers a big opportunity. Katie Norton, senior research manager for DevSecOps at IDC, noted that the Wiz report pointed out a disturbing fact. “The safety check people rely on to catch these actions doesn’t actually stop anything. That’s a real way for an attacker to break into a developer’s machine,” she said. “The scope is bounded by one condition: the attack requires a developer to clone and operate on an untrusted or malicious repository. That concentrates the risk in workflows touching external contributors, forked repositories, and third-party or open source dependencies, rather than in internally authored code.” Norton said the exposure from this flaw, along with similar holes in other AI dev tools, is potentially massive. “Since March 2025, security vendors and researchers have disclosed comparable issues in nearly every major AI coding assistant. That pattern: a mitigation ships, then a new bypass of that same mitigation surfaces within months. That is worth watching and reflects how new this category’s threat model still is across the board, it’s not a gap specific to any one vendor’s practices.” That means, she said, that agentic coding tools need multilayered defense, because the risk isn’t confined to the code an agent generates. “The tools themselves sit within the software supply chain and can be attacked directly. GhostApproval makes that point clearly,” she noted. “The vulnerability has nothing to do with code quality or insecure output. It’s a flaw in how the agent handles files and represents its own actions to the user, introduced by the tool’s design rather than a bad prompt or a compromised dependency. Failure to account for the coding tools’ own attack surface is what leaves this kind of gap unaddressed.” Rethink policies and procedures Noah Kenney, principal consultant at Digital 520, agreed; enterprise CISOs need to potentially rethink many of their AI dev tool policies and procedures. “The significant part is that the agent’s own reasoning identified the malicious target and the approval dialog hid it anyway. The tool knew it was writing to SSH keys and still asked a human to approve an edit to a config file, giving the human an illusion of control over the model,” Kenney said. “Many considered human in the loop to be the answer to agent risk, but this report shows that the loop can be fed bad information by the very agent it is supposed to be supervising.” Because of this, Kenney advised adjusting the way tool management is enforced. “Treat AI coding assistants as privileged software with filesystem access, not as editor plugins. That means patch discipline, version pinning, and knowing which tools in your environment write to disk before authorization,” Kenney said. “Then sandbox the blast radius. These agents should run against trusted repositories in isolated environments where a write to authorized_keys goes nowhere. Do not rely on the tool’s own dialog as your control or governance solution.” A category-wide design issue Justin Greis, CEO of consulting firm Acceligence, added that this security hole is a much bigger enterprise security strategy problem than most CISOs realize. “Six different vendors independently arrived at a very similar trust model. That suggests we’re looking at a category-wide design challenge rather than a collection of isolated implementation bugs. If vulnerabilities like this remained uncorrected, they would represent a meaningful enterprise risk, particularly for organizations that allow AI coding assistants to interact with untrusted repositories or production development environments,” he said. “The immediate concern isn’t simply remote code execution. It’s that these agents operate with a level of filesystem access, tool access, and developer trust that traditional IDE extensions never had. Once an AI agent becomes an active participant in software development, every trust boundary it crosses becomes part of the organization’s attack surface.” View the full article

A security hole within AI dev tools has allowed attackers to escape sandboxes by misleading the humans in the loop who were supposed to knowingly approve the tool’s actions, according to cybersecurity research firm Wiz. “We discovered GhostApproval, a systematic vulnerability pattern affecting six of the top AI coding assistants: Amazon Q Developer, Anthropic Claude Code, Augment, Cursor, Google Antigravity, and Windsurf [now known as Devin Desktop],” the Wiz report said. “In each case, a malicious repository can trick the agent into accessing arbitrary files outside the workspace sandbox, potentially achieving remote code execution on the developer’s machine.” The first report of the hole came earlier this month from Cato Networks, but was limited to one platform, Cursor, whereas Wiz found that its impact was far wider. The underlying security problem, symbolic links (symlinks), is well known and has been leveraged for decades. But GhostApproval, Wiz noted, goes well beyond their historic use as an attack vector. Symbolic links are special files that act as shortcuts to other files or directories. In attacks, they typically resolve to a target outside of the intended control sphere, which allows a threat actor to operate on unauthorized files in a less- or uncontrolled environment, outside of a secure sandbox, or even an air-gapped system. “In several cases,” Wiz noted, “the agent’s internal reasoning explicitly recognizes the dangerous target, yet the confirmation prompt shown to the user conceals this information entirely. This is CWE-451 – UI misrepresentation of critical information – layered on top of the symlink vulnerability. The user approves what they believe is a harmless local edit. The agent then writes to a sensitive file outside of the project workspace.” Wiz said it reported the issue to the six vendors initially impacted; AWS, Cursor and Google “fixed the issue promptly,” Augment and Windsurf/Devin “acknowledged receipt but went silent,” and Anthropic had already fixed the problem before it was contacted by Wiz. Potentially massive exposure But analysts and consultants said the AI dev tool problem that Wiz described illustrates a far greater security risk: enterprises are trusting these tools and the information they report far too much, which is what may give attackers a big opportunity. Katie Norton, senior research manager for DevSecOps at IDC, noted that the Wiz report pointed out a disturbing fact. “The safety check people rely on to catch these actions doesn’t actually stop anything. That’s a real way for an attacker to break into a developer’s machine,” she said. “The scope is bounded by one condition: the attack requires a developer to clone and operate on an untrusted or malicious repository. That concentrates the risk in workflows touching external contributors, forked repositories, and third-party or open source dependencies, rather than in internally authored code.” Norton said the exposure from this flaw, along with similar holes in other AI dev tools, is potentially massive. “Since March 2025, security vendors and researchers have disclosed comparable issues in nearly every major AI coding assistant. That pattern: a mitigation ships, then a new bypass of that same mitigation surfaces within months. That is worth watching and reflects how new this category’s threat model still is across the board, it’s not a gap specific to any one vendor’s practices.” That means, she said, that agentic coding tools need multilayered defense, because the risk isn’t confined to the code an agent generates. “The tools themselves sit within the software supply chain and can be attacked directly. GhostApproval makes that point clearly,” she noted. “The vulnerability has nothing to do with code quality or insecure output. It’s a flaw in how the agent handles files and represents its own actions to the user, introduced by the tool’s design rather than a bad prompt or a compromised dependency. Failure to account for the coding tools’ own attack surface is what leaves this kind of gap unaddressed.” Rethink policies and procedures Noah Kenney, principal consultant at Digital 520, agreed; enterprise CISOs need to potentially rethink many of their AI dev tool policies and procedures. “The significant part is that the agent’s own reasoning identified the malicious target and the approval dialog hid it anyway. The tool knew it was writing to SSH keys and still asked a human to approve an edit to a config file, giving the human an illusion of control over the model,” Kenney said. “Many considered human in the loop to be the answer to agent risk, but this report shows that the loop can be fed bad information by the very agent it is supposed to be supervising.” Because of this, Kenney advised adjusting the way tool management is enforced. “Treat AI coding assistants as privileged software with filesystem access, not as editor plugins. That means patch discipline, version pinning, and knowing which tools in your environment write to disk before authorization,” Kenney said. “Then sandbox the blast radius. These agents should run against trusted repositories in isolated environments where a write to authorized_keys goes nowhere. Do not rely on the tool’s own dialog as your control or governance solution.” A category-wide design issue Justin Greis, CEO of consulting firm Acceligence, added that this security hole is a much bigger enterprise security strategy problem than most CISOs realize. “Six different vendors independently arrived at a very similar trust model. That suggests we’re looking at a category-wide design challenge rather than a collection of isolated implementation bugs. If vulnerabilities like this remained uncorrected, they would represent a meaningful enterprise risk, particularly for organizations that allow AI coding assistants to interact with untrusted repositories or production development environments,” he said. “The immediate concern isn’t simply remote code execution. It’s that these agents operate with a level of filesystem access, tool access, and developer trust that traditional IDE extensions never had. Once an AI agent becomes an active participant in software development, every trust boundary it crosses becomes part of the organization’s attack surface.” View the full article

A cloud intrusion that ended with the deployment of cryptomining malware has exposed a bigger risk for enterprises: AI gateways that concentrate access to cloud identities, permissions, and foundation models in a single, highly privileged system. Researchers from cybersecurity firm Darktrace found attackers compromising an AWS EC2 instance acting as a LiteLLM proxy for Amazon Bedrock, eventually deploying XMRig cryptomining malware, along with attempts to abuse cloud identities and AI services. Although the attack ended in cryptomining, researchers said the bigger concern is that AI gateways centralize model access, identities, and cloud privileges, making them valuable targets. Experts found the attack familiar and consistent with past cloud attack techniques. “Strip off the AI branding and this is a cloud intrusion pattern we’ve been watching since at least 2018: SSH open to the internet, brute-force attempts, a commodity XMRig miner, and repeated connections to a mining pool,” said Sean Malone, CISO at BeyondTrust. “Even the AI-specific angle, stolen credentials probing Bedrock model access, has had a name since 2024: LLMjacking.” However, Malone agreed with Darktrace researchers on the potential blast radius. “AI gateways concentrate credentials, cloud permissions, and model access into a single choke point, so a routine intrusion lands on a privileged asset,” he explained. The attack followed a known pattern According to Darktrace, the compromised EC2 instance appeared to support LiteLLM activity and was associated with an IAM role capable of accessing Amazon Bedrock resources. While researchers could not conclusively determine the initial access vector, they said the attack followed a sequence commonly seen in cloud intrusions. Before the miner was deployed, the instance had SSH exposed to the internet, with port 22 accessible from anywhere. Darktrace observed a high volume of inbound SSH connection attempts, largely originating from a single external IP address, indicating probable brute-force activity. Shortly afterward, the host downloaded a ZIP archive containing XMRig cryptomining malware before repeatedly connecting to a known mining pool over HTTPS. Darktrace stressed that it could not confirm whether the SSH activity directly led to the compromise because host-level logs were unavailable. However, the timing of the SSH exposure, miner download, and subsequent mining-pool communications strongly suggested the EC2 instance had been compromised and repurposed for unauthorized compute activity. Compromised AI gateways are a big deal The disclosure also detailed suspicious IAM activity observed separately, a day later, by another AWS identity. Among the unusual actions were a “GetSendQuota” API call from an IP address in Vietnam, attempts to enumerate and invoke Amazon Bedrock foundation models, and an effort to create a new IAM user using a randomly generated username. This behavior is commonly associated with establishing persistence following credential compromise. However, Darktrace could not link the IAM activity directly to the LiteLLM incident. Jason Soroko, senior fellow at Sectigo, said the incident’s significance lies less in the cryptominer than in the system that was compromised. “These gateways are becoming brokers for identity, model access, prompts, logs, and policy,” he noted. “When one is exposed over SSH or backed by broad IAM permissions, it is no longer just another EC2 instance. It is a control point for AI operations.” To protect against such attacks, Soroko added, security teams should close public admin paths, remove long-term keys where possible, scope IAM permissions, monitor Bedrock and model access patterns, and correlate workload telemetry with control-plane events. Darktrace said it helped in the timely containment of the attack. “The cryptomining activity was received by Darktrace’s Managed Threat Detection service and reviewed by Darktrace’s SOC,” the researchers said in a blog post shared with CSO ahead of its publication on Thursday. “Following review, the activity was escalated to the customer. This escalation provided the customer with timely notification of active resource abuse in the AWS environment.” View the full article

A cloud intrusion that ended with the deployment of cryptomining malware has exposed a bigger risk for enterprises: AI gateways that concentrate access to cloud identities, permissions, and foundation models in a single, highly privileged system. Researchers from cybersecurity firm Darktrace found attackers compromising an AWS EC2 instance acting as a LiteLLM proxy for Amazon Bedrock, eventually deploying XMRig cryptomining malware, along with attempts to abuse cloud identities and AI services. Although the attack ended in cryptomining, researchers said the bigger concern is that AI gateways centralize model access, identities, and cloud privileges, making them valuable targets. Experts found the attack familiar and consistent with past cloud attack techniques. “Strip off the AI branding and this is a cloud intrusion pattern we’ve been watching since at least 2018: SSH open to the internet, brute-force attempts, a commodity XMRig miner, and repeated connections to a mining pool,” said Sean Malone, CISO at BeyondTrust. “Even the AI-specific angle, stolen credentials probing Bedrock model access, has had a name since 2024: LLMjacking.” However, Malone agreed with Darktrace researchers on the potential blast radius. “AI gateways concentrate credentials, cloud permissions, and model access into a single choke point, so a routine intrusion lands on a privileged asset,” he explained. The attack followed a known pattern According to Darktrace, the compromised EC2 instance appeared to support LiteLLM activity and was associated with an IAM role capable of accessing Amazon Bedrock resources. While researchers could not conclusively determine the initial access vector, they said the attack followed a sequence commonly seen in cloud intrusions. Before the miner was deployed, the instance had SSH exposed to the internet, with port 22 accessible from anywhere. Darktrace observed a high volume of inbound SSH connection attempts, largely originating from a single external IP address, indicating probable brute-force activity. Shortly afterward, the host downloaded a ZIP archive containing XMRig cryptomining malware before repeatedly connecting to a known mining pool over HTTPS. Darktrace stressed that it could not confirm whether the SSH activity directly led to the compromise because host-level logs were unavailable. However, the timing of the SSH exposure, miner download, and subsequent mining-pool communications strongly suggested the EC2 instance had been compromised and repurposed for unauthorized compute activity. Compromised AI gateways are a big deal The disclosure also detailed suspicious IAM activity observed separately, a day later, by another AWS identity. Among the unusual actions were a “GetSendQuota” API call from an IP address in Vietnam, attempts to enumerate and invoke Amazon Bedrock foundation models, and an effort to create a new IAM user using a randomly generated username. This behavior is commonly associated with establishing persistence following credential compromise. However, Darktrace could not link the IAM activity directly to the LiteLLM incident. Jason Soroko, senior fellow at Sectigo, said the incident’s significance lies less in the cryptominer than in the system that was compromised. “These gateways are becoming brokers for identity, model access, prompts, logs, and policy,” he noted. “When one is exposed over SSH or backed by broad IAM permissions, it is no longer just another EC2 instance. It is a control point for AI operations.” To protect against such attacks, Soroko added, security teams should close public admin paths, remove long-term keys where possible, scope IAM permissions, monitor Bedrock and model access patterns, and correlate workload telemetry with control-plane events. Darktrace said it helped in the timely containment of the attack. “The cryptomining activity was received by Darktrace’s Managed Threat Detection service and reviewed by Darktrace’s SOC,” the researchers said in a blog post shared with CSO ahead of its publication on Thursday. “Following review, the activity was escalated to the customer. This escalation provided the customer with timely notification of active resource abuse in the AWS environment.” View the full article