An extensive program at Meta to gather a wide range of data from employees to train its AI model has been frozen after employees reportedly broke through its guardrails and accessed restricted data, and then did so again after Meta claimed to have fixed the vulnerability.

Whether or not the data collection by the $201 billion owner of Facebook was a good idea, analysts argue that the data protections deployed were woefully inadequate, given the extreme sensitive nature of the collected data.

“Meta had the resources to get it right, and yet they failed exponentially,” said Karianne Michelle, a director with consulting firm Acceligence. “That is what it looks like when the policy decision and the technical execution are happening in two different rooms that are not fully in sync. It is the kind of gap you see often enough at organizations under structural strain.”

Fritz Jean-Louis, principal cybersecurity advisor at Info-Tech Research Group,  agreed.

“What we just observed from the Meta story is a classic failure mode in AI-era data strategy: collecting high-risk telemetry without equally mature access controls,” Jean-Louis said. “At that scale, a single misconfiguration turns internal data into a systemic exposure.”

The story, detailed in a Wired report, involved a program that Meta rolled out in April called the Model Compatibility Initiative (MCI), which collects computer inputs such as mouse movements, click locations, and keystrokes, as well as screen content, the story said. Meta employees were initially not allowed to opt out. 

The data collected included full prompts and transcriptions, private conversations, people and performance data, Wired said, adding, “Meta executives have repeatedly defended the data-gathering project, saying it was necessary to train AI systems to operate computer software the way humans do, and that employees were the best examples for the artificial intelligence to learn from.”

Wired also quoted Stephane Kasriel, a Meta vice president overseeing AI research, who saying that the company discovered that unauthorized employees were found to have accessed MCI data on June 18, and that the hole was closed “within four hours.” But, he added, “ the initial fix didn’t stick, and access to the data had to be further locked down.”

In an email statement, Meta confirmed that the program was being halted for the time being. “We have carefully designed this program with privacy safeguards, and while we have no indication at this time that any data was improperly accessed by Meta employees, we’re pausing it while we investigate,” Meta said. 

A ‘liability surface’

Analysts, consultants, and industry practitioners said they were more concerned about the inadequate protections than the underlying data exposure.

Carmi Levy, an independent technology analyst, said that although there should be concerns about Meta’s “Orwellian oversight of workers’ keystrokes and mouse movements,” the bigger issue is the paper-thin protections that it used to protect that data.

“As creepy as MCI was and is, the reason Meta has hit the pause button has nothing to do with the moral and ethical fuzziness of everyday employee surveillance, and everything to do with its failure to secure the data it collected in the process,” Levy said. “Conceivably, it will resume monitoring and data collection once it fully understands how highly sensitive data, such as employees’ private conversations, performance data, and transcriptions, ended up being inadvertently shared with the entire workforce.”

One of the critical background issues is that while the data collected was highly sensitive, it was not, from a strict compliance law perspective, PII (personally identifiable information). That distinction might have lulled Meta into a false sense of security and convinced it that the data did not merit strong protections. 

“I think companies can get a little too comfortable saying, ‘Well, it’s not PII,’ as if that makes the data low-risk,” said Tom Findling, CEO of Conifers.ai. “But internal prompts, transcripts, chats, data tables, and performance notes can tell you a lot about how a company works, what it’s building and where things are messy or exposed. That’s sensitive, even if it’s not someone’s Social Security number.”

Findling argued that Meta executives “wanted to pretend that they didn’t understand” how sensitive the collected data was, and that was their excuse for why they should not have to protect it sufficiently. “There is no doubt that Meta did not tag this at an appropriate risk level,” he said.

Info-Tech’s Jean-Louis took particular umbrage at the particulars of the collected data. 

