CSOonline

Stephen Wilson, field chief technology officer for HashiCorp, an IBM company, likens AI agents to “really smart kindergartners.” “They know how to do something, but they have no clue as to why they should do it,” Wilson says. This combination of superior execution power and lack of judgment can create a significant challenge for organizations trying to fit AI agents into their existing zero trust architectures. In a robust zero trust environment, Wilson notes, human users are first authenticated, then given escalating decision-making powers and access over time, with many organizations potentially taking weeks to onboard an IT employee with elevated privileges. But that model breaks down with AI agents that can be spun up for single tasks and then quickly destroyed. “Imagine having to onboard and offboard one of these entities within your ecosystem once every second,” Wilson says. “The introduction of AI agents isn’t necessarily creating new problems. But it is exacerbating problems that have always been there.” ‘You don’t know when they’re going to be wrong’ The pressure for organizations to aggressively adopt AI has brought a corresponding pressure to lower or delete barriers between authentication, decision-making, execution, and authorization, Wilson says. Rather than rearchitecting their zero trust programs for AI agents, many organizations are essentially giving the tools broad access and hoping for the best. “These agents move so quickly, and no one is quite certain exactly what access they should have,” Wilson says. “I’ve never seen this before, where really smart security people are just closing their eyes and moving at a rate that can be dangerous.” Already, unfettered access for agentic AI could unleash “calamity” within some organizations, Wilson says, with a report emerging that an AI agent deleted entire production databases. “We’ve seen an example of months and months of work disappearing, even in stable software development environments,” Wilson says. “Even if we estimate that AI agents are right 80% of the time, the problem is the other 20%—what happens when they’re wrong?” Taking the long view While agentic AI can raise short-term security problems, Wilson sees the technology as a forcing function that will spur long-term improvements to organizations’ zero trust environments. “We’re at an inflection point where we’re going to have to do the hard things,” he says. “With human users, we’ve accepted that we’re not going to move as fast as we want, and we’re going to have to say no a lot. But this is a tidal wave.” Wilson likens the rise of agentic AI to the debut of the iPhone (“but 10 times more potent”), noting that smartphones forced organizations to create security and governance practices for bring-your-own-device (BYOD) and remote work programs. “Before the iPhone, there was no such thing as BYOD,” he says. “It was very painful at first, but we would not have remote work if it wasn’t for the iPhone.” “AI brings that same challenge,” Wilson says. Doing the hard things, he adds, means moving to zero standing privilege, issuing dynamic credentials at the moment of use rather than relying on long-lived secrets, and building security in rather than bolting it on. The goal is to keep the human “on the loop” rather than in it, supervising agents without slowing them down. “Some organizations are going to take some hard lumps, but I think we’re going to be more secure in the long run.” To learn more, visit us here. View the full article

Existing security controls weren’t designed for AI agents. Static credentials and standing privileges aren’t sufficient for an emerging model where organizations need to rapidly authorize, limit, and revoke permissions from autonomous agents, sometimes more than once within a single workflow. Agentic AI requires organizations to carefully consider how to govern agentic identity, agent-to-agent communication, secrets management, privileged access, and workforce identity. Agentic identity The first challenge is to establish a reliable identity for agents themselves. The “how” here is still being hotly debated. Some organizations treat AI agents as another form of non-human identity, similar to service accounts or machine identities. Others argue that agents should be their own category, distinct from both human users and machine accounts. In any case, agents need something like a “certificate” to give them an identity that can be recognized and governed across environments. This is especially important because, in most enterprises, agents will operate across multiple environments, including cloud platforms, on-premises systems, and SaaS applications. Agent-to-agent communication Securing agentic AI requires organizations to limit not only which resources AI agents can access, but also which other access-enabled agents they can communicate with. This is often currently handled with Model Context Protocol (MCP) gateways, although this approach is largely giving way to the use of agentic mesh. An agentic mesh is a distributed architecture where multiple specialized AI agents can discover one another, coordinate, and collaborate on tasks without a central controller. This approach lets organizations overlay intent-based communication rules via certificates, but also allows permissions to be revoked on demand. Agentic secrets Traditionally, secrets like passwords and API keys are managed via requests through IT service management platforms. But this mechanism doesn’t work for AI agents, which operate too quickly and across too many systems to rely on static credentials. Instead, secrets should be generated dynamically, used for a specific purpose, and then retired when the task is complete. This approach can be compared to modern hotel key cards. Unlike the physical room keys of the past, a key card is issued for a specific stay, but after that, it becomes worthless to both legitimate users and malicious actors. Privileged access AI agents may start with the same permissions as a given human user, drawing on relevant business systems and data for context. However, as workflows get handed off from agent to agent, this privilege should not be passed along throughout the process. Rather, privileges should be whittled down at each stage until only a thin layer remains to authorize a specific execution step. Workforce identity Organizations already manage the identities of human workers, of course, but often these identities are handled differently across separate management platforms and sign-on tools. To support agentic AI, organizations must find ways to break through this fragmentation, ensure that worker identities are current, and translate workforce permissions correctly into agentic workflows. A lifecycle approach to identity These five areas should not be addressed in isolation. Rather, organizations should apply governance and observability across the identity lifecycle, ensuring that every agentic action can ultimately be traced back to approved access and permission levels. The outcomes of this effort—including dynamic access, the principle of least privilege, strong identity, and clear auditability—are goals that many organizations have long been pursuing. The rise of agentic AI makes them more urgent than ever. To learn more, visit us here. View the full article

Ever since ChatGPT made its public debut nearly four years ago, governance and security have largely lagged behind AI adoption. Eager to experiment with AI tools and find ways to improve their work and personal lives, users have uploaded corporate data, financial records, and even their own health information to large language models (LLMs). While this freewheeling activity presents obvious risks, many users and businesses have so far been spared from catastrophic consequences. Stephen Wilson, field chief technology officer for HashiCorp, an IBM company, notes that most people are still using AI tools largely as “assistants,” with the technology only taking action at the direction of human users. But, as AI agents are given more ability to act on their own, the risk calculus is changing. And so far, Wilson says, security and governance practices aren’t keeping up. “Right now, what’s happening is that organizations are starting to use AI tools as full partners but governing the tools the same way they did when they were only using them as assistants,” Wilson says. “When AI is an assistant, the user is very close to the execution, and they’re handing over API keys, social media credentials, and bank information. But now we’re starting to ask AI to do things on our behalf autonomously.” As organizations move from assisted use cases toward more autonomous workflows, Wilson says, they need to mature their governance models across three common adoption patterns: AI as assistant, AI as an agent, and AI as operator. AI as assistant The most basic and widespread form of enterprise AI adoption is AI as an assistant. In this model, a human remains close to the work, using the technology to summarize information, draft content, generate code, and complete other discrete tasks. The user enters a prompt, evaluates the response, and decides what to do next. Although humans remain close to the execution at this stage, activity is not free from risk. When users interact with AI assistants, they can easily bring sensitive data, credentials, or permissions with them into the workflow. A user with privileged access might paste an API key into a prompt or even ask an LLM to analyze confidential records. “You need to have a very tight handoff from the human identity to the machine identity,” Wilson says. “You also need to be able to govern what that machine can access from a machine-to-service perspective, because if I get elevated privilege, it’s not hard to inject that privilege into the context window.” At the assistant stage, organizations largely need to ensure that AI activity is governed by the same boundaries already established for users. But as AI moves from answering prompts to completing work, those governance boundaries must expand. AI as an agent At this stage, human users begin asking AI tools to complete certain tasks autonomously. For example, instead of going back and forth with an LLM to outline and draft a piece of content, a user might simply give an AI tool a set of inputs and basic instructions and then ask the tool to generate the piece on its own. In fact, the writing agent may even pass off the finished draft to an editing agent or other AI tools before coming back to a human user. “When that happens, the governance controls and the identity and auditability have to go up because you’re moving the human out of the loop even more,” Wilson says. “With AI assistants, the human is still the initiator of the request that happens back and forth. But with AI as agent, you’re making a request and then just letting it run.” At this stage, Wilson says, organizations must determine what level of access different agents need to complete certain tasks, as well as how to confer identity upon AI agents. “How do you manage the persona? How do you accelerate its ability to be more correct often? These are the things you have to think about as you start to move to AI as an agent.” AI as operator This is the stage where AI agents take on not just individual tasks but entire projects. Instead of prompting agentic tools to write and edit a single article, an organization might ask a team of AI agents to design and execute an entire marketing campaign. “The human comes back in two or three hours and has the entire project, including where to publish, individual social media posts, and engagement strategies,” Wilson says. “The level of governance and identity and auditing have to increase as your level of oversight decreases.” Wilson notes that it is important at this stage to establish strong governance not only around data access but also around accuracy. For example, if an AI agent creates social media content, the organization needs to know that the content uses approved messaging, moves through the right review process, and is published only through authorized channels. This is a complex challenge because AI agents are probabilistic systems, while many enterprise workflows are deterministic. Before giving agents the power to complete these workflows, Wilson says, leaders must think carefully about where AI-generated work should end and controlled execution should begin. The road ahead Most organizations are only beginning to deploy agentic AI beyond the assistant stage, and Wilson notes that security leaders are still debating the right governance, identity, auditability, and observability models for these systems. But the overarching governance demand is clear: As AI systems gain more autonomy, organizations must implement more rigorous controls. An AI assistant can be governed largely as an extension of the individual user. An AI agent must be governed as part of a team, with clear visibility into the work it performs and the systems it touches. And an AI operator must be governed as a business function, with controls that span data access, workflow execution, approvals, and audit trails. “Your scope of governance, identity, and observability has to increase at the same rate as if you were moving from an individual to a team to an organization,” Wilson says. To learn more, visit us here. View the full article

A fully autonomous AI agent conducted an end-to-end cyber intrusion and extortion campaign after exploiting a vulnerable Langflow server, demonstrating how large language models could accelerate ransomware operations, according to research published by Sysdig. Sysdig detailed the operation in a research paper, saying the AI agent, dubbed JadePuffer, completed the entire intrusion chain, from initial access to database extortion, using an LLM to adapt its actions and execute more than 600 coordinated payloads. “The Sysdig Threat Research Team (TRT) has captured what we assess to be the first documented case of agentic ransomware: a complete extortion operation driven end-to-end by a large language model (LLM),” Michael Clark, director of threat research at Sysdig, wrote in the paper. Sysdig classifies JadePuffer as an agentic threat actor, meaning its attack capability was delivered by an AI agent rather than a human-driven toolkit. A known flaw opens the door According to Sysdig, JadePuffer gained initial access by exploiting CVE-2025-3248, an RCE vulnerability in an internet-facing Langflow instance, before pivoting to a production server running MySQL and Alibaba’s Nacos configuration platform. The AI agent harvested credentials, established persistence, mapped internal services, and ultimately encrypted 1,342 Nacos configuration records before deleting the original tables and leaving behind a Bitcoin ransom demand. Clark wrote that what distinguished the campaign was not the exploitation techniques, which largely relied on known vulnerabilities and misconfigurations, but the AI agent’s ability to make operational decisions throughout the intrusion. Sysdig said the operation touched two separate machines: the compromised Langflow host that provided initial access, and a second production database server that was the agent’s true objective. All payloads, the researchers said, were delivered as Base64-encoded Python sent through the Langflow remote-code-execution endpoint. “The most striking characteristic, however, was the LLM’s behavior,” he wrote. “JADEPUFFER’s own payloads were self-narrating. They contained natural language reasoning, target prioritization, and the kind of detailed annotations that human operators don’t often write but LLM-generated code produces reflexively.” The paper cited multiple instances where the AI agent diagnosed failures and generated corrected payloads without human intervention. In one case, it recovered from a failed attempt to create an administrator account in Alibaba’s Nacos platform within 31 seconds. Sysdig said the behavior, along with self-narrating code and contextual reasoning, supported its assessment that the operation was LLM-driven. Experts see evolution, not a revolution Independent cybersecurity researcher and red teamer Vibhum Dubey said the campaign represents “an evolution in execution” rather than a fundamentally new ransomware technique. “I see it more as an evolution in execution than a completely new ransomware technique,” Dubey said. “Attackers have automated reconnaissance, credential theft, and deployment for years. The difference is that an AI agent can connect those stages together and make decisions without waiting for a human operator.” Adaptive decision making is the biggest concern, he said. “Traditional detections assume attackers follow fairly predictable paths. An AI agent can quickly change tactics if something is blocked, making every intrusion look slightly different. I’m less worried about the encryption stage than the quiet phase beforehand, where the agent maps identities, privileges, and trust relationships while avoiding detection.” Rather than focusing on individual tools, defenders should prioritize detecting attacker behavior, including suspicious identity activity, privilege escalation, abnormal authentication patterns, and unusual sequences of actions across systems, Dubey said. Although AI lowers the operational barrier for ransomware campaigns, it does not replace experienced attackers, he added. “Where AI makes a difference is helping less experienced operators chain together post-exploitation activities more effectively. Defenders should assume future intrusions will move faster and require less hands-on interaction from the attacker.” Behavioral detection remains key Autonomous AI agents capable of independently executing multiple stages of an attack represent “an evolution rather than a revolution,” said Prashant Sharma, cybersecurity consultant at Cyble. “AI-assisted techniques have been in use for some time, but the emergence of autonomous agents capable of independently executing multiple stages of an attack could substantially increase the speed, scale, and adaptability of ransomware operations,” Sharma said. He said threat actors are already using AI to improve phishing, malware development, reconnaissance, and social engineering, and he expects autonomous capabilities to become more common as the technology matures. For enterprise defenders, however, the security priorities remain largely unchanged. “Modern EDR, XDR, and SOC platforms are built to flag malicious behavior rather than the underlying technology driving it,” Sharma said. “Whether an attack is carried out manually or orchestrated by an AI agent, actions such as credential abuse, privilege escalation, lateral movement, data exfiltration, and ransomware deployment still leave detectable behavioral traces.” View the full article

