The ATG Vulnerability Architecture

Client-Side Rendering produces a runtime environment that trusts what it loads and does not re-verify. The runtime trusts by default because of the way the architecture works, not because an operator chose a setting. Structural trust by itself is exposure, not vulnerability: the runtime is not vulnerable on its own, and becomes vulnerable when the supply chain feeding it can be shaped by an adversary.

The digital supply chain is unlike any chain humanity has built. Code, content, and configuration flow into Client Runtimes from millions of producers, through a small number of consolidated delivery providers, to billions of devices every day. No single party owns it. No inspection regime governs it. The protection rigor every other consequential supply chain carries (provenance, chain of custody, recall capacity) is largely absent. The runtime accepts what the chain delivers, and the chain has no obligation to deliver what was reviewed.

Attack the Glass (ATG) is a type of supply chain injection vulnerability that targets client-side rendering. It arises at that meeting point: a runtime that trusts what it loads, fed by a supply chain no one has inspected. What defines it is the architecture rather than any one exploit. If an adversary can swap what the runtime receives at the moment of delivery, and the swapped content then runs inside the assembled application, that is ATG.

Information manipulation is the dominant form of ATG attack. Functional disruption (making an application fail, silencing an alert, subverting a feature) takes more technical skill to carry out, and it happens less often, succeeds less often, and does less damage when it does.

2.1: The Internet Is a Supply Chain

The internet is not a communication network. It is a layered supply chain through which code, content, configuration, and behavior flow from many producers and intermediaries to the rendering surface on the user's device. Communication is one flow within that chain, not the chain itself.

Four dimensions set it apart from any prior supply chain humanity has built: scale, decentralization, rate of evolution, and embeddedness.

• Scale: billions of users, billions of devices, millions of distinct producers and intermediaries, and a continuous flow of code and content that no other chain matches in volume. The grocery system, the global pharmaceutical chain, the semiconductor industry, the defense materiel pipeline: each is large in its own terms, and each is a fraction of the volume the internet supply chain moves every hour.
• Decentralization: no single owner, no single regulator, no single governance authority, no single inspection regime. The internet is assembled across nearly every country and culture and operates simultaneously interconnected and autonomous: nodes cooperate at the protocol level while answering to different jurisdictions, different operators, and different commercial incentives. No prior supply chain of comparable consequence has lacked a central ownership or governance layer.
• Evolution rate: the internet at the start of any decade is materially different from the internet at the end. Protocols are added; whole categories of intermediaries (CDNs, model hosts, identity providers, tag managers that load third-party scripts into a page, AI inference services) emerge in years rather than generations; entire delivery pathways come into existence, replace prior pathways, and are themselves replaced. The chain rewrites itself faster than the institutions designed to oversee any one of its segments can adapt.
• Embeddedness: the internet now sits inside nearly every aspect of government, commercial, and civil-society activity, deeply integrated into the personal lives of billions of people. Banking, healthcare, transportation, energy, and the daily attention of populations all route through it. Almost no consequential decision in modern life is reachable without traversing some part of the chain. The internet is the most consequential and transformative invention in human history. It was built through the largest cooperative international effort in history. Client-Side Rendering is the architecture that extends that chain all the way into the runtime on the user's device.

2.2: The Most Important Supply Chain Is the Least Protected

Physical supply chains carry rigor commensurate with their consequence. A pallet of spinach crossing into a major market arrives with documented producer identification, lot codes, harvest dates, cold-chain telemetry, and recall capability that lets a contamination event be traced to a specific field on a specific day. A shipment of pharmaceutical product carries serialized packaging, transaction histories that document every change of custody from manufacturer through distributor to dispenser, and regulatory mechanisms that require irregularities to be reported and acted on. A semiconductor entering a defense application arrives through a trusted-foundry pathway with provenance documentation, anti-counterfeit attestation (a signed record of how the part was built and by whom), and chain-of-custody verification at each handoff. The protection rigor in each case is proportional to what would happen if the chain were compromised.

By contrast, the digital supply chain that delivers code, content, and configuration to billions of Client Runtimes every day carries nothing comparable. There is no provenance requirement on a script loaded from an arbitrary URL. There is no chain of custody on a configuration payload fetched at runtime. There is no inspection regime on a model file downloaded into a runtime. There is no recall mechanism on a third-party script deployed across thousands of sites. The asymmetry is structural and has been well-known for more than a decade. It remains uncorrected.

ATG operates inside that asymmetry. An adversary in the digital supply chain faces none of the documentation, inspection, or attribution requirements an adversary in the physical chain would face. Economics, detection difficulty, and recoverability all favor the adversary. The same is not true in the supply chains the world has decided to protect.

Behind the protection asymmetry sits a deeper one: almost no one knows how this supply chain actually works, who operates it at the relevant layers, or who controls it. Some segments are increasingly being protected: package registries with provenance attestation, software bills of materials, build-system integrity programs, and signed binaries are real progress at the producer end of the chain. Vast sections remain opaque, unguarded, and structurally vulnerable to anyone willing to learn where the gaps are. Effective defense requires an inventory of what is being defended. Vast sections of this chain offer none.

The most important supply chain humanity has ever built is the least protected supply chain humanity has ever built.

2.3: The Digital Supply Chain

The Digital Supply Chain is the system of producers, intermediaries, transformation points, distribution channels, and delivery mechanisms through which executable code, content, and configuration move from their source to the rendering surface inside a Client Runtime. The same general shape governs every Client Runtime on every host platform.

The chain does not carry only files. It carries scripts and modules that execute as code. It carries content (HTML, CSS, JSON, media, ads) the runtime interprets. It carries configuration (feature flags, A/B-test assignments, tag-manager directives, import maps, manifests) that changes behavior or directs further fetches. It carries the AI substrate (model weights, LoRA adapters, prompts, system instructions, tool definitions) that drives any model integrated into the runtime. It carries telemetry specifications that determine what is collected and where it is sent. The distinctions between code, content, and configuration are useful for description. Inside a Client Runtime, all three become executable behavior.

The chain runs through five layers from origin to rendering surface: producers, intermediaries, transformation points, distribution channels, and delivery mechanisms.

