WithSecure concludes that the Greyvibe group used LLMs to generate custom malware, backend infrastructure and phishing lures in order to target organizations in Ukraine as part of Russian intelligence gathering efforts.

Researchers have uncovered a previously undocumented Russian group that makes extensive use of large language models (LLMs) in its attacks against private, government, and military organizations in Ukraine. It uses a variety of attack vectors along with custom malware, with the goal of intelligence gathering for the ongoing war.

Dubbed Greyvibe by researchers from WithSecure, the group has shown systematic use of generative AI across all stages of its operations, from crafting spear phishing lures and malicious scripts to full on malware development and setting up of backend infrastructure.

“While the activities align with Russian state interests, several observed indicators suggest the group has ties to the broader cybercrime ecosystem, with the group potentially involving current or former cybercriminal actors,” the WithSecure researchers said in their report.

Shifting attack vectors

Greyvibe’s first campaign was launched in August 2025, with a series of spear phishing emails that purported to come from Ukrainian officials and government agencies including the Kyiv City, the Main Directorate of the State Emergency, and the State Service of Special Communications and Information Protection.

The emails included links to ZIP and RAR archives, hosted on Google Drive and a service called 4sync, that contained malware loaders written in Python and JavaScript. The final payload was a custom malware program developed by the group that the WithSecure researchers dubbed PhantomRelay.

In another attack in October, the group experimented with ClickFix-style attacks on fake CloudFlare CAPTCHA pages. These attacks instructed users to open the Windows Run dialog and paste in malicious commands.

Greyvibe also set up fake adult club websites in Ukrainian, as well as fake websites for charities claiming to support the Ukrainian military with FPV drones and UAVs. These attacks distributed several malware programs for both Android devices (FallSpy) and Windows (PhantomRelay and LegionRelay).

The researchers also tracked a website in Russian that they believe was part of the group’s operations; it referenced hard-coded telephone exchange numbers for secure telecommunications that are typically used by the Russian military.

“The intended victimology of this activity remains unclear,” the researchers said. “However, the most plausible hypothesis is that the lure was designed to deceive Ukrainian military personnel by presenting the illusion of access to a Russian military terminal.”

Custom malware developed using LLMs

The PhantomRelay malware program is a remote access trojan (RAT) written in PowerShell that can execute additional custom scripts received from the command-and-control (C2) server. While variants of this program have been observed in activity that might be unrelated to Greyvibe, the group completely rewrote the tool and created a version that was exclusively used in its own operations.

LegionRelay is another PowerShell-based RAT that can similarly execute commands and scripts received from the C2 server; it is used for file enumeration, file exfiltration, screenshot capture, browser data theft, Telegram and WhatsApp data exfiltration, RDP access setup and other actions.

FallSpy is an Android spyware program that can steal contacts, call logs, a list of installed applications, SIM-linked phone numbers, device and network information, Wi-Fi SSID, the phone’s last known location, its public IP address, and media files.

Finally, a series of custom scripts for obfuscating and loading malware was also observed: LOOKVALPS (PowerShell), LOOKVALJS (JavaScript), DAYLIGHT (PowerShell), and TEASOUP (JavaScript).

The WithSecure researchers have determined, with moderate confidence, that several of these custom tools were developed with the help of LLMs. LegionRelay in particular, as well as the background infrastructure serving it, show strong indicators of AI generation. The researchers believe some of the platforms used by the attackers include Ideogram AI, ChatGPT and Google Gemini.

They pit ‘do not tell the attackers what they don’t know’ against the slow response time after disclosure by many vendors.

Microsoft and a prominent cybersecurity researcher have gotten into a very public and rather personal exchange of unpleasantries about what responsible cybersecurity disclosures should mean in 2026. 

A cybersecurity researcher going by the name Nightmare Eclipse, who has disclosed several cybersecurity holes before patches were available, posted that he had tried to contact Microsoft officials and was rebuffed, which led him to publish details about the bugs.

“When I actively asked you [Microsoft] to communicate with me, you refused, humiliated me and made sure to insult me in front of people. You defame me in public with your CVE-2026-45585 advisory even though you literally deleted the Microsoft account I used to report bugs to you with and I got zero pennies from doing so and I still happily did like an idiot,” the researcher posted, adding that Microsoft has now deleted his GitHub account. “You are proving to everyone that you [are] actively escalating this conflict but I’m done begging you.”

The researcher then made a cryptic threat: “Mark this date July 14th, I will make sure your bones are shattered that day.” 

In another post, the researcher was even more direct: “I was told personally by [Microsoft] that they will ruin my life and they did” adding that Microsoft will “do everything but support the research community, I won’t disclose details, but they sabotage people a lot.”

Microsoft responded with its own post saying that some of the vulnerabilities revealed by the researcher “were not responsibly disclosed” and that there was an “unnecessary risk created by these disclosures,” adding, “uncoordinated disclosures that put proof-of-concept code for unpatched vulnerabilities into the hands of bad actors are never justifiable, and have real-world consequences.”

It was then Microsoft’s turn to get personal, with the veiled implication that the researcher has a bad reputation. “We always have and will continue to welcome vulnerability submissions from  anyone through our public researcher portal, regardless of past interactions or reputation,” the post said.

However, one senior Microsoft security executive posted a slightly more upbeat message, suggesting that the company may now have to rethink how it handles cybersecurity bug reports. 

“At this time, we are not changing our bug bar or the criteria we use to decide when a fix is required, though we will continue to evaluate as conditions evolve. Severity continues to be grounded in real-world impact and exploitability, drawing on the full set of signals in the Security Update Guide,” wrote Tom Gallagher, VP of engineering at the Microsoft Security Response Center (MSRC). 

“We will continue to anchor on a predictable rhythm and a disciplined process, while adapting as needed to the conditions in front of us,” he said. “What we encourage in turn is a thoughtful look at whether the practices that worked well for the patching landscape of a few years ago are still well matched to where the landscape is heading. The fundamentals have not changed. The pace at which they need to be applied is changing.”

CSOonline reached out to both Microsoft and Nightmare Eclipse, and neither provided any clarification or additional comments by publication time.

Frustration on both sides

One of the issues behind the debate over cybersecurity disclosure policies is that many researchers feel that their disclosures are often either ignored or the patch is unreasonably delayed by major vendors, including Microsoft. 

Adding to researchers’ frustration is the fact that vendors often do not communicate well about where things stand with a reported security problem. 

But vendors have their own complaint: they can’t address every one of the many holes that are reported to them quickly, given finite resources, and they must prioritize what they patch.

A related issue is the belief that major vendors, including Microsoft, will quickly prioritize patches once the hole becomes public; one example was the Microsoft Authenticator flaw, which Microsoft had known about for eight years before fixing it after it was publicized.  

Both sides may be right

Consultants and cybersecurity executives said both sides make good points in this instance. 

“Microsoft is right that uncoordinated zero‑day drops create real and immediate risk for customers, and researchers are right that vendors sometimes move only when pushed,” said cybersecurity consultant Brian Levine, executive director of FormerGov. “Both truths can exist at the same time.”