Higher education has consolidated its entire academic operation into a handful of massive SaaS platforms. The LMS manages instruction, grading and communication. The SIS owns enrollment, records and financial aid. Identity and productivity live in a small number of cloud providers. These are not peripheral tools — they are the operational infrastructure of the institution. As IT stewards, we manage platforms we do not own, cannot restore ourselves and cannot directly control — which makes contingency planning not optional, but fundamental to the role. The contracts are in place. The SLAs are signed. The compliance certifications are current. None of that matters to a student who cannot reach her instructor three days before finals. None of it matters to a faculty member who has no roster, no grade book and no way to document the work his students submitted before the platform went dark. SLAs govern vendor response timelines. Keeping academic operations running during that response window is IT’s responsibility. The disruption hit during finals week 2026, and I was doing what every CIO in higher education was doing — monitoring. A major learning management system had been breached. The disruption spread fast. Finals were canceled. Exams were postponed. Students and staff were stranded without access to coursework, rosters or grade books. The costs — in academic disruption, extended contracts, emergency response — were substantial and widely reported. My institution was not directly impacted. But watching peer institutions in my own state go dark during the highest-stakes moment of the academic calendar was not reassuring. It was a confirmation of something I had been thinking about for a long time. The disruption proved something IT professionals have relearned in every decade of their careers. Mark Twain observed that history does not repeat itself, but it does rhyme. This is a verse we have heard before: Dependence on a single point of failure, without a tested contingency plan, is not a strategy — it is a risk that has simply not yet been called. Whether the failure comes from a cyberattack, a vendor outage, an infrastructure collapse or a cloud provider’s bad deployment, the result is the same. The institution stops. And no SLA, contract or compliance certification prevents that moment from arriving. Vigilance is not optional. Technologies are evolving faster than any IT team can fully anticipate. New platforms, new integrations, new dependencies emerge constantly — and with each one comes a new potential failure point. That is not an argument against adopting new technology. It is an argument for the one principle that never becomes obsolete: Reliance on any single critical system, whether it is a connectivity provider, an identity platform or a SaaS solution, is a proven strategy for failure. The question is never whether that system will fail. The question is whether the institution is prepared when it does. Single points of failure fail — inevitably, and at the worst possible time. IT professionals have known this for thirty years. The SaaS layer is not exempt. This is not a new lesson. Azure has gone down. AWS has failed. Google Workspace has had outages that took organizations dark globally. No campus runs a single ISP connection — we provision redundant circuits, preferably from independent providers, because we learned long ago that the connection will sometimes fail and the institution cannot afford to stop when it does. Financial services, government and multinational enterprises applied that same logic to every dependency in their stack. Their response to platform risk was not to demand better SLAs. It was to architect around the dependency. Redundancy. Failover. Independent continuity capability. The massive disruptions from Canvas demonstrate that effective contingency solutions for these critical platforms have not kept pace with our dependence on them. We cannot get fooled again. That omission is what made the 2026 attack so damaging. Not the sophistication of the breach — the entry point was a peripheral free-tier environment that wasn’t even within the vendor’s primary certification scope. The damage was catastrophic because institutions had no fallback. Faculty had no rosters. Administrators had no enrollment data. There was no continuity layer. A single point of failure, at institutional scale, with no plan for when it fails. And now the economics have shifted in the worst possible direction. PowerSchool paid a ransom in December 2024 after attackers stole data on 60 million students — and was re-extorted anyway, with individual school districts receiving separate demands months later using the same stolen data. Instructure’s CEO publicly confirmed the extortion payment. Anyone who has paid a ransom only to be hit a second time at double the cost can tell you — paying the attackers resolves nothing and instead invites more attacks. The sector has now proven twice, publicly, and at scale, that it will pay. That changes the threat calculus entirely. Higher education stops being a target of opportunity and becomes a target of strategy. Criminal groups share that intelligence. Banner serves over 1,400 institutions. Blackboard reaches tens of millions of users across thousands of campuses. Every major higher education SaaS platform is now on active threat actor priority lists — not because they are newly vulnerable, but because the sector has proven it will pay, that academic calendar pressure creates maximum leverage, and that IT has not yet built the operational alternative that our dependence on these platforms demands — and therefore the failure is ours to own, especially if we allow it to happen a second time. The sector has proven it will pay. Every ransomware group operating today just received the same market signal. What follows is not unpredictable — it is documented, underway and aimed directly at the platforms carrying your institution’s academic operations. As a CIO, my approach to this is not a spreadsheet or a stack of printed reports. IT is responsible for identifying critical failure points and countering them — that is not optional; it is the job. Accepting failure as inevitable without a mitigation strategy is not viable. Redundancy and continuity solutions are standard practice everywhere else in our infrastructure. There was no reason the SaaS layer should be different. A leader’s first job isn’t to be right — it’s to be responsible. The solution I implemented is a secure, read-only, centralized repository — a continuity strategy that ensures students, staff and faculty can continue to function whether the issue is a power outage, a cyberattack or a SaaS platform going dark. It is not a replacement for Canvas or Banner. It is the independent fallback that allows the institution to keep operating while the primary system is restored. I have learned the hard way that accepting failure without a plan is not a posture any CIO can defend. Watching the frustration across the industry during and after the 2026 attack — institutions paralyzed, peer CIOs improvising, faculty working from personal spreadsheets, boards asking questions no one could answer — the logic of extending this capability to other institutions became unavoidable. The solution is not complex. The architecture is straightforward. The discipline behind it is thirty years old. The discipline is established. The responsibility to apply it is our field of expertise in IT. To be precise about scope: An ACR does not prevent vendor breaches, replace cyber insurance or remove notification obligations. When an incident hits, legal counsel, security teams and institutional leadership still manage the response. What the ACR changes is what they have to work with — a governed, auditable record of what data was accessed, what manual actions were taken and how operations continued while the vendor worked to restore service. Redundancy, disaster recovery, continuity of operations — the discipline is not new. The SaaS platforms carrying academic operations deserve the same standard we hold everywhere else. The solution to this problem exists. A SaaS third-party continuity of operations strategy requires an independent data layer — one the institution controls, synchronized on a regular scheduled cycle from source systems, and accessible when those systems are not. Platform-agnostic across Canvas, Banner, Blackboard and PowerSchool. Read-only by design. Auditable by requirement. Independent by architecture. That last word is the one that matters — independent of the platforms whose availability you cannot guarantee. Every CIO in higher education knows what a single point of failure looks like. Every one of us has built around them at every other layer. Servers, networks, data centers — we do not accept the single-point risk, and we do not wait for the failure to motivate the fix. The SaaS layer is not an exception. The question is not whether your institution will face it. The question is whether you will have a continuity strategy in place when it arrives — or be explaining to your board why you did not. Leaders don’t rent accountability — they own it outright. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

If you wanted to become a basketball star, how would you get started? You wouldn’t read a book on basketball and take an online course. You’d set up a hoop in your driveway, join a local team to train, and play in real matches. So why do we expect cybersecurity professionals to learn their skills from theory and static training? The cybersecurity industry talks constantly about the “skills gap.” The recent World Economic Forum’s Global Cybersecurity Outlook report revealed skills and budgets were significant blockers to achieving cyber resilience. However, I argue that we don’t have a skills gap; we have a validation gap. The “skills gap” gets a lot of airtime in cybersecurity industry discourse, but what are we really talking about when we talk about a skills gap? It’s not about staffing; how can we have both a skills gap and a graduate unemployment problem? “AI” is the lazy explanation (is there anything anyone hates more than hearing that their job could be replaced by AI?) But if AI really is the explanation, why are we still experiencing breaches and fixating on a supposed lack of skills in the cybersecurity workforce? The reality is that we don’t yet fully trust AI with our most critical security concerns, and for good reason. Few people would dispute that there are serious production risks in relying on AI and most wouldn’t actually use it to replace an experienced security analyst. While comparatively fewer organizations have reported serious breaches of AI models or applications, many are favoring rapid-scale deployments of AI technologies over establishing robust governance structures. Data from IBM suggests that, of 600 organizations polled globally between March 2024 and February 2025, 13% reported breaches of AI models or applications. More worrisome, 8% had no idea whether or not they had been compromised, and 63% of breached organizations either lacked AI governance policies or were developing them at the time of the reported incident. Despite these risks — and the significant financial damage they can cause — only 49% of organizations planned to invest in additional security measures in 2025, compared to 63% in 2024. You can’t hire or tool your way out of the skills gap. You have to build your way out. The industry keeps asking, “How do we close the cyber skills gap?” The better question is, how do we prove readiness before the fight begins? That is the real challenge emerging in cybersecurity today. This is more challenging when we need skills and expertise that just don’t exist yet. AI poses new threats to combat, from the development of more insecure software to the exploitation of models to do things they weren’t designed for to attackers weaponizing AI for more efficient attacks. No one was preparing to respond to these threats five years ago, so these skills need to be developed in real time. Even the most advanced training programs cannot hope to match the pace and scale of the vulnerabilities posed by AI and the increasingly broad attack surface it presents to potential threat actors. Relying on outdated training modalities is practically an invitation to attackers seeking to compromise critical systems, yet many organizations fail to recognize this as the systemic vulnerability it is. Traditional upskilling is flawed and wholly impractical for the present risk environment. Organizations are shelling out tens of thousands per employee on courses, certifications, and boot camps, but certifications simply cannot keep up with the pace of technological change and the evolution of attacker tactics and techniques. Security professionals need continuous hands-on experience that represents the actual attack surfaces of their organizations. How they apply their skills in real-world scenarios is a big part of what’s missing; even the most rigorous theoretical exercises cannot replicate the experience of combatting an intrusion event in real time or identify potential weaknesses in SOC response protocols. Our industry has traditionally seen technology as the answer. More tools and more alerts feel like we’re getting somewhere, but all it really leads to is teams that are fatigued and burned out on noise. When the main source of breaches remains human failure, we’re not going to tip the scales unless we invest in the people on the front line. Dynamic cyber ranges are the difference between learning a skill in theory and learning it in context. A truly effective upskilling cyber range needs an AI Proving Ground, with a high degree of customization and fidelity, as well as in-depth post-exercise analysis, to nurture and retain effective talent with the skills and experience to combat increasingly sophisticated threats. High degree of customization. Replicate your real production environment and tech stack and introduce panic-inducing live-fire exercises. This gives employees invaluable insight into how they’ll react in a real-life scenario. Does everyone have the right context and information to make quick decisions that will protect the business? Replicating a real production environment also allows for testing integration flows between security and IT tools to validate how they work together. Post-exercise analysis. It’s not enough to run tests if you can’t analyze the outcomes to make improvements. This data is also particularly useful as execs are pushing for tech consolidation by proving the need to retain budget or secure additional resources for tools and features. Cyber ranges can also make detailed recommendations based on best practices and support and identify specific business cases for additional investment. Nurture talent. How do you take a tier 1 SOC analyst and turn them into a tier 3? While AI might be able to perform the role of a junior analyst, you need a pipeline of talent to become that high-performing individual who could be the difference between spotting an unusual indicator of compromise or allowing an attacker to gain further access into critical systems. It’s faster and more cost-effective to teach someone over time than hunt out the top performer to hire into the organization. Nurturing and investing in existing talent also becomes a significant competitive advantage over time. For overstretched teams, on-the-job training might feel onerous, but the benefits are considerable. You really can see 10X returns on your investment. Some of our customers have saved upward of $400,000 in training expenses and made their organizations significantly more resilient to novel threats. The key is to not see practical, hands-on training as an annual event or one-off investment, but to employ a continuous platform that accurately reflects the risks faced by your organization and becomes part of your operating model and broader security culture. I don’t know about you, but working in a team environment feels far more rewarding than studying in a classroom environment. Retain your top talent by validating their skills and allowing them to add to their resumes in a way that feels natural and instinctive. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

