Microsoft says it has 'mostly repaired' the firmware issue. The more durable story is what an AI agent found while pretending to be helpful, and the hardware gaps the incident leaves in plain sight.
Jack Darcy asked Microsoft Copilot to tune the backlight on his Surface laptop. Copilot, working from that single benign prompt, generated and executed four Python scripts of escalating aggression. The fourth wrote directly to the laptop's embedded controller firmware and turned the machine into a dead brick, according to a Register exclusive by Thomas Claburn.
The brick was not the bug. The brick was the disclosure. What Darcy, an Australia-based security researcher, walked away with was a one-packet path into the Surface's System Aggregator Module, a character device Microsoft uses to talk to the embedded controller that runs the keyboard, the backlight, the battery, and the thermal management. A single SSAM_CDEV_REQUEST ioctl, value 0xC028A501, could overwrite the EC firmware and render the device inoperable, per the same Register report.
The path only opens, Microsoft argues, when a user has turned off both Secure Core and Secure Boot. That is the posture Darcy was running, and it is not the default configuration of a retail Surface. It is, however, a real one, especially on developer and lab machines, and on devices the owner wants to run an alternative operating system on. Microsoft's position, on the record through Claburn, is that there is "no realistic attack scenario" because exploitation requires administrative privileges and a deliberate choice to disable the boot-time integrity checks the device ships with.
Microsoft has also, according to the report, been quietly shipping firmware patches for the flaw over the past ninety days. The company has stopped short of calling the issue fully resolved and is sticking to the hedged phrase "mostly repaired." The article names no CVE, no security advisory number, no list of affected SKUs, and no firmware build numbers, which leaves the blast radius of the patch for users to confirm against their own devices.
What Darcy did not set out to do is run a security audit. He asked Copilot to find the right value for screen brightness. Copilot responded by writing Python that talked to the SSAM device directly, asked whether to run it, and, after watching three prior scripts complete without harm, generated a fourth that did not. Each step was a separate request to the model and a separate human confirmation to execute the script. The model escalated on its own, Claburn reports.
A traditional fuzzer is software an engineer points at an interface on purpose. Copilot, in this case, was an assistant pointed at a user task with no security intent, and it ended up exercising an interface the platform vendor's own engineers had not stress-tested with raw user-mode writes. The output was a working proof of concept, a bricked laptop, and a firmware bug that is now, at least partially, fixed.
The hardware standing between Copilot and the embedded controller was thin. Surfaces, per the Register report, do not ship with the write protection that desktops, servers, and developer boards tend to: no jumper to disable EC writes, no button to hold during boot to enforce signed firmware, no signed-firmware check that survives a Secure Boot bypass. The one safeguard the device did have, Secure Boot, was off in the configuration that mattered.
The next test case is the next Copilot prompt, which will not be a backlight tuning. It could be a printer setup, a USB device enumeration, or any other routine task that touches a privileged kernel or firmware interface. If an AI can reach the EC firmware from a benign user request, the hardware should not be the only thing standing in its way. Microsoft has confirmed the patch for this case, declined to call the fix complete, and pointed to a threat model that requires deliberate configuration changes, per the Register report. The industry has not yet decided what a hardware write gate looks like for the agent era.