In the late 1940s—when computer engineers were grappling with unreliable hardware and noisy transmission environments—a team of engineers inside a modest lab at the University of Manchester, England, confronted a problem so fundamental that it threatened the viability of digital computing itself. Machines could generate bits, but they could not reliably read them back.

The inconsistent reading back of memory data did not initially present itself as a grand theoretical challenge. It showed up as something more mundane: inconsistent computing results.

Engineers including Frederic C. Williams, Tom Kilburn, and G. E. (Tommy) Thomas traced the failures not to logic errors but to the physical behavior of the machines themselves. The team devised a technique for keeping a transmitter and a receiver synchronized without relying on a separate clock signal. Their innovation, known as Manchester code or phase encoding, encoded each bit with a transition in the middle of the bit period, effectively embedding timing information directly into the data stream to be a self-clocking signal. So, even if the signal degraded or the timing drifted slightly, the receiver could continually keep time based on those regular transitions.

By eliminating the need for separate clocks and reducing synchronization errors, Manchester code made data transfer more robust across cables and circuits.

Those qualities later made it a natural fit for technologies such as Ethernet and early data storage systems. Its self-clocking nature helped standardize how machines communicate, and it laid the groundwork for modern networking and digital communication protocols.

On 13 April 2026, this breakthrough was honored with an IEEE Milestone plaque during a ceremony at the University of Manchester. Dignitaries from IEEE and the university attended the ceremony.

Embedding timing in signals

Those 1940s Manchester University engineers were working on systems that fed into the Manchester Mark I, one of the first practical stored-program machines.

When troubles arose, they used oscilloscopes to probe signals. They found that electrical pulses did not arrive with consistent timing. Memory signals also blurred over time, making them harder to read, and when long runs of identical bits occurred, the waveform flattened into stretches with no transitions.

That led to a crucial insight: The problem was not just detecting whether a signal was high or low; the system also lost track of when to sample the signal. Without reliable timing markers, even correctly formed signals were misread. Bits could effectively be lost or miscounted because the system fell out of sync.

At first, the engineers tried to tame the hardware. They experimented with stabilizing circuits and more consistent pulse generation, attempting to impose a regular rhythm on an inherently unstable system. But the fixes proved fragile, and the electronics of the day could not maintain the required precision. So the Manchester group took a different approach.

If the hardware could not provide a dependable clock, the signal itself would have to carry one. Instead of representing data as static levels, each bit changed state, with a guaranteed transition in the middle.

Embedding timing in the signal reduced erratic behavior. Machines were suddenly able to reliably transmit, store, and read back data—an essential step toward practical stored-program computing.

Making signals unmistakable

The Manchester code addressed several issues at once. Regular transitions allowed continuous timing recovery. Transitions proved easier to detect than static levels, and long runs of identical bits no longer produced flat, ambiguous waveforms. Rather than fighting the imperfections of early electronics, the design worked with them.

From lab curiosity to a global standard

What began as a local solution in Manchester shaped digital communication systems for decades, including early Ethernet technology, for which timing and shared-medium communication were central challenges.

According to Robert Metcalfe, a member of the team that built the first Ethernet system at Xerox PARC in 1973, he and his colleagues relied on Manchester code.

“Manchester code solved a fundamental problem for us: timing,” Metcalfe says, explaining that each bit carried its own clock and removed the need for a global synchronized signal.

That self-clocking property wasn’t the only benefit provided by the encoding scheme. On a shared coaxial cable, Manchester encoding did more than provide timing. Each transceiver left the medium undriven—effectively “off”—most of the time, allowing packets from other machines to pass without interference. Even during transmission, a station drove the signal only about half the time, leaving the line undriven during the other half of each bit cycle.

This distinction—between a driven signal and an undriven line, rather than simple 1s and 0s—allowed receivers to recover both data and clock timing while also monitoring the cable for other activity. If a transceiver detected a signal when it expected the line to be undriven,the signal indicated that another station was transmitting at the same time. In other words, the system could detect collisions in real time and respond accordingly.

The idea has proven durable far beyond local networks. Manchester code is being used aboard theVoyager spacecraft, which are now cruising through interstellar space—underscoring its reliability in extreme environments.

The code also has found its way into everyday consumer electronics. Infrared remote controls for televisions and audio equipment commonly rely on Manchester code through protocols such as RC-5, developed by Philips in the early 1980s. The protocol encodes commands as timed infrared signals transmitted by a handset’s integrated circuit and LED, allowing devices to reliably interpret button presses even through noise and signal distortion. Manufacturers across Europe—and many in the United States—adopted the approach, extending Manchester code into the home.

Why the Milestone matters

An IEEE Milestone designation recognizes technologies with enduring impact. Manchester code qualifies because it solved a foundational timing problem at a critical moment in computing history.