• Producers write the code or create the content. Application developers, library maintainers, content creators, advertising operations, configuration owners, model trainers, and AI service operators all sit at this layer. The producer layer is where a piece of code or content first gets the name it claims and the behavior it is supposed to have.
• Intermediaries host and aggregate. Open-source package registries, source-control hosts, model repositories, ad networks, and configuration-management services all carry code and content forward without creating it. The intermediary layer is the first place a file leaves the producer's control and lands on infrastructure that other parties share.
• Transformation points change the code between the intermediary stage and the distribution stage. Build systems, bundlers, transpilers, minifiers, optimizers, CI/CD pipelines, and integration-time composition tools each take one piece of code in and emit a different one. The transformation layer is where what the producer published and what the device eventually runs stop being the same thing.
• Distribution channels push the transformed code toward the rendering surface. Content delivery networks, package mirrors, app stores, over-the-air bundle delivery services (which push code updates straight from a server to an already-installed application, without going back through the app store), and tag managers each operate at this layer. The distribution layer is where the largest aggregations of dependent applications meet a single point of delivery.
• Delivery mechanisms bring the code or content across the trust boundary into the runtime. HTTP requests for scripts, fonts, configuration, and content; WebSocket and server-sent-event streams; push notifications; over-the-air bundle pulls; and responses from an inference API, the address an application calls to get an answer from a model, are all delivery mechanisms. The delivery layer is where a piece of content enters the running Client Runtime. The chain ends at the rendering surface. The Client Runtime assembles the application from whatever the delivery layer brings, integrates it with everything already loaded, and executes the result.

Trust at each handoff is structural and largely implicit. Producers trust their own pipelines. Intermediaries trust producers' uploads, with verification rigor that varies from registry to registry. Transformation points trust their inputs, and the outputs they emit are rarely cryptographically pinned to the producer-declared identity. Distribution channels trust the transformation pipeline that fed them. Delivery mechanisms authenticate the endpoint, not the content. The rendering surface trusts whatever arrives. Once producer-layer trust is established, every subsequent layer extends it without re-verification. The result at the rendering surface is that every check happened before the code ran, and nothing checks it again once it does.

2.4: The Glass: The Final Mile of Every Digital System

Modern life takes place in front of glass. A person wakes to a phone screen, works at a laptop, takes a meeting through a webcam, glances at a vehicle dashboard, watches the evening on a television, and checks a refrigerator's screen for a grocery list. The number of distinct panes most people interact with in a day runs in the dozens; the time spent looking at them runs to most of the day.

Each pane is an aperture into a system the unaided senses cannot reach. A child sees a relative two thousand miles away. A surgeon sees inside their patient. An engineer sees the floor of a building a continent away. Each pane lets a person see around the world or deep into systems at scales the unaided eye cannot see.

The Glass is not a figure of speech here. It is the last component in the delivery chain, the surface on which the finished application is drawn. Every system that produces value for a person finally produces it on a piece of glass. Public billboards, signage in transit hubs, industrial control HMIs, medical-equipment screens, AR headsets, and point-of-sale terminals all carry the same essential property as the consumer panes: a piece of glass with technology behind it. The browser is the most studied case, not the boundary.

The Glass is that final point of contact. The Glass means the rendering surface wherever it appears, not any one device and not any one physical pane. The Glass is the final mile of every digital delivery chain. Whatever provenance, signing, scanning, or verification existed upstream, the system arrives at the user only after passing through the Glass. The Glass is where the assembled application meets the user, where the value of the system materializes, and where the vulnerability lies.

The Glass is also where a person acts. It is the surface on which they see, interact with, and act on the information and features the software puts in front of them, and the acting matters as much as the seeing. A screen that only displayed would expose a reader. A screen that is also the control surface exposes every decision taken through it, which is why the exposure runs from a news page through an administrative console to an operator's panel without changing its shape.

2.5: Integration on the Glass (IOTG)

The integration moment in modern software does not happen in the build pipeline, at the CDN, at the package registry, the bundler, the packaged build output, or any layer where software-supply-chain controls are typically applied. It happens at the Glass, on the user's device, at runtime, after every upstream control has already finished its work.

CSR is the technique that makes this true. The rendered application is composed at runtime from many independent sources: scripts and modules from package registries, content from CDNs, configuration from feature-flag services, ads from ad networks, and model weights or inference responses from AI endpoints. None of these sources sees or coordinates with the others. Each is integrated only when the runtime assembles them inside the Client Runtime.

Integration on the Glass (IOTG) is that moment. IOTG is what CSR produces in operational terms when it meets the Glass: the point at which all the upstream supply-chain pieces become a single executing system. The integration happens on the user's device, inside an untrusted container, with no participant in the chain having authority over the others.

The shift is structural. Server-rendered systems integrated on infrastructure the operator owned. CSR systems integrate on infrastructure the operator does not own and cannot inspect. Every defense that assumed integration happened inside the operator's perimeter is operating against an assumption that no longer holds. IOTG is what replaced it.

2.6: URL Overtrust

A URL is a place. Most cybersecurity work treats URLs as strings of text the runtime uses to fetch resources, and that operational definition is correct as far as it goes. It is also incomplete. A URL is a place within the digital supply chain, and like any place in the physical world, it carries attributes that determine what a relationship with it actually means.

Five attributes determine what a URL means as a place: ownership, jurisdiction, access control, allowed activity, and risk relationship.

• Ownership: who controls the space. The owner of yesterday is not necessarily the owner today. Domains change hands, providers are acquired, certificates are reissued, and the operator behind the URL can change without any change to the URL itself.
• Jurisdiction: the law that governs the space. A URL hosted in one country answers to that country's legal regime, regardless of where the application loading it operates or where the user lives.
• Access control: who can write to the space. This includes who can publish content, who can change configuration, who can rotate keys, and who can reach the underlying infrastructure.
• Allowed activity: what the space is permitted to do. Most URL operators are subject to no enforceable constraint on what content they serve, what scripts they push, or what behavior they direct.
• Risk relationship: what the application accepts when it loads from that space. Every URL the runtime fetches is a continuing relationship with whoever currently controls the URL, on whatever terms that party chooses, under whatever oversight regime applies to them. A URL whose ownership is unverified, whose jurisdiction is unknown, whose access control is opaque, whose allowed activity is unconstrained, and whose risk relationship has never been examined is not a passive string. It is a delivery point inside a supply chain.

URLs and the HTTP payloads passed between them operate like a shipping-and-receiving layer. Calling a URL is sending a package: the request carries the application's identifying information, session state, and any data the request body includes. The response is receiving a package: code, content, configuration, or instructions the runtime then acts on. Every URL the runtime touches is a two-way exchange in which the supply chain runs in both directions.

Each URL is therefore a layer in the supply chain. A compromised URL can return a payload that arrives looking like the expected resource and behaves correctly long enough to establish trust. It can equally return one that does damage the moment the runtime processes it. Either is delivered through a URL the application chose to trust at runtime. Neither is detectable by anything in the loading chain that does not inspect the response itself, with knowledge of what the response should be.

Three properties make URL trust an attack surface no current control regime manages: scale, opacity, and payload vastness.

• Scale: a modern application loads dozens to hundreds of distinct URLs at runtime, across the producer, intermediary, transformation, distribution, and delivery layers.
• Opacity: the ownership and operational control behind any given URL is rarely known to the application's operator and is changeable without notice.
• Payload vastness: the aggregate volume of code, content, configuration, and AI assets flowing through these URLs every session is far beyond the inspection capacity of any defensive control that operates at runtime. Few organizations can answer the question that follows from those properties: what URLs does our application load at runtime, and who controls each one? The honest answer in most cases is that the inventory does not exist.