And, Flavio Villanustre, CISO for the LexisNexis Risk Solutions Group, added, “the cry from the security researcher feels like there is something vindictive going on. If the researcher believes that [Microsoft] acted unethically or illegally and has evidence in that respect, they could raise complaints with the appropriate authorities, rather than write a blog post. I am inclined to believe Microsoft more in this case.”

Gary Longsine, CEO of Intrinsic Security, also pushed back against Nightmare Eclipse, questioning whether they are functioning as an objective security researcher.

“This person might have a legitimate grievance of some sort against Microsoft, however, legitimate security researchers don’t do things this way,” he said. “I don’t do things that cause damage to literally billions of innocent bystanders, as retribution for whatever slight I may perceive. This is an attacker, an adversary, not a security researcher.”

Erosion of trust

In addition, Ishraq Khan, CEO of coding productivity tool vendor Kodezi, said that he is concerned about the emotional elements of the exchange between the researcher and Microsoft, because it is eroding trust, and that erosion is potentially the biggest danger.

“The researcher appears to believe the relationship failed long before the disclosures occurred. Reading the public posts, the recurring theme is not simply vulnerability research, but frustration over communication, trust, and access to the disclosure process,” Khan said. “Whether those claims are accurate or not, the researcher clearly believes private channels stopped working and that escalation was the only remaining option.”

And that erosion of trust, Khan said, is a critical issue, because AI, especially autonomous agents, is going to require far more trust between vendors and researchers. 

“The industry is entering a new era of vulnerability discovery. We are seeing increasingly capable AI systems uncover bugs, identify attack paths, and assist researchers in ways that were not possible a few years ago. The volume of discovered vulnerabilities is increasing while the time between discovery and potential exploitation is shrinking,” Khan said. “That changes the dynamics of disclosure. Historically, researchers and vendors were operating on a timeline measured in months. Today, discoveries can spread globally within hours. A breakdown in trust that might have once affected a handful of people can now affect entire ecosystems.”

He added, “the reality is that responsible disclosure only works when both sides believe the system is functioning. Researchers need confidence that findings will be taken seriously. Vendors need confidence that researchers will give them enough time to protect customers. Once either side loses faith in that process, the entire model becomes fragile.”

“What concerns me is that these disputes appear to be becoming more public, more adversarial, and more personal. Once security discussions shift from technical facts to questions of intent, reputation, and motivation, customer protection risks becoming secondary to the conflict itself.”

The proposed DNS extension underscores the importance of communication with and between AI agents.

As AI agents become more numerous and more communicative, keeping track of where to find them is becoming increasingly important. Numerous proprietary agent registries are on the market, but the Linux Foundation suggests we simply extend the distributed, open Domain Name System (DNS) infrastructure we already have.

The foundation is now inviting contributions to the DNS-AID project, a standard way for AI agents to discover, verify, and communicate with one another over DNS that requires no new infrastructure. It enables agents and Model Context Protocol (MCP) servers to use DNS as a global, vendor-neutral directory.

While many details remain to be worked out, the proposal suggests domain owners create a new well-known address that can provide a starting point for agents looking for one another: _index._agents.{domain}.

This approach ensures that agent discovery remains scalable, secure, and compatible with the protocols that underly the internet, the Linux Foundation said.

“AI agents are quickly becoming the connective tissue of the modern internet, but without secure, open discovery infrastructure, that connectivity becomes a liability,” said Jim Zemlin, CEO at the Linux Foundation. “DNS-AID helps anchor agent discovery in the DNS infrastructure that the internet already trusts.”

DNS-AID was initially developed by staff at Infoblox, and the latest internet draft of the DNS-AID proposal includes contributions from staff at Deutsche Telekom and Amazon. The Linux Foundation said it intends that DNS-AID will remain vendor-neutral.

The randomness in quantum physics is imperfect and needs amplification to be considered truly random, the researchers say.

Researchers in Switzerland claim to have built a perfect random number generator from two quantum superconducting chips, a 30-meter-long pipe, and some software. The resulting device could be used to generate cryptographic keys, or to offer a “public randomness service” for lotteries or blockchain applications, they say.

They’re not the first to make the claim.

Many sources of randomness are biased. For example, coins or dice tend to favor one side. “Even modern random number generators, which are based on quantum mechanical effects like the reflection of photons from beam splitters, are not entirely immune to such a systematic error or ‘bias’,” said Andreas Wallraff, one of the leaders of the research team at ETH Zurich.

Similar biases can be found in purely software-based pseudo-random number generators. This has led to security problems in IoT devices and WhatsApp, among other applications.

To get around that, the researchers set up of two supercomputing chips, each representing one qubit, cooled to near absolute zero. The chips are connected by a 30-meter-long microwave guide, similarly cooled, and the microwave photons flying between them create a situation of quantum entanglement.

The results produced by this process are then transformed via a special algorithm to generate perfect randomness. “The resulting sequence of zeros and ones is now really perfectly random, and we can even certify that,” said Renato Renner, the other team leader. “The technical improvements allowed us to create random numbers that will remain perfectly random for all eternity.”

Two flaws in the widely used open-source editor can be triggered through manipulated configuration files, prompting security updates from the project's maintainers.

Two arbitrary code execution vulnerabilities in Notepad++ let local attackers run commands of their choice on Windows machines by tampering with the editor’s XML configuration files, with both flaws rated High at CVSS 7.8.

The flaws, tracked as CVE-2026-48778 and CVE-2026-48800, affect every version of the editor up to and including 8.9.6, Notepad++ said in a release note. However, the vulnerabilities were patched the same day in version 8.9.6.1, alongside a third lower-severity crash bug, CVE-2026-48770, Notepad ++ author Dun Ho wrote in the release note.

The two code execution flaws share a single design weakness. Notepad++ stores user choices, such as the path to the command-line interpreter and the list of user-defined commands, inside XML files in the user’s profile directory. The editor reads those values and passes them to the operating system as commands without checking what they contain, according to a GitHub Security Advisory on Notepad++ published on May 27.

Anyone who can write to the XML files can decide what the editor executes, the advisory said.

The more concerning of the two flaws, CVE-2026-48800, targets the file that holds user-defined Run menu entries.

Notepad++ reads its user-defined commands from a file called shortcuts.xml and accepts whatever it finds there without validation, the advisory said. An attacker who can write to that file can add an entry that launches an arbitrary executable when the user clicks it in the Run menu.

“The injected commands appear with legitimate-looking names in the Run menu, making them appear as normal user-created shortcuts,” the advisory said. “This creates a viable persistence mechanism, as the injected commands survive reboots.”

The proof of concept Ho published shows an injected entry named “System Update Check” that launches Windows Calculator. Italian researcher Michele Piccinni reported the flaw.

A second path through the command-line interpreter

