Xenon / Research notesClient security / 01

Where the AI client boundary ends

What desktop instrumentation, recovered test records, and plaintext-boundary prototypes tell us about hardening an AI application.

A remote model still depends on a local client to prepare requests, handle credentials, display responses, and present actions for approval. Those responsibilities create several different security boundaries. Evidence about one boundary does not automatically establish anything about the others.

I developed this research tooling with AI coding assistance. This revision reviews the surviving source, including an unpublished portion of zack-utils, alongside recovered session logs, historical notes, and my recollection of the interaction. No live instrumentation or model experiment was performed for this article update. The aim is to make the evidence useful to defenders and separate recorded observations from broader claims.

The investigation framing and the surviving evidence

During the investigation, I described the target to the coding agent as my own Electron application to get it to investigate the client binary. That framing did not accurately establish ownership of the target or authorization to assess it.

I also used model swapping during the investigation, stopping and rewinding the interaction before continuing with a different selected model.

An earlier revision stated that the original conversation was unavailable. On October 11, retained raw JSONL session records from the August 24 investigation were located. They preserve portions of the conversation, local model-selection commands, timestamped tool activity, and captured test output. The broader account above still includes recollection: the recovered portions do not establish the complete investigation history, and a locally selected model label does not independently verify the model served.

The surviving material includes Electron/MSIX-oriented notes and hardening checks, alongside native-client reader and writer prototypes. These artifact groups must be evaluated separately. Their labels do not, by themselves, establish the runtime of the binary investigated or a verified sequence of separate experiments.

What survived, and what it establishes
ArtifactSupported statementEvidence limit
Electron/MSIX notesMaintainer notes describe cold-start instrumentation, process checks, and renderer attachment refusals.Historical reports; not independently reproduced in this review.
Hardening toolkitSource contains configuration inspection, source-pattern checks, and process-access probes.Several verdicts are heuristic or confounded. They are not a security certification.
Native-client readerA prototype copies application-side buffers and parses framed, compressed response streams.Source establishes the implementation, not successful capture of a particular session.
Recovered session logsA local scan-and-patch run reports 33 marker replacements. A target-session record preserves the original marker prompt, a reply referring to the replacement, and a subsequent parsing error.Contemporaneous local records, not an independently authenticated service trace. The standalone temporary output file has not survived.
Native-client writerA separate prototype implements equal-length marker replacement in outgoing request data.Its own source explicitly says it was not runtime-verified. The recovered scan-and-patch run does not validate this separate implementation.

The earlier documentation also contained contradictory explanations for a cold-start crash: one passage blamed a hook implementation, while another exonerated instrumentation and proposed a store-file race. The revised notes preserve the distinction. An empty-JSON exception identifies a symptom; it does not, by itself, identify its cause.

Recovered logs: the August 24 marker test

The retained records put the matching run on August 24, 2026, around 11:35 AM Central Daylight Time (UTC-05:00). The recorded replacement direction is ZEBRA to HORSE. Earlier attempts with zero matches remain in the session history.

Recorded sequence on August 24, 2026 - all times CDT
TimeRetained observationSource record
11:35:09 AMThe scan-and-patch task was launched.Launch session, line 647.
11:35:45 AMThe target session records the prompt Tell me about ZEBRA.Target session, line 99.
11:35:56 AMThe background-task notice reports completion with exit code 0.Investigation session, line 62.
11:35:59 AMThe next visible target reply refers to "HORSE" in caps and asks whether it could be a codename.Target session, line 107.
11:36:00 AMThe target session records API Error: JSON Parse error: Unterminated string.Target session, line 108.
11:37:11 AMCaptured tool output reports 33 replacements: 24 ASCII copies and 9 UTF-16 copies.Investigation session, line 85.

This is evidence of a recorded local mutation run and an associated change in the visible reply. It strengthens the account beyond source-code inspection alone. The records were collected locally during a process-mutation experiment; they do not independently establish the exact bytes received by the service. In particular, the historical statement that the model "never saw the original" goes further than these records can verify.

The temporary output file is no longer present, but its output was captured in the retained session transcript. Original JSONL files have been preserved unchanged during this review, with SHA-256 hashes recorded on October 11. Those hashes identify the reviewed files from recovery onward; they are not independent attestations of their state in August.

Encrypted transport is only one boundary

The unpublished reader prototypes focus on application data before encryption or after decryption inside the client process. That is different from decrypting captured network traffic by exporting TLS session keys. I found no session-key export implementation in the reviewed kit; the surviving source supports plaintext-buffer observation as the mechanism.

Separately, I recall asking a coding agent to configure TLS key logging, setting the associated environment variable, and using local proxying during the investigation. That recollection describes a separate mechanism from the in-process reader prototypes. The exact TLS-logging and proxy configuration, their effect on request delivery, and any connection to the subsequent account ban remain unverified. The newly recovered marker-test records concern the separate in-process scan-and-patch run.

Conceptual data flow, not a captured trace. The reviewed prototypes target the client endpoint. Transport security and endpoint integrity are separate questions.

TLS protects the channel between endpoints. Its confidentiality and integrity guarantees do not mean the endpoint never processes plaintext. Observing data inside a client therefore does not demonstrate that TLS was broken. See the channel properties in RFC 8446.

The reader source includes HTTP framing, decompression, and streamed-event parsing. It recognizes fields named text_delta and thinking_delta. These are transmitted event fields. Their labels do not establish access to internal activations, complete private reasoning, model weights, or any computation that was never transmitted to the client.

The implementation also attempts output redaction. That is a feature to evaluate, not a guarantee that a capture is safe to share. This article includes short marker-test excerpts and a chronology. Full conversation logs, process-memory captures, and execution procedures remain outside the public article.

Keep the recorded run separate from the writer prototype

The recovered run used a scan-and-patch approach to local process memory. A separate companion writer prototype targets outgoing request buffers. Its source says the live behavior was not verified on the authoring machine. The scan-and-patch result does not remove that qualification, and syntax or logic checks cannot resolve it.

The marker test now has retained runtime records and a visible reply referring to the replacement marker. Whether the separate writer succeeded, whether a protected capability became accessible, and why the account was banned remain unresolved.

For an agent application, this leaves a useful defensive question: how is an approved action bound to the exact operation the executor will perform? That question deserves a controlled test on an authorized target. The prototype alone is not its answer.

The measuring instrument needs an audit too

The unpublished hardening kit was intended to turn observations into checks for Xenon. Reviewing the checks exposed limitations that matter as much as their output labels:

These are source-review findings about the research tooling. They do not establish vulnerabilities in the client being studied. In a revised measurement harness, outcomes should distinguish observed behavior, unsupported conditions, timeouts, instrumentation errors, and unresolved results instead of compressing them into a reassuring PASS.

What this suggests for defenders

Keep authority outside mutable presentation

My design recommendation is to validate authorization at the service or executor that controls the action. Bind approval to the operation, parameters, destination, and relevant state. A changed label or displayed response should not become permission to do something different. This is a proposed defense, not a claim that the surviving experiment bypassed such a control.

Inspect the release that users actually run

Establish the target's actual runtime and test its packaged startup and privilege boundaries rather than extrapolating from a development executable or task description. For Electron-based applications, Electron's security guidance covers renderer isolation and related protections; its fuse documentation explains packaging-time controls. Configuration inspection should be followed by tests of effective behavior.

Make diagnostics useful without making them a second exposure

Record build identity, the observation, and the reason a check stopped. Treat locally produced diagnostic events as untrusted input. Limit collection and retention, and exclude credentials and sensitive payloads. OWASP's logging guidance identifies tokens, passwords, encryption keys, and other sensitive material that should normally be removed or protected.

What remains unproved

The recovered logs support the local marker-test account. They do not demonstrate server-side compromise, unauthorized access to another account, independently authenticated service receipt of a modified request, or general defeat of client protections. They do not establish access to a model's lowest-level thoughts. No causal connection to a vendor's published incidents or account-enforcement decision has been established.

The original investigation took place on my own installation, but ownership of a workstation does not establish vendor authorization. I do not describe that history as a vendor-authorized assessment. No CVE, bounty, vendor acknowledgement, or responsible-disclosure outcome is claimed.

For a future authorized study, I would preserve exact prompts, verified model identity, client and tool versions, privilege level, timestamped runtime observations, unchanged controls, and before-and-after results. Standalone tool output should be retained alongside the conversation transcript, with independent observation where feasible. Failed and incomplete attempts would remain in the record, as they do in the recovered session.

Artifact provenance and editorial changes

The unpublished source reviewed here is local zack-utils commit 386d6d6. Its implementation remains unpushed. Relevant artifacts include:

On October 9, the documentation cleanup was merged as zack-utils PR #1. The repository is private, so that link requires access. Neutral examples and qualified historical claims replaced misleading wording; the original Git history was preserved. This article publishes the analysis, not the underlying prototypes or a procedure for bypassing a particular product.

On October 11, the article was updated after recovery of the session records. The earlier blanket statement that the original conversation was unavailable and the marker outcome was unknown has been narrowed accordingly. The independent-verification limits and the separate writer's unverified status remain. Prepared from source review, retained session records, historical notes, and the author's recollection with OpenAI Codex assistance. No new live test is implied by the editorial changes.