A cyber risk assessment helps security teams identify, estimate, and prioritize potential threats and vulnerabilities to key enterprise digital and physical assets. Yet, despite its importance, many CISOs fall victim to several types of “gotchas” that prevent them from fully achieving their risk assessment goals. An assessment should be an essential part of every organization’s overall cybersecurity strategy. The process helps security leaders understand risks to business objectives, evaluate the likelihood and impact of cyberattacks, and develop ways to mitigate the risks they uncover. Here are the top seven mistakes security leaders should avoid to ensure risk assessment effectiveness. 1. Going through the motions The biggest “gotcha” is treating cyber risk assessments as a preset checklist or control inventory instead of a decision tool tied to real business impact and threat scenarios, says Shirsendu Mondal, a cybersecurity researcher at the University of North Carolina. “When assessments become all about checking boxes, they lose the ability to reflect how risk actually shows up in an environment,” he states. “The goal should be to inform decisions about where a business is truly exposed.” Mondal assers that the best way to avoid the complacency trap is to take a context-driven approach. “Ask where the asset is, who can reach it, what data it touches, how important it is to operations, and what happens if it goes down,” he explains. “Risk should always be tied to business impact, not only technical findings.” Mondal also recommends adding internal business leaders to security teams, including individuals in areas such as IT and operations, given that risk is more than a technical issue. 2. Sugarcoating results These are challenging times, so we must be honest with our stakeholders, says Pablo Riboldi, CISO at BairesDev, a nearshore software development firm. “When results are discouraging, admit that the threat landscape has evolved much faster than the previous evaluation framework anticipated,” he says. Instead of just handing over lists of vulnerabilities, you need to start presenting actual attack scenarios, Riboldi adds. “For example, by prioritizing the top three most critical business assets and conducting an in-depth assessment on them, you can show immediate value.” 3. Falling short on the scope of your assessments CISOs often securitize document controls, check compliance boxes, and produce a risk register that claims everything looks absolutely fine, says Denis Calderone, CTO at cybersecurity services firm Suzu Labs. Yet nobody bothered to test whether those controls actually work or stopped to ask whether the scope of the assessment covered what really matters. We see it all the time, Calderone says. “For instance, the assessment covers the production servers and the corporate network, but skips the old dev box in the corner, the third-party vendor portal nobody owns internally, or the API endpoint that was stood up for a project two years ago and never decommissioned.” Attackers don’t care about your scoping decisions, he says. “They look at the whole environment and find the thing you decided wasn’t worth assessing.” AI is making the situation worse, Calderone says. Organizations are deploying AI tools, connecting them to internal systems, granting them access to sensitive data, and none of this is landing in the risk assessment. Meanwhile, AI agents are out there making API calls, accessing databases, and operating with credentials that nobody is tracking, he says. “If your risk assessment was written before your organization started plugging AI into its workflows, it’s already stale,” Calderone warns. 4. Overindexing on the risk register without checking your assumptions When the goal becomes completing the assessment instead of understanding actual exposure, the output is a document that satisfies auditors but misleads leadership, says Amit Basu, CIO and CISO at International Seaways, a major independent maritime shipping company that transports crude oil and refined petroleum products worldwide. Such an attitude can create false confidence. Executives and board members see a completed risk register and assume the organization is protected, Basu says. Meanwhile, real threats go unaddressed because they didn’t fit neatly into the assessment framework. “The gotcha does not announce itself,” he explains. “It hides inside a green dashboard.” A risk assessment is only as good as the assumptions that lie underneath it, Basu observes. “Document those assumptions explicitly and review them whenever your business changes, when the threat landscape shifts, or when an incident exposes a gap,” he advises. “The assessment is not a finished product — it’s a living input to an ongoing conversation between security and the business.” 5. Failing to link risk with business impact Ignoring or downplaying the connection between risk and business makes it easier to de-prioritize or ignore problems, says Dan Moore, senior director of strategy and identity standards at FusionAuth, a customer identity and access management (CIAM) platform provider. “As a result, it becomes difficult to communicate the real risks of breaches and other risks,” he states. “Worse yet, it gives security team members an excuse to complain about being misunderstood or not valued, which degrades team effectiveness.” It’s important to be specific and targeted, Moore advises. “For instance, don’t say, ‘We have 95% patch compliance,’” he suggests. “Instead, talk about the risk unpatched systems pose to the business.” Some systems, such as legacy systems that aren’t connected to the internet or the core business, carry a lower risk than others, even if they have the same patch issues. “Acknowledge that fact and weigh your response.” 6. Confusing compliance with real-world security Compliance alone doesn’t lead to good security, nor does it satisfy even the baseline requirements for effective protection, says Adriel Desautels, CEO of Netragard, a penetration testing and security advisory company. Organizations tend to fall into this trap when they hire penetration testing firms that focus on compliance while promising top-tier services, Desautels says. “In truth, they deliver autonomous scanning masquerading as human-driven testing.” The result is a false sense of security — a paper seatbelt, Desautels warns. “You feel protected, but when you crash, even at low speed, you get injured or worse,” he says. “Remember, every major breach in the past decade involved an organization that was compliant at the time of compromise.” 7. Failing to fully understand risk Organizations often treat risk assessment as a vulnerability-cataloging exercise that includes finding gaps, counting severities, and passing the audit. Yet passing an audit and understanding risk are not the same thing, states Safi Raza, senior director of cyber security at Fusion Risk Management, a firm offering cloud-based operational resilience, business continuity, and risk management solutions. Raza says that CISOs should focus on connecting technical risk signals to operational outcomes. “This includes understanding what services are affected, how disruption propagates, and what it means for revenue, customers, or regulatory obligations.” Start by shifting from static assessments to continuous, context-driven risk visibility, Raza advises. “Risk needs to be understood not just technically, but in terms of business impact and financial exposure,” he states. View the full article

Microsoft users have been hit by a massive, automated password spray attack. Among those targeted by the attack were clients of security company Huntress. It reported that the attackers made 81 million attempts to log into its customers’ accounts between June 12 and 26 — and succeeded in at least 78 cases. And that’s just the attacks on Microsoft account holders who also happen to be Huntress customers: The number of compromised accounts could be much higher, as it’s in the nature of a password spray attack to attempt to connect indiscriminately. The attacks all came from a single source, an IPv6 address range controlled by internet provider LSHIY LLC, Huntress said in a blog post. LSHIY has since terminated access for the customer using the IP addresses involved in the attack. Huntress had been monitoring spray attacks for some time and had noticed a slight increase from June 12, and then a sudden spike on June 22 when 30 of its customers were affected. The attackers replayed validated credentials via the OAuth ROPC (Resource Owner Password Credentials) flow. This takes a username/password at the /token endpoint for a tenant and mints a new user-delegated token, once provided with the correct credentials. This was possible because multi-factor authentication (MFA) had not been configured to handle the techniques deployed by the attackers. Huntress said that this was because, in some cases, MFA had been enforced for specific apps instead of “All Cloud Apps.” For example, some organizations enforced MFA for Microsoft Admin Portals, which did not cover the Azure CLI logins used by the attacker. In other cases, organizations enabled MFA only for specific user groups (such as Admins Only). The compromised users were not in the scope of these specific user groups. View the full article

Adobe will now issue security patches for its products twice as often to deal with the increasing pace of software vulnerability discovery and exploitation. This follows Oracle’s decision to increase its quarterly patch program to a monthly one. Adobe issues patches on the second Tuesday of each month, as do Microsoft and SAP. Starting in July, it will also issue them on the fourth Tuesday of each month, it said in a blog post. As an early indicator of the need for the faster rhythm, it issued two security advisories dealing with a number of critical vulnerabilities on June 30 — the fifth Tuesday of that month: APSB 26-28 and APSB26-29. It is not alone in issuing out-of-sequence patches for urgent fixes: In April, Microsoft also released one to react to a particular threat. Adobe said in a blog post that it is responding to the increased level of threats: “Twice-monthly bulletins will enable us to keep pace with the era of frontier AI. More vulnerabilities found means more fixes to deploy and a once-a-month publication window is no longer fast enough to stay ahead of our adversaries. This new cadence is the direct result of investing in improved vulnerability discovery.” The new schedule will be effective from July 14 and will apply to every advisory that includes a formally published CVE requiring customer action. View the full article

Citrix NetScaler appliances have been a constant target for attackers in recent years, most recently through an information leak vulnerability dubbed CitrixBleed 3, the latest in a series of NetScaler memory overreads going back to 2023. This week, Citrix patched yet another CitrixBleed-like vulnerability and there are signs of in-the-wild exploitation already. The new memory overread vulnerability, tracked as CVE-2026-8451, was found by researchers from security firm watchTowr who published a detailed write-up showing how unauthenticated malformed requests can result in protected process memory data being leaked back in responses. The original CitrixBleed (CVE-2023-4966), CitrixBleed 2 (CVE-2025–5777), and CitrixBleed 3 (CVE-2026-3055) vulnerabilities were all rated critical because they could be used to leak session tokens and other credentials stored in memory. The new CVE-2026-8451 can only be used to leak much smaller amounts of data which do not appear to include session IDs. For this reason, Citrix gave it a CVSS score of 8.8 (high severity). For exploitation to be possible, the NetScaler appliance needs to be configured as a SAML Identity Provider, but this was also the case for CitrixBleed 3, which was patched in March and was subsequently exploited in the wild. So, this requirement doesn’t mean attacks are unlikely or that this configuration is uncommon. In fact, less than 24 hours after the Citirix patch, security firm Lupovis reported seeing exploitation attempts hitting its honeypot sensors. “Three separate sensors were targeted within a five-hour window,” the company said. “The actor received a 200 response on the third sensor and immediately delivered the exploit payload.” Smaller leak but still dangerous Even though watchTowr was only able to leak bytes of data using this flaw, compared to kilobytes with previous CitrixBleed issues, the exposed information could still be useful to attackers. While the proof-of-concept did not reveal credentials or tokens, it’s possible that repeated requests would eventually be able to leak something sensitive. At the very least, the leaks can expose process memory pointers that could allow attackers to more easily deliver payloads using memory write vulnerabilities such as buffer overflows. By overwriting data in a memory location that normally contains code the process executes, attackers could bypass anti-exploitation defenses like ASLR to take full control of the device. As part of this same patch cycle Citrix also addressed two high-severity memory overflow vulnerabilities, tracked as CVE-2026-8452 and CVE-2026-8655. Chaining exploits for different vulnerabilities is a common approach in modern attacks. The company also patched an unauthenticated arbitrary file read (CVE-2026-10816), another out-of-bounds memory overread (CVE-2026-10817) and a denial-of-service issue exploitable through HTTP/2 requests (CVE-2026-13474). The latter is actually a NetScaler-specific instance of the HTTP/2 Bomb vulnerability (CVE-2026-49975) patched recently in Apache Web Server. Mitigation Citrix advises customers to upgrade their NetScaler ADC and NetScaler Gateway appliances to versions 14.1-72.61, 14.1-72.61 FIPS, 13.1-63.18, 13.1-FIPS and 13.1-NDcPP 13.1.37.272. The HTTP/2 Bomb vulnerability also requires configuration changes in addition to the patches. These changes are described in the Citrix advisory along with methods to determine if appliances meet the configuration pre-conditions for exploitation for the other flaws. WatchTowr also published a Python detection script for the CVE-2026-8451 vulnerability that allows organizations to quickly test if their appliances are susceptible to the exploit. View the full article

A newly disclosed vulnerability in Argo CD is drawing attention to the security risks of GitOps platforms, with researchers warning that the flaw could allow attackers who gain a foothold inside a Kubernetes cluster to execute code and manipulate application deployments. Security firm Synacktiv said in a report that the flaw affects Argo CD’s repo-server component, which fetches content from Git repositories and generates Kubernetes manifests used to deploy resources in a cluster. Argo CD is one of the most popular Kubernetes tools and is based on the GitOps paradigm. “Argo CD requires significant privileges within the cluster,” Synacktiv said. “Additionally, it has access to private Git repositories, making it an attractive target for attackers.” The issue centers on the repo-server’s unauthenticated GenerateManifest gRPC endpoint. Synacktiv said an attacker able to reach that endpoint could supply Kustomize options in a manifest generation request and abuse Kustomize’s Helm-related build options to execute attacker-controlled commands. Exploitation requires access to both the repo-server gRPC port and the Redis database port, which should not be exposed to users. Argo CD provides Kubernetes network policies designed to prevent that scenario, but those protections are not enabled by default in Helm chart deployments, according to Synacktiv. In such deployments, compromising a single pod inside the cluster could be enough to give an attacker the internal access needed to exploit the vulnerability. Synacktiv said it was able to use the flaw to obtain the Redis password from the repo-server environment and access Argo CD’s Redis database. The researchers then manipulated cached deployment data, allowing a malicious manifest to be deployed automatically when Argo CD’s Auto Sync feature was enabled. If Auto Sync is not enabled, exploitation would require a user to manually sync the application. Synacktiv publicly disclosed the details on July 1, 2026, after first reporting the issue to Argo CD maintainers in January 2025. The vulnerability remains unpatched, and the firm recommended strict Kubernetes network policies to block untrusted pods from reaching the repo-server and Redis services until a fix is available. Assessing internal cluster exposure For CISOs, the key question is not only whether Argo CD is exposed to the internet, but whether other workloads inside the Kubernetes cluster can reach its internal services. “Because the repo-server’s gRPC service does not enforce authentication, any pod that can reach it becomes equivalent to an authenticated attacker,” said Devashri Datta, a cybersecurity researcher. “In a typical cluster, that means any compromised application pod, misconfigured service mesh, or adjacent workload with local code execution can directly query the GenerateManifest endpoint or hit the Redis cache, no internet exposure required.” Organizations should not equate “not internet-facing” with “low risk,” because modern attacks often begin with the compromise of an internal workload, according to Sakshi Grover, senior research manager for cybersecurity services research at IDC Asia/Pacific. “CISOs should therefore evaluate which workloads can communicate with the Argo CD control plane, whether east-west traffic is appropriately segmented, and whether unnecessary trust relationships exist between application workloads and GitOps infrastructure,” Grover said. “The assessment should focus on attack paths rather than perimeter exposure.” Treating GitOps as tier-zero The flaw also underscores the role GitOps platforms play in controlling software deployment across enterprise infrastructure. “GitOps engines aren’t utility services; they’re tier-0 control-plane components,” Datta said. “By design, Argo CD holds read access to private repositories, sync/write access to target clusters, and custody of deployment secrets. It sits at the precise intersection of source code, configuration management, and live infrastructure.” That level of access means an Argo CD compromise may extend beyond a single application. An attacker could turn the platform used to deploy applications into a channel for malicious manifests, while also interfering with auto-sync behavior and extracting credentials cached in supporting systems such as Redis. A compromise of these platforms could influence software delivery at scale, making them strategic assets that should be subject to stricter governance and privileged access controls similar to those applied to identity platforms and other critical management systems. View the full article