The second code execution bug, CVE-2026-48778, targets a different file. Notepad++ stores the path to its command-line interpreter in a file called config.xml and accepts whatever value it finds there as the program to launch when the user opens a folder in cmd, a separate advisory said. The interpreter path is stored “without any validation, whitelist, or digital signature check,” the advisory said. An attacker who edits config.xml can substitute any executable for the real Windows command prompt. Piccinni reported this one as well.

Neither flaw lets an attacker reach the XML files on their own, the advisories said. Both assume the attacker already has the ability to write to the user’s AppData directory or can trick the user into running Notepad++ against a poisoned settings folder, whether through local malware, a malicious Windows shortcut, cloud-synced settings, or a social-engineered archive extraction.

The third patched flaw, CVE-2026-48770, follows the same theme of unchecked input but stops short of code execution. A local process in the same Windows session can send the editor a malformed inter-process message that reliably crashes it, the advisory added. The bug carries a CVSS score of 5.0.

A question mark over MSI patch delivery

Notepad++ users can download the patched 8.9.6.1 binaries from the project’s download page, which offers both the EXE installer and an MSI installer for enterprise IT deployment that Ho added in November 2025.

The MSI followed sustained enterprise demand that intensified after a Chinese state-sponsored group hijacked the editor’s update infrastructure for six months in 2025 and after Ho hardened the update mechanism in February with cryptographic integrity checks.

The advisories recommended that users monitor the AppData folder on machines running Notepad++ for unexpected changes to shortcuts.xml and config.xml. The persistence of both flaws leaves no trace at the installation directory and no change to the Notepad++ binary itself, the advisories said, which means endpoint tools that look only at executables will miss it. Ho published no indicators of compromise.

Microsoft’s analysis of the Gentlemen ransomware reveals a Go-based encryptor capable of spreading across networks, helping operators expand attacks beyond the initially compromised system.

Ransomware operators have spent years refining the art of locking files. Now, some are working harder to get those lockers to every reachable system first.

Microsoft’s recent warning of the Gentlemen ransomware revealed its operators using a self-propagating Go-based encryptor capable of moving laterally through compromised environments and deploying itself across additional systems.

“Modern ransomware is no longer just about encrypting files,” said Paul Reid, vice president of Adversary Research at AttackIQ. “The bigger risk is how quickly a single compromised machine can become a broader business disruption.”

In a technical breakdown of its operations, Microsoft said the Gentlemen Ransomware was first observed in mid-2025 and remains highly active through 2026, impacting organizations across education, transportation, healthcare, and financial industries in North America, South America, Europe, Africa, and Asia.

Gentlemen began as a “closed ransomware,” turned into a ransomware-as-a-service (RaaS) offering in September 2025, and eventually partnered up with BreachForums to pick up affiliates, including pen-testers and initial access brokers, from the popular cybercriminal marketplace.

Built to move before it encrypts

Microsoft’s analysis specifically focused on the ransomware’s ability to propagate through a network without relying entirely on manual operator intervention.

The encryptor, written in Go, includes functionality designed to identify additional systems, authenticate using harvested credentials, and copy itself to remote machines over Server Message Block (SMB). Once deployed, it can execute remotely and continue spreading, creating a chain infection inside compromised environments.

According to Microsoft, the malware leverages legitimate administrative tools and Windows functionality to facilitate movement while reducing the need for attackers to remain actively engaged through the operation.

“The ransomware operator can control The Gentlemen encryptor through command-line arguments,” Microsoft said. “A password is required for execution, and optional arguments allow the operator to specify encryption scope, speed, lateral movement, and post-encryption behaviors.”

One of the command line arguments,“–full,” launches separate processes to encrypt local drives with SYSTEM privileges and network shares visible to the user, to maximize encryption coverage once the machine is compromised. Additionally, a “–spread” command is used for lateral propagation.

“Defenders should treat The Gentlemen as an attack-path problem, not just a patching or detection problem,” Reid said. “The priority is to understand where the ransomware could move, which controls would detect, contain, or disrupt it, and where gaps still exist before an incident occurs.”

Gentlemen performs a “password check” to validate the use of its RaaS by the affiliates, and blocks its usage from unwanted binary recovery or interception. “Before executing its primary functionality, the malware validates the –password argument against a hardcoded value embedded within the binary,” Microsoft noted. “For the sample analyzed in this blog, the expected password is ‘9VoAvR7G’.”

Detection windows are shrinking

Microsoft’s analysis highlights the defensive challenges posed by self-propagating ransomware. Once execution begins, the time available to detect, investigate, and contain malicious activity can shrink considerably as the malware spreads to additional systems.

“This is not the kind of threat where an organization can wait for a help desk ticket or a locked screen to realize something is wrong,” said John Joyner, Senior Director of Technology at Corsica Technologies. “Malware can move quickly through a network once it gets a foothold, which makes early detection the difference between a contained incident and a business-wide disruption.”

Microsoft emphasized the importance of monitoring lateral movement activity, credential abuse, remote execution attempts, and other behaviors associated with Gentlemen’s propagation rather than focusing solely on encryption events.

Additionally, it shared a list of indicators of compromise (IOCs) to support detection efforts. For those who don’t catch it on time, the ransomware leaves a note. “Your network is locked by the Gentlemen,” a desktop wallpaper reads on the victim’s machines.

Analyzing SEC 10-K filings reveals that while CISOs handle cybersecurity under the CIO, companies rely on the NIST framework to address growing AI and supply chain risks.

In 2023, the Securities and Exchange Commission (SEC) required public companies to include a new section in their 10-K annual filings that is devoted to cybersecurity. This section is meant to address “cybersecurity risk management, strategy, governance and incidents.” I got curious as to what senior cybersecurity executives are conveying about their companies in these reports. I turned this into a research project that also gives me a reason to test out some AI techniques as well.

The article is broken into two sections: My findings regarding Section 1.C for the top 200 companies in the S&P, and the second being my methods used to include some AI tech.

10-K Section 1.C

Some really great analysis of Section 1.C has already been done to include a Harvard Law School study, a PWC study and an International Journal of Accounting Information Systems paper. These were great reads, but both were done over a year ago with the first batch of filings. Also, with the Harvard Law study, they only looked at the top 100 companies. I wanted to see if I could reproduce some of the analysis using this year’s filings, as well as ask some of my own questions, like whether there are any major changes between 2024 and 2025.

Companies are required to disclose governance regarding cybersecurity risks. Key requirements include describing board oversight of cyber risks, the committee responsible and management’s role in assessing and managing material cybersecurity threats. Years of experience are often included.

Similar to the Harvard study, I’ll look at who holds the senior cybersecurity role and their level of experience, who they report to, what part of the board oversees cybersecurity and standards that they are using. Not every company included all these pieces of information, but the bulk of them did. I’ll also look at overall trends between 2024 and 2025.

CISO role top for cybersecurity

