The control API, the preview pane and the permission grant

A network request to an unauthenticated agent API and an HTML file rendered by a desktop assistant look like different security problems. They become comparable at the moment low-trust material acquires a capability that the original sender was never supposed to hold. A new harness research paper, L3M, proposes an alternative in which those capabilities must be explicitly represented and checked. Its proposal also illustrates how difficult that enforcement is.

The Archon advisory identifies a control API exposed on 0.0.0.0 by default, without authentication in the listed affected versions. If an attacker could reach /api/*, it could send messages to a coding agent running with bypassPermissions; the documented consequence was command execution as the Archon user. The model's handling of a prompt is not the central access check here. The API accepted an unauthorized task before any legitimate user was identified.

Binding a listener only to a trusted address can reduce who reaches it, but does not answer who is allowed to dispatch particular commands. Authentication and task authorization need to precede execution, while the process itself should have no more operating-system authority than required. The CVE does not establish exploitation or an exact fixed release.

The SneakPeek disclosure takes a different route. An attacker-provided HTML report in a repository was presented as ordinary project material. According to Noma Labs, once an oversized file entered a desktop file:// preview path without the smaller preview's content restrictions, its script could read and export local developer credentials. The attacker did not need to receive a direct shell tool from the agent. A separate renderer crossed the file-access boundary.

Noma reports that an initial fix was bypassed with a Web Worker and dates the final correction to Claude Desktop 1.30096.1 on August 17, 2026. The case demonstrates why the entire path from untrusted file to preview execution matters, including components that do not look like model tools. It remains a researcher proof of concept, not a verified campaign.

L3M treats side-effect permissions as tokens checked by its Lean 4 runtime. A self-authored program cannot enlarge its admitted capabilities through an ordinary child delegation under the documented rules. Git-backed state, reversible actions and staged byte approval offer ways to separate a proposed next step from permission to execute it. In the authors' Terminal-Bench experiment, an untuned safe-only configuration reached roughly two thirds of an unrestricted shell baseline's pass rate. That is a measured utility cost, not evidence that all safe runtimes must pay the same price.

The authors explicitly limit their security claims. They do not present a session-wide safety theorem; parts of token issuance, external providers and compilation behavior remain in the trusted base. A signed-off unsafe shell could still escape the guarantee the system is designed to enforce. The paper is an architectural prototype, not a deployed fix for Archon or SneakPeek.

The common design rule is narrower than declaring an agent secure. Identify each component that can cause an external effect, record what authority it receives, and make permission checks enforceable in that component. The source material supports the listed cases and the proposed runtime pattern, not a universal remedy.

Evidence: Archon CVE, Noma research and L3M paper.