Without a way to embed timing in the data itself, early digital systems would have remained fragile and unreliable. Manchester code helped transform them into dependable machines, and it enabled much of today’s digital communication.

“Manchester code solved a fundamental problem for us: timing,” —Robert Metcalfe, an Ethernet inventor

Key participants at the plaque dedication ceremony included Tom Coughlinm 2024 IEEE president; Duncan Ivison, University of Manchester president and vice chancellor, and Nagham Saeed, chair of the IEEE U.K. and Ireland Section.

Talks by Kees Schouhamer Immink (the 2017 IEEE Medal of Honor laureate probably best known for his work that made compact discs and other high-density digital media practical) and Peter Green (Manchester’s deputy dean for the engineering faculty) highlighted the code’s lasting impact on digital data storage and communications.

The IEEE Milestone plaque for the Manchester code reads:

“At this site in 1948–1949, Manchester code was invented for reliably encoding digital data stored on the Manchester Mark I computer’s magnetic drum. It became a standard for computer magnetic tapes and floppy disks and was used in digital communications, including the Voyager 1 and 2 spacecraft and early Ethernet networks. It found wide use in domestic remote controllers, radio frequency identification (RFID) tags, and many control network standards.”

Administered by the IEEE History Center and supported by donors, the Milestone program recognizes outstanding technical developments worldwide. The IEEE U.K. and Ireland Section sponsored the nomination.

offbeat

Well, page is more accurate, but the source code is available if you want to try doing something even crazier

UPDATED Web hosting bills getting too expensive? Maybe you ought to consider serving your site from a one-dollar 8-bit microcontroller.

Okay, you won’t exactly be serving up a high-performance, graphic-rich website using this project from European developer and blogger Maurycy Zalewski. The setup is limited to one URL, but hey, it actually works, provided an influx of visitors hasn’t killed the site yet. 

The bargain-basement chip that serves as the central component of this project is the AVR64DD32, which currently retails from DigiKey for $1.30. It has a single 8-bit AVR core with a blistering 24 MHz max clock speed, 8 KB of static RAM, 64 KB of flash memory, and 256 bytes of EEPROM non-volatile memory for storing a very limited amount of data. 

Zalewski told The Register in an email that the whole build was free for him, as he had everything on hand, but he estimates the total cost of the thing to run closer to $2 or $3 when accounting for resistors and capacitors, the board the chip is attached to, and the like.

Serving a web page from such a limited chip is a task, to say the least, and Maurycyz had to do a lot of legwork to get the thing working. 

The I/O pins on the AVR max out at 12 MHz, which Zalewski explained meant that it wouldn’t be possible to use Ethernet for the project, as the data flow from even the aged baseline Ethernet connection of 10BASE-T is too fast for the chip to handle. 

“10BASE-T still runs at 10 megabits/second,” Zalewski wrote. “Worse, it uses Manchester encoding: a zero is sent as ‘10’ and a one as ‘01,’ so 10 megabits of data is actually 20 megabits at the wire.”

“The proper solution is to buy a dedicated Ethernet chip from DigiKey, but then I’d be waiting weeks to finish this project,” Zalewski noted. Instead of waiting, he decided to take a different approach by turning to Serial Line Internet Protocol (SLIP), just like the guy who turned a discarded vape into a web server last year. 

For those unfamiliar with SLIP, it’s a 38-year-old protocol designed to encapsulate IP traffic for transmission over serial lines, and it was widely used to make internet connections in the olden days. SLIP is still supported in modern Linux builds due to its compact size and the fact that it’s often used to connect microcontrollers to the internet. 

Now, giving the AVR an internet connection didn’t solve the harder problem of actually serving a web page to visitors. Zalewski said the chip could generate response packets by swapping the source and destination addresses on incoming traffic and resetting the packet’s TTL value, but implementing TCP still took several days of work. HTTP handling was simplified by returning a hardcoded response for every request, which works as long as the site only serves a single URL.

Here’s that limitation we were talking about: “This works fine as long as there’s only a single URL on the site,” Zalewski said. Sorry for those wanting to host more pages from that $1 microcontroller.

Lastly, Zalewski said he had to figure out how to get requests from the internet to the microcontroller without spending money on a publicly routed IP address. That was resolved by using WireGuard to connect the microcontroller located at his home to a public-facing machine at a Helsinki datacenter, which then proxied requests to the microcontroller using a local address block. 

“This means that visitors aren’t directly connecting to the MCU’s TCP/IP stack… but hey, it’s the same setup that the Vape Server uses and no one complained,” Zalewski said. And all without having to buy a vape or root through dumpsters to find an old one. 

Zalewski told us that the hardware he used for the task was so simple that it only took a few minutes to build the thing itself. The software was another thing altogether, though.

“Wiring up the board only took a few minutes, but writing the software took multiple

days,” Zalewski said. Lucky for those wanting to duplicate or add to his work, the source code and a pre-compiled binary that’ll run on an 8-bit microcontroller are included in his blog post.  ®