The chief information security officer (CISO) continues to be the principal position responsible for cybersecurity, with over 70% of companies reporting CISO as the role responsible for cybersecurity.  Numbers for CISO slightly increased from 2024 to 2025, going from 137 to 142.  A distant second and third are CIO and CSO.  The average years of experience for the role is about 23 years (standard deviation 6 years, 140 companies reported).

CIO remains top senior in a varied field

Chief information officer remains the top person that the cybersecurity official reports to and remained stable between 2024 and 2025 (~49 vs ~48).  This is consistent with surveys and other reporting that CIO is the most frequent.  I agree with another CSO article that having the position under the CIO is sub-optimal and both inserts conflicts of interest as well as downplays the importance of cybersecurity at the enterprise level.  Not saying it can’t work, but there are likely better arrangements.  No clear alternative has appeared in either 2024 or 2025 data (see the chart below), and the small relative numbers indicate there is a lot of variety in who the CISO reports to.  The CEO, CFO and CTO were other common reporting positions, but none were a clear second.  It is also worth noting that for over 50 companies, it wasn’t clear from the 10-K write-ups who the reporting position was.

Board oversight

Within the Company’s board, the Audit Committee is by far the most common group responsible for cybersecurity, representing 60% of companies.  This jumps to about 70% (138 companies), If you include all the variations of Audit to include Audit & Risk, Audit & Finance, etc.  Overall, audit numbers remained steady between 2024 and 2025.  Distant second and third were the Risk Committee and Board of Directors broadly.

NIST CSF for the win

National Institute of Standards and Technology (NIST) Cybersecurity Framework (CSF) is the most referenced cybersecurity standard, increasing between 2024 and 2025(113 vs 118). The most common other standard being ISO 27001, which also grew between 2024 and 2025 (49 vs 55).  Interestingly, System and Organization Controls (SOC) was only mentioned by 17 companies.  I find this seemingly low, given the importance of SOC reporting in large public sector companies.

Overall trends

Other interesting observations were what companies listed as their broad efforts as well as disclosures of incidents.

• Third-party and supply chain risk management. Acknowledging that external partners and suppliers represent a massive attack vector, multiple companies have instituted rigorous third-party risk management (TPRM) programs. These programs mandate pre-engagement security assessments, continuous monitoring and contractual requirements for vendors to maintain security standards and report breaches promptly.  Third-party cybersecurity programs are indispensable in an increasingly interconnected economy and increasing reliance on external tools and services for company processes.
• Proactive testing and incident preparedness. Companies are moving past passive defense into proactive and simulated testing. This includes regular penetration testing, vulnerability scanning and engaging independent external auditors or consultants to assess program maturity and test controls. Furthermore, practically all companies maintain formal Incident Response Plans (IRPs) and conduct regular “tabletop exercises” to simulate cyberattacks, ensuring that management, legal and operational teams are prepared to respond to and recover from real-world crises. The devil is in the details on this one. The 10-K is not meant as a detailed technical rundown of company methods, so while it’s good to see, it’s mostly boilerplate language.
• Human-centric security defenses. Recognizing that human error is a primary vulnerability, mandatory, enterprise-wide cybersecurity awareness training is a standard requirement. These training programs are frequently supplemented with regular, simulated phishing campaigns to test employee vigilance and provide immediate, targeted feedback or remedial training.  This training will need to adapt to the growing sophistication of AI-enabled deep fakes.
• Consistent disclosure of “No Material Impact” despite ongoing threats. A ubiquitous trend across the filings is the acknowledgment that while the companies face continuous, sophisticated and evolving cyberattacks, they have not experienced any incidents that have had a material adverse effect on their business strategy, results of operations or financial condition to date. I find this interesting, especially with the Critical Infrastructure//telecoms coming under repeated VOLT/SALT TYPHOON compromises as well as other attacks. Many companies also disclose that they rely on cyber liability insurance to mitigate financial exposure, though they frequently note it may not cover all potential losses.  I’ll be doing further research here as there are likely more interesting findings between material impacts, news reporting and formal disclosures.
• Artificial intelligence. AI was cited by over 50 companies and is increasingly referenced as a double-edged sword for cybersecurity.  Companies are leveraging AI and machine learning to automate threat detection and sort through vast amounts of security data. However, several acknowledged that AI empowers threat actors to execute more sophisticated, high-velocity attacks (e.g. deepfakes, advanced phishing).  A further seven companies mentioned the concern of AI and intellectual property disclosures with Prudential and Capital One having the most explicit language on this risk.

Part 2: Data gathering and analysis

This was a very iterative process that increased in complexity as I went through the process and also due to the increased need for accuracy.  I used several coding methods and AI tools to do this analysis. At first, I tried to use the big models to do all the work for me, but that quickly failed when they didn’t want to do that level of work! It also became apparent that getting the 10-K filings would take more work than just asking an AI agent.

Enter some vibe coding. I was raised on C, Java and BASH scripting and have avoided using Python until now. Nothing against Python, I just haven’t needed to, and laziness with going with what you already know has won out before. So, this proved a nice additional challenge. Using the datamule Python module and some vibing, I managed to download all the recent 10-Ks for the top 200 companies onto my local machine. From there, I extracted the 1.C sections into a separate file using another Python script. This caused a bit of an issue as there were some differences (~5%) in filings that used a different format, or the cybersecurity write-up was in a different section of the 10-K.  About 15 companies put them in the Risk section or elsewhere.  I used a second Python script that leveraged the command-line version of Gemini (gemini-cli) to pull this information out.

I then created a database in postgres that would store some of the key findings and allow for some further analysis. To get the data into there, I created a Python script that would run each of the 1.C files through Gemini and Claude using Python API calls.

The use of Gemini API and Anthropic API was the new part that I really wanted to test out, and it proved very interesting. LLMs really shine for condensing and summarizing large texts for meaning. The alternative would be very complex and manually written regular expressions. Using Gemini API and Anthropic API, it took the below prompt and produced a string that I could then plug into the SQL command. Very cool seeing this work. (**Note: I was also thinking of how to do prompt injection, data poisoning and the like with this, but the dataset was small and controlled and this isn’t production code!).

As a verification step, I then wrote another script that found all database entry differences between Gemini and Claude answers and ran the original 1.C section through Gemini again and told it to pick which answer was better.  This changed about 10-30% of the entries, depending on the field.  Additional analysis was done in Google Sheets and Google NotebookLM.

With this, I created a basic AI-enabled workflow. It wasn’t agentic, but that would be interesting to create an automated version of this.  This project showed some of the productivity potential of AI by allowing me to do very detailed research in about 15-20 hours of work, which would have taken at least twice as long by hand.  It also highlighted the continued issue with accuracy where accuracy is needed.  The bulk of the 15-20 hours was spent doing verification and refinement to make sure the AI answers were correct.

The total cost in tokens for development, debugging, and running was around $15, not expensive, but not something I’d likely develop for every project I have. The bulk of that cost came with the refinement and the addition of additional verification checks to ensure the data was correct.  Next projects might try to do this on my local computer using a local LLM like llama3 using ollama or maybe an agent that allows queries to the dataset this project created.