“Employee behavioral data, such as keystrokes, screenshots, and usage patterns, is effectively sensitive by default. If you’re using it to train AI, you have to treat it like production secrets, not analytics exhaust,” Jean-Louis said. “When thousands of internal tables are broadly accessible, you have a liability surface rather than a data platform. Trust nowadays is a security control. Once employees believe their data is overcollected or underprotected, you introduce both insider risk and reputational damage at the same time.”

Acceligence’s Michelle echoed Jean-Louis’ concerns.

“The data Meta exposed is not the real risk. Security policy only works if people believe it, and belief is exactly what is now in question,” Michelle said. “That gap is where incidents like this one do their damage: once employees stop trusting what leadership says about their own data, the doubt follows every policy that comes next, producing workarounds, quiet noncompliance, and employees who stop raising flags.”

This article originally appeared on CSOonline.

OpenAI has launched a program with cybersecurity firm Trail of Bits to use AI to find and fix vulnerabilities in widely used open-source software, as enterprises face growing risks from flaws buried deep in their software supply chains.

The initiative, called Patch the Planet, uses AI-assisted vulnerability research alongside human review to help turn security findings into tested fixes that can be disclosed through existing project channels.

Initial participants include Python, Go, cURL, Sigstore, NATS Server, aiohttp, freenginx, pyca/cryptography, and python.org. These projects support software development, networking, cryptography, and supply chain infrastructure used across a wide range of enterprise applications and services.

OpenAI said each engagement will begin with consultation with maintainers to identify where security support is most needed. Researchers will then investigate potential vulnerabilities, validate meaningful issues, develop or refine patches, support testing, and coordinate disclosure through the project’s existing channels.

Participating security researchers will use the company’s models and Codex Security to analyze code and help move fixes toward release. Trail of Bits engineers will review findings before they are sent to maintainers, a step meant to filter out false positives and duplicate reports before they add to the workload of open-source projects.

The company is also working with HackerOne and Calif to support vulnerability triage, coordinated disclosure, and additional discovery work as the program expands.

OpenAI said work under the program has already identified “hundreds of security issues and merged dozens of patches, with many more still undergoing coordinated disclosure.”

The work has also produced tools for fuzzing, historical CVE analysis, and differential testing, along with systems to filter inaccurate findings before patches are generated, OpenAI added.

The focus on open-source security follows incidents such as Log4Shell and the XZ Utils backdoor, which showed how quickly a flaw in a shared component can move through enterprise software.

Analysts said Patch the Planet changes the risk equation only if enterprises treat AI-assisted vulnerability research as an input to a broader software supply chain risk program, not as a substitute for one.

“The key shift is speed: AI-assisted research can help find, validate, patch, test, and document issues faster, while human reviewers reduce false positives before maintainers are burdened,” said Biswajeet Mahapatra, principal analyst at Forrester. “But the dependency on scarce expertise does not go away; it moves to triage, exploitability judgment, patch safety, disclosure timing, and production rollout.”

Guardrails before deployment

CISOs should put governance controls in place before using AI-assisted vulnerability research in enterprise security pipelines, to ensure unverified findings do not overwhelm engineering teams, said Devashri Datta, an open-source cybersecurity architect.

“CISOs should demand a Safety Relevance Layer in their risk modeling, a structured framework that requires every AI-generated finding to pass automated verification, including dynamic proof-of-concept validation and strong false-positive filtering, before it reaches a human analyst,” Datta said.

Those controls should also cover disclosure, particularly when AI tools identify flaws in third-party open-source components that the enterprise does not control, Datta said. Organizations need predefined escalation paths, notification timelines, and role assignments that take effect once a confirmed issue is found in an external dependency.

“Ad hoc disclosure in an AI-accelerated environment isn’t just a process gap; it’s a liability,” Datta said. “Trusting AI in the production pipeline requires verifiable auditability: organizations must be able to trace why the AI flagged a line of code, how it validated the exploit, and how it determined that the patch would not break downstream production systems.”

Continuous exposure reduction