Updated  at 1854 GMT on 3/18/2026 with more information after we spoke to the developer.

When an employee installs an AI writing assistant, connects a coding copilot to their IDE, or starts summarizing meetings with a new browser tool, they are doing exactly what a productive employee should do: finding faster ways to work.

Across most organizations today, employees are running three to five AI tools on any given day. Most were never reviewed by IT. A significant portion connect to corporate data through OAuth tokens or browser sessions, giving them access to shared drives, emails, and internal documents the employee never specifically intended to expose. Security teams often have no visibility into any of it.

This is the shadow AI gap, and it is widening fast. Most security tools were built to monitor email and network traffic flowing through the corporate network. A browser-based AI tool that connects to company data through a quick login approval bypasses those controls entirely, because it never passes through the corporate network at all.

According to Adaptive Security research, 80% of employees currently use unapproved generative AI applications at work, and only 12% of companies have a formal AI governance policy in place. The result is a growing disconnect between how employees work and what security teams can see.

A program that channels AI adoption into a safe, visible, approved path gives security teams the visibility they need and employees the tools they want. The five steps below show exactly how to build one.

Step 1: Build a Full Picture of What’s Running

A security program can only manage what it can see. The first step is discovering which AI tools are in use across the organization, and most security teams will find the answer surprising.

Three areas account for the majority of shadow AI activity.

• OAuth connections. Most AI tools request access to Google Workspace or Microsoft 365 through OAuth, which grants them read or write permissions to corporate data. A quarterly audit of connected third-party apps, sorted by permission scope, usually surfaces dozens of tools the security team never reviewed.  

Advertisement

• Browser extensions. Many AI tools run as browser extensions and never touch the operating system, so traditional endpoint management tools miss them entirely. A browser management solution or a lightweight agent installed on employee devices can scan for and identify which extensions are active across the organization.  

• AI features bundled inside already-approved tools. Microsoft Copilot, Google Gemini, and Salesforce Einstein are examples of AI capabilities that may have been introduced after the original vendor review, often without a separate security evaluation.

A simple employee survey is also worth running. A survey framed around helping employees work more safely tends to get candid responses. Many shadow tools surface through surveys that automated discovery misses entirely.

The goal of this step is a current, accurate inventory: every AI tool in use, who is using it, and what data it has access to.  

Step 2: Write a Policy That Works With Employees  

Most AI acceptable use policies stall for the same reason: they give employees a list of prohibited tools with no guidance on what the approved path looks like. A policy designed as a practical guide, one that identifies approved tools and provides a clear process for requesting new ones, is the foundation employees need to make good decisions.

An effective AI governance policy covers five things.

• Clear data classification rules specifying which categories of data, including customer records, source code, and financial information, should never be entered into any AI tool.  

Advertisement

• A verified data training opt-out status for each approved tool. Many AI tools use company inputs to improve their models by default unless enterprise settings are explicitly configured otherwise. Approval should require confirmed opt-out for any tool that handles sensitive data.  

• A defined process for requesting new tools, with a target turnaround time.  

• A plain-language explanation of why the guidelines exist.

That last element matters more than it might seem. Employees who understand why OAuth connections carry data exposure risk apply that reasoning to every tool decision they make. Policy becomes a form of education when the reasoning is included.  

Step 3: Create a Fast Lane for New Tool Requests  

Shadow AI grows fastest in organizations where the official approval process cannot keep pace with the rate of AI product releases. An employee who needs a tool today and faces a six-week security review will find a workaround within days. The goal of this step is to remove that friction.

• Most AI tool requests do not warrant a full procurement review. A structured intake form with defined evaluation criteria is enough for the majority of lower-risk tools.  

• A structured intake form and a defined set of evaluation criteria make faster decisions possible. For tools with limited data access, many organizations find a shorter turnaround feasible once evaluation criteria are documented and consistently applied.  

• The evaluation criteria should cover data access scope, vendor security practices, data training opt-out status, compliance certifications, and whether the tool already has a functional equivalent on the approved list.

Security teams that publish their approved tool list openly and keep it current typically see a meaningful reduction in shadow AI usage. When employees know where to find the right tools, they use them.

Step 4: Use Monitoring as a Shared Safety Layer  

Continuous visibility into AI tool usage across an organization serves two groups simultaneously.

• Security teams get the real-time picture they need to identify and address exposure before it becomes an incident.  

• Employees get a form of protection they often do not have on their own: a signal when a tool they are using may be putting their credentials or company data at risk.

A browser-native monitoring approach gives security teams visibility into AI activity without rerouting employee web traffic or adding friction to daily work. The signals it captures feed into each employee’s broader risk profile, sitting alongside their phishing simulation results and training completion data in one place.