Researchers have discovered two vulnerabilities in the widely used Cursor AI-enabled integrated development environment (IDE) that can be exploited through prompt injection to achieve remote code execution (RCE). The two flaws, tracked as CVE-2026-50548 and CVE-2026-50549, allow attackers to break out of Cursor’s command execution sandbox, the protective layer that’s supposed to prevent the internal AI agent from performing rogue actions on the underlying operating system. “The exploit requires no prior user privileges or specific user interaction,” researchers from Cato Networks, who found the flaws, said in their report. “It is triggered when a victim makes an innocuous prompt that inadvertently ingests a threat actor-controlled payload from an untrusted source, such as an MCP server or a web search result.” Cursor, which was recently acquired by SpaceX for $60 billion in stock, produces one of the most widely used AI-assisted coding tools used in the enterprise space. The two flaws were patched in version 3.0 of the Cursor IDE, which was released in April. Native vulnerability in LLMs Large Language Models (LLMs) are natively vulnerable to malicious instructions that could be hidden inside the content they process. This is particularly dangerous in the age of agentic AI, where LLMs are combined with a variety of tools, including browsers and APIs that allow them to access a variety of third-party public content, such as parsing web pages in search results and RSS feeds, code in repositories, comments in bug trackers, emails in users’ inboxes, and their documents. Protecting AI tools from prompt injection is very hard, and usually involves a layered approach, including guardrails built into the model by the AI lab that created it, instructions in system prompts to treat certain content as passive data, supervisor models running on top of the LLMs that process data, traditional keyword filtering, context segmentation, granular access controls, adding humans back into the loop to approve sensitive operations and more. AI-assisted IDEs like Cursor, as well as command line agentic coding harnesses, usually prompt the user for approval by default for every file modification or command they need to execute. But this is not practical for autonomous coding workflows, and quickly leads to approval fatigue. Another way to address that issue is to run these autonomous workflows inside containers, virtualized environments, or sandboxes, so that if the agents execute malicious instructions due to rogue prompts injected in third-party data sources, the impact is limited. Cursor uses a command execution sandbox that by default limits file writes to the current project’s directory. Logic flaws in the isolation layer However, the Cato researchers discovered that the run_terminal_cmd tool supports a parameter called working_directory that allows overriding that default path programmatically. “A prompt injection (served through an innocuous MCP server request, or a poisoned web result) can steer the LLM to set the working_directory to a threat actor-controlled path outside the project scope,” they explained. By exploiting this oversight, attackers could overwrite the cursorsandbox executable itself from the application path, or could write malicious scripts to the shell configuration file which gets loaded every time the user executes a command, or to the system’s start-up folders such as ~/Library/LaunchAgents on macOS. Separately, the researchers also found that attackers could instruct the Cursor agent to create a symbolic link (symlink) file inside the project directory, pointing to a file that resides outside of the directory. “By default, the Cursor Agent attempts to canonicalize paths (resolving symlinks) to determine their true location and verify they are within the project root,” the researchers said. “The vulnerability occurs because the canonicalization logic contains a dangerous fallback: if canonicalization fails (for example, when the path doesn’t exist or if the path lacks read permissions on one of its directories), Cursor falls back to using the original symlink path inside the project directory.” These two vulnerabilities, which Cato has dubbed DuneSlide, can allow complete compromise of the underlying operating system through executing code outside of the restricted Cursor sandbox. More than that, however, they show that prompt injection can be an attack vector for exploiting vulnerabilities in the software used to implement the AI agents. Cursor is far from the only AI-powered IDE or coding harness, and, according to the researchers, not the only one that has such logic flaws in its isolation layers. “Had these issues been singular cases of compromise via prompt injections, we might have attributed them to specific vulnerabilities,” they said. “Cato AI Labs, however, is in the process of responsibly disclosing vulnerabilities in all popular coding agents, highlighting that a more systemic approach to protection is required.” View the full article

Detection engineering, which was once a niche practice among mostly large companies, appears to have evolved into a capability that organizations across industries now consider essential to their security operations. What is detection engineering? Detection engineering is about creating and implementing systems to identify potential security threats within an organization’s specific technology environment without drowning in false alarms. It’s about writing smart rules that can tell when something potentially suspicious or malicious is happening in an organization’s networks or systems and making sure those alerts are useful. The process typically involves threat modeling, understanding attacker TTPs, writing, testing and validating detection rules, and adapting detections based on new threats and attack techniques. A small survey of 264 cybersecurity professionals by the SANS Institute and Anvilogic found that 80% of organizations — and 85% of large enterprises — are actively investing in detection engineering, with 60% now having dedicated teams. More than two-thirds (67%) reported strong leadership support for the practice within their organization. The survey’s data suggested that many companies have not just merely adopted detection engineering practices but have made it a strategic focus of their cyber risk mitigation effort. “Just a decade ago, detection engineering was a relatively unknown role in cybersecurity,” the report stated. “Now, it is emerging as one of the most critical roles in security operations.” More than the usual threat detection practices Proponents argue that detection engineering differs from traditional threat detection practices in approach, methodology, and integration with the development lifecycle. Threat detection processes are typically more reactive and rely on pre-built rules and signatures from vendors that offer limited customization for the organizations using them. In contrast, detection engineering applies software development principles to create and maintain custom detection logic for an organization’s specific environment and threat landscape. Rather than relying on static, generic rules and known IOCs, the goal with detection engineering is to develop tailored mechanisms for detecting threats as they would actually manifest in an organization’s specific environment. Often this involves a stronger emphasis on behavior-based detections, the integration of threat intelligence to create detections aligned with real-world adversary tactics and the use of threat modeling to anticipate potential attack paths, says Heath Renfrow, CISO and co-founder of Fenix24 a cyber disaster recovery firm. “Unlike conventional threat detection, which often relies on static signatures and pre-built rules, detection engineering is behavior-driven, context-aware, and tailored to an organization’s unique threat landscape,” Renfrow says. “It involves a blend of security operations, threat intelligence, and data science to build more adaptive and resilient detection capabilities.” The SANS-Anvilogic report describes detection engineering practices as evolving over the years from being over-reliant on vendor-specific consoles and proprietary languages to incorporate software development life cycle (SDLC) and continuous integration/continuous deployment (CI/CD) principles. This is enabling teams to test, deploy, and refine detections more efficiently while maintaining auditable trails of changes. Drivers of detection engineering’s adoption There are a couple of factors driving adoption of detection engineering practices. The biggest is the fact that out-of-the-box detections aren’t good enough. They don’t baseline the environment, they don’t drive down false positives and, troublingly, they don’t always alert on the things that matter, says Johnathon Miller, vice president of security operations at Lumifi Cyber. Generic alerts that don’t account for organizational context have become a major problem and a contributor to false positive fatigue within many security teams. Sixty-four percent of organizations in Anvilogic’s survey for instance, reported high false positive rates; 61% struggled with detections that lacked environmental accuracy; and 34% said they had encountered delays in updates and improvements. “Traditional threat detection methods historically have been static; if a=a, create an alert,” says Kevin Gonzalez, VP of security, operations and data, Anvilogic. “They are often rigid, black-box mechanisms that lack flexibility in customization. Though useful to some extent, these approaches become unmanageable at scale especially in organizations with hybrid environments,” he says. Growing threat volumes and sophistication are another issue. Attackers are using more advanced and evasive techniques — including fileless malware, living off the land approaches, zero-day exploits and attacks via the software supply chain — rendering signature-based detection largely insufficient. Rising cloud adoption has introduced new vulnerabilities as well and created blind spots that legacy detection methods often struggle to cover. The rise in advanced persistent threats (APTs), supply chain attacks, and ransomware operations has made traditional reactive approaches insufficient, Renfrow says. “Organizations now realize that proactive detection engineering reduces dwell time, improves response capabilities, and enhances overall cyber resilience. Additionally, compliance frameworks and cyber insurance providers are increasingly emphasizing strong detection strategies.” Industries adopting detection engineering Organizations in the banking and finance sector, the technology industry, cybersecurity companies and, to a lesser extent, healthcare companies are among the leading adopters of detection engineering practices. Many are in sectors that must deal with regulatory scrutiny or are frequent targets of sophisticated threat actors. But the reality is that most organizations, especially larger ones, can benefit from implementing a systematic approach to developing detection mechanisms for their specific threat profile. Any large enterprise with a complex IT infrastructure can benefit from detection engineering. Security operations centers (SOCs) need to continuously improve and maximize their detection posture. “Along with the evolving threat landscape, their own internal IT infrastructures are constantly changing, which can result in detection ‘drift,’ where detection rules are broken and will no longer fire or alert,” CardinalOps CEO Michael Mumcuoglu says. Security experts point out some key requirements for setting up a detection engineering capability. The biggest among them is data. To succeed, detection engineering teams need access to logs and security event data from endpoints, networks, cloud environments, and security tools and a centralized SIEM or log management platform to aggregate and normalize the security data. An effective detection engineering capability also means having skilled personnel including detection engineers, analysts, and threat researchers, to develop and refine detection rules. Also important are formal processes for threat modeling, testing and integrating threat intelligence with incident response. The goal should be to move beyond static signatures and focus on how attackers operate, by prioritizing behavior-based threat detection. Use frameworks like MITRE ATT&CK to map detection coverage against known adversary techniques and utilize adversary emulation tools like Atomic Red Team to validate effectiveness, Renfrow says. “Detection engineering works best when security operations, threat intelligence, and IT teams work together,” Renfrow notes. How AI and automation can help AI/ML can play a key role in rule tuning and automation as well. Some 45% of the survey respondents described their organizations as using AI in their detection engineering programs for purposes like anomaly detection, rule generation and alert triage. Nearly nine in 10 (88%) believed AI would have a big impact on their detection engineering programs in the next three years. “One of [AI’s] strongest use cases is analyzing vast amounts of data to identify anomalies, particularly when utilizing a custom-trained language model,” says Glenn Thorpe, senior director of security research and detection engineering at GreyNoise Intelligence. “Depending on an organization’s threat model and risk tolerance, employing AI with a well-trained LLM can significantly enhance the effectiveness and efficiency of defenders within the organization.” AI is not the only change. More organizations are also adopting automated processes for detection engineering. The areas that organizations are automating include mapping detection coverage to the MITRE ATT&CK framework, identifying broken or misconfigured detections, and being able to operationalize threat intelligence and convert it into actionable detection rules, Mumcuoglu says. Ninety-three percent of Anvilogic’s survey respondents reported they are currently using or plan to use automation in their detection engineering workflow for rules development, tuning existing detections and threat hunting. Thorpe cautions against organizations looking for some kind of one-size-fits-all approach to standing up a detection engineering capability. “Instead, a creative mindset, diversity of thoughts and experiences, and curiosity are vital for building an effective team.” A good place to start is by identifying your organization’s core data and finding individuals who can analyze that data from multiple perspectives. Develop a realistic understanding of what you don’t know and begin to address those information gaps. “You might discover that small changes can significantly improve your visibility and understanding of network traffic,” Thorpe notes. View the full article

Google has removed a malicious browser extension masquerading as Perplexity AI after Microsoft researchers found it was intercepting users’ search traffic and routing queries through attacker-controlled servers before forwarding them to legitimate search engines. Microsoft Threat Intelligence said the extension masqueraded as the AI-powered answer engine to trick users into installing it. Based on its analysis, the company said the extension’s primary objective was to intercept search traffic and collect browsing data while maintaining a normal browsing experience, making the activity difficult for users to detect. “Microsoft Threat Intelligence has identified a malicious Chromium-based extension that spoofs the AI-powered answer engine Perplexity AI to trick unsuspecting users into installing it,” the company’s threat intelligence team said in a blog post. “Based on our observation of the extension’s behavior, we assess its primary objective to be search traffic interception and data collection, which might enable downstream use cases such as profiling, targeted advertising, or other forms of misuse depending on operator intent.” Microsoft said it reported the extension to Google, which subsequently removed it. The incident reflects a broader trend identified by Microsoft’s researchers, who earlier this month warned that attackers were increasingly abusing the names and branding of popular AI platforms in phishing and malware campaigns. Extension quietly intercepted browser searches Unlike traditional browser hijackers that alter search results or flood users with advertisements, the extension operated less conspicuously. According to Microsoft, it abused Chromium’s Manifest V3 APIs to intercept searches entered through the browser’s address bar, forwarding those queries through intermediary infrastructure controlled by the attacker before redirecting users to legitimate search providers. Because victims ultimately received the expected search results, the activity could remain largely unnoticed, the blog post added. “The use of intermediary infrastructure allows the operator to observe search traffic while maintaining the expected browsing experience,” Microsoft Threat Intelligence said. The attack also relied on user trust rather than exploiting a browser vulnerability. “What makes this interesting is that the attack doesn’t really depend on exploiting a browser vulnerability. The user becomes the initial access vector,” said Vibhum Dubey, an independent cybersecurity researcher and red teamer. Employees routinely install browser-based productivity tools, password managers, and AI assistants, making AI-branded extensions appear legitimate, Dubey said. “Users also expect AI tools to request broad permissions to access websites and browser content, allowing malicious permission requests to blend in with legitimate functionality.” Why AI brands make good bait For attackers, trusted AI brands are becoming increasingly attractive social engineering lures as enterprises accelerate adoption of generative AI tools. “Attackers are following user trust,” said Sushovan Mukhopadhyay, director analyst at Gartner. “As employees adopt AI tools quickly, trusted AI brands become high-value bait for social engineering.” Browser extensions can quietly become “a data collection layer inside the employee’s everyday workflow,” exposing sensitive search queries, browsing activity, and business context, he said. Mukhopadhyay said the larger issue is that enterprise AI adoption is moving faster than security governance, creating opportunities for attackers to exploit the gap between employee enthusiasm and organizational controls. A governance blind spot Both experts said the harder enterprise problem is visibility. “Most organizations have a mature process for software inventory, but very few have the same level of visibility for browser extensions,” Dubey said. During security assessments, he has seen organizations maintain strict application allowlists while employees continued installing browser extensions with little or no oversight. Rather than looking only for known malicious extensions, security teams should monitor for risky behaviors such as changes to default search providers, requests for access to all websites, communications with domains unrelated to the claimed publisher, and extensions that seek additional permissions after installation, he said. Microsoft similarly recommended that organizations verify extension publishers, carefully review requested permissions, and monitor enterprise browsers for unauthorized or unapproved extensions. Mukhopadhyay said CISOs should begin treating browser extensions as governed enterprise software rather than personal productivity tools. “That means using allowlists, permission reviews, search-setting monitoring, and controls for unapproved AI tools,” he said. Citing Gartner data, he said by 2029, 30% of enterprises will use secure enterprise browser technologies to improve browser extension auditing, risk profiling, and policy enforcement. As browsers become the primary workspace for email, SaaS applications, and AI assistants, attackers are likely to continue targeting them, Dubey said. Organizations should therefore treat browser extensions “as third-party software suppliers” that are reviewed, approved, and continuously monitored like any other enterprise application. View the full article