GEMINI_PROMPT = """ Analyze this SEC 10-K document and extract the following cybersecurity information. Return the response strictly as a JSON object with these exact keys: { "senior_cyber": "Name or title of the senior person responsible for cybersecurity. Provide a one word response either CISO, CTO, CSO, CIO, or position title.", "report_to": "Title or name of who the senior cybersecurity person reports to. one word response either CEO, CTO, CSO, CIO, position title, or unknown. ", "board": "The board committee overseeing cybersecurity Provide a 1-3 word answer. ", "standards": "The cybersecurity standards/frameworks used use provide 5-7 word answer. If unknown, state unknown. use acronyms if available (e.g., NIST, NIST CSF, NIST CSF 2.0, ISO 27001)", "years_of_experience": integer representing years of experience (use 0 if unknown) } """ MODEL_ID = 'gemini-2.5-flash' —---- # 6. Update PostgreSQL upsert_query = """ INSERT INTO company_cyber_filings_v1_4 (ticker, filing_date, senior_cyber, reports_to, board, st andards, years_of_experience) VALUES (%s, %s, %s,%s,%s,%s,%s) ON CONFLICT (ticker, filing_date) DO UPDATE SET senior_cyber = EXCLUDED.senior_cyber, reports_to = EXCLUDED.reports_to, board = EXCLUDED.board, standards = EXCLUDED.standards, years_of_experience = EXCLUDED.years_of_experience; """ # 4. Upload file formatted_date = f"{year}-{month}-{day}" # Formatted for standard SQL DATE cursor.execute(upsert_query, ( prefix, formatted_date, gemini_data.get("senior_cyber"), gemini_data.get("report_to"), gemini_data.get("board"), gemini_data.get("standards"), gemini_data.get("years_of_experience") )) cursor.execute(upsert_query, (prefix,f"{year}{month}{day}")) conn.commit() print(f" -> Saved to database.")

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

With just 60% of fines paid to date and AI laws on the horizon, the EU’s landmark data protection law has raised the bar for cybersecurity and exposed weaknesses regulations have in court.

Big tech firms continue to push back against fines levied for alleged violations of European data protection law, in what could be a harbinger for AI regulations to come.

While lawyers and experts quizzed by CSO broadly argue that big tech firms contesting data protection rules isn’t a particular cause for concern, the more widespread introduction of AI technologies is a far greater data protection challenge on the horizon.

The EU’s General Data Protection Regulation (GDPR) came into force eight years ago this week. Over those eight years, European regulators announced an estimated €7.1 billion in GDPR fines but nearly 40%, around €2.8 billion, has either already been annulled or is under active legal challenge, according to analysis by insurance brokerage Alliance Risk.

Fines that have already been annulled include one against Amazon at €746 million (Luxembourg, March 2026) and another versus OpenAI at €15 million (Italy, March 2026). Those under active appeal include three fines against Meta (€1.2 billion, €265 million, and €91 million) and one against TikTok (€530 million).

Alliance Risk used CMS Law GDPR Enforcement Tracker as its primary source for information on GDPR enforcement, cross-referenced against IAPP enforcement data and trackers from Kiteworks and UniConsent. Data on annulments came from reported court decisions.

GDPR established a benchmark for breach notification

According to Alliance Risk, GDPR successfully laid the foundation for data protection law globally — particularly by first establishing the 72-hour breach notification standard.

This three-day notification rule is law in six jurisdictions — EU, UK, Thailand, Kenya, Nigeria, and South Korea — and influential elsewhere. For example, the US CIRCIA rule for critical infrastructure, which is pending final rule publication this month, is due to apply the 72-hour standard.

By comparison, HIPAA gives US healthcare organisations 60 days as a breach notification deadline. The SEC gives public companies four business days but only after they’ve internally determined a breach is “material,” which adds its own delay.

Although the breach notification regulations established by GDPR have been a success, issues with the enforcement of rules remain.

“The framework has structural weaknesses that large companies have learned to exploit in court, and nearly 40% of announced fines reflect that,” according to Alliance Risk.

The EU’s AI Act reaches full application in August, and the European Commission is already proposing to reform GDPR through the Digital Omnibus. “The framework is being rewritten while it’s still being tested,” Alliance Risk concludes.

“The fact that around 40% of GDPR fines by value are under challenge isn’t necessarily a sign the system is broken,” Nick Phillips, an intellectual property lawyer at Edwin Coe LLP tells CSO. “Eight years in, the bigger fines were always going to end up in court, and the rulings that come out of those appeals are starting to give in-house teams something they’ve never really had before: practical guidance on what regulators can and can’t defend.”

Phillips argues that achieving compliance with GDPR has improved enterprise security maturity because of the 72-hour breach notification rule coupled with the obligation to record all breaches and to notify data subjects combined with the need to improve security controls even more than the threat of a fine for non-compliance.

“That breach notification regime has arguably been the single biggest factor in forcing organisations to put proper incident response in place, get forensics providers on retainer, and start reporting breaches up to the board,” Phillips says. “A lot of that simply wasn’t happening before 2018, and it’s the part of GDPR that’s done the most work.”

Marco Eggerling, LL.M, security and trust officer EMEA and Asia, at robotic process automation vendor UiPath, says it would be a “mistake to read these annulments as courts clearing big tech.”

“In the Amazon case, the Luxembourg court upheld the substance of the violations and sent the matter back to the regulator,” Eggerling notes. “The fine fell because the authority skipped required steps, not because the conduct was found lawful.”

Eggerling adds: “The lesson for regulators is to build procedurally bulletproof decisions. The lesson for companies is that the underlying obligations have not moved an inch.”

Even within the EU there is a disparity in how regulations are understood and applied, making cross-border decisions about data and AI challenging.

“A lot of organisations lean towards the ‘lowest common denominator’ and adhere to the strictest governance and more conservative approaches in order to avoid the wrath of regulators,” says Caroline Carruthers, CEO and founder of global data consultancy Carruthers and Jackson.

The UK and EU apply stricter regulations than the US or China, so many organisations adhere to the stricter rules wherever they operate.

Due to their size and nature, “big tech” organisations tend to have a heightened appetite for risk and a desire to push the boundaries of regulations — and often a different relationship with the general public, whose data is the business model. “They have a vested interest in deregulation and so will naturally be the most likely to contest enforcement,” Carruthers notes.

Data regulations need to evolve with the advent of AI

For most organisations, the enforcement of GDPR has gotten to a place where it is broadly fit-for-purpose, according to Carruthers.

“When GDPR was first introduced, the guidance was unclear and inconsistent,” Carruthers explains. “It felt legally robust, but a lot of the data practitioners struggled to make it work. Even now, some businesses tell us that they are ‘paralysed’ a little by GDPR. They are highly fearful of data and the associated regulation, to the extent that they are unable to maximise — or even touch on — the potential power of data.”

However, as AI and data regulation evolves, there’s a need to account for how these tools are now being used.