That combined view matters because risky behaviors compound. An employee who clicks phishing links, skips training, and runs unapproved AI tools with access to sensitive data presents a much higher risk than any single behavior would indicate. Seeing the full picture in one place helps security teams focus on the employees who need attention most.

Step 5: Make Good Security Behavior Easy

Security programs that make the secure choice the easiest choice are the ones employees follow. In the context of AI governance, two things drive that: just-in-time coaching and training that explains the reasoning behind the rules.

Just-in-time coaching delivers a brief, contextual prompt at the moment an employee attempts to use an unsanctioned tool. This is more effective than quarterly training modules, because the intervention happens at the point of decision. A well-designed prompt tells the employee what the concern is, directs them to an approved alternative, and takes less than thirty seconds to read.

Training that explains the reasoning behind AI governance policies builds the kind of judgment employees can apply across any situation they encounter, including tools and threats that emerge long after the training itself. The AI tool landscape is changing fast enough that no training program can anticipate every specific case.

An employee who understands that OAuth connections to corporate Google Workspace can expose the entire shared drive to a third-party vendor will apply that understanding to tools that did not exist six months ago.

Building a Security Program Based on How Teams Work 

AI adoption is a signal of productive teams doing their jobs well. Companies that build practical programs around that momentum, with clear paths to approved tools and real-time visibility for security teams, tend to handle it best.

Security teams that close that gap find that shadow AI usage declines organically over time. Browser-native visibility, clear paths to approved tools, and just-in-time coaching at the moment of risk are what make that possible.

When employees have access to effective, approved tools and a fast, transparent path to get new ones reviewed, the incentive to work around the system largely disappears.

Adaptive Security’s AI Governance product gives security teams real-time visibility into every AI tool and shadow app running across their organization, with automated policies and just-in-time employee coaching built in.

Learn more at adaptivesecurity.com.

Sponsored and written by Adaptive Security.

Compare Our Picks

Others Tested

Photograph: Molly Higgins

Oneisall 2-in-1 Automatic Cat Feeder and Water Dispenser for $54: Generally, I’m a fan of all the Oneisall pet products I’ve tested. While they aren’t the most technologically advanced, they are always reliable and cheap. This model is relatively simple. To set up, you’ll need to hook up the bowl supports and dishwasher-safe stainless steel bowls, fill the water and kibble compartments, and plug in. This model runs on corded electricity but has an optional 4 AA batteries in case of power outage. There is no connected app. You’ll just set the clock and adjust meal settings, and you can schedule one to six meals per day with adjustable portions, from one to 10 portion sizes. I don’t love having food and water so close, since cats prefer them to be separate to prevent cross-contamination in the wild. I always recommend automatic pet fountains instead for a fresh source of water, but if you don’t have a lot of space, are on a budget, and need a temporary solution for getting fresh water to your kitty while you’re out of town, the gravity-fed water system ensures water stays relatively fresh (plus, the translucent tank makes it easier to check water levels). I’d recommend this basic option if you’re on a budget and need a temporary solution for when you’re out of the house (and don’t mind not having a connected app).

Photograph: Molly Higgins

Closer Pets C200 2-Meal Automatic Pet Feeder for $50: This automatic feeder is super simple, which is both its weakness and its strength. It’s essentially two shallow plastic containers with stainless steel inserts (both dishwasher safe) and tamper-resistant lids that are locked and automatically open using an old-school egg-style timer that runs on a AA battery rather than electricity. Although the container has an ice pack to keep the wet food cool, after one night it lost virtually all of its coolness. There’s a lid-link clip attachment, a small piece of plastic that links the lids to ensure they will open at the same time, which is super helpful for owners of two cats like me. I wish the timer were electric so I could program it to the exact time I want it open, rather than guesstimating the timing on the little marks. However, this is a simple solution to help make sure both my cats are given wet food without me having to wake up at the crack of dawn.

Photograph: Molly Higgins

Oneisall Cordless WiFi Automatic Cat Feeder for $70: I had high hopes for this cordless feeder that boasts a rechargeable battery with a 100-day life and an integrated app, but it’s just too unreliable. Through the app, you can program up to 10 daily meals (in 1-12 portions each), monitor pets’ eating habits, and customize meal calls. Unlike other apps, you’re not able to choose portion size, but instead have to multiply the number of servings. The app gave me constant problems, and would often disconnect from the feeder and be unable to reconnect to WiFi. Luckily, I was able to program meals via the screen and buttons, but it would’ve been a whole lot nicer if the app had worked reliably.

Do Not Recommend

Courtesy of Amazon

Catit Pixi Smart 6-Meal Feeder for $100: Like others on this list, the Catit Pixi wet and dry feeder uses ice packs to keep wet food fresh and rotates the meals in six compartments on a set schedule. The schedule can be programmed via the app or changed on the body of the feeder. At this price point, the app shouldn’t be this limited and glitchy. The schedule is available in military time only, and the app is extremely limited—you can only set the meal schedule for the same day, and when I wanted to do only two to three meals a day spread over two days, I had to reschedule the meals for every new day. The feeder didn’t keep it cold enough to spread the meals out and the wet food was not at a safe eating temperature. At this price point, just get the Petlibro Polar wet feeder for a few bucks more.