Hackers are exploiting a critical vulnerability recently patched in PTC Windchill and FlexPLM, two product lifecycle management solutions used by organizations across a range of industries, including defense, aerospace, automotive, medical, electronics, industrial machinery, and consumer goods. The vulnerability, tracked as CVE-2026-12569, is an unsafe deserialization flaw that enables remote code execution. It’s located in the web-based Windchill PDMLink product data management component and is rated 9.3 severity on the CVSS scale. Product lifecycle management software is vital to organizations that manufacture products as it allows them to track a product from design to retirement, including storing CAD designs, bills of materials, workflows, engineering data, and more. PTC alerted customers about the vulnerability and shared mitigation instructions on June 17. Over the next two days the company also released patches for Windchill versions 13.1.1, 13.0.2, 12.1.2, 12.0.2, 11.2.1, 11.1 M020, and 11.0 M030, as well as indicators of compromise. On Thursday, PTC updated its advisory to warn customers that it has received reports of heightened threat activity. The update included new indicators of compromise that suggest attackers are deploying web shells — backdoor web scripts — on compromised instances. On the same day the US Cybersecurity and Infrastructure Security Agency (CISA) added the vulnerability to its Known Exploited Vulnerabilities (KEV) catalog. Active exploitation of product lifecycle software is rare, but not surprising given its footprint in sectors that are attractive to threat actors, for both cyber espionage and data extortion. These systems also store highly sensitive intellectual property. In fact, the damage to organizations could be so serious that back in March, German police reportedly took the unusual step to contact companies in the middle of the night in person to warn about a different zero-day vulnerability in Windchill that they had information attackers were planning to exploit. The German Federal Office for Information Security (BSI) alerted companies about this new vulnerability as well, stressing it had reliable information about impending cyberattacks, the Heise media group reported. PTC Windchill was first released 28 years ago and has more than 1.5 million users around the world, including companies such as BMW, Lockheed Martin, Boeing, and NVIDIA. PTC FlexPLM is a variant specifically designed for the retail, footwear, apparel, and consumer products industries. View the full article

Enterprises that have turned to AI in order to boost their security defenses may have to reconsider their approach. Malware containing code that commands LLM-assisted products to abort their analysis or refuse to implement it is already circulating, according to a post from security company SentinelLabs. SentinelLabs thinks it knows who’s responsible for the malware, which attacks MacOS systems. “Apple’s XProtect detects the sample under the rule MACOS_BONZAI_COBUCH, and SentinelLabs associates the BONZAI signature family with North Korean threat activity,” the company wrote. It’s calling the malware macOS.Gaslight. This is not the first example of malware specifically targeting AI-generated analysis. As SentinelLabs noted, Checkpoint first documented such an approach exactly a year ago. And Socket followed suit with a report of a payload that also used code to evade detection by AI models. This new generation of threats was mentioned in the OPSWAT report, The State of File Security and cybersecurity experts are warning that AI-supported protection is not always the answer. SentinelLabs would certainly agree with that view. “As LLM-assisted analysis becomes routine, defenders should expect more samples built to exploit it,” it wrote. View the full article

Australia’s Security Intelligence Organization (ASIO) has uncovered an attack on a critical infrastructure operator’s network. State-sponsored actors had compromised the network and were preparing to sabotage it, according to its director general, Mike Burgess. Other countries face similar cyber-threats to critical infrastructure. It’s impossible to exaggerate the danger that the country is facing from cyberattacks on its infrastructure, he said, presenting ASIO’s annual threat assessment this week. “We categorize them into ‘threats to life’ and ‘threats to our way of life,’” he said. In this case, the hackers had gained access to login details and passwords for active users of the networks, including the IT professionals guarding it. ASIO had set up a specific team to deal with the issue of cyber sabotage. Australia isn’t alone in facing threats from the same state actors, Burgess said. “We struggle to find a single country in our region that has not been compromised by this state’s cyber apparatus.” This meant that Australia is facing a persistent threat in the future, one that could have consequences for the way that the critical infrastructure is deployed and managed. “The biggest challenge is the cumulative one: in a degraded security environment defined by concurrent, cascading, compounding threats, when resources are limited, how and what do you prioritize?” he said. View the full article

I work as a principal specialist at a pipeline operator where Operational Technology (OT) is the backbone of the business. I do not report to the board or act as a CISO, but the issues that get raised to those levels affect my job every single day. Since the Colonial pipeline ransomware incident in 2021, it has become apparent that our industry has started posing different tones of “Are we zero trust yet?” I frequently witness its intense significance through auditing requests, TSA security directives and conversations around some control project’s goals. One experience the zero trust role has changed is that it often feels misaligned with OT heavy environments. The NIST’s Zero Trust Architecture (SP 800‑207) model works for all, but is originally written as though for an IT network, not terminals, compressor stations and control rooms where equipment must run 24/7, perhaps more aged than the technology present within the organization. CISA’s guidance on adapting zero trust principles to operational technology helps close that gap, but applying it means satisfying the OT teams and company leadership at the same time. The zero trust question I hear behind the scenes I am pretty sure we all know it comes as a jolt of reality after something really major has happened, rather than a bullet point on a slide deck. You have pipeline. The whole distribution stops for six days. In Washington, DC, US congressional hearings are underway, and legislation is coming. TSA Directive 2021-02C requires pipeline operators to attest to several things, like network segmentation and zero-trust architectures. NERC CIP-013 exists on a similar tack, more around supply chain security. In our case, the decision on how to select and manage a vendor partner and control their remote access is driven by regulatory compliance and governance frameworks. So, you have all those things that happen externally and force change. They say, “Are you zero trust? Yes or no?” We always get “yes.” They know it is not “yes, ” and the vendors know it is not “yes,” and nothing gets done about it until something happens. How I reframe zero trust for OT in my work My influence comes from how I frame problems and options in the conversations I am invited into. Zero trust is a good example. NIST’s SP 800‑207 describes zero trust as a model where access decisions are to be based on strong identity, policy and context rather than network. CISA’s OT guidance narrows it, advising operators on the appearance of devices, identity management and what overlaps with IT instead of the overall replacement. Why zero trust breaks down in IoT and OT environments” highlights that when facing the complications of IoT and OT environments, one needs to be proactive. During these conversations, I try to focus on three major points when talking about IoT. Refer to zero trust as its functioning principle. In my experience, teams respond better when I say “Every user and system has to prove who they are and why they need access” than when I talk about abstract architectures. That language matches what NIST and CISA emphasize without overwhelming people with jargon. Focus on where IT and OT converge, like jump hosts, historian connections, remote access paths and shared identity stores that span both worlds. Those are the choke points where zero trust style controls like stronger authentication, least privilege and detailed logging can give us quick wins without disrupting operations that depend on predictable behavior. Tie everything that we need to do to the existing requirements. The conversation moves from “why are we changing this?” to “how do we do this well?” which aligns with TSA Security Directive Pipeline‑2021‑02C, a CISA alert or a NERC CIP‑013 requirement. A 90-day plan OT leaders can execute While someone operates a gas pipeline, they cannot play around with zero trust. Questions such as: “What can we accomplish before the TSA checks up next quarter?” Or “How can we show the internal audit team we are making progress this month?” comes often. We have established a list of actions we take over in a ninety-day plan, because we find it aligns more with our industrial settings while also being transferable to other OT settings. Days 1–30: Map assets and identities at the IT/OT boundary The first 30 days are for increased visibility. I focus on a relatively simple question: “Who and what can currently reach OT, intentionally or accidentally?” CISA’s guidance on zero trust for OT, alongside other warnings, advocates for identifying and managing assets and communications where IT and OT interfaces exist, in addition to informal remote access routes. Also, TSA requires pipeline operators to regularly update and manage plans detailing which networks, systems and access points they will assess as per their established requirements across both IT and OT. In my position, it comes down to three actions. First, I work with OT engineers, network staff and asset inventory systems to determine which OT assets threaten operations, safety or compliance if compromised, rather than inventorying every device. Second, I map the users and links that reach into OT, such as internal staff granted advanced privileges, remote vendor support, VPNs and cloud platforms that interact with production data. Third, I categorize these identities and connections based on risk, impact and exposure, not by their roles. By the close of the first 30 days, the intention is to present leadership with an easily comprehensible overview: outlining the critical OT assets, delineating the entry points from both internal IT systems and external sources and identifying the associated identities. Having established this common understanding makes subsequent zero trust discussions less vague. Days 31–60: Contain vendor remote access and create early wins Look for quick wins in the next month, in a high-impact but non-disruptive area. Vendor or third-party remote access often fulfills it, and CISA has warned about it and continues to do so. Their guidance emphasizes best practices, including using MFA, segmented user privileges and monitoring third-party activity independently. The NERC CIP-013 requires utilities to consider cybersecurity threats and risk management that protect their supply chains and suppliers that connect to critical systems. The TSA’s pipeline directives expect close monitoring and controls of remote access. In my case, early wins look like telling a vendor: OK, instead of an unsecured, remote access method, use an audited brokered remote access solution. MFA for any and all remote OT sessions. Close old vendor RDP connections that are not in service. You are simply saying that times change and since these methods were put in place a few years back, they have evolved; it is reasonable for you to evolve. Days 61–90: Build a simple maturity scorecard and narrative The third month is about visibility and repeatable progress. We now will have more clarity on assets and identities traversing the IT/OT boundary and have choked down the most dangerous of remote access paths. Now we will take time to track where we have been over time. I will consult with leaders within security and OT teams to identify the right-sized set of metrics relevant to the specific context of the organization. While the specific terminology may vary, many will align with common language found in TSA, NERC, CISA and other industry documents. Consider the broad themes of “govern, protect and detect & respond”. We can then identify solid “now” and “better next quarter” capabilities within each of these themes. “Govern” could incorporate specific OT policies on identity and access management that pull in zero trust directives alongside existing authoritative frameworks. “Protect” might track what fraction of your high-impact OT assets have been put behind better segmentation practices, coupled with the percent of your remote access pathways to OT identified as high-risk that have both MFA and a brokered connection. “Detect & respond” could see tested playbooks in place assuming a remote connection compromise that directly injects malware into an OT system, which aligns with how recent incidents have unfolded throughout North American utilities. The output is not a scorecard to pass around but will be a meaningful, honest conversation for our leaders. You will know how to accurately frame how your organization applies zero trust in the OT world today, show what you achieved over the past three months and honestly describe where there is more work ahead. I am not the only one trying to make zero trust ideas actually fit OT, and I pay attention to the CISOs who voice the same frustrations with IoT and OT environments. We are solving the same problem from different seats. What I have found is that a workable 90-day plan, updated monthly, beats any pledge to “Let us achieve zero trust together” This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

US lawmakers on Thursday introduced a bill that would require developers of advanced AI models to report major safety and security incidents to the Commerce Department, establishing a federal oversight framework for high-risk AI systems. The proposed AI Incident Reporting Act would mandate that developers of designated “covered models” disclose incidents within seven days of knowing, or reasonably believing, that one has occurred. For incidents posing an imminent or ongoing risk of serious harm, the Commerce Department would have to notify congressional leadership and the chairs of relevant House and Senate committees within 48 hours after receiving the report. The bill directs the Secretary of Commerce to establish capability thresholds to determine which AI models and developers are subject to the reporting requirements. “AI is a powerful engine of innovation, and I want to see it flourish, but not without accountability and not without human oversight,” Moran said in a statement announcing the legislation. “The rule of law should apply to this new frontier. This legislation ensures that when something goes wrong with a high-capability AI system, the US Government has the information needed to act quickly.” Broad range of reportable incidents The proposal identifies a broad set of incidents that would require disclosure to the Commerce Department. According to the bill, developers would have to report attempts by covered AI models to evade human oversight, deceive operators, circumvent safeguards, resist shutdown, or obtain unauthorized access to systems or privileges. The reporting requirement would also apply to theft or attempted theft of model weights, capabilities that could materially enable offensive cyber operations against important software or critical infrastructure, autonomous development of more capable AI systems, and capabilities that could accelerate the development or use of chemical, biological, radiological, nuclear, or explosive weapons. The legislation also directs the Commerce Department to develop the capability thresholds in consultation with AI developers, academic researchers, cybersecurity experts, national security officials, and other stakeholders before issuing implementation guidance. Sanchit Vir Gogia, chief analyst at Greyhound Research, said the proposal would make reporting serious AI incidents a legal obligation rather than a voluntary practice for developers of frontier AI models. “The serious frontier developers already run the evaluations, the red-teaming and the escalation drills,” Gogia said. “What they have never faced at the federal level is a legal obligation to tell the government, on the clock, when a model behaves dangerously.” Reporting timelines and enforcement The bill requires covered developers to submit an initial report within seven days of discovering a reportable incident and supplemental reports as additional information becomes available. The legislation also authorizes the Commerce Department to investigate compliance, issue subpoenas, require corrective action, and impose civil penalties of up to $2 million for violations. Each day of a continuing violation would constitute a separate violation, the bill states. Gogia said implementation could hinge on how regulators define reporting triggers. “Capability thresholds are the visible difficulty, and not the deepest one. Thresholds decide which models enter the regime. Discovery decides whether the regime ever sees the fire,” he said. Drawing a comparison with cybersecurity regulations, he said reporting requirements should clearly define when an incident becomes reportable. “Cyber reporting has already taught the lesson. A vague trigger produces either silence or noise: firms stay quiet until they are certain, or they file everything and bury the signal,” Gogia said. Filling a gap, a recent dispute exposed The bill follows a US government action that exposed the absence of any such process. On June 12, the Commerce Department took action against the latest models from Anthropic, a US AI developer, on national security grounds, prompting the company to disable global access to those models. “Export control was the sledgehammer. This proposal is the search for a scalpel,” Gogia noted. The measure is a narrower alternative to the Great American Artificial Intelligence Act, a broader discussion draft released earlier in June that also routes critical safety incidents to Commerce. The Commerce Department’s Center for AI Standards and Innovation has separately signed agreements to evaluate leading models before deployment. Compliance burden falls on enterprises Gogia said the legal duty falls on the developer, but the operational cost reaches the customers. “Regulation may name the lab, but the bill for poor visibility is settled downstream,” he said. He said the hardest question is not which models qualify but when a reporting clock starts. “Thresholds decide which models enter the regime. Discovery decides whether the regime ever sees the fire,” he said, adding that a model can pass laboratory tests yet behave differently once connected to live tools and enterprise data. The bill exempts submitted reports from public disclosure requirements and states that submitting a report would not waive trade secret protections or attorney-client privilege. “The instinct behind this bill is sound, but the balance cannot be scored from a press release,” Gogia said. “The wording will decide everything.” View the full article