The concern is that history may repeat itself as regulation looks to keep pace with technological change. “There is a risk that organisations get stuck in a mid-maturity plateau in which innovation is halted by complex and inconsistent interpretations of regulations,” Carruthers warns.

The $5 billion Project Lightwell initiative combines AI systems with 20,000 engineers to deliver validated fixes directly into enterprise software supply chains without disruptive upgrades.

Open source code is everywhere in the enterprise; it’s estimated that upwards of 90% of Fortune 500 companies have it in their software supply chains. But open source code is notoriously rife with vulnerabilities, and identifying and patching those bugs can be an endless battle for security teams.

IBM and Red Hat are betting that a new initiative, Project Lightwell, can help accelerate this process.

Announced today, the project will commit $5 billion and 20,000 IBM and Red Hat engineers to build a new ‘enterprise clearinghouse’ to accelerate discovery and remediation of vulnerabilities in open source software. The companies say the clearinghouse will serve as an AI-powered  “security coordination layer,” giving enterprises the ability to integrate patches directly into their existing software supply chains.

Now in the design phase with a group of 11 financial partners, Project Lightwell will eventually be offered as a commercial subscription.

“The advancement in AI tools has broken the patching map, which is the ability to discover vulnerabilities in software without losing the speed of remediation,” Ashesh Badani, Red Hat SVP and CPO, told CSOonline. “Everyone’s running open source software, and the challenge is not being able to fix vulnerabilities quickly enough.”

Open source security issues have been well documented: Almost 50,000 common vulnerabilities and exposures (CVEs) were published in 2025, and Anthropic’s Project Glasswing, powered by its Mythos Preview model, found roughly 3,900 previously undiscovered high or critical severity vulnerabilities in open source software shortly after launch.

IBM is considered one of the broadest commercial open source ecosystems, using more than 62,000 packages and operating across Linux, Kubernetes, Kafka, Terraform, Java and other platforms, and providing lifecycle management, validation, and patching for elements within those environments.

The company says Project Lightwell will now apply those same engineering principles to broader AI frameworks, independent libraries, language toolchains, and data streaming platforms, to deliver validated fixes to open-source code already in use in enterprise environments. This can support remediation without disruption of stability, certification, or compliance.

No upgrades or access to source code are required; Project Lightwell will backport fixes to exact dependency versions that have already been tested and deployed. It operates on fundamental configuration manifests like pom.xml so code remains in controlled enterprise environments when patched artifacts are rolled out. Initial focus will be on Java/Maven, but the project will eventually expand to PyPI, npm, Go, and others.

Enterprises will have the ability to share sensitive vulnerabilities under embargo through a “secure intermediary model” and receive validated patches spanning Red Hat platforms and independent community code. They will also be able to deliver fixes across dependency chains; report and address issues across active production environments; and share fixes upstream so the wider open-source community can incorporate them.

“We want to make sure that whatever fixes we provide to the enterprises through the clearinghouse also find their way back into the open source community that developed [the code],” Badani explained. For instance, if a piece of Python code was patched, the fix should be quickly delivered back to the Python community. With Project Lightwell, that process can be achieved through a “secure map.”

Using advanced AI, and working with leading open source contributors, IBM and Red Hat engineers will focus on connecting upstream and downstream environments so fixes are enterprise-ready. They will also develop patches and perform “high volume” vulnerability review and triage, and dependency hardening.

The network of 20,000 engineers will come from IBM’s and Red Hat’s existing pools of talent, and the companies will augment those teams as needed, Badani explained. The companies will take advantage of foundation models coming out of frontier labs, as well as their own internally-built AI tools and frameworks. The $5 billion will be used to equip teams with AI tools and build out internal operational infrastructure.

Early Project Lightwell adopters include Bank of America, BNY, Citi, Goldman Sachs, JPMorganChase, Mastercard, Morgan Stanley, Royal Bank of Canada, State Street, Visa, and Wells Fargo. Following the initial design period, IBM and Red Hat will phase more customers onto Project Lightwell via a subscription model.

A call to action?

This type of initiative is “desperately needed” if enterprise is to save open source, noted David Shipley of Beauceron Security.

The days of trillions in wealth depending on volunteers “ended violently” with Mythos, he noted, and the bill has ultimately come due for open source. Enterprises will need to pay up, or lose it.

“If we don’t find a way to invest in open source, which will close a long-standing equity issue, the alternative is everyone building their own bespoke code using AI,” Shipley said. That would be “massively wasteful” from a compute and environmental perspective.

“I hope this drives others to act,” he said.

Keeping humans in the loop for an ongoing battle

Badani emphasized that, while AI is great at discovering security issues in open-source code, the patching process can still be cumbersome. Fixes have to be sent upstream, distributed to the open source community, then flow back to customers and users.

“Finding the bug is one thing,” said Badani. “The other is all the steps that it takes to actually go and remediate it. That extra amount of time is the gap that we’re trying to help close.”

Underscoring the severity of the problem, IBM and Red Hat have already had an “onslaught of incoming requests” since Project Lightwell was announced.

“This isn’t going to stop any time soon,” Badani said. “Even if we were to very successfully solve the initial set of challenges that come to us, this will be something that companies are going to need on an ongoing or recurring basis.”

And, while the narrative has focused on cutting human engineers in favor of AI, Project Lightwell is focused on the opposite: “We can address [the problem] with a mixture of AI tools and human knowledge and expertise,” Badani said. “Coupling the two gives you a better outcome than just using one or the other.”

This article originally appeared on InfoWorld.

This article originally appeared on InfoWorld.

Howard Solomon is a Toronto-based freelance reporter who writes on IT and cybersecurity issues.

Howard is a former editor of IT World Canada and Computing Canada. An IT journalist over 30 years, he has also written for ITBusiness.ca and Computer Dealer News. Before that he was a staff reporter at the Calgary Herald and the Brampton (Ontario) Daily Times.

The cyber agency is pushing aggressive remediation windows, continuous exposure management, and AI governance controls in what analysts say could preview future global standards.

India’s cybersecurity agency, CERT-In, has urged organizations to patch, mitigate, or isolate known exploited vulnerabilities affecting internet-facing “crown jewel” systems within 12 hours where feasible, warning that AI-assisted attacks are dramatically compressing the time between vulnerability disclosure and exploitation.

The recommendation, part of a sweeping new CERT-In blueprint on defending against AI-assisted cyber exploitation, signals a significant escalation in expectations around enterprise vulnerability management, exposure reduction, and operational resilience.

The 38-page framework also recommends one-day remediation for critical externally exposed vulnerabilities, three days for critical internal vulnerabilities affecting high-value systems, and five days for high-severity flaws based on risk prioritization.

CERT-In said threat actors are increasingly using AI to accelerate reconnaissance, vulnerability discovery, phishing, malware generation, and automated exploitation workflows.

“Exploitation timelines are reducing significantly,” the agency warned in the advisory, adding that attacks are expected to become “increasingly autonomous.”

An operationally disruptive target