AI-assisted vulnerability research could force enterprises to move away from periodic patching cycles and toward more continuous risk assessment, analysts said. If variant analysis and differential testing can be compressed from weeks to days, security teams may need faster ways to decide which findings matter most in their own environments.

That shift also means enterprises can no longer rely only on generic CVSS scores to prioritize remediation, Datta said. Findings will need to be assessed against the affected system, its business role, runtime exposure and the likelihood that a flaw can be exploited.

“We have to move toward context-aware, safety-critical prioritization,” Datta said. “Enterprise SBOM and VEX programs must evolve from passive compliance spreadsheets into live, machine-readable data feeds. For AI-assisted pipelines specifically, that means extending the VEX model to cover AI-introduced risk surfaces.”

Mahapatra said vulnerability management programs will also need to become more closely tied to software ownership, supplier response, and business impact.

“Security teams should move from periodic vulnerability handling to continuous exposure reduction,” Mahapatra said.

That means SBOMs should be treated as live inventories tied to runtime exposure and supplier response, rather than static compliance documents. Patch decisions should also account for asset criticality, exploitability, compensating controls, and business impact.

The article originally appeared on CSO.

Stung by a surge in cyberattacks that have run amok in developer environments, GitHub has strengthened the security of actions/checkout to block ‘pwn request’ attacks that exploit insecure use of the pull_request_target workflow trigger to run an attacker’s code with the workflow’s full privileges.

Announced on June 18, actions/checkout v7 now automatically blocks and fails workflows when used inside pull_request_target or workflow_run events when attempting to fetch unreviewed fork pull request code.

From now on, the only away around these checks will be for developers to implement an opt out by adding an explicit allow-unsafe-pr-checkout to actions/checkout, GitHub said in its V7 changelog.

The change signals the beginning of a new ‘secure by default’ era in which security will be defined by the GitHub system rather than being left to discretion of developers. As part of that effort, on July 16, the new defaults will be backported to all supported major versions.

“Workflows pinned to a floating major tag (e.g., actions/checkout@v4) will automatically pick up the change. Workflows pinned to a specific SHA, minor, or patch version aren’t affected by the backport and will need to upgrade using Dependabot or through established upgrade processes,” GitHub explained.

However, because pwn request attacks can happen in other ways, “further hardening of additional events may be explored in future releases,” the changelog added.

Blind spot

If there’s a criticism that can be levelled at GitHub over this, it’s that it has taken so long to address a weakness that’s been known about for years.

The issue is with GitHub Actions, which allows triggers to run workflows, including pull_request, which processes third-party forks without giving access to secrets such as API keys, service tokens, and credentials. The downside is that this restriction prevents some automations from working, which is why developers turn to an alternative trigger, pull_request_target, which grants the required access.

At some point, attackers realized that where pull_request_target was configured carelessly with actions/checkout to pull in untrusted fork code, it offered a back door into repositories and their secrets.

In other words, the weakness in pull_request_target isn’t the trigger itself, which is legitimate and secure when correctly used, but in its  incorrect use. As GitHub’s changelog puts it: “Checking out the head of an unreviewed pull request from a fork inside one of these workflows typically lets attacker-controlled code execute with the workflow’s full privileges.”

The arrival of actions/checkout v7, however, should make this harder, automatically blocking risky workflows regardless of their configuration.

Unfortunately, a lot of damage has already been done. Open source repositories have recently come under sustained attacks from the TeamPCP hacking group, using a variety of techniques, including pwn requests.

A notable example was its attack last month, which compromised 170 node package manager (npm) packages, including the TanStack Router ecosystem, thanks to a pwn request exploit. Embarrassingly, in a separate incident not involving a pwn request, GitHub itself was breached and the attackers exfiltrated source code from around 3,800 of the company’s internal repositories.

Better late than never, GitHub has sprung into action, plotting a series of security reforms on the platform, including, earlier this month, limiting automatic install script execution in npm.