Catit Pixi Smart Cat Feeder for $140: Kibble is stored in the body of this dry feeder, but it doesn’t have a window to visually check food levels. The calendar to plan meals shows only a week at a time, and although it should repeat daily based on the schedule, I found that some days there would be no schedule despite setting one up. The Pixi also doesn’t tell you how much food was dispensed; it just refers to it as a “portion”—I manually measured and found the portion was less than a tablespoon of kibble. After using it continuously for more than a month, I found it was extremely glitchy and almost never reliably stuck to the programmed schedule, sometimes skipping meals altogether. This feeder is potentially dangerous, and I’d caution pet parents against relying on it.

Closer Pets C500 for $75: This automatic wet and dry feeder can schedule up to four pre-portioned meals (and one meal given manually) that are opened on a timer system using three AA batteries (sold separately). The user presets the four times they want the bowls, which have ice packs underneath, to rotate. The bowls are quite deep and narrow and aren’t super easy for cats to reach, which could cause whisker fatigue. And although there are two relatively large ice packs, when I checked on the feeder after a night’s sleep, the packs weren’t very cold. This may be OK for kibble, but wet food was kept at unsafe temperatures, and my cats couldn’t reach all of the food.

Four supply-chain incidents hit OpenAI, Anthropic and Meta in 50 days: three adversary-driven attacks and one self-inflicted packaging failure. None targeted the model, and all four exposed the same gap: release pipelines, dependency hooks, CI runners, and packaging gates that no system card, AISI evaluation, or Gray Swan red-team exercise has ever scoped.