The addressing and delivery system of the digital supply chain runs without a governance regime, without an inspection regime, and without an inventory underneath it. It treats a URL as a fixed, safe resource when the URL is in fact a position in a supply chain that can, by design, return different content on any request. That is URL Overtrust. The mistake is not that the trust is too generous. It is that the thing being trusted was never a fixed file sitting at rest, so there is nothing stable there to trust.

2.7: The Static Resource Assumption

Industry supply-chain practice rests on a dangerous and widespread fiction: that a resource fetched from a URL is the same resource the next time it is fetched, and that hashing, signing, or reviewing one fetch protects every future fetch from that URL. The fiction is structurally wrong, not occasionally wrong. A URL resolves to a resource that can be generated per request, so the same address can return different content to different requesters; the thing was never a static file to begin with.

In a CSR context, the resource at a given URL can change between fetches without changing the URL, the request headers, the application code, or anything else a defender would inspect. The endpoint controls what it returns. Whoever controls the endpoint at the moment of the response controls what the application receives, regardless of what was published, signed, or reviewed at any earlier moment.

Manufacturing on demand, not mass production, is the closer model. Most readers carry an unstated mental picture in which URL responses come from a fixed-inventory warehouse: a producer made the file some time ago, the file sits on a shelf, and every fetch retrieves the same thing from the shelf. The picture is wrong. URL traffic is on-demand manufacturing. Every response is built freshly when the request arrives, by whoever currently controls the endpoint, with whatever inputs and instructions that controller chooses to apply at that moment. There is no file on the shelf. What sits at the address is a piece of code that builds the response, and it can be rewritten between any two requests.

The Static Resource Assumption underlies most existing software-supply-chain controls (signing, hashing, attestation, software bills of materials, integrity checks at build or release time) so those controls check the file at build or release time and never check the copy the runtime actually fetches. The architectural pattern is that verification finishes before the code runs. The Static Resource Assumption is the belief that pattern leaves defenders holding: that checking once was enough.

Operationally, the Two-Stage Attack rests on this. An adversary who controls the endpoint can serve a clean file to inspectors, scanners, and reviewers, and a malicious one to the runtime under attack, without changing anything a defender can inspect. The on-demand manufacturing model is not a metaphor for the adversary; it is the adversary's working environment.

2.8: The Digital Supernode

Runtime traffic concentrates at a small number of delivery-layer providers. Content delivery networks are the visible case: a handful of operators serve scripts, fonts, configuration, and assets to a substantial fraction of the world's Client Runtimes every day.

Conventional analysis treats a CDN as a chokepoint: one node through which many dependent applications fetch their resources. Treating a CDN as a chokepoint is right as far as it goes and stops short of what is actually there. A CDN is not a single node. It sits at a hub where millions of applications, sites, and organizations all depend on the same point, with millions of source libraries, each with its own producers, intermediaries, transformation points, and distribution channels, feeding into it.

The Digital Supernode is a dependency at such a hub: a dominant CDN, a near-universal library, a key service on which millions depend at once. It reaches that position through Herd Trust: the more places that use it, the more trustworthy it looks, and the more places adopt it. That concentration makes it one of the highest-value targets in the supply chain, because controlling one Digital Supernode means controlling what millions of dependent applications receive. Behind the visible chokepoint sits an aggregation of millions of dependent supply chains. Compromise at any one of those underlying chains can be propagated through the centralized node to every application that consumes from it.

Beyond CDNs, the pattern repeats. Widely used JavaScript libraries are nested supply chains: each library bundles many upstream packages, and the same library is loaded into thousands of host applications. Open-source package registries are nested supply chains: a registry is a chokepoint that aggregates millions of independently maintained packages, each with its own dependency tree. Model repositories are nested supply chains: a repository aggregates millions of models, each with its own training data, fine-tuning history, and inheritance chain. Analytics endpoints, tag managers, identity providers, advertising networks, and inference services follow the same shape: a small number of providers each aggregating millions of underlying dependencies and reaching into the same population of Client Runtimes.

Supernodes also sit inside one another. A library that thousands of applications bundle can itself fetch a font service, a polyfill provider, or a telemetry endpoint while it runs, and that provider is then reached by every application that bundled the library, none of which chose it or knows it is there. Dependency chain depth is what makes a position compound: each layer carries the applications above it down to the provider at the bottom, which inherits all of them at once. An application's own inventory records the libraries its developers selected. It does not record what those libraries reach for at runtime, so a provider no one contracted with can sit deeper in the chain than anything the inventory names.

Compromise at any of these layers reaches every dependent application at once, at runtime, inside the IOTG composition, inheriting the trust the host application granted to the endpoint. The reach is not theoretical. It has been demonstrated in confirmed historical events.

Centralization of risk in the delivery layer is not a CDN problem. It is the structural property of every layer at which many applications consume from the same provider. Wherever scale creates aggregation, aggregation creates a Digital Supernode, and the node sits on top of the supply chains it inherits. Own the node, own the millions who trust it.

2.9: The ATG Vulnerability Defined

Attack the Glass (ATG) is a type of supply chain injection vulnerability that targets client-side rendering: an adversary controls, modifies, or substitutes the content, code, or configuration delivered to the rendering surface inside a Client Runtime. What the adversary puts in its place then runs inside the assembled application with the full permissions of the legitimate code. The Client Runtime does not continuously re-verify the sources or content influencing its behavior after the initial trust grant.

Three structural parts make the definition precise: what is delivered, what the adversary does, and what makes it a vulnerability.

• What is delivered: content, code, or configuration delivered to the rendering surface. This covers both pathways CSR uses. The first is executable code loaded straight into the runtime. The second is content the runtime interprets (data, media, configuration, templates, prompts) that then drives further execution.
• What the adversary does: the adversary controls, modifies, or substitutes what is delivered. Substitution can occur at the cache, in transit, at the configuration source, at the data endpoint, or at the inference response. In every case, the pattern is the same: the swap happens at the moment of delivery, and never touches the copy that was inspected.
• What makes it a vulnerability: inside the assembled application, the substituted code runs with the full permissions of the legitimate code, inside a Client Runtime that does not continuously re-verify what it loads after the initial trust grant. The exposure is created by the architecture of the runtime, not by the operational choice of any one operator. ATG is a client-side supply-chain vulnerability that lets whoever controls one component of a modern application change what its users see, or what the application does for them, and deliver that change through a source the users and the application both trust. Who receives that change is the adversary's choice, and the range runs from every user of the application, through a region, a language community, or a segment defined by behavior or demographics, down to one named individual on one device. It reaches the web browser and the systems beyond it, up to and including critical infrastructure. Operations of this kind can be configured to leave no forensic evidence on the device and to trigger no intrusion detection.

One asymmetry follows directly from the definition. The party that decides which third parties a device will trust is not the party that bears the consequences of the decision.