When a new AI capability starts making headlines, I see the same pattern play out in boardrooms and executive staff meetings. The technology is introduced as a looming breakthrough for attackers. The conversation quickly shifts to worst-case scenarios. Then security leaders are asked some version of the same question: Are we suddenly exposed in ways we were not exposed before? My answer is usually no. In most organizations, the bigger issue is not that a frontier model such as Mythos will magically create a new category of risk overnight. It is that these models can accelerate work on both sides of the cybersecurity equation. Attackers may use them to move faster, but defenders can use them to identify, prioritize and fix weaknesses that have been sitting in plain sight for years. That is why I view Mythos as a signal, not a siren. It signals that the economics of cyber offense and defense are changing. It does not signal that security fundamentals no longer matter. If anything, it proves the opposite. The organizations that have clear asset visibility, disciplined patching, strong identity controls and resilient operating models will be in a far better position to absorb whatever AI changes next. That perspective matters because recent breach reporting still points to familiar failure points. Verizon’s 2025 Data Breach Investigations Report shows that credential abuse and vulnerability exploitation remain central themes in how organizations get compromised, with exploitation continuing to rise. In other words, the path into the enterprise is still usually paved by weaknesses security teams already understand. The real problem is still the basics In my experience, many organizations do not have a strategy problem as much as they have an execution problem. Security leaders know the basics. Their teams know the basics. Their auditors, regulators and board committees know the basics. The struggle is sustaining those basics consistently across hybrid estates, aging systems, cloud platforms, remote users and sprawling third-party dependencies. That is why I am cautious when I hear predictions that AI will fundamentally change which controls are relevant. Most successful breaches still start with a known weakness that was not remediated, not prioritized correctly or not visible in the first place. An unpatched internet-facing system. A misconfigured identity relationship. Excessive privilege. Weak segmentation. A service account nobody has reviewed in years. A business-critical exception that quietly became permanent. I have seen security programs lose momentum when they over-rotate toward the newest threat narrative. They start funding edge use cases while old control gaps remain open. They buy more tooling before fixing ownership, process discipline and accountability. They treat cybersecurity maturity as a collection of projects instead of an operating model. That approach was risky before frontier AI, and it will be even riskier if these models compress attacker timelines further. If Mythos changes anything for most enterprises, it changes the urgency of getting the basics right. It increases the cost of delays. It raises the penalty for security debt. It puts more pressure on teams that already struggle to inventory assets, rationalize findings and close the delta between what they know and what they have actually fixed. That shift should also change the way we prioritize work. In many programs, vulnerability backlogs grow because teams are making decisions in fragments. Infrastructure owns one piece. Security operations own another. Identity, cloud and application teams each see a different slice of the problem. What gets lost is the full risk picture. That is why so many organizations feel busy but not measurably safer. They are addressing issues, but they are not consistently reducing the combinations of weakness that attackers actually exploit. The practical takeaway is straightforward. Before leaders assume Mythos creates a completely new threat model, they should ask a simpler question: Where are we still weak in ways that an attacker would recognize immediately? In my experience, that question leads to a more honest and productive discussion than any speculative debate about what AI may eventually do. AI can help defenders close the gaps they already know they have The more constructive way to think about Mythos is to ask where frontier AI can improve defensive capacity right now. I do not mean replacing analysts or handing sensitive decisions to a model without oversight. I mean using AI to tackle problems security teams have long understood but have not had the scale or time to address consistently. Identity is a good example. NIST says identity and access management is a fundamental and critical cybersecurity capability. Most CISOs would agree. Yet identity environments remain full of drift: nested groups, inherited entitlements, stale accounts, inconsistent role definitions and privileged access that survives long after the business need is gone. Those issues are rarely invisible. They are just hard to analyze holistically in real time. This is where AI can become valuable. It can help correlate relationships across directories, cloud control planes, tickets, logs and policy stores. It can help surface unusual combinations of access, identify probable attack paths and prioritize fixes based on business impact rather than raw alert volume. The benefit is not more noise. The benefit is faster understanding. The same logic applies to vulnerability and patch management. Most enterprises already have scanners, ticketing systems and dashboards. What they often lack is a consistent way to decide which vulnerabilities matter most in the context of exploitability, exposure, compensating controls and asset criticality. Frontier AI can help teams move from a long list of findings to a shorter list of actions that materially reduce risk. I also see opportunities in configuration management and detection engineering. Security teams are drowning in fragmented data. AI can help normalize evidence from multiple sources, highlight configuration drift and connect seemingly isolated signals into a more realistic picture of operational risk. For lean teams, especially, that matters. It can mean spending more time reducing risk and less time reconciling spreadsheets, duplicate alerts and disconnected workflows. None of this eliminates the need for skilled practitioners. It simply gives them leverage. And in a field where the volume of exposure routinely outpaces available staff, leverage matters. The most important point is that this is not a call to hand the keys to a model. It is a call to use AI where the return is clearest: accelerating analysis, improving prioritization and helping teams close long-standing control gaps. In other words, the biggest opportunity is not building a futuristic security theater. It is finally operationalizing the fundamentals at a speed the business can sustain. The board conversation should shift from fear to resilience The most important shift Mythos should trigger may not be technical at all. It should change the way CISOs talk to boards, CEOs and operating leaders. Too often, emerging technologies force security leaders into reactive conversations rooted in fear. The implied message is that a new attacker capability has arrived, so the organization now needs a new budget line, another platform or a fresh round of urgent exceptions. Sometimes that is true. Often it is not. More often, the better response is to connect the new development to existing risk priorities and reinforce the investments that improve resilience across multiple scenarios. When I speak with executives about AI-driven cyber risk, I try to keep the conversation grounded in three points: Most cyber losses still stem from preventable weaknesses. That is not a comforting message, but it is an actionable one. Improvements in identity, asset governance, patch discipline, third-party oversight and response readiness create value beyond any single threat cycle. The organizations that manage complexity best will usually outperform those that react most dramatically. That framing also helps boards ask better questions. Instead of asking, “What are we doing about Mythos?” they should ask, “Where would AI make our current weaknesses more expensive or more exploitable?” Instead of asking for a point solution, they should ask whether security and IT operations are aligned on the highest-risk remediation work. Instead of measuring activity, they should measure whether security debt is shrinking. For CISOs, that is an opportunity. Mythos can be used to justify another round of panic, or it can be used to elevate the quality of the risk conversation. I believe the better path is clear. Use the attention to tighten fundamentals. Use the technology to improve prioritization. Use the moment to reduce chronic control failures that attackers have exploited for decades. That is why I do not see Mythos as a siren demanding overreaction. I see it as a signal that the enterprises most prepared for the AI era will be the ones that finally operationalize what security leaders have been saying for years: resilience is built through disciplined execution, not headline-driven improvisation. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Ten years have passed since the General Data Protection Regulation (GDPR) came into force, and the results are mixed. While data protection has become more firmly established in European companies — and beyond — than ever before, the business world remains critical of the regulation due to increasing bureaucracy, legal uncertainty, and competitive disadvantages. From a data protection perspective, this is a success story. According to a 2018 Bitkom study, shortly before GDPR came into effect that year, only 7% of German companies had fully or largely implemented the requirements. Six years later, 71% of German companies said they had done so. Furthermore, GDPR has significantly increased awareness of the protection of personal data — both among companies and consumers. Customers are paying closer attention to transparency, consent, and data security. For many companies, data protection has now become a competitive factor in building customer trust. At the same time, record fines against data giants such as Meta, TikTok, and Uber show that the GDPR is serious business, with the total amount of publicly known GDPR fines having exceeded €6 billion for the first time in March 2026. Still, just 60% of fines have been paid to date, with other fines having been annulled or remaining under appeal. Also, according to law firm CMS, there has been a clear shift in focus for GDPR enforcement: Supervisory authorities are increasingly concentrating on practical compliance issues and less on isolated, high-profile cases. What began with landmark proceedings and record fines has now evolved into a routine, operational review of companies’ day-to-day data protection practices. Companies complain of increasing burden At the same time, dissatisfaction within the business community is increasing. What was originally intended to provide greater legal certainty and uniform rules across Europe is now perceived by many companies as a constant burden. In a Bitkom survey from 2025, 81% of companies surveyed stated that the GDPR was making their business processes more complicated. In 2016, only 25% held this view. By 2025, 97% rated the effort required as high, with 44% rating it as very high. There are many reasons for this discontent. Four out of five companies surveyed (82%) by Bitkom cited uncertainty regarding the precise data protection regulations as a challenge in 2025. At the same time, 86% believe that implementation is never truly complete because companies must continuously react to technical and legal developments. Data protection is thus perceived as a particularly challenging, ongoing compliance task. AI: GDPR’s new test Data-driven projects are particularly affected. In 2025, 59% of study participants reported that the development of data pools had failed or not even been initiated due to data protection regulations. The figures remain high for data analysis tools, AI applications, and the digitization of business processes as well. Data protection regulations are thus perceived as a hurdle primarily where — as is particularly the case with AI — innovations depend on large volumes of data. The result: According to Bitkom, 59% of companies see European data protection as an advantage for AI development in Germany and Europe compared to other countries. In practice, however, they experience the opposite. For example, in 2025, 69% of respondents stated that data protection makes it difficult to train AI models with sufficient data. “The reality is: AI is not being developed in Europe because of our data protection practices, but the models are still being used here,” commented Bitkom President Ralf Wintergerst on the findings. “This means nothing is gained for the protection of European citizens’ data, but much is lost for Europe as a business location.” Bitkom is therefore calling for a reform that strengthens data protection where real risks to people arise — and relieves companies of the burden where formal obligations offer no additional protection. Specifically, this means a consistent risk-oriented approach to the GDPR and a unified understanding that the training and operation of AI systems must also be possible in Europe, says Wintergerst. Whether the industry association’s demand for a relaxation of data protection standards in favor of technological competitiveness is also in the interest of consumers is another matter. What is certain is that the GDPR has not lost its relevance even 10 years after its entry into force (or eight years since its application). Or, as lawyer Anna Lena Füllsack from CMS puts it: “The enforcement of the GDPR has outgrown its infancy and is now an integral part of the regular legal landscape throughout Europe. For companies, it will remain a key strategic issue in the coming years.” View the full article

