AI in the Client Runtime | Attack the Glass

AI is not an adjacent technology to ATG. It makes the same architectural pattern worse. The model is a runtime resource. The inference response, the answer that comes back when an application calls a model, is a data endpoint. Both reach Client Runtimes that already carry the Just-in-Time App Blueprint, Runtime Anarchy, and the Client Runtime Boundary: the moment fetched code begins to execute. AI does not introduce a new architecture for ATG. It compounds the one already in place, with properties that make detection harder and consequences larger than the non-AI cases.

AI in the Client Runtime is not a browser concern. Browsers run on-device inference through WebGPU, ONNX Runtime Web, and transformers.js. Mobile applications run models through CoreML, TensorFlow Lite, and MLC. Desktop shells that wrap a web runtime (Electron, Tauri) bundle local inference; productivity tools host model-driven features inside their plugin runtimes; vehicle infotainment systems and IoT dashboards increasingly carry on-device inference; AR, VR, and spatial runtimes are following the same trajectory. Every one of these host platforms also calls inference APIs: the addresses an application calls to get an answer from a model. Wherever a Client Runtime already runs, AI is moving inside it.

Two paths carry AI into the runtime, and they instantiate different ATG mechanics. Local model execution loads a model file into the Client Runtime the same way the runtime loads any other fetched resource, and it carries the same trust gaps; compromise of the model is compromise of the runtime that loads it. Inference API consumption calls a remote inference endpoint and acts on the response; the response is the second stage of the Two-Stage Attack, with the model in the loop and per-target personalization built into the output.

10.1: Why AI Matters for ATG

AI puts a new kind of component, the model, into the architecture already in place. Models load like scripts; inference responses arrive like data; the runtime acts on both. The two paths into the Client Runtime (local model execution and inference API consumption) instantiate ATG mechanics already named. What changes is what is loaded and what comes back: the response is shaped for one target, the model's behavior is statistical and emergent rather than written down anywhere, and the consequences build on the static-content cases.

The ML supply chain risks are well documented: model-file format issues including pickle execution; model repository trust across HuggingFace, Civitai, ModelScope, and Replicate; namespace hijacking and typosquatting in model distribution; and training-data poisoning research.

When AI risks meet the Client Runtime, the picture changes. A poisoned model sitting in a public registry is one thing; the same model loaded into a vehicle's infotainment runtime, a productivity tool's plugin host, or a mobile banking application is another, because the host application now acts on whatever that model produces. From there, the path through the runtime is the ATG path; what is new along it comes from the loaded thing being a model rather than a script.

10.2: The Path from Model to Client Runtime

The two paths share little beyond the destination. A local model is a runtime resource: a file the host fetches and executes through a model framework. An inference response is a data endpoint: bytes the host receives from a remote service and acts on. What is loaded, why the runtime trusts it, how it fails, and what would defend it all differ between the two.

Local model execution loads a model file into the Client Runtime the way it loads any other fetched resource. Whether the runtime is a browser running ONNX Runtime Web, a mobile application running CoreML or TensorFlow Lite, an Electron or Tauri shell running bundled inference, a vehicle infotainment system running an embedded engine, or a productivity-tool extension running an in-app model, the thing being loaded is the same kind of thing and the trust gaps are the same. The Manifest Illusion applies: the runtime fetches and executes without inspecting what behavior the model will produce. The model file behaves like any other runtime resource the host trusts. Compromise of the model is compromise of the runtime that loads it.

Inference API consumption calls a remote endpoint from the Client Runtime and acts on the response. This is Supply Chain Injection at the data endpoint; the response is the second stage of the Two-Stage Attack, with the model in the loop and per-target context shaping what comes back. Whether the calling runtime is a browser, a mobile app, an Electron shell, a vehicle infotainment system, or a productivity tool, the structure is the same: trusted endpoint, trusted response, runtime acting on whatever the response contains. Compromise of the inference path reaches every Client Runtime that calls it, regardless of which host platform that runtime runs on.

Prompt injection is the dominant technique on this path: content arriving in the model's input gets read as an instruction rather than as data, so whoever controls the input controls the answer. Direct prompt injection places adversarial content in a user-supplied input the model reads and acts on; the second stage delivers behavior the application owner did not intend. Indirect prompt injection places adversarial content in retrieval sources, tool outputs, or memory the model will later ingest; the second stage activates at consumption rather than at submission, decoupling the adversary's act of placement from the moment of effect. Either variant turns the inference path into a chain of data endpoints. The endpoint and the model can both be uncompromised. What is compromised is what the model reads, and the runtime carries no signal that the model's behavior has been redirected.

The two paths need different defenses. Local-model loading is dependency loading at the model layer; a single-source-of-truth inventory of runtime resources covers the model file as one more resource. The inference-API path is harder. A clean endpoint can return a compromised response, and prompt injection produces compromised responses without ever touching the endpoint. No major host runtime carries the defenses either path needs at the AI boundary today.

10.3: The Inference Response as Data Endpoint

The inference response is a data endpoint. The visible application code is benign; the operative content arrives in the response. The Two-Stage Attack describes the same structure for static content. AI inference adds three properties the static case did not have. The pattern holds across every host platform a Client Runtime runs on.

Per-target personalization: inference produces output tailored per-request, per-context, per-target. The same code path returns different content to different users. Detection, audit, and comparison across a population of users all weaken when every user is shown something different. This is where AI amplifies the problem. A data endpoint that returns different content to every user is what the easiest, most rewarding, and most dangerous ATG attack mode requires: information manipulation.
Action endpoints: where a model is allowed to act on its own, the response carries tool calls, function invocations, and instructions the host runs. The data endpoint becomes an action endpoint, and the Two-Stage Attack's second stage reaches beyond what is rendered into what the host does.
No validation against intent: the runtime knows the response arrived. It does not know whether the response is what the application owner would have wanted the model to produce. There is no model of intent the runtime evaluates against, and no signal in the response itself that intent has been violated. Adjacent engineering work has produced partial mechanisms: structured-output enforcement against JSON schemas, deterministic policy frameworks such as NeMo Guardrails, constrained-decoding libraries, and tool-call signature validation. Each binds a narrow property (schema conformance, topic adherence, output shape) without addressing what the application owner would have wanted the model to produce in the operative case. The gap holds: each of these measures narrows it without closing it. The three properties compound. A response personalized to the target, encoding actions in its content, with no runtime mechanism to validate it against intent: none of these existed in the static-content case.

10.4: The Model as Compositional Surface

A model in production is rarely just the base model. Base weights load first. LoRA adapters, small extra weight files that adjust a base model without retraining it, specialize behavior. System prompts shape the model's defaults. User prompts arrive at runtime. Tool definitions let the model act on its own by calling other software. Retrieval-augmented context supplies additional knowledge during inference. Each layer is a separate source, often delivered separately, each with its own trust assumptions. The Just-in-Time App Blueprint returns at the model layer.

Each of those layers is a P&A position: the base weights, the LoRA adapter, the system prompt, the tool definition, and the retrieval source are each a place an adversary can take up position and change what the model produces at runtime. The model's behavior is not produced from one source; placement at any layer reaches the response.
The layers combine in ways no one can predict from the parts: a small change in any one of them can produce a large change in what the composed model does. Detection through code analysis does not transfer; the behavior is statistical and emergent, and the defensive question is what the composed model produces under varied inputs rather than what the loaded model file "is."
The pickle problem is one instance: the well-documented pickle-execution issue at the model file level is one case of a problem that recurs at every layer that goes into an inference.
Foreign jurisdictional risk is a compositional concern: a model trained or hosted under a government that can compel cooperation with its intelligence services becomes one of these layers, and its behavior cannot be presumed neutral. The jurisdictional thread reaches the runtime through whatever layer carries the affected source, and Ownership Opacity at any layer means the defender cannot tell who holds placement there. Inside a composed model, several resources interact at inference time. Each is a P&A position whose trust assumptions the runtime inherits. The Just-in-Time App Blueprint at the application layer was about how the bundle is assembled. At the model layer, it is about how a single inference is assembled: from weights, adapters, prompts, tool definitions, and retrieved text, each arriving separately.

When the model runs on the device, the adversarial intelligence work happens inside the runtime with no outbound traffic for any external system to inspect. The model loads once, inference runs locally, and manipulation happens inside the runtime. Network monitoring, the dominant defensive tool for behavioral signal, sees none of it.

No network fingerprint for inference: detection architectures built around network monitoring miss local-AI-driven operations. The traffic that produced model behavior happened at load time, often once, and the inference that uses the model produces no traffic at all. The blind spot holds across host platforms; it is not a property of the browser, the mobile app, the desktop shell, the vehicle infotainment system, or the productivity tool. Wherever inference runs locally, the network-monitoring layer is silent.
Model behavior is harder to characterize than code behavior: static analysis of code can enumerate what the code might do. Static analysis of a model's weights cannot enumerate what the model will produce. The behavior is statistical and emergent, and the defensive question shifts from inspecting the file to watching what the model produces under varied inputs. The instruments that exist for code do not exist for models. The detection blind spot is architectural, not an oversight in any specific runtime. Network-era instruments do not reach into it.

10.6: Tailored Deception

Tailored Deception is the offensive capability that exploits the local-AI blind spot: generative AI in the runtime produces substituted content per target, on-device, at machine speed, with no shared population to detect against. AI's content-generation reach now spans text, image, audio, video, voice, and code, and it can produce content for a single target using whatever context the device makes available about that target. Three properties combine to turn this from a marketing feature into an ATG-class capability.

Per-target tailoring at machine speed eliminates the production bottleneck that previously gated precision deception. Content shaped to one user's data, history, social graph, behavior, and communication style once took a human analyst working one target at a time; a model now produces it in the time it takes to answer a prompt. On-device execution moves the tailoring inside the runtime, beyond the reach of network observation. The deception material is generated where it will be consumed.

The third property reaches into the device itself: the AI executing inside the Client Runtime inherits the runtime's access to local resources. Files, documents, browser history, contacts, calendar entries, geolocation, sensor data, and application state are reachable through the same APIs the host application uses. The context the model tailors against does not have to be handed to it. The model can gather it, on demand, from wherever the runtime is permitted to read. Runtime Anarchy reaches the AI layer here: the AI executes with the host's permissions, and per-target tailoring draws on the host's view of the target. Tailored at machine speed, generated on-device, fed by direct access to the device: each property compounds the others, and the combination is what produces a different problem than precision deception or local AI alone.

Deepfakes on device: on-device voice synthesis can clone a contact's voice for a real-time call placed through the device. On-device video synthesis can impersonate a participant in a video call rendered through the device's runtime layer. On-device image generation can fabricate documents, evidence, or communications that appear inside the user's familiar runtime context. The Hong Kong $25 million video-conference fraud in early 2024 shows the eight-figure stakes of deepfake deception; that case used attacker-generated deepfakes presented on a call rather than on-device synthesis inside the victim's runtime, so it evidences the consequence rather than the on-device mechanism.
Tailored persuasion content: phishing messages, social-engineering scripts, fake notifications, fabricated context, manipulated documents, and plausible inbox messages can be produced per-target through any host runtime the user interacts with: a browser, a mobile messaging app, a desktop email client, a productivity tool.
Adaptive deception where the model is allowed to act on its own: an AI agent generates content for each interaction that adapts to the user's responses in real time. Every interaction produces unique content. Static signature detection has no purchase because there is no static signature. Detecting deception that is generated on the user's device and shaped for that one user is a different problem from detecting static deception or server-generated AI content. The defensive techniques that have evolved against email spam, fraudulent web pages, and templated phishing depend on a population of deceptive instances that share signal: text overlap, image hashes, infrastructure correlations, behavioral patterns. Locally generated, per-target content shares no such signal across users. Each instance is a population of one. Existing approaches do not transfer.

Older deception cases did not reach into the user's trust in their own device. Tailored Deception does. When the user's own device produces convincing deceptive content through legitimate runtime APIs, the user's trust in their own device becomes part of the attack surface. This is trust-of-runtime erosion. The user has been taught that the device is the trustworthy edge. The voice on the call is the contact's voice, generated by the trusted device. The face on the video is the colleague's face, rendered through the trusted client. The message is the message the trusted application showed. The user has no working heuristic for distrusting any of it, and the attack surface includes the user's confidence in their own runtime.

Information manipulation is the easiest to execute, the most rewarding to run, and the most dangerous ATG attack mode. Tailored Deception is the AI-amplified instance, delivered at population scale through the user's device.

Each instance is unique to the target, assembled inside the device, running in memory. On-device generation leaves no signal for network monitoring or population-scale signature detection: there is no shared population to compare against and no common signature to match across users. The model file and the in-memory state remain forensically recoverable on the device itself. This is, in effect, a unique deception per user, manufactured on demand, with the user's own device as the manufacturing line.

10.7: Deceiving the Model

Tailored Deception treats AI as the adversary's instrument. The model is also a target, and the Deceive effect applies to it directly. A model does not evaluate whether its input is true. It produces output consistent with what it was given, which makes deception of a model a matter of controlling what reaches it rather than of defeating any judgment it makes.

Deception of a model happens at two different timescales. At training time, corpus poisoning and disinformation channels feed the material a model learns from, so that the model states falsehoods as fact to everyone who asks. This is already happening. At runtime, the inference response can be substituted, retrieval and context can be poisoned, and instructions can be carried in content an agent reads on the Glass. ATG's specific contribution is the second: the Glass is where a model's inputs and outputs are assembled, and an agent operating in a Client Runtime consumes whatever the runtime hands it, with the same absence of verification that applies to every other resource.

The defensive position is worse than for a human consumer. A person can, in principle, notice that a figure looks wrong. An automated consumer has no such capacity, executes at machine speed, and produces output that downstream systems and people then treat as the product of analysis rather than as the echo of a substituted input.

10.8: No Defense at the Client Runtime AI Boundary

Existing ML supply chain defenses operate at the registry and build layers. Model signing, repository security, model scanning, and records of where training data came from each reduce the attack surface meaningfully and remain necessary defensive work. None reach the Client Runtime AI boundary.

At the Client Runtime AI boundary, the host runtime accepts the model (or accepts the inference response), runs inference, and acts on the output. Each of those steps is downstream of the defenses just named. A model can arrive here signed, scanned, and documented back to its training data; everything after this boundary is the runtime's problem, and the runtime carries no built-in instrument for any of it.

A single-source-of-truth inventory of the model resources actually loaded: the runtime would have to know which model files, LoRA adapters, system prompts, tool definitions, and retrieval sources are loaded into the inference path at any moment, and verify them against an authoritative inventory. The same single-source-of-truth pattern used at the language and provider layers extends here.
Content-validation against intent for inference responses: the runtime would have to test the inference response against the application's declared intent for the call before acting on it. Today the runtime knows the response arrived; it does not know whether the response is the response the application owner would have wanted the model to produce. Schema enforcement, policy-layer guardrails, and constrained decoding cover narrow slices of this requirement and do not reach intent validation.
In-memory anti-manipulation for model behavior: the runtime would have to monitor model behavior under varied inputs, in memory, against an expected behavioral envelope. Static analysis of the loaded weights cannot do this; behavioral monitoring at the runtime layer can.
Signature-independent detection of Tailored Deception: the runtime would have to detect locally produced, per-target deception material without depending on shared signatures across users. Because each user receives material no other user receives, there is no shared signal to match against; the requirement is an instrument that does not need one. The gap is the same across host platforms. Browser, mobile app, desktop shell, vehicle infotainment system, IoT and operational technology (industrial control) dashboard, productivity tool: none of them ship with these capabilities at the AI boundary today. The architectural requirement is uniform across the landscape, even where implementation differs.

This is the AI-specific expression of Malice Without Malware. The same architectural shape repeats from the language, provider, and open-source defense gaps: existing controls operate where they have always operated, the runtime boundary remains unprotected, and the gap is structural rather than operational. What is distinctive at the AI boundary is the fourth required defense: signature-independent detection of locally generated, per-target deception. The other layers do not need it.