ATG is not a single attack technique. Different surfaces, different mechanisms, and different attackers produce different versions of it, and the architectural pattern underneath stays the same.

Every Client Runtime inherits the exposure. Browser, mobile-application runtime, hybrid desktop shell, smart-TV runtime, vehicle infotainment, AR and VR scene engine, IoT and operational technology (industrial control) dashboard, productivity-tool extension host, and plugin marketplace are each a Client Runtime, and ATG is the exposure they all share. The architecture creates the exposure, not the host platform.

2.10: Supply Chain Injection

Supply Chain Injection is the structural condition in which adversary-controlled content is introduced into a trusted delivery path. ATG is the specific instance that targets the rendering surface inside a Client Runtime. Substituted content executes there with the full permissions of the legitimate code. Beyond the rendering surface, the same mechanism operates at every layer of the digital supply chain. A compromise anywhere upstream flows forward, through composition, to the glass.

Across every layer, the mechanics share one property: the swap happens when content is delivered, and never touches the copy that was checked. The file that was reviewed, signed, hashed, and approved is not necessarily the file that arrives.

Five patterns illustrate the structure: cache and CDN substitution, network-path substitution, configuration-driven substitution, tag-manager and feature-flag substitution, and inference-response substitution.

• Cache and CDN substitution: what the cache hands out differs from what the source published.
• Network-path substitution: what arrives over the wire differs from what the source sent.
• Configuration-driven substitution: the runtime fetches a different file because configuration delivered through a separate channel told it to.
• Tag-manager and feature-flag substitution: the runtime executes different content based on flags delivered through a separate channel.
• Inference-response substitution: the model's answer is content the runtime acts on, and it is built fresh for each request, so there is no checked copy to compare it against. What unifies the patterns is a separation in time. The moment a copy is checked and the moment content is delivered are not the same moment. Static integrity verification (signing, hashing, Subresource Integrity) protects the copy that was checked, not the copy that is delivered. This is why ATG, the rendering-surface instance of Supply Chain Injection, defeats pre-delivery controls: every pre-delivery control inspects the copy that was checked, and the runtime executes the copy that was delivered.

Placement and Access (P&A) is the position from which an adversary can act on the supply chain. Every P&A position is an injection point in this sense. The injection point is structural, not exploit-dependent, and it persists as long as the P&A position persists.

2.11: The Two-Stage Attack

The Two-Stage Attack splits delivery into two parts. The first stage is the visible code: the script, module, or bundle that the runtime fetches at session start and that any reviewer, scanner, or signing process operates on. The first stage is benign by design and contains no payload any pre-delivery control would flag.

Stage two is the data the first-stage code consults at runtime. The first-stage code reaches out to a data endpoint and uses the response to drive its behavior. The data endpoint can be a configuration service, a feature-flag service, an analytics endpoint, an inference API, or any other URL the code is structured to call. The data endpoint is what the adversary controls.

What makes this work is the structural separation of stage one and stage two. Verification of the first stage proves nothing about the second. What a reviewer sees is the bundle; what actually happens is whatever the data endpoint tells the bundle to do at runtime. The separation is the defensive blind spot: the code a defender can inspect is not the thing that decides what runs. The code looks clean because the weapon is hidden in the data it loads.

Obscuring attribution and inspection is part of the design. Resources loaded into the Client Runtime during a session can be nearly impossible to detect as they arrive: they are data, not code, and the loading code is benign. They are nearly impossible to track back to their point of origin afterward: the data endpoint may have stopped serving the malicious content by the time investigators look, and the runtime keeps no audit trail of what each call returned.

Deepfakes generated client-side, runtime media modification, and runtime data manipulation are concrete instances of two-stage payloads. Each loads a benign first-stage element (a media library, a chart renderer, a numeric formatter) that consults a data endpoint for the actual content. On-device AI amplifies the class: the same loading code that fetches an inference response can be steered to produce per-target deceptive media, per-target deceptive numbers, per-target deceptive narratives, and per-target deceptive recommendations, none of which appear in any file a reviewer could inspect. Information manipulation is the dominant ATG attack mode, and the Two-Stage Attack is the operational mechanism through which information manipulation can be delivered today at scale without detection.

The two-stage architecture defeats static integrity verification (signing the file, hashing it, Subresource Integrity, package-level scanning). It does not defeat runtime behavioral monitoring at the rendering layer. Static integrity verification operates on the file as it sits at rest; runtime behavioral monitoring operates on what the runtime is doing in the moment. They are different kinds of control, they are complementary, and the appropriate response to two-stage attacks is the latter deployed alongside the former rather than in place of it.

Underneath the two-stage pattern sits a structural property that holds for any runtime injection, not only the two-stage form. The Runtime Injection Advantage is that property. Four features define it:

• After all pre-delivery verification has passed: whatever review, signing, scanning, or approval the file went through is complete. The runtime cannot check again, because the copy that was verified is not there; only what was just delivered is, and that is what runs.
• Per-request and per-target: runtime injection can deliver different content to different requests, different users, different contexts. The same delivery channel can serve one response to inspectors, scanners, and reviewers, and a different response to the runtime under attack.
• Difficult to reproduce in forensic analysis: when investigators try to reproduce an attack after the fact, the adversary may have stopped delivering the malicious content, leaving no evidence in the runtime that anything was wrong.
• Compatible with arbitrary trust granted to the source: the runtime granted trust to the source (CDN, package, script host, inference endpoint) at the moment of loading; injection at runtime inherits all of that trust by design. Together, these four properties make the Runtime Injection Advantage the structural reason ATG-class attacks are difficult to detect with traditional defensive postures and difficult to investigate after the fact. The Two-Stage Attack is the contemporary form of ATG that exploits the advantage most fully. It is the most sophisticated form of the class known to date.

2.12: Content Swapping

The delivery analysis establishes that an adversary in the supply chain can substitute what the runtime receives. What that buys depends on what is substituted on the rendered surface, and the forms are not interchangeable.

Content Swapping is the family of on-page changes an ATG operation produces: a value, an image, a link, a form field, or a chart rendered as something other than what the application intended. The change can be introduced in the delivered resource, in the data a loaded script consults at runtime, or in the rendered output after both have arrived. The category names the change the user sees, not the channel that carried it, and it is the surface reading of what the D5 analysis calls information manipulation: the same event described by what it does to the page rather than by what it does to the person reading it. Eight forms follow from the architecture. Injected content and link swaps also appear directly in the confirmed record.