Security analysts said the headline 12-hour expectation is likely to force enterprises to rethink traditional weekly or monthly patching cycles, but cautioned that the guidance is more nuanced than a blanket patch mandate.

“The 12-hour window is the outlier, realistic only as a containment target on a narrow set of exposed assets, never as a patch-completion target across sprawling estates burdened by fragmented infrastructure, layered approvals, outsourced operations, and legacy dependency,” said Sanchit Vir Gogia, chief analyst at Greyhound Research.

Gogia said the blueprint’s tiered approach is more significant than the headline remediation clock itself because it ties response timelines to exposure and operational criticality rather than applying a uniform patching mandate across all systems.

“The five-day high-severity window is comfortable for most enterprises. The three-day critical-internal window is where the pressure actually bites,” he said, particularly in sectors such as finance, telecom, healthcare, and operational technology environments where uptime concerns complicate rapid change management.

Apeksha Kaushik, senior principal analyst at Gartner, said the biggest challenge for many organizations will not necessarily be deploying patches, but achieving the operational maturity needed for rapid exposure management.

“The primary barriers are not just technical, but operational. Most organizations lack real-time asset visibility, automated vulnerability prioritization, and cross-functional incident response playbooks,” Kaushik said.

“The most acute struggles will be in asset discovery, risk-based prioritization, and orchestrating rapid response across silos,” she added.

From vulnerability management to exposure management

The blueprint repeatedly emphasizes that traditional periodic security assessments are becoming insufficient against AI-enabled attacks capable of rapidly weaponizing newly disclosed flaws.

Instead, CERT-In is pushing organizations toward continuous exposure management, threat-informed defense, continuous monitoring, and adversarial testing.

Notably, the framework leans heavily on temporary mitigations, including isolation, access restrictions, WAF/API protections, enhanced monitoring, and compensating controls when immediate patching is not possible.

Analysts said that approach makes the timelines more achievable operationally, but also shifts the burden onto asset visibility and exposure intelligence.

“Compensating controls do make the timelines more workable. They also remove every excuse,” Gogia said. “If you cannot isolate, restrict, or monitor quickly, the problem was never patch cadence. The problem is that you do not know your own exposure.”

Kaushik similarly said the guidance effectively pushes organizations toward more mature exposure management capabilities.

“Organizations must be able to rapidly identify affected assets, assess risk, and deploy effective interim controls,” she said, adding that enterprises lacking mature asset inventories, segmentation, and monitoring capabilities will struggle to operationalize the guidance at scale.

The blueprint also calls for continuous vulnerability assessments, AI-assisted security testing, adversarial simulations, penetration testing, and red teaming exercises.

A preview of future global standards?

Analysts said CERT-In’s remediation expectations are among the most aggressive currently issued by a national cyber agency and may influence broader international vulnerability-management practices as AI compresses attacker timelines globally.

“CERT-In has done something the West has largely avoided: it has set standing clocks by asset category rather than deadlines by individual vulnerability,” Gogia said.

He contrasted the framework with CISA’s Known Exploited Vulnerabilities (KEV) program, which typically uses vulnerability-specific remediation deadlines rather than persistent enterprise-wide remediation clocks.

“The fixed-clock model looks aggressive today because the rest of the world has not caught up, not because it is reading the threat wrongly,” Gogia said.

Kaushik said the framework could create operational challenges for multinationals whose global service-level agreements are less stringent than India’s expectations. “For providers, this may create a compliance gap where internal SLAs are less stringent than India’s requirements, necessitating a reassessment of global patching and mitigation processes,” she said.

CrowdStrike, Google, and the Shadowserver Foundation dismantled the GlassWorm malware operation, but experts say the broader chaos unfolding across open-source ecosystems is making isolated takedowns feel increasingly temporary.

Taking down a sprawling malware operation once signaled progress in securing the open-source ecosystem. Now, it barely registers. The GlassWorm campaign disruption comes at a moment when attackers can quickly reconstitute, and defenders are increasingly grappling with a new challenge: distinguishing real threats from automated noise.

“I think coordinated actions, like GlassWorm, can sever control, significantly increase attacker costs, buy time for remediation, and signal the possibility of a fightback,” said Agnidipta Sarkar, chief evangelist at ColorTokens. “But most takedowns are temporary actions in a long fight.”

The CrowdStrike-led takedown, conducted alongside Google and the Shadowserver Foundation, disrupted infrastructure linked to the campaign that had poisoned hundreds of repositories with malicious packages targeting developers.

A day after the takedown, in an independent development, the OSV database withdrew 157 malware reports after maintainers determined the submissions were likely automated false positives.

Takedowns help, but analysts question long-term impact

The takedown happened on May 26, at 14:00 UTC, with CrowdStrike confirming the operation to have struck down “all four of GlassWorm’s command-and-control (C2) channels simultaneously”. This reportedly helped sever the botnet operators from their infected machines, blocking them from pushing out new malware.

CrowdStrike described the GlassWorm operation as targeting infrastructure used to distribute malware through developer-focused repositories, an increasingly popular attack vector as adversaries chase CI/CD access, developer credentials, and downstream enterprise environments.

GlassWorm was a cross-platform operation affecting Windows, macOS, and Linux systems, with trojanized VSCode extensions and compromised npm and Python packages for information and credential harvesting.

“As part of our disruption efforts, we are working with partners to bring more pain to attackers, especially when we see them abusing our products or targeting our users,” said Google Threat Intelligence Group’s (GTIG) chief analyst, John Hultquist, in an X post.

Still, the broader economics of repository abuse remain unchanged. Open-source ecosystems continue to offer attackers low-cost distribution, massive reach, and relatively weak identity verification compared to traditional software distribution channels. That means operators behind campaigns like GlassWorm can often reappear quickly under new accounts, domains, or package names.

“It is disruption, not eradication,” Sarkar warned. “To build resilience after a takedown, defenders should prioritize rapid post-takedown scanning to detect the reemergence of malicious artifacts across related repositories and distribution platforms. ”

They should then establish granular micro-perimeters, build capabilities to contain propagation across workloads, endpoints, IT/OT/IoT/cloud assets, and limit the blast radius of supply-chain compromises (e.g., a poisoned npm package or a GitHub workflow stealing creds can’t easily pivot).

Sarkar advised developers and organizations to establish “granular micro-perimeters,” build capabilities to contain propagation across workloads, and limit the blast radius of supply-chain compromises.

AI False positives are becoming part of the supply chain problem

If GlassWorm highlights the persistence of real malware campaigns, the OSV withdrawal incident exposed a parallel issue affecting the open-source software (OSS) supply chain. It is the growing reliability surrounding automated security reporting.

The withdrawal of 157 malware reports believed to be AI-generated false positives matters, especially when it includes packages like FastAPI v0.136.3. FastAPI is a heavily adopted Python framework powering production APIs, AI services, and cloud-native applications across industries. Even a few days of false flagging can trigger costly deployment delays, CI/CD disruptions, and hours of development time in isolating legitimate software.

“I would recommend that enterprises be concerned enough about signal-to-noise problems to consider remedial measures, as automation erodes trust in defensive tools,” Sarkar said. “Unless you have a highly microsegmented enterprise, noise wastes analyst time, slows velocity, and risks missing sophisticated attacks amid fatigue.”

In 2026, with AI-assisted malware and reporting both accelerating and rising false positives in SAST/SCA tools, defensive automation is getting asymmetrically compounded by supply-chain volume, he noted.

In a blog post, Socket called bad OSV records particularly dangerous as the popular database gets rapidly carried through dependency scanners, CI checks, registry controls, SBOM tools, dashboards, and internal policy systems.

All hope is not lost, though, as newer tools promise lower reliance on AI for hunting dependency vulnerabilities. CVE Lite CLI, a light-weight, JavaScript and TypeScript dependency vulnerability scanner, is offering developers a way to know dependency risks while they are still writing code, much earlier than failing automated scanners in CI pipelines.

Organizations that deploy AI agents without observability processes and tools in place are disasters waiting to happen, some experts say.

CIOs rushing to roll out AI agents without real visibility into their decision-making processes are flirting with disaster.

According to AI experts, deploying agents without observability processes and tools creates a ticking time bomb with the potential for huge negative consequences.

Many companies are deploying AI agents and expecting them to increase productivity with little human intervention, observes T.J. Marlin, CEO of AI security firm Guardrail Technologies. That’s the wrong approach, he says. Instead, IT teams need to keep a close eye on agents and adjust policies and practices throughout the agentic process.

“It’s not just set it and forget it like a crock pot,” he says. “You don’t put it in the kitchen in the morning with the chicken inside and come back at night and have a great dinner. The organizations doing that are going to be on the front page because they just had some terrible thing happen to them.”

Many organizations are rapidly deploying agents because of a fear of missing out, while not understanding the nuances of the technology, Marlin says. Some IT leaders seem to compare agents to robotic process automation, when RPA results are far more deterministic, he adds.

“There’s a talent shortage and a knowledge shortage and people are building at pace without checking whether it’s correct and it’s operating as expected,” he says. “Those are all the hallmarks of the worst disasters that I’ve seen across my career.”

A recent report from agent governance vendor TrueFoundry puts numbers behind fears of unregulated agents. A survey of more than 200 enterprise AI leaders found that 54% of organizations represented can’t fully trace what their agents are doing and 56% have no centralized agent control or governance layer.

While TrueFoundry has an interest in driving agent governance forward, many other AI experts see the same problems.

Governing blind

Difficulties with governance and observability are major impediments to the deployment of productive agents, and many organizations are deploying agents without creating a centralized list of them, says Mahesh Kumar Goyal, senior data and AI expert at Google.

“Most enterprises have no inventory of the agents already running in production — they’re trying to govern what they can’t see,” he says.

In addition, traditional SIEM and EDR security tools were built to spot human anomalies, not rogue agents, he notes. “An agent running code perfectly 10,000 times in a row looks normal even if it’s been hijacked,” he says.

Running fully autonomous agents is not a good idea, he adds, and organizations need to think about least-privilege scoped tool permissions, policy enforcement layers that mediate every prompt and tool call, and end-to-end tracing that stitches prompts, tool calls, and downstream actions into one auditable trail.

“The financial system doesn’t run on trust; it runs on auditability, reconciliation, and circuit breakers,” Goyal says. “Agents will mature the same way. Tiered autonomy is the realistic answer: free rein on low-stakes tasks, human-in-the-loop on consequential ones.”

Part of the problem is that agents have upended the models used to determine whether traditional software was running correctly, adds Adel El Hallak, vice president of AI software at Nvidia. With traditional software, QA and security professionals could look at the code to debug problems, but agents make decisions in the runtime environment of an AI model.

The source of truth for agents resides in the traces, the records of the execution flow, not in the code, he adds. Collecting traces ­­— in essence, detailed logs — is a start toward agent governance, but organizations need to be able to act on the information, he says.

“For you to trust something, it has to be transparent, and observability is foundational to transparency,” El Hallak adds. “But just observing is not enough. We need to be able to take those signals and turn them into something actionable.”

Agent governance goes beyond observability to allow organizations to test and fine-tune agents continuously, he says. The tools are out there, with companies like Nvidia building their own internal governance frameworks, and several other vendors offering agent observability and governance tools, he notes.

“It’s not enough to just have the behavioral data, to capture the feedback data,” he says. “The system should allow me to annotate, change, augment, or create additional feedback data, and then I can use that data to improve my agent as a whole.”

The governance bottleneck

At the same time, many companies moving into agent governance have found it can be a huge bottleneck if done wrong, says Nirmal Ganesh, senior director of product management for agentic workflow automation at cloud storage vendor Box.

“I don’t believe we are past the hard part yet in terms of deploying agents in the enterprise,” he says. “Most companies are not yet good at those, and far fewer of them have gotten good at running them at scale with agent governance and observability.”

Ganesh sees several problems, including agents running without clear permission models. “If an agent can see more than a person or access more than a person’s permission on content or data, that’s an incident is waiting to happen,” he says.

However, some early agent governance models don’t scale. Some IT teams have defaulted to a position of humans needing to approve every agent output because that’s the safest option, he says.

“In reality, this is rebuilding manual process with more checkpoints or suggestion points,” Ganesh says. “At a high volume, governance is your bottleneck to scale and no longer your safely net.”

Organizations need observability and governance processes in place that are both scalable and comprehensive, he adds. Agent ROI will come from strong guardrails, clear permission models, and clear human-in-the-loop involvement, he says.

“Every mature automation needs ongoing observability — workflows change, policies change, decisions change, new use cases show up,” he says. “Human intervention is always needed for what changes over time, but we need less intervention for known paths and more focus on exception handling and governance fine-tuning.”

Observing output is not enough

Governance can’t just focus on agent output, adds Marcelo Lorenzetti, founder and CAIO at legal services AI vendor SavvyLex.

“The biggest challenge is not simply whether an agent produces a good answer,” he says. “It is whether the organization can prove what the agent accessed, what instructions it followed, what tools it invoked, what decisions it made, where a human intervened, and whether it stayed within authorized boundaries.”

Without a full level of runtime visibility, companies are left with screenshots, logs, and after-the-fact explanations that may not meet legal, compliance, or security requirements, he says.

Agents should be continuously verified instead of fully trusted, he adds, with governance engineered into the agent architecture itself. Governance should include role-based access, policy-bound execution, human approval thresholds, source and tool provenance, immutable activity records, confidence scoring, exception handling, and clear escalation paths when an agent reaches the edge of its authority, he recommends.

“Observability should not be limited to whether the model responded,” Lorenzetti says. “It should show the full decision path from input to action.”

AI agents have shifted the governance model that’s needed, he adds.

“The core problem is that many companies are moving from AI that answers questions to AI that takes actions, but their governance models are still built for passive tools, not autonomous workflows,” he says.