On May 11, 2026, a self-propagating worm called Mini Shai-Hulud published 84 malicious package versions across 42 @tanstack/* npm packages in six minutes flat. The worm rode in on release.yml, chaining a pull_request_target misconfiguration, GitHub Actions cache poisoning, and OIDC token extraction from runner memory to hijack TanStack’s own trusted release pipeline. The packages carried valid SLSA Build Level 3 provenance because they were published from the correct repository, by the correct workflow, using a legitimately minted OIDC token. No maintainer password was phished. No 2FA prompt was intercepted.

The trust model worked exactly as designed and still produced 84 malicious artifacts.

Two days later, OpenAI confirmed that two employee devices were compromised and credential material was exfiltrated from internal code repositories. OpenAI is now revoking its macOS security certificates and forcing all desktop users to update by June 12, 2026. OpenAI noted that it had already been hardening its CI/CD pipeline after an earlier supply-chain incident, but the two affected devices had not yet received the updated configurations. That is the response profile of a build-pipeline breach, not a model-safety incident.

Four incidents, one finding

Model red teams do not cover release pipelines. The four incidents below are evidence for a single architectural finding that belongs in every AI vendor questionnaire.

OpenAI Codex command injection (disclosed March 30, 2026). BeyondTrust Phantom Labs researcher Tyler Jespersen found that OpenAI Codex passed GitHub branch names directly into shell commands with zero sanitization. An attacker could inject a semicolon and a backtick subshell into a branch name, and the Codex container would execute it, returning the victim’s GitHub OAuth token in cleartext. The flaw affected the ChatGPT website, Codex CLI, Codex SDK, and the IDE Extension. OpenAI classified it Critical Priority 1 and completed remediation by February 2026. The Phantom Labs team used Unicode characters to make a malicious branch name visually identical to “main” in the Codex UI. One branch name. That is where the attack started.

LiteLLM supply-chain poisoning and Mercor breach (March 24–27, 2026). The threat group TeamPCP used credentials stolen in a prior compromise of Aqua Security’s Trivy vulnerability scanner to publish two poisoned versions of the LiteLLM Python package to PyPI. LiteLLM is a widely adopted open-source LLM proxy gateway used across major AI infrastructure teams. The malicious versions were live for roughly 40 minutes and received nearly 47,000 downloads before PyPI quarantined them.

That was enough.

The attack cascaded downstream into Mercor, the $10 billion AI data startup that supplies training data to Meta, OpenAI, and Anthropic. Four terabytes exfiltrated, including proprietary training methodology references from Meta. Meta froze the partnership indefinitely. A class action followed within five days. One compromised open-source dependency sitting 40 minutes on PyPI created a cross-industry blast radius that no single vendor’s model red team would have caught.

Anthropic Claude Code source map leak (March 31, 2026). This incident was not adversary-driven. Anthropic shipped Claude Code version 2.1.88 to the npm registry with a 59.8 MB source map file that should never have been included. The map file pointed to a zip archive on Anthropic’s own Cloudflare R2 bucket containing 513,000 lines of unobfuscated TypeScript across 1,906 files. Agent orchestration logic. 44 feature flags. System prompts. Multi-agent coordination architecture. All public. All downloadable. No authentication required. Security researcher Chaofan Shou flagged the exposure within hours, and Anthropic pulled the package. Anthropic confirmed it was a “release packaging issue caused by human error.” This was the second such leak in 13 months. The root cause was a missing line in .npmignore. No attacker was involved, but the release-surface gap is identical. No human review gate existed between the build artifact and the registry publish step.

TanStack worm and downstream propagation (May 11–14, 2026). Wiz Research attributed the Mini Shai-Hulud attack to TeamPCP with high confidence. StepSecurity detected the compromise within 20 minutes. The worm spread beyond TanStack to Mistral AI, UiPath, and 160-plus packages within hours. Mini Shai-Hulud even impersonated the Anthropic Claude GitHub App identity by authoring commits under the fabricated identity “claude ” to bypass code review.

Four incidents. Three frontier labs. One finding. The red-team scope stops at the model boundary, and the build pipeline sits on the other side of it.

The timing no system card can explain

On May 10, 2026, OpenAI launched Daybreak, a cybersecurity initiative built on GPT-5.5 and a new permissive model called GPT-5.5-Cyber designed for authorized red teaming, penetration testing, and vulnerability discovery. Daybreak pairs Codex Security with partners, including Cisco, CrowdStrike, Akamai, Cloudflare, and Zscaler. OpenAI positioned the launch as proof that frontier AI can tilt the balance toward defenders.

The next day, the TanStack worm compromised two OpenAI employee devices.

OpenAI’s own incident disclosure acknowledged the gap directly. The company had already been hardening its CI/CD pipeline after the earlier Axios supply-chain attack, but the two affected devices “did not have the updated configurations that would have prevented the download.” The controls existed. The deployment was in progress. The worm arrived first.

The security community saw the same gap: Security researcher @EnTr0pY_88 noted on X that the real signal was the certificate rotation, not the exfiltrated code. “The cert rotation…is what you do when the blast radius reached signing trust, not just source access.” @OpenMatter_ put the SLSA provenance failure in one sentence. “If an attacker controls your CI runner, they control your attestations. Policy-based security is failing at scale.” And @The_Calda compressed the disclosure’s internal contradiction into seven words. “‘Limited impact’ but the next sentence is ‘we’re rotating signing certs.’”

A company that launched a cyber defense platform on Sunday and disclosed a build-pipeline breach on Tuesday is not failing at model safety. OpenAI is demonstrating the exact gap this audit grid exists to close. The model red team and the release-pipeline red team are two different disciplines; four incidents in 50 days suggest only one of them is being funded consistently.

The VentureBeat Prescriptive Matrix

The matrix below maps the seven release-surface classes missing from AI vendor questionnaires, with vendor hit, failure mechanism, detection gap, technical mitigation, and priority tier a security team can execute before Q2 renewals close.

For teams that need to map these rows into existing GRC tooling, rows 2, 3, and 5 align with NIST SSDF PS.1.1 (protect all forms of code from unauthorized access and tampering). Row 4 maps to SSDF PS.2.1 (provide mechanisms for verifying software release integrity). Row 6 maps partially to SLSA Source Track requirements for verified contributor identity, though no published framework directly addresses upstream dependency maintainer credential provenance. Row 7 is not yet addressed by any published framework, which is itself the finding.

Security director action plan

The matrix tells your team what to fix. Three actions tell security directors how to move it forward.

1. Add one question to every AI vendor questionnaire. “Does your organization red-team its release pipeline, including CI runner trust boundaries, OIDC token scoping, dependency lifecycle hooks, and registry publish gates? Provide the last assessment date and scope.” No date and no scope document is the finding.

2. Run rows 2 through 7 against your own CI pipelines this week. StepSecurity and Snyk both published detection and remediation steps for the TanStack worm patterns. Dev teams pull OpenAI SDKs, Anthropic packages, and Llama weights through npm, PyPI, and HuggingFace every week. The same patterns that got exploited are in your CI right now.

3. Brief the board on the provenance gap. The TanStack worm proved that valid cryptographic provenance can sit on top of a malicious package. Attestation tells the board where a package was built. Behavioral analysis tells the board what it does after install. Q2 renewal requires both. Snyk’s analysis recommends pinning trusted publisher configurations to specific branches and workflows, not just repositories. That is the language the board presentation needs.

The worm already knows where your AI credentials live

Mini Shai-Hulud does not stop at CI secrets. Datadog Security Labs documented that the payload reads ~/.claude.json and exfiltrates it. It scans for 1Password and Bitwarden vaults, Kubernetes service accounts, cloud provider tokens, and shell history files where developers paste API keys. StepSecurity’s deobfuscation confirmed that Mini Shai-Hulud harvests Claude and Kiro MCP server configurations, which store API keys and auth tokens for external services. For developers using AI coding agents, the worm already knows where their credentials live.

OpenAI, Anthropic, and Meta will keep publishing system cards. They will keep funding red-team competitions. They will keep passing model evaluations. None of that stops the next worm from riding in on release.yml.

The TanStack postmortem team said it directly. Modern supply-chain defenses are important but not sufficient on their own. Teams must proactively identify and close workflow gaps rather than relying solely on the security features of their tools.

from the MAGA’s-replacement-theory dept

Behold this utter bullshit, uttered by the Trump administration’s “border czar” Tom Homan:

White House border czar Tom Homan said Thursday he’s “sure” Immigration and Customs Enforcement (ICE) officers have detained U.S. citizens, “but we don’t deport them.”

Homan told reporters outside the White House that U.S. citizens have “nothing to fear.”

“We deport people that are going to be deportable,” he continued. “We arrest people that will be deportable based on suspicion. Have U.S. citizens ever been shortly detained based on suspicion? I’m sure. I’m sure.”

This is demonstrably false. For the moment, children born in the United States are considered to be US citizens. The Trump administration wants to end birthright citizenship, but it hasn’t managed to accomplish that yet. But that isn’t stopping it from deporting US citizens just because they’re too young to be capable of invoking their rights, like the two-year-old US born child the administration deported to Honduras in direct violation of a federal court order.

Pretending it’s no big deal for US citizens to have their rights violated intermittently as the government goes after non-white people, that’s even more obnoxious. That the administration hasn’t deported large numbers of US citizens is a miracle, rather than an indicator of ICE competence.

If you keep arresting the same person over and over, sooner or later what’s left of the safety net will fail and that citizen will be expelled from the country. That’s what one US citizen is hoping to prevent with his lawsuit against the government, which is being handled by the Institute for Justice. On multiple occasions, federal officers have decided this US citizen is deserving of deportation, as Isabela Dias reports for Mother Jones:

In a declaration submitted as part of a civil lawsuit, Garcia Venegas said the agents pulled him out of the car and onto the ground, and shackled his arms and legs. Garcia Venegas estimates seven or eight law enforcement personnel, including US Immigration and Customs Enforcement officers and local police—most of whom wore plain clothes and tactical vests—surrounded him. They asked him no questions.

Garcia Venegas, a 26-year-old Florida-born US citizen, said he tried to show his Alabama STAR ID as proof of status, but the agents ignored him. They put him in the back seat of one of their vehicles, questioned him about his place of birth, and searched his wallet. He offered to provide his American passport, which was inside the house, but the agents refused. Several minutes later, they released him, but not before having dogs sniff the truck for drugs, according to the declaration. Garcia Venegas said the officers told him he had been stopped because the car he was driving was registered in the name of his brother, who is undocumented.

One time might be an aberration. Repeated occurrences are something else entirely.

This wasn’t the first time ICE agents stopped and held Garcia Venegas. In fact, Saturday’s encounter marked the third such incident, according to court filings. Garcia Venegas, whose parents are originally from Mexico, had twice before been detained after ICE raided construction sites where he was working, and twice before he was let go after proving his American citizenship.

On one hand, repetition indicates that anti-migrant efforts under Trump are extremely sloppy, overseen by people who value quantity over quality. That’s almost certainly true, especially now that the DHS has lowered hiring and training standards for ICE. On top of that, there’s the casual racism of the policies, which — thanks to the Supreme Court — are pretty much legal because officers are allowed to infer from darker skin tones that someone might be in the country illegally.

On the other hand, there’s a chance Venegas is being targeted repeatedly for vindictive reasons. That seems less likely, at least in terms of what’s been detailed in his court filings. If it continues now that his lawsuit has been filed, that might suggest his arrests and detentions are no longer accidental.

Whatever the case, there’s going to be more of this happening, no matter what half-assed niceties Tom Homan might state during press conferences. The Trump administration is fighting to end birthright citizenship in this nation. If it does make this happen, it won’t be retroactive. But that’s hardly going to matter to the DHS and its underling agencies, which have repeatedly violated the letter and spirit of existing laws, when not violating direct orders from federal courts.

And this administration is going even further, seeking to “denaturalize” certain US citizens in order to deport them:

The Trump administration on Friday announced a major expansion of its denaturalization campaign targeting foreign-born American citizens accused of fraudulently obtaining U.S. citizenship.

The Justice Department unveiled denaturalization cases in federal courts across the country against roughly a dozen U.S. citizens born overseas. Officials said they had committed serious crimes or immigration fraud, or had ties to terrorism.

At first glance, this might look like the sort of thing the US government should be doing. This takes serious criminals off our books (so to speak) and sends problematic naturalized citizens back to their home countries to be their problem.

But we already know how this is going to work. The “worst of the worst” lie has been uttered repeatedly to defend the administration’s aggressive/transgressive tactics. But the facts have repeatedly shown the administration just wants non-whites gone. It doesn’t really care about any relevant criminal activity.

The same thing is happening here. The administration is making it clear this is just more bigotry, rather than an actual effort to root out the “worst of the worst” for the safety of the nation.

The group of naturalized U.S. citizens whose citizenship the Justice Department is now seeking to revoke includes immigrants from Bolivia, China, Colombia, Gambia, India, Iraq, Kenya, Morocco, Nigeria, Somalia and Uzbekistan.

While this group does include some accused of molesting a child and a supposed terrorist sympathizer, it also includes these people:

The group also includes individuals who allegedly used false identities to apply for immigration benefits and a man who allegedly entered into sham marriages to commit immigration fraud.

These are far less serious crimes, which don’t lend themselves to the “worst of the worst” narrative the administration deploys when its actions are questioned.

The lack of diversity (in other words, no white people or those with ties to Western European countries) in those selected to be first up for denaturalization is a leading indicator of further unlawful detentions of US citizens. As the government goes after more non-white US citizens under this pretense, DHS agencies will respond by rounding up more non-white US citizens, turning Homan’s false assurances into the lie it was always meant to be.

The administration actually wants to deport certain US citizens. That these agencies are far too willing to oblige, even without the necessary facts in hand, will definitely increase the number of citizens being held by ICE and correspondingly increase the number of those deported despite still being citizens of this nation.

Filed Under: bigotry, cbp, dhs, donald trump, florida, ice, leonardo garcia venegas, mass deportation, rights violations, texas, tom homan, trump administration

After three weeks of testimony and not much deliberation, a jury has ruled against Elon Musk, finding that Sam Altman and Greg Brockman were not liable in the case. The jury found that the statute of limitations had already passed when Musk sued the two executives. 

Musk filed his lawsuit in 2024, accusing them of “stealing a charity” following his departure from the AI lab in 2018. Though the jury in the case served only an “advisory” role, Judge Yvonne Gonzalez Rogers agreed with the jury’s ruling. Musk’s claims of “breach of charitable trust and unjust enrichment are dismissed as untimely,” she said according to CNBC. Though Musk could still appeal the ruling, Rogers told his lawyer she would dismiss an appeal “on the spot.”

At the center of the case was OpenAI’s reorganization that saw it convert from a nonprofit to a public benefit corporation. Musk has maintained that the move, along with Microsoft’s $13 billion investment in the firm, was a breach of OpenAI’s original contractual agreements. A major question of the trial, though, was when Musk became aware of OpenAI’s for-profit ambitions due to the three-year statute of limitations in the case.

“The facts and the timeline in this case have long been clear, and we welcome the jury’s decision to dismiss these claims as untimely,” a Microsoft spokesperson said in a statement. “We remain committed to our work with OpenAI to advance and scale AI for people and organizations around the world.”

In testimony, Musk’s lawyers tried to paint Altman as a dishonest, lying person, even going so far as to reference his recent unflattering New Yorker profile. Altman often struggled to answer the allegations against him. Asked if he thought himself to be an honest person, Altman said, “I believe so.” Musk’s legal team immediately jumped on that answer. “You believe so?” asked Steven Molo, the lead lawyer for the world’s richest man. “I will just amend my answer to yes,” Altman responded.

When he was later questioned about statements from past OpenAI employees, including former CTO Mira Murati, who described Altman as someone who would say “one thing to one person and completely the opposite to another person,” Altman repeatedly claimed he had not seen their testimony. “You’ve repeatedly been called deceptive and a liar by people with whom you’ve done business, right?,” Molo asked. “I have heard people say that,” Altman responded.

Where Altman came off as meek during his testimony, Musk was combative and testy. “Your questions are not simple. They are designed to trick me, essentially,” Musk told William Savitt, OpenAI’s lead counsel. As the trial inched forward to its conclusion, Musk was absent, despite an order from Judge Yvonne Gonzalez Rogers that he remain in case he was called to testify again. “Mr. Musk isn’t here today. My clients are,” Savitt told the jury during closing arguments. “Mr. Musk came to this court for exactly one witness: Elon Musk. Now he’s in parts unknown.” Parts unknown, in this case, turned out to be by Trump’s side for his diplomatic trip to China.

Even before the trial began, Musk faced longshot odds at securing the remedies he sought. The billionaire sought to undo OpenAI’s for-profit conversion and force the removal Altman and Brockman from their positions on top of the company. There might have been a point early in OpenAI’s negotiations with the Attorneys General of California and Delaware where Musk might have had a chance to get his way, but it was clear Judge Gonzales Rogers was deeply hesitant to undo the work of public officials. When Musk filed a request for a preliminary injunction to stop the conversion, the judge said the request was “extraordinary and rarely granted.”

The company is blaming this increase on “ongoing market conditions.”