The new CIO mandate is clear: facilitate AI adoption across the enterprise at speed. According to CIO.com’s State of the CIO survey, CEOs’ top priority for their IT executives is to capitalize on AI. From researching to evaluating AI products, CIOs are now the central figures in their organizations’ AI strategies. And company leaders are looking for real outcomes. Almost two-thirds of senior leaders report there is more pressure to prove ROI on their AI investments than a year ago, according to Kyndryl’s 2025 Readiness Report. Numerous sources — from the board, to the CEO, to business units and competitors — are behind this pressure, says Jonathan Tushman, chief AI officer and CTO at Hi Marley, a customer conversational platform for the property and casualty insurance industry. Succeeding in the task ahead of them requires complex conversations, and getting through legal, compliance, and other checks “at a reasonable clip,” adds Tushman, who added CAIO to his remit more than 18 months ago but has felt added urgency in the past six months. In professional gatherings, board conversations, and almost everywhere across the business world, the conversation turns to AI — and then quickly the fear of failing behind. That includes employees as well. “It’s the engineering team and there’s everybody else — marketing, sales, finance. It’s people who are not AI-native, but they’re very eager to use these tools at an early level,” he says. As CIOs find themselves facing pressure to scale and demonstrate real value, the challenge is keeping up with risk considerations — without creating unnecessary friction. “CIOs cannot be risk averse on this,” says Karthik Chakkarapani, SVP, CIO, and head of enterprise AI at Zuora. “We need to do security and governance, but we don’t want to be seen as slowing down the process. You have to build the highway with enough guardrails and fewer speed breakers.” Moreover, he adds, “this is not about automating existing work. This is reimagining how work gets done.” AI is a step-change in risk management Most IT leaders are a long way from feeling comfortable with the new AI risk management balancing act. Just 31% of respondents feel completely ready across external business risks, Kyndryl’s survey reports. Tushman believes two things are genuinely different about the risks AI introduces. The first is that AI is indeterminate, whereas most technology is deterministic. “You can’t prove an AI system will or won’t do X, so the traditional ‘put controls around it and verify’ model breaks down,” he says. “We need a different way to govern something whose behavior you fundamentally can’t pin down.” The second is the gravitational pull on end-users. “With most tech, IT could take its time evaluating before rollout,” he says. “With AI, if you don’t put powerful tools in front of people fast, they’ll route around you — and shadow use creates more risk than controlled access ever would. The timeline compresses at the same time the control model gets harder.” Tony Vizza, founder and managing partner of Novera, agrees that the instinct to move fast can lead to the exact failures everyone fears. “This might be staff putting sensitive information into public tools without a proper governance structure, or people copying and pasting straight out of AI and sending incorrect deliverables to customers,” says Vizza. Organizations should avoid jumping into AI because of the fear of missing out without first clarifying where and how it will be used. All risk decisions should flow from these questions, he says. “What problems are you trying to solve — is it better customer service or deeper insight into your data? What are you actually trying to do?” Vizza recommends guiding AI decisions with a risk assessment that considers expected outcomes, size of investment, and its importance to the organization’s objectives. “You define your risk appetite, build a risk register, and define what risk treatment should be for each risk,” he says. “For example, if you’re going to use a public AI model, you might treat that risk by not putting sensitive data in or buying the right license so that if you do, you’re covered, or getting guidance from the regulator before you proceed.” Organizations must also consider AI services as a third-party risk, and not leave all accountability with AI providers, Vizza says. “You can’t outsource the responsibility,” he adds. Due diligence is required to understand what is in the AI provider’s contract, who is responsible if they have a data breach, and how your organization can pursue them if something goes wrong. “Some organizations build that into their risk management process. Others are quite flippant or don’t even know they should be asking those questions — and that’s what gets them stuck down the track,” he says. The importance of organizational design At Hi Marley, Tushman and team have made structural decisions to foster “healthy internal tensions” that are intended to surface and address AI risk considerations. This includes separation between the “AI adopters” in the product and technical teams and the “AI oversight” teams in compliance and legal. Compliance owns the audits, security concerns, and ongoing oversight, while legal owns the documentation that describes the boundaries. “The key is that it’s independent from the teams pushing AI forward,” he says. “Companies need to invest seriously in these compliance functions. Hire smart, nuanced people. These roles can’t just be ‘no’ machines, but they can’t rubber-stamp everything either. The value is in the judgment,” he says. Tushman’s role is the AI innovation steward, spearheading AI adoption that includes being challenged on risk, compliance, and legal considerations. “We have a senior leadership team and we have ‘conflict by design’ within that group,” he says. “I play the CAIO role and next to me, I have our head of legal and our head of compliance. So in that leadership team, if we have ‘conflict,’ we’re able to understand the trade-offs and make a decision as a group.” Tushman believes this creates healthy tension: Innovation-minded leaders push boundaries while compliance and risk leaders counterbalance them. But if a decision can’t be reached, it goes to the CEO. “I do recommend a [split decision] goes to another officer in the organization,” he says. Decisions about organizational structure could prove to be as consequential as the AI adoption decisions themselves, Tushman says. “The companies that get the organizational design right early will have a real advantage,” he explains. Desire for AI advances the risk equation One of the features of the AI wave is the thirst for access — from the board to employees — to use the tools, build applications, and start putting them to work. “Right now, everyone’s dying to try it,” says Tushman. Hi Marley is in the “activation” phase — meeting the appetite for the tools with safety wrappers. “My main goal here is to have people learn the tools, start using them, and gain some competency with them,” he says. “We will get to the measurement phase, but I think spending too much time on measuring right now is not worth the effort.” Tushman, like many, is watching how quickly models improve. “AI has huge implications for how you organize, how you hire, and what buy‑versus‑build decisions you make,” he says. Zuora, which specializes in software for subscription and recurring revenue businesses, is three years into its AI journey. Chakkarapani is adamant that speed for speed’s sake is not the goal. “We don’t want to take an existing process and just make it faster. You’re just making a process more chaotic. Can we make it fast, smarter, and reorganize it?” Vizza believes a good percentage of CIOs will need external help to navigate the push for rapid AI adoption. “Or they’ll need to upskill themselves, because AI operates very differently to traditional IT,” he says. His advice is threefold. First, “make your decisions on the right basis — either learn how AI really works or bring in someone who can advise you properly,” he says. Second, bring it back to the business purpose. “There are opportunities with AI, but the core question is, ‘What are we trying to achieve by bringing this in?’” And third, work out how you’re going to manage the risk. “Risk isn’t necessarily a bad thing — Formula 1 cars are risky, but they have very good braking systems so they can go faster,” he says. “It’s the same with AI: You put the right risk management in place so the business can move quickly without suffering adverse consequences.” In its almost three-year AI journey, Zuora started with experimentation before moving 12 enterprise-wide pilots into production, Chakkarapani says, adding that there are three pillars to assess potential AI projects against: effort, value, and confidence. “Effort includes the security risk,” he says. “Is it low, medium, or high?” Chakkarapani’s team started with simple executions, although the first experiments didn’t go as hoped — providing valuable lessons for the following ones. “We learned AI is only good when you have the right data — the right content, context, and governance,” he says. They moved on to IT service management and that’s when the practical learnings really started, gaining feedback from internal teams and users, answering the security and governance questions, and iterating as they went. Early applications include marketing, sales, product, and technology, achieving 10x to 25x throughput improvements. Success is measured in business outcomes such as growth, cost saving, customer engagement. Through this process, the team has been doing the “behind the scenes” work to speed AI adoption across the company. “We realized that to go at speed and scale, we need to have the right trust, security, and governance underlying it,” he says. An enterprise-wide platform connects Zuora’s approved AI services, including ChatGPT and domain-specific tools, to its structured and unstructured data. On top of this is the context layer and services so that people can build their own applications. It uses each employee’s existing login and organizational profile, and it respects the same role-based security. “We slowly developed the framework that became our blueprint with the 10 to 12 things that need to be considered when creating an AI-driven application. When someone is interested, they’re taken to the self-directed process with these do’s and don’ts that is automatically downloaded as a markdown file to that person’s computer,” he says. The ultimate aim is delivering up to 100x business value through an enterprise-wide governed platform — covering IT, HR, finance, legal, procurement, sales, and product. IT plays the role of orchestrator, providing the platform to access the tools and agents and collaborating with the business team to reorganize that workflow. The AI maturity model Chakkarapani believes the more secure the environment, the more it paves the way for experimentation, adoption, and, in time, business results. At Zuora, Chakkarapani has evolved this process through three levels of organizational AI maturity to date: Level 1: IT provides a platform and services. Employees have controlled access to data based on their role and security privileges. They can create their own agent for themselves. If something doesn’t pass the minimal security and compliance and requirements, it cannot move ahead. Level 2: An employee-built agent goes through an IT governance check for duplication or overlap, model improvements, security scans, and manual reviews. If approved, it’s shared with the wider enterprise. “We’re doing well on that, but it’s still a lot of manual work because there are no tools in the market that can automate this,” he says. Level 3: At this stage of maturity, an organization has established a secure foundation across its applications so AI can scale safely. At Zuora, over six to eight months the team tightened endpoint and application security, enforced mobile device management, introduced AI usage monitoring (including what staff upload into prompts), and disabled Google authentication to block personal or bulk email accounts from accessing unapproved apps. Earlier this year, the team embarked on working toward Level 4 maturity, where anyone can create a functioning application with minimal human involvement. Realistically, they expect to be 80% to 85% zero-touch because the final mile will still require human involvement. “My goal is to provide a zero-touch service for anybody in the organization to create applications. If we do, they can go from a concept to an idea, prototype, design, and production — and they do it in less than two weeks,” he says. View the full article

We are auditing a curated version of history. I’ve worked in security long enough now to know something most of us don’t really say out loud. A lot of compliance is theatre. Not all of it, and not all auditors or frameworks, but enough of it that most experienced CISOs know exactly what I mean. If you understand how audits work, know how controls are interpreted and can manage scope and narrative well enough, you can often steer things where you need them to go. That’s uncomfortable to admit, but it’s true. The market now treats things like SOC 2 and ISO 27001 as direct statements about operational maturity and security posture when they really aren’t. They are snapshots. Point-in-time reviews based on selected evidence and sampled testing. That doesn’t make them useless. These frameworks were built for a completely different world where cloud infrastructure was less dynamic, APIs weren’t everywhere and continuous telemetry at scale simply wasn’t realistic. Sampling existed because there wasn’t much of an alternative. That’s before we even mention AI, where technology now changes on a monthly cadence against a regulatory backdrop that speaks in years. The issue is that the world moved on, but assurance largely didn’t. The team behind FedRAMP 20x are attempting to address exactly that problem, pushing assurance towards automation, machine-readable evidence and continuous validation rather than documentation-heavy compliance exercises. Most compliance programs still revolve around screenshots, exported evidence, manually curated narratives and carefully staged representations of reality. And that word, reality, is the important bit because in many cases, we are not auditing reality at all. We are auditing a curated version of history. That’s why one of the most important things I’ve heard said around FedRAMP 20x is this: Passing audits does not equal security. Exactly. A company can pass an audit while engineers bypass processes every Friday night to hit deadlines. Controls can drift quietly over time while nobody notices because the evidence only exists for a specific audit window. The audit passes because the story passes, and honestly, I think that’s the bit the industry is becoming increasingly uncomfortable with. How many times a year is the production push made as a “hot fix”? And honestly, I think that’s why movements like GRC engineering are getting so much traction. Not because people suddenly wanted a trendy new title for compliance. But because there’s growing frustration with how artificial parts of the industry have become. A few months ago, I gave a talk in Seattle comparing the rise of GRC engineering to the rise of grunge music. I’m a huge Nirvana fan, so maybe the analogy was inevitable, but the more I thought about it, the more it made sense. Grunge didn’t emerge because people desperately wanted something shiny and new. It emerged because people stopped believing the polished version was real. Hair metal had become overproduced and performative. Grunge felt rough around the edges, but it also felt honest. That’s exactly where GRC feels like it is right now. Too much compliance has become about presenting the cleanest possible version of reality instead of exposing operational truth. Too many clean reports. Too many green ticks on trust centers. Too many perfect policies. The sat nav problem Which brings me to one of the dumbest weekends of my life. Many years ago, my wife decided she wanted to go glamping in the Lake District for Valentine’s Day. We drove north through classic, miserable British weather in a tiny little car completely unsuited for what was coming. As we got closer to the Lakes, the rain slowly turned into heavy snow. Then a full blizzard. The sat nav confidently directed us up a tiny snow-covered road that we physically could not drive up. We got stuck. Eventually, we got free. The sat nav recalculated and sent us up another equally impossible road. Same outcome. This happened multiple times until we eventually ended up buried in a snow drift somewhere in the middle of nowhere, waiting for a bloke in a 4×4 to rescue us while trying not to laugh too hard at the idiots in the tiny car. After about seventeen hours of driving, we gave up and drove home. Completely failed Valentine’s trip. But honestly, I think about that weekend a lot when I think about GRC because the sat nav had data. What it lacked was context. It didn’t understand the environment, the conditions, the capability of the vehicle or even the actual outcome we were trying to achieve. We became obsessed with following the prescribed route instead of stepping back and asking whether the route itself still made sense. It reminds me of stories like tourists literally driving into the sea while blindly following GPS directions. The problem wasn’t the absence of data. The problem was understanding the context around the data. Tourists drive into sea following GPS directions. A lot of compliance programs behave the same way. The objective quietly becomes “pass the audit” instead of “reduce meaningful risk”, and once that happens, teams start optimising for the framework rather than the security outcome. That’s the shift I think FedRAMP 20x and the broader GRC engineering movement are trying to force. Not just better automation or more integrations, but a fundamentally different way of thinking about trust. Compliance becomes an engineering problem One of the central ideas behind FedRAMP 20x is that assurance increasingly needs to be treated as an engineering challenge rather than a documentation exercise. Historically, most compliance has been based on samples. Sampled pull requests, sampled access reviews and sampled infrastructure evidence. FedRAMP 20x pushes in a very different direction with machine-readable evidence, APIs, telemetry and complete datasets instead of manually curated snapshots. Many of these principles closely mirror those outlined in the GRC Engineering Manifesto, which argues that modern assurance should be built on automation, telemetry and engineering disciplines rather than static evidence collection. One of the biggest mindset shifts for our engineering teams was realising FedRAMP wasn’t really asking for selected evidence anymore. They wanted the underlying operational data itself. Not a screenshot proving something was configured correctly on one specific day, but the actual flow of telemetry that underpinned the control or assurance statement. That’s a completely different way of thinking about compliance because the conversation moves away from “prove this existed once” and towards “show me the operational reality continuously.” Instead of showing a screenshot proving a virtual machine was configured correctly on one day, you expose every VM in the environment alongside drift data over time. Instead of selecting a handful of GitHub pull requests, you expose the entire development workflow, including the messy bits where processes were bypassed. Instead of showing sampled JML evidence, you expose the full lifecycle history of identity management over years. Honestly, it should feel uncomfortable because that discomfort is probably a sign you’re finally exposing operational truth instead of polishing it away. Trust shouldn’t come from perfection. It should come from transparency. We thought we were ready And honestly, that’s exactly why our own FedRAMP 20x journey became so interesting. We originally planned to move towards moderate through a much longer runway. Then the programme timings changed, government shutdowns caused disruption, and suddenly we found ourselves with around six or seven weeks before audit activity started. We thought we had a solid plan. We didn’t. Or at least not one that was mature enough yet. We had missed the low pilot earlier in the journey and entered the moderate phase without having already gone through that foundational learning process. We were also the only organization in our pilot group that hadn’t already completed the low pathway first. That mattered. We didn’t yet have the operational muscle memory. No established playbook. No previous iteration. No deeply embedded understanding of how this model actually behaved in practice. At the same time, we weren’t trying to approach FedRAMP 20x like traditional compliance. We built direct API connectivity that allowed FedRAMP and auditors to pull complete machine-readable datasets in JSON format directly from the platform. Human-readable exports still existed where required, but the focus was on exposing operational truth rather than curating static evidence. That’s also one of the core principles behind FedRAMP 20x itself. Controls increasingly need to be both machine-readable and human-readable. The baseline expectation is that a large percentage of controls should be automated with continuous evidence flowing behind them instead of static evidence being manually assembled before an audit. What that means in practice is that auditors no longer just review a point-in-time evidence pack. They gain ongoing visibility into operational datasets and can interrogate those environments in a much more dynamic way. That’s a very different mindset from traditional compliance. And honestly, I think that difference is part of what made the journey so valuable. We didn’t fail. We iterated Because I don’t actually think what happened next was failure. I think it was iteration. Modern engineering teams don’t release perfect software on day one. They test, rebuild, refactor, improve and iterate continuously based on telemetry and feedback. Applications go through: Testing User feedback Redesign Bug fixing Telemetry analysis Continuous improvement Nobody expects version one to be perfect. Yet historically, GRC has behaved completely differently. Build the controls. Collect the evidence. Pass the audit. Repeat next year. The audit becomes the finish line. Our finish line became a “good effort,” “we think you’re ready for a Low authorization, but not Moderate just yet.” For a moment, it felt like failure. It hurt. It felt fundamentally different from any other assessment or audit as we genuinely didn’t know what we’d achieved. In fact, FedRAMP 20x feels fundamentally different and maybe that’s the whole point. The process itself became feedback. Not: Can you tell a convincing enough story? But: What does your environment actually look like and how do you continuously improve it? That’s a completely different mindset. One of the recurring themes throughout FedRAMP 20x is that assurance should improve through continuous iteration rather than annual point-in-time validation. Exactly. That’s how engineering works. The Low authorization wasn’t the end state. It was a checkpoint and a recalibration moment that helped us understand where the next iteration needed to go. And honestly, if you can speedrun moderate FedRAMP with perfectly polished dashboards and no uncomfortable truths exposed, then the framework probably isn’t doing its job. That’s one of the things I genuinely appreciate about FedRAMP 20x. It challenges your assumptions. It forces you to rethink approaches that have become normalized across large parts of the compliance industry. Historically, proving infrastructure security often meant screenshots or exported configs. Now we can expose every VM, every drift event and the full history of posture changes across the environment. That changes behavior massively because you can no longer optimize around the cleanest possible sample. You have to maintain the actual posture continuously. Historically, proving SDLC maturity meant selecting a handful of pull requests. Now we can expose the entire workflow, including every bypassed approval or manual push into production. Historically, proving identity governance meant sampled JML reviews. Now we can expose the operational history of the full identity lifecycle over years. And honestly, that was one of the areas that challenged some of our own assumptions the most. Traditional sampled evidence can make processes look consistently successful because you’re only reviewing selected examples. But operational truth is different. You only need one joiner, mover or leaver process to fail in the wrong way for the risk to become real. That’s exactly the kind of thing continuous operational visibility exposes much more quickly than traditional evidence collection. That’s not just better evidence. It’s a fundamentally different philosophy of assurance. The rise of GRC engineering And this is where I think GRC engineering becomes genuinely important. Not because everybody suddenly needs to become a software engineer, but because the discipline itself is evolving from a documentation exercise into an operational engineering problem. Modern GRC teams are increasingly building telemetry pipelines, integrations, APIs, infrastructure visibility and continuous assurance layers. And honestly, some of those pipelines are much harder to build than people realize. Cloud infrastructure, CSPM tooling and application security platforms are relatively straightforward because the data is already fairly structured and accessible. The really difficult parts are the messy operational systems that organizations historically handled through process and human coordination. Things like policy management workflows, budget approvals, software bill of materials tracking and non-standard operational processes are far harder to standardize and expose consistently. That’s another reason this shift matters so much. It forces organizations to operationalize areas that historically lived in spreadsheets, meetings or tribal knowledge. That’s a very different skillset from managing spreadsheets and coordinating screenshots. More importantly, it changes the conversations. One of the things I enjoyed most throughout the FedRAMP 20x process was that discussions increasingly stopped being: How do we satisfy this control? And became: What risk are we actually trying to reduce here? That’s such a healthier conversation for security teams to have. Because not every risk matters equally to every organization. Not every control meaningfully improves security posture. Not every framework requirement deserves the same operational investment. Traditional compliance often struggles with that nuance because it optimizes around consistency and uniformity. Modern engineering-led assurance feels different. It feels more contextual, more operational and honestly far more honest. And honestly, honesty is probably the biggest thing missing from large parts of compliance today. We’ve built an industry where everyone feels pressure to look perfect. Perfect dashboards. Perfect controls. Perfect audit outcomes. But real engineering environments are never perfect. They have bugs, drift, exceptions, failures, temporary workarounds and weird edge cases. That doesn’t automatically mean the environment is insecure. It means it’s real. I actually think one of the biggest mindset shifts FedRAMP 20x and the broader GRC engineering movement are pushing is this: nonconformities should not automatically destroy trust. Handled correctly, they should build it. Because mature organizations are not the ones pretending problems don’t exist. They’re the ones capable of identifying issues quickly, exposing them honestly and improving continuously. That’s engineering. And maybe that’s where compliance finally starts becoming useful again. The future of trust For organizations participating in the current pilots, many of these concepts are already being tested through automation-first assessments, machine-readable evidence and continuous visibility. FedRAMP 20x Phase 2. Because right now, most compliance still works like we’re printing MapQuest directions in 2004 and hoping nothing changes between point A and point B. The environment changes constantly. Cloud infrastructure drifts, engineers move quickly, businesses evolve and threat actors adapt far faster than annual audits ever could. Yet most assurance still relies on frozen snapshots and sampled evidence that were already out of date the second they were exported into a PDF. That’s the bit I think FedRAMP 20x genuinely understands. This isn’t just about modernising audits. It’s about acknowledging that modern systems are living systems. They are transient, constantly changing and impossible to understand properly through static evidence alone. That’s why the move towards APIs, telemetry and machine-readable evidence matters so much. Not because APIs are trendy. Because they allow us to expose operational truth continuously instead of periodically reconstructing it after the fact. And honestly, I think that changes the future of trust. In five years, I don’t think organizations will primarily send customers PDFs and certifications. I think they’ll expose assurance layers. APIs. Telemetry. Machine-readable evidence. Instead of saying: Here’s our SOC 2. They’ll say: Here’s the operational data. Query it yourself. Auditors won’t disappear, but I think their role changes significantly. Less time auditing screenshots and selected controls. More time validating whether the underlying evidence pipelines are complete, accurate and trustworthy. Modern audit becomes less about auditing controls and more about auditing data integrity. And honestly? That feels like a much healthier future than the one we’ve built today. Because the future of trust probably isn’t polished dashboards and carefully curated evidence. It’s operational truth, and operational truth is messy. It contains drift, exceptions, bypasses, gaps and uncomfortable findings, but that’s exactly why it’s valuable. Stop rewarding the best storytellers Maybe that’s the biggest shift FedRAMP 20x is trying to create. Not better paperwork. Better visibility. For years, we’ve rewarded organizations for telling the cleanest story. Maybe it’s finally time we reward them for exposing the truth instead. That’s the revolution FedRAMP 20x and GRC engineering are leading. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Researchers have identified a new backdoor program that has been used in enterprise intrusions since April and appears to be linked to an initial access broker that sells network footholds to ransomware gangs. Dubbed Mistic by researchers from Symantec, the malware program has been deployed on networks belonging to organizations from multiple sectors, including insurance, education, IT, and professional services. In some cases it has been used alongside ModeloRAT, a piece of malware written in Python that’s associated with threat actor Woodgnat, also known as KongTuke. “Woodgnat reportedly functions primarily as an IAB [initial access broker],” the Symantec researchers said in their report. “Its goal is not to deliver the final payload, but to establish highly durable remote access within an enterprise and sell this high-level access to ransomware affiliates and other attackers for a fee. The Symantec Threat Hunter Team has observed ModeloRAT being used in attacks delivering the Qilin ransomware.” Woodgnat has been operating since at least May 2024 and has served multiple ransomware gangs over the past two years, including Interlock, Rhysida, Akira, 8Base, and Black Basta. Its attacks are largely opportunistic by routing web visitors through a variety of ClickFix social engineering campaigns. A backdoor with credential stealing capabilities The Mistic backdoor is launched through a technique called DLL sideloading, where a legitimate executable belonging to another program is executed first and searches for a DLL of a particular name to load into memory. This is a very popular technique for avoiding detection, as many legitimate programs perform dynamic DLL searches across multiple folders and are vulnerable to DLL poisoning. Ironically in this case the attackers deliver and execute a file called MpExtMs.exe, which is digitally signed and belongs to Microsoft Defender. This file searches for a DLL called version.dll, which in turn searchers for and loads another one called EndpointDlp.dll. The attackers have named their backdoor EndpointDlp.dll so it gets loaded directly in memory. The backdoor itself reaches out to a command-and-control (C2) server and can execute code delivered from it directly in memory, without saving any file on disk. Other features include the ability to write, delete, and move files on the victim machine and to download and upload files to the C2 server. The researchers have also observed a credential-stealing .NET DLL being downloaded and executed on victims’ networks, in addition to ModeloRAT. Common system tools used by the attackers include curl, reg.exe, net.exe, PowerShell, certutil.exe, and the Windows Management Instrumentation (WMIC). “The fact that Mistic executes in memory and also has a kill switch built in means that it is very stealthy, potentially allowing for long-term, stealthy access for attackers,” the researchers said. ClickFix infection chains The Woodgnat group’s attack campaigns often involved tricking users into executing malicious PowerShell commands on their computers using a variety of social engineering tricks that include displaying fake CAPTCHA tests on websites and crashing the user’s browser and asking them to paste commands to fix the crash. Since April the attackers have also started messaging victims on Microsoft Teams impersonating IT support staff and guiding them through a series of malicious paste-and-run steps. “While the initial compromise may be opportunistic, the attackers profile the machines for potential interest to determine their value and if they can sell access to them,” the researchers said. The Mistic backdoor is the latest example of initial access brokers and ransomware gangs returning to the use of custom malware tools they developed in-house instead of solely relying on living-off-the-land and dual-use system administration tools. The Symantec report includes a list of indicators of compromise for this new backdoor and other malicious files and IP addresses used in the recent Woodgnat attacks. View the full article

Two members of the Scattered Spider cybercrime collective have admitted launching a cyberattack against Transport for London (TfL) that caused millions in damages. Thalha Jubair, 20, from East London, and Owen Flowers, 18, from Walsall, West Midlands, were due to stand trial for computer hacking offences at Woolwich Crown Court on Monday but changed their pleas to guilty on the first day of what was scheduled to be a six-week trial. Sentencing for the pair is due to take place in the same outer London court on July 22. Mind the gap Jubair and Flowers compromised TfL’s network between Aug. 31 and Sept. 3, 2024, in an attack that disrupted in-station services such as information boards, and online services such as TfL’s refunds portal and Oyster photocard application systems for young people. The same attack also meant all 28,000 employees of the London transport network were obliged to attend a TfL office for a password reset. A BBC investigation in March 2026 revealed that the hack had exposed the names, email addresses, mobile phone numbers and physical addresses of an estimated 10 million people. TfL suffered a reported £29 million ($38.2 million) in losses, incident response, and other recovery costs. The attack was investigated by the UK’s National Crime Agency and City of London Police. Police investigators quickly identified Flowers as a suspect prior to his arrest at his home on Sept. 6, 2024. Forensic analysis on the laptops, tower computers, hard drives, and USB sticks seized at the time of Flower’s arrest uncovered evidence that he had also broken into the systems of US healthcare companies SSM Health Care and Sutter Health. One Acer laptop seized during the arrest held videos showing Jubair accessing TfL systems during the attack, according to a police statement on the case. The pair were messaging each other through the Telegram messaging service as well as using a common workspace that they shared with other cybercriminals. Web of destruction The Scattered Spider group burst onto the scene with ransomware attacks against Caesars Entertainment and MGM Resorts in 2023. Attacks against a wide variety of targets across multiple industries, including retail, hospitality, telecoms, and aviation, followed. UK attacks linked to Scattered Spider include high-profile attacks on Jaguar Land Rover and retailer Marks and Spencer. Scattered Spider is best viewed as an overlapping network of largely English-speaking crews and affiliates rather than a tightly knit organisation. The group’s tradecraft is characterised by social engineering, help-desk impersonation, SIM swapping in the furtherance of ransomware-enabled extortion, and other scams. In particular, Scattered Spider targeted outsourced IT support and help-desk providers to reset credentials and bypass multi-factor authentication controls to expand their access into victim’s networks. A loose alliance or collective of cybercrime groups including Scattered Spider, Lapsus$, and ShinyHunters was established last year. Jubair and Flowers are among a growing number of members of the group to be convicted for computer crime offences. Tyler Buchanan, a senior figure in the group, was arrested at a Spanish airport in June 2024. Buchanan, 24, of Dundee, Scotland, was extradited to the US and pleaded guilty in April 2026 to a scam that aimed to steal $8 million in virtual currency from at least a dozen companies as well as numerous individuals. Co-conspirator Noah Michael Urban of Palm Coast, Florida, was jailed for 10 years in April 2025 after pleading guilty to aggravated identity theft and wire fraud offences. Other prosecutions remain pending. View the full article