• Data-value swap: a number, price, quantity, date, status, or identifier renders as a different value than the source returned.
• Media swap: an image, video, or audio element renders content other than what the application referenced.
• Link swap: a link or action target resolves somewhere other than where the application intended.
• Injected content: content the application never referenced appears in the rendered output.
• Suppressed content: content the application did reference does not appear.
• Reordered content: the sequence of items in a list, feed, or result set differs from the order the source supplied.
• Form-value swap: a field value differs between what the user entered and what the application submits, or between what the source supplied and what the user is shown.
• Chart-value swap: the series behind a visualization is altered, so the rendered chart is internally consistent and factually wrong. Most of these do not require the application to fail. The application continues to run correctly in the only sense it can measure: it renders what it was given. What it was given is the thing that changed. That property separates most Content Swapping from functional attacks, and it is why a swap can carry through a session, a workflow, and a decision without producing an error anyone would investigate. Suppressed content is the partial exception, since removing a referenced element can produce a visible failure.

The eight are forms of visible change, and they are drawn from the browser and mobile case. Data-value, suppressed, reordered, and chart-value swaps carry across to an operator surface as setpoints and readings, alarm suppression, sequence and priority order, and trend series. Link, media, and form-value swaps map poorly there or not at all. A control-surface taxonomy would not be these eight.

Everything the runtime receives that the application did not reference is an injection, whether it is markup, a value, an image, a stylesheet, or code. The distinction that matters is not code against content but whether the runtime acts on what it receives or only presents it. Presented content reaches its effect by being consumed. Actioned content is interpreted and executed by the runtime and needs nobody present at all. The line between the two is not fixed, which is Data as Code applied to this taxonomy: a data payload is presented until something evaluates it, templates it, binds it to a handler, or supplies it to a model as instruction. Actioned injections carry the widest reach, because they can manufacture any of the eight forms at will, and because they can also produce effects that render nothing at all. A destructive call, an exfiltration, and a silent write each leave the surface looking exactly as it should.

Style Injection is the least recognized actioned form. The presentation layer is altered by a stylesheet the runtime loads or by script that writes style while running, so the rendered surface no longer represents the data behind it. A control can be hidden so the user cannot reach it, a color-coded threshold restyled so it reads as its opposite, a list reordered visually while the source order is untouched, a control taken out of service while remaining visible and pressable, and layout and filter work driven until the surface is unusable. Stylesheets are interpreted and acted on, and they are rarely treated as executable, rarely enumerated in a dependency inventory, and exempt in practice from the integrity reasoning applied to script. The case is the cleanest available statement of the pattern: the data is correct, the render is wrong, and every integrity check on the data passes.

2.13: Post-Load and Post-Trust Modification

Content Swapping catalogs what changes on the rendered surface. When the change happens determines what, if anything, was in a position to notice it. The most consequential timing is the latest one: after the resource has been fetched, after whatever integrity checking was going to run has run, and after the runtime has admitted the content into the executing application.

Post-Load and Post-Trust Modification is that case. Data that arrived over an authenticated connection, passed the verification the application applied, and was accepted as correct is then altered in memory by code already running in the same context. The value the user sees is no longer the value that arrived. Nothing in the loading path re-examines it, because the loading path finished before the modification occurred.

The mechanism requires no exotic capability. Code executing in a Client Runtime can read and write the global objects, the shared prototypes, and the rendered nodes that other code depends on, which is the ordinary condition of the runtime rather than a defect in any one application. A script that legitimately formats a number can rewrite it. A component that legitimately renders a list can reorder the list after it arrives. A charting library that legitimately draws a series can draw a series other than the one it was handed.

Verification and modification are separated in time, and that separation is what distinguishes this case from a delivery-side swap. A delivery-side swap defeats integrity checking by changing what is delivered. Post-load modification does not need to defeat integrity checking at all. It lets the check pass and changes the result afterward. Everything the check measured was true at the moment it was measured.

The practical consequence is a matter of order. Changes delivered through this channel run after the existing cybersecurity defenses have done their work, in what the research calls the post-trust and post-load environment. Every control that operates on delivery has already operated. Every check that was going to run has run and passed. The environment is not one where defenses failed; it is one they have already exited.

2.14: Targeted Delivery

The Runtime Injection Advantage establishes that a delivery channel can serve one response to inspectors and another to the runtime under attack. What decides which requester falls into which group is the operationally interesting part, and it is ordinary commercial infrastructure.

Targeted Delivery is the practice of conditioning what a resource returns on who is asking. The conditions available are the conditions any content-personalization system already uses: source address and inferred geography, device and user-agent characteristics, time of day and session timing, authenticated identity, prior behavior, cohort membership, and experiment-assignment buckets. An operation that can express its target as a rule in that vocabulary can deliver a swap to the target population and clean content to everyone else, from the same URL, in the same session window.

The middle of that range is where an influence operation lives, and it is worth working through rather than asserting. One position inside one advertising or analytics provider can serve, in the same hour and from the same address: the genuine article to most readers; a version with one paragraph altered to readers whose address resolves to a particular country; a different alteration again to readers whose prior behavior places them in a commercial or political segment; and the genuine article once more to any requester whose characteristics look like a scanner, a fact-checker, or a newsroom. No group can see another group's version, and the publisher's own servers were never touched.

Precision down to a single device is the extreme of the range rather than its center. It demonstrates how fine the targeting can be, and an operation seeking reach would not use it. The operations that matter at population scale are the ones that segment: one position, one trusted source, different content to different groups, simultaneously.

Investigation after the fact meets the difficulty from the other direction. The population that could confirm the swap is the population that received it, and that population had no reason to know it had. None of this requires the adversary to hide. It requires only that the adversary answer a different question than the one the defender is asking.

Deciding who receives a swap and actually delivering the swap are two separate things. The rule can be resolved by the same personalization and advertising infrastructure the commercialization analysis describes, and that infrastructure is not the vector. The swap is carried by code running in the application's own context. The same rules that decide which advertisement a person sees can decide which person receives a swap.

Narrowing the target set is deliberate on the adversary's part, and it makes detection harder rather than limiting the harm. A swap delivered to a thousand people out of a hundred million is harder to detect than one delivered to all of them, and it is worth more to an operation that only ever cared about the thousand.

2.15: The Integrity Blindspot

In the common case, no party can establish at the moment it matters whether the content in front of them is what it should be. That inability is not a gap in anyone's tooling. It follows from the architecture, and it applies both while the content executes and afterward.

The Integrity Blindspot is that condition. Where no authoritative reference exists for what a given resource should be at the moment it is delivered, there is nothing to compare the delivered resource against, either live or later. The invisibility is structural rather than an oversight in any one product: monitoring inside the rendering boundary, where the substitution occurs, is not deployed at meaningful scale in the current landscape.

• The Detection Blindspot: nothing verifies, at the moment of execution, that a fetched resource matches an authoritative reference. Subresource Integrity is the closest the platform comes, and the existing-defenses analysis sets out where its coverage ends. The verification that does exist runs before execution and covers the file as it was delivered, not what it does once it runs.
• The Forensic Blindspot: nothing is recorded that would let the substitution be reconstructed later. The substituted resource existed in memory for the duration of a session and is gone when the tab or the application closes. Unless traffic is intercepted at a proxy that terminates TLS, a network monitor records only metadata, timing, size, and destination, never the content itself. In the post-load and targeted-delivery cases there is often no file left to scan and no distinct domain to block, and the substitution leaves no entry in the logs the defender keeps.
• The Missing Source of Truth: the application owner declares what a resource is at build time, and nothing keeps that declaration current at the moment of delivery. The Detection Blindspot and the Forensic Blindspot both follow from this. A live check has nothing to measure against, and an investigation after the fact has nothing to reconstruct toward.

Remote Cache Control closes the forensic route deliberately. Response cache directives are set by the server that answers the request, and clients honor them by default, so the party serving a resource decides how long, and whether, the client keeps it. This is the same serving-side authority the CDN analysis describes, applied to a different purpose. That server can send a substituted resource once, mark it no-store so the client's HTTP cache keeps nothing, and serve clean content to every request after that. Served to the target, the resource lives in memory for the session and is never written to the cache an investigator would go looking in. The cache is clean because it was never used.

The condition is not permanent. It holds where no live reference for runtime resources is deployed and no monitoring operates inside the rendering boundary, which is the common case today rather than a property of the architecture. An application that pins every resource, declares an integrity hash for each, and admits no dynamically generated code has a reference to check against. Few applications are built that way, and the ones that are give up the capabilities that made CSR worth adopting. Runtime behavioral monitoring at the rendering layer is the complementary control, and the existing-defenses analysis sets out where it stands today.

Absence of evidence is not evidence of absence. A blind spot is precisely a place where not seeing something is not the same as its not being there. The instrumentation that would produce evidence of a swap at the rendering surface is not deployed at population scale, so the absence of that evidence carries no information about whether swaps are occurring. Every claim about the operational prevalence of ATG runs into this, including the claims in this whitepaper.

2.16: ATG Applies to All Networks, Not Just the Internet

Public-internet framing is the default mental model for software supply-chain vulnerabilities. ATG does not stop at the public network. The vulnerability class travels with the architectural pattern. Wherever a Client Runtime consumes content from any external source, ATG applies, regardless of which network connects the runtime to that source.

Air-gapped enclaves, classified networks, OT segments, vehicle networks, industrial control networks, and private corporate networks all host Client Runtimes. Those Client Runtimes fetch scripts, configuration, content, and data from upstream sources within their respective networks. The networks are different; the runtime is the same. An air gap does not eliminate the supply chain; it brings it inside the wire. The pattern is the Trojan Horse: high walls and isolation do not protect against what you carry inside the perimeter yourself, and where the vulnerability predates the isolation, air-gapping can simply do the adversary's work of getting it inside. Isolating a network relocates the supply chain rather than removing it.

Equating protected networks with the public internet would overstate the risk inside protected environments. The digital supply chain inside a classified network or a hardened OT segment is significantly smaller and more controlled than the public web. Access control is rigorous, nodes are validated, the inventory of upstream sources is tractable, and the adversary set is different from the population that operates against the public internet. The protected-network differential is real.

Protected networks are not immune. The Glass inside those networks is not currently defended against ATG; ATG is not yet a recognized attack vector for which industry has built defenses. Even the most secure classified networks are built on commercial hardware, run commercial operating systems, and host largely commercial software platforms. The runtime structures are the same as on the public internet; the differences are the supply-chain inventory and the adversary set.

ATG applies inside protected networks because the architectural pattern is present. The risk inside a protected network differs from the risk on the public internet because the supply chain is smaller, the controls on access are tighter, and the adversaries with positions inside that supply chain are a smaller, different group. The protected-network case is not exempt; it is differently exposed.

2.17: D5 Effects

Operational consequence is what an attack accomplishes, distinct from how the attack is delivered. ATG can produce five classes of operational consequence, the D5 effects. The five are distinct outcomes rather than five degrees of one outcome: each is fully capable alone, combinations are ordinary rather than exceptional, and the 01 to 05 ordering is a stable index rather than a severity ranking. Every effect is scored together with the object it acted on and the reach it was delivered to, and neither of those belongs inside the definition of the effect itself.

• Deceive: the consumer accepts as authoritative content that does not match what the system intended, and acts on it. False prices, doctored images, manipulated alerts, fabricated recommendations, and per-target deceptive content all sit here. The consumer may be a person or an automated one: an alarm evaluation, a control loop, an agent, or a model reads what it is given and behaves accordingly, without judging whether it is true.
• Disrupt: an intended function is interfered with. The function is present and does not do what it is for. Workflows fail, alerts stay silent, controls miss, features behave incorrectly. The boundary against Deceive is what was consumed: a false value that the function processes correctly is Deceive, because the function worked; a malformed value or an altered code path that stops the function achieving its purpose is Disrupt.
• Degrade: volume, speed, scale, or response time declines below intended levels without anything failing. The system does everything it is supposed to do and does it worse. The mechanism is induced work rather than substituted meaning: a delay inserted ahead of every outgoing request, forced repaints driven by mutating bound values, listeners and polling added to the runtime, payloads sized past what the renderer can handle. Reduced accuracy is not Degrade. Content that is wrong is Deceive, and content that is withheld or truncated is Deny.
• Deny: something is made unavailable or inaccessible at the rendering layer. The control is removed from the interface, the navigation point is deleted, the returned set is truncated, authentication fails, transactions block, services become unreachable, content cannot be loaded. Deny runs from a single control up to an entire application and stays Deny at every scale, because what makes it Deny is that the effect is achieved at the Glass.
• Destroy: adversary-controlled code reaches through the rendering layer into a backend or connected system and damages it, so that it cannot function until it is restored or rebuilt. Data and the structures holding it are destroyed, configuration or credentials the system runs on are removed, or a connected system the application drives is damaged. Two conditions are required and neither is optional: the damage occurs beyond the Glass, and the adversary's code causes it. Where a person was deceived into taking the damaging action, the effect is Deceive and the damage is its consequence. Whether a backup exists measures the operator's resilience and belongs to the consequence rather than to the effect: dropping every table is Destroy whether or not the tables can be restored. Each effect is achievable on any Client Runtime once supply-chain control is established. The full spectrum is the operational expression of the Malice Without Malware argument: D5 attacks weaponize features of the platform and the language to produce effects that current detection systems do not recognize as malicious behavior. The result is an uncontested operating environment in which truly malicious activity proceeds undetected because it does not match any signature or behavioral pattern the defender's tools were built to flag.

Consequence and delivery are different axes. D5 names the consequence; the Two-Stage Attack, supply chain injection, and runtime injection generally name the delivery side. A delivery mechanism produces an effect, and the effect produced is the D5 score for that mechanism.

What a given effect is worth, and whether it is available at all, is set by the authority of the session the runtime is holding. A swap on a retail checkout reaches a customer's belief and a customer's transaction, because that session has no destructive path to aim. The same swap on an administrative console reaches whatever that console is authorized to reach: a database administration interface can destroy tables, a cloud console can delete an account's storage, an identity console can revoke a directory. The adversary's capability is identical in both cases; the session's authority is not. This is the D5 expression of what Placement, Access, Influence, Control already argues, that control follows position rather than actor size. The corollary deserves stating plainly: the interfaces that operate infrastructure, from database tools and cloud consoles to CI/CD interfaces and identity administration, are client-side rendered applications assembled at runtime from the same commercial supply chain as any other.

ATG grants an adversary nothing the target application could not already do. It substitutes what the application works from. The effects available against a given system therefore depend on that system's function, deployment, users, and connections, and not every system has a pathway to every effect. A read-only reference surface has no Destroy pathway from the Glass and little worth disrupting. An operator console has all five. An administrative surface is a trade rather than a prize: a higher ceiling, a smaller user base, and often a more controlled dependency set to reach through.

Two operations outside ATG's inclusion criterion show where the line between Deceive and Destroy falls. They share a mechanism and score differently. Stuxnet was an attack on the interface: monitoring systems were shown recorded normal process values while centrifuges ran outside their tolerances. No person was deceived into acting. The automated evaluation was supplied false data so that it would not intervene, and the adversary's code reached through into the connected system and did the damage. That is Deceive against an automated consumer and Destroy against a connected system, on one operation. Operation Orchard in September 2007 scores differently. The Syrian air-defense system reportedly presented a picture that did not match the sky, and the al-Kibar site was then destroyed by aircraft ordnance. The deception was the same class of act, worked on the same kind of consumer, and produced no Destroy at all, because nothing reached through the Glass and a separate kinetic means did the damage. Severity did not decide the difference, and neither did the presence of physical destruction. What decided it was whether the code went through.

Neither case satisfies the inclusion criterion. Neither environment is a CSR-capable Client Runtime: a PLC and HMI pairing is not one, and an air-defense sensor network is further from one still. Neither belongs in the confirmed ATG record. Both are precedents for how the five effects are told apart, and that is the only work they do. Israel acknowledged the Orchard strike in March 2018; the electronic method is reported rather than confirmed and is carried as Presumed.

Within the D5 spectrum, one effect class dominates. Information manipulation is the modification of the data, content, media, and features the user sees. Within ATG, information manipulation is the easiest to execute, the most rewarding to run, and the most dangerous category of attack. The information-manipulation hierarchy is that ordering, and three independent dimensions support it.

• Easiest to execute: information manipulation requires the smallest adversary capability footprint. Most of the Content Swapping forms (a swapped numeric field, a media element, a price, an alert text, a recommendation) produce an effect without disrupting normal operation, without crashing the application, and often without leaving any structural sign. The execution barrier is the lowest in the spectrum.
• Most rewarding to run: information manipulation produces the highest expected value per unit of adversary effort. The same placement and access position that enables a single information-modification effect enables a population of targeted variations across users, contexts, and time windows. The economics favor information manipulation across criminal motivation (fraud), state motivation (influence), commercial motivation (competitive sabotage), and insider motivation (selective harm).
• Most dangerous: information manipulation operates beneath the user's verification capacity. The user trusts what the Glass shows. When the Glass shows a different number, a different image, a different sentence, a different recommendation, or a different alert state than the system intended, the user makes a decision based on the manipulated information without any signal that something is wrong. The damage compounds because the trust that produces the wrong decision is the same trust that protects the wrong decision from review. Functional disruption (Disrupt, Degrade, and Deny effects against application behavior; alert suppression; feature subversion) sits above information manipulation in technical sophistication and below it in frequency, payoff, and damage. Destroy effects are the rarest, because they require a path through the Glass into a system that can be damaged, and most sessions do not hold one. Second-order outcomes that flow from information manipulation producing wrong decisions are consequences of Deceive and are recorded against Deceive.

A category whose dominant exposure is information manipulation sits in a higher-priority defensive position than a category whose dominant exposure is functional disruption.

2.18: Scope and Exclusions

The inclusion criterion defines ATG's scope, and it is deliberately conservative: a vulnerability is in scope for ATG if and only if it manifests through code or content execution inside a CSR-capable Client Runtime at the rendering surface. The severity-methodology analysis applies the same rule.

Two exclusions follow from the criteria: server-side runtime scripting and precompiled-only Client Runtimes.

Server-side runtime scripting is the principal exclusion. Server-side template injection (SSTI), remote code execution in server-rendered languages, and similar server-side execution patterns are not in scope for ATG. The execution environment is different. A server is not a CSR-capable Client Runtime; the rendering surface of a server-side rendering (SSR) application sits behind the operator's defensive perimeter; and the existing frameworks for server-side vulnerability cataloging cover the server-side cases reasonably well already.

Precompiled-only Client Runtimes are the structural exclusion. They are out of scope structurally, not by analytical choice.

Both exclusions are of scope, not of relevance. The D5 effects framework applies equally to server-side environments. Malice Without Malware applies across tiers. Any form of supply chain injection can produce D5 effects on any tier in a system architecture, and a server-side compromise that produces deception, disruption, degradation, denial, or destruction is a serious matter regardless of whether ATG names it.

ATG is about the unprotected client-side rendering layer inside the Client Runtime. Server-side supply chains may be more secure and more closely monitored, in part because they sit inside the traditional defensive boundary of modern cybersecurity frameworks. The client side does not. Where the traditional defensive boundary stops, the analytical focus picks up.

2.19: ATG Beyond the Browser

Beyond the browser, the Glass is everywhere. Client Runtimes render it through many non-browser hosts, and ATG applies in each of them. Six categories illustrate the breadth.

Mobile OTA bundle delivery. CodePush, Capgo, Appflow, and similar services let mobile applications fetch and apply JavaScript or React Native bundles at runtime, replacing the application's executing code without going through the app store. The Glass is the mobile screen; the Client Runtime is the application's JavaScript runtime; the supply chain is the OTA service and whatever the bundle inherits from. ATG applies directly: the bundle is built by the over-the-air service at the moment it is fetched.

User-generated-content (UGC) interactive runtimes. Roblox, Unity's AssetBundle pipeline, and similar systems load user-generated assets into a runtime that integrates them into the running game. What an asset can carry differs by platform: Roblox assets carry Lua scripts directly, while Unity's manual records that AssetBundles cannot contain executable code and that the reachable path is altered serialized data exploiting the application or the runtime. The Glass is the gameplay screen; the runtime is the engine; the supply chain is whatever the user-generated asset depends on. The user trusts what the engine renders; the engine renders what the asset directs.

Productivity add-ins. Office.js add-ins inside Excel, Word, and PowerPoint; Jupyter notebook frontends; and the broader productivity-extension ecosystem each provide a Client Runtime inside an application typically not classified as a runtime host. The Glass is the document or notebook surface; the runtime is the embedded JavaScript or kernel-language runtime; the supply chain is the registry and CDN the add-in fetches from.

Spatial-asset auto-render. USDZ AR Quick Look on iOS renders a 3D scene from a URL the moment the user taps the link, with no step at which the user chooses to execute it as code. The Glass is the AR-rendered space; the runtime is the spatial-asset interpreter; the supply chain is the URL host serving the USDZ file. The structural property is that visual rendering is itself execution: the asset is interpreted, and interpretation produces what the user sees.

Plugin and extension marketplaces. IntelliJ Platform plugins, VSIX extensions for Visual Studio, Blender add-ons, and Anki add-ons each install code into a host application and run that code with the host's privileges. The Glass is the application UI; the runtime is the host's plugin runtime; the supply chain is the marketplace and the plugin's own dependencies. A compromised plugin executes inside the host with the host's trust.

IoT and control-system dashboards. The HMI of a smart-home appliance, the dashboard of an industrial control system, the screen of a medical device, and the touchscreen of a vehicle infotainment system are Client Runtimes running on devices typically not perceived as runtimes. The Glass in these cases sits in front of consequence: a mis-rendered alert, a deceptive status indicator, a manipulated control reading. The supply chains are smaller than the public web's, but ATG applies in the same structural form.

Each category is a Client Runtime rendering the Glass through a non-browser host. The full taxonomy spans languages, platforms, and providers. ATG is structural, not browser-bound.

One of those categories carries the highest concentration of function on the Glass anywhere, and it behaves differently from the rest. Industrial HMIs, embedded appliance interfaces, vehicle systems treated as controls rather than as media, building management panels, and medical device interfaces render a control layer rather than a reading surface. What appears on them is bound to actuation, timing, sequencing, interlocks, alarms, setpoints, and modes. The effect profile shifts accordingly. Disrupt, which is narrow against a page whose purpose is to be read, becomes the widest and most consequential effect where there is that much function to interfere with. Where a system carries real-time deadlines, the boundary between Degrade and Disrupt moves as well, because latency that reads as an annoyance in a browser is a missed deadline on a control loop, and a missed deadline is a functional failure rather than a slower success. Deny is harder to achieve against a fixed panel with little navigation, and more absolute when achieved, because there is no second device to try. Destroy has the shortest path of any surface class, because the Glass sits closest to the system it drives.

2.20: ATX: Beyond the Glass

Beyond the Glass, the architectural pattern that produces ATG generalizes. ATX (Attack the X) is the broader framework, where X is any human-computer interaction surface. The Glass is one X. Audio surfaces, haptic surfaces, voice interaction surfaces, gesture and sensor-driven interfaces, and emerging modalities such as brain-computer interfaces and robotic actuators are other instances.

ATX is forward-looking research framing. The current operational threat is overwhelmingly the Glass; non-Glass surfaces are emerging and operationally insignificant by comparison today. The enumeration below flags published attack vectors for future research, not for any expansion of operational scope.

Audio surfaces have received the most published research outside the Glass. Voice-assistant injection attacks place commands the human ear cannot detect into the system the assistant trusts: DolphinAttack and similar ultrasonic-injection research, SurfingAttack and other solid-surface conduction techniques, and commands hidden in music or background audio all sit here. Audio deepfakes drive executive-impersonation wire fraud, family-distress scams, and voice-authentication bypass. In-vehicle audio manipulation, smart-speaker hijacking, hearable-device exploitation, VoIP call modification, and streaming-audio injections round out the surface. The dominant D5 effect across the audio surface is Deceive, with Disrupt reachable through specific subvariants. Destroy is reachable where an injected command executes against a connected system; where a person is misled into acting, the effect is Deceive and the harm is its consequence.

Haptic surfaces are growing as wearables, controllers, and accessibility devices proliferate. Spoofed haptic confirmations falsify transaction success or biometric capture. Game-controller haptic manipulation deceives players in gambling and esports contexts. Wearable false notifications fabricate health alerts and trigger panic responses. Accessibility-device exploitation can misdirect or fail to alert visually impaired users. Steering-wheel haptic deception falsifies lane-drift or collision warnings or suppresses legitimate ones. Deceive dominates. Haptic misdirection that produces physical action is Deceive with a physical consequence rather than Destroy: a person acted, and nothing reached through the surface into another system.

Voice interaction surfaces overlap with audio but use voice as the input modality. Voice-driven UI manipulation hijacks kiosk, vehicle, and smart-home command flows. Voice authentication bypass combines deepfake audio with replay or injection. IVR-system manipulation targets phone-based voice-response systems through model compromise or middleware injection. Deceive is the dominant effect; Destroy appears at the consequence level via account takeover.

Gesture and sensor-driven interfaces bypass traditional UI inspection entirely. Motion-control deception manipulates Vision Pro, Wii, Kinect, and similar input through environmental injections or model compromise. Eye-tracking manipulation targets gaze-based authentication and AR/VR intent capture. Biometric spoofing covers fingerprint replay, face spoofing, and iris spoofing. Health-sensor data poisoning influences medical decisions, fitness records, insurance underwriting, and continuous-glucose-monitor readings. Environmental-sensor manipulation targets smart-home heating, security alarms, door unlocks, and HVAC controls. Deceive, Disrupt, and Degrade all appear. Physical harm that follows a person acting on manipulated sensor output is Deceive with a physical consequence; Destroy applies where the manipulation drives a connected system directly, as in environmental controls acting with no person in the loop.

Emerging surfaces are largely without confirmed operational attacks today. Brain-computer interfaces (Neuralink, Synchron, and the broader invasive and non-invasive BCI category) sit at the early-research stage; the theoretical D5 reach spans Deceive (false sensory input), Disrupt (interrupted intent translation), and Destroy (induced motor activity or harmful neural signaling). Robotic actuators with HCI (humanoid robots, collaborative robots, autonomous service robots) carry direct Destroy potential through compromised commands. Digital olfaction is nascent. The prospective attack delivers a false scent that misrepresents environmental safety or danger.

Across non-Glass ATX surfaces today, Deceive is the dominant achievable effect. Disrupt is second most common (jamming voice commands, blocking sensor inputs). Degrade is present but rarer (degraded voice recognition through targeted poisoning, gradual sensor drift). Deny is present in authentication and emergency-notification contexts. Destroy is present where an injected instruction executes against a connected system with no person in the loop, as in voice commands triggering destructive actions and robotic actuator compromise. Account takeover through biometric bypass is Deceive against the authenticating system, and physical harm that follows a person acting on manipulated sensor output is Deceive with a physical consequence.

Malice Without Malware anticipates this surface expansion. The defensive vocabulary built for binary malware does not capture the audio, haptic, voice, gesture, sensor, or emerging-modality cases any better than it captures the Glass cases. The same architectural reasoning applies: each surface is a runtime that grants trust to upstream content, and each grant of trust without continuous re-verification creates the conditions for D5 effects.

ATX is the horizon. The Glass is the operational threat today. As non-Glass surfaces mature operationally, the same structural reasoning will extend to them.