The Provider Landscape

The runtime executes what providers send. Every Client Runtime in deployment runs content delivered by a population of supply-chain entities. Scripts come from CDNs. Analytics scripts come from tag managers, the hosted consoles that decide which of those scripts a page loads. Ads come from ad exchanges. Identity claims come from authentication providers. Model output comes from inference endpoints, the addresses an application calls to get an answer from a model. None of that content lived inside the application before it loaded. The runtime is built from what providers deliver, every time.

Modern applications depend on dozens to hundreds of providers across multiple categories. Each provider is a Placement and Access position. A compromise at the provider reaches every dependent application on every dependent runtime, every time those applications load.

Providers, languages, and platforms vary independently of one another: a single provider category usually delivers content into multiple language runtimes, the same provider usually feeds multiple platform categories, and language and platform together cannot predict which providers a given application depends on. A defender has to read all three together.

The provider dimension covers the full Client Runtime landscape. The familiar cases are web-targeting providers feeding browsers: CDNs serving JavaScript libraries, tag managers, ad networks, web fonts. The same provider categories deliver content into mobile applications, desktop shells that wrap a web runtime (Electron, Tauri), smart televisions and signage runtimes, vehicle infotainment systems, IoT and operational technology (industrial control) dashboards, AR/VR runtimes, productivity-tool extension hosts, and game and interactive runtimes that load user-generated content. A mobile attribution SDK, the code an app embeds to report which ad or campaign led to an install, is a provider. A vehicle infotainment map-tile service is a provider. A productivity-tool extension store is a provider. A foundation-model inference endpoint consumed by an Electron desktop client is a provider.

Six things shape a provider's risk, two of them about depth in different senses.

An adversary takes a provider over in one of five ways, each a different route to the same outcome. Which of the five is most likely varies from provider to provider.

The provider's shape and the ways an adversary gets in are two dimensions of risk. Reach is the third: how many Client Runtimes depend on this provider class, and how broad the population of dependent applications and devices is. Defendability runs alongside reach. SRI and CSP cover certain provider patterns inside browsers and have no functioning analog at scale across most non-browser Client Runtimes, so a provider's defendability depends on which Client Runtime consumes its content.

Twenty provider categories cover the entities that deliver content into Client Runtimes at meaningful scale, ranging from code and package delivery and tag-and-analytics infrastructure through advertising and identity into AI services, plugin distribution, and the data-broker layer.

Eight patterns recur across the categories.

The code that implements a defense does not carry from one provider category to the next; the architectural pattern behind it does. The patterns that carry are a single source of truth (SSoT) for runtime resources, content-swap detection at the provider boundary, and provider-inventory discipline. Provider-inventory discipline carries an additional requirement: the inventory has to reach the dependencies of its dependencies, which is the lesson of the Log4j case, where exposure ran several dependency layers below what most organizations could see.

6.1: Why the Provider Matters

Providers are the dimension where the supply chain operates load by load. The runtime calls out, the provider responds, the runtime executes the response. Each call extends trust. Each response delivers content the runtime treats as authentic. Most of those calls go to organizations distinct from the application owner; some go to first-party infrastructure operated by the same organization. Either way, the application's own configuration named the destination, set the trust relationship, and admitted the content. Languages and platforms are also produced by organizations, and those organizations are themselves supply-chain entities at the level of the runtime. The operational supply chain inside any given application is the population of providers the application has configured to call out to and trust on every load.

An application that loads scripts from a CDN, more scripts from a tag manager, ads from an ad exchange, identity from an authentication provider, and inference from a model service has named five entities its runtime trusts on every load. Each is a Placement and Access position with a real address, a real owner, real personnel, and real means of being acquired or compromised. An adversary controlling any one of those providers determines the content every dependent runtime executes on the next call, and holds the power to segment those runtimes into a multitude of target groups: by region, by IP, by user-agent, by tenant, by hour of the day. The same machinery that delivers personalized content legitimately delivers selective compromise. Provider compromise is therefore a direct operational task in adversary economics: identify the named entity, find the route in, and serve the desired content to the desired subset on the desired schedule.

Inside the runtime, the provider is a URL, a hash, a TLS certificate, a tag manager's container identifier, an inference endpoint, an extension manifest. The organizational structure behind the URL is invisible. The owner change last quarter is invisible. The maintainer's credential leak two months ago is invisible. The build-pipeline compromise yesterday is invisible. The runtime's trust extends to whatever the URL returns, on the implicit assumption that the URL maps to the same supply-chain reality it mapped to last load. Providers are where that assumption can drift, and an ATG operation is what runs in the gap between the supply-chain reality the URL mapped to last load and the one it maps to now.

6.2: What Makes a Provider an ATG Surface

A provider's risk has two parts. The first is the shape of the provider itself: what content it delivers, what defenses cover that content, how the runtime decides to trust it, how its updates flow, how widely it fans out, and how deep its own dependencies run. The second is how an adversary takes the provider over.

• Injection vectors: which content types the provider delivers, and how each one carries content to the point where the runtime executes it. Scripts (browsers, JavaScript runtimes inside Electron shells, mobile WebViews, productivity-tool extension hosts). Iframes (browsers and any embedded WebView). Media (images, video, audio that the rendering pipeline processes and where unsafe-deserialization paths exist). Styles and fonts (CSS that fetches additional resources, font foundries that ship hinting code). Manifest-driven auto-fetch (web app manifests, OTA update manifests, AI tool manifests). Declarative configuration (files the runtime reads at load time and acts on, which direct its behavior). Mobile over-the-air bundles: code updates an installed app pulls straight from a server, without going back through the app store (CodePush, Capgo, Expo OTA, vehicle infotainment OTA). Plugin manifests (browser extensions, IDE plugins, productivity-tool add-ins). Model weights (inference runtimes that load from a model hub). Prompt and tool definitions (AI agent runtimes that fetch templates and tool schemas at call time). Most providers carry more than one.

• Defendability: whether the existing defenses built for client-side rendering cover the provider's content type. SRI covers static script and style sub-resources fetched from a known URL with a known hash. CSP can constrain the set of URLs the runtime is permitted to fetch. Both are browser-specific defenses. Many provider patterns sit outside the coverage of either even inside browsers: tag managers that return different scripts to different requests, mobile attribution SDKs calling out from hybrid runtimes, model endpoints returning fresh inference output, manifest-driven configuration auto-fetched at load. Across non-browser Client Runtimes (mobile WebViews outside the host-browser context, Electron and Tauri shells, smart-TV runtimes, vehicle infotainment systems, IoT dashboards, productivity-tool extension hosts, AR/VR runtimes, interactive runtimes that load user-generated content), SRI and CSP analogs are largely absent at scale. A provider's defendability depends on which Client Runtime consumes its content.

• Trust model: how the runtime decides to trust the provider's response. Pinned hash. Signed certificate (TLS, code signing, manifest signing). Domain reputation (the URL is on an allowlist or carries an organizational identity the runtime treats as authoritative). Contractual relationship (the provider is a third party the application owner has procured and tracks). No explicit trust check at all (the runtime fetches and executes the response without re-verification). Each model holds against the threats it was designed for, and not against an adversary operating inside the trust the model has already extended.

• Update authority: whether content updates from the provider require any explicit acceptance or run silently as part of normal operation. Web fetches happen on every page load; CDN-served libraries can change between page loads with no version pin. Tag managers change which scripts they serve from an administrative console, with no signal to the application. OTA bundles replace mobile application code on next launch. Plugin marketplaces push extension updates with no end-user prompt in many configurations. AI inference endpoints return fresh output on every call. Silent updates are the default for most providers.

• Aggregation depth: how widely the provider fans out across underlying sources. A CDN serving a library catalog hosts thousands of libraries from different upstream maintainers under one URL. A tag manager fires analytics, advertising, personalization, fraud-detection, and customer-engagement scripts through one container, a single hosted list of the scripts a page should load. A package registry holds millions of packages from millions of maintainer accounts. An AI-service hub aggregates models, adapters, and prompts from many publishers behind one endpoint. A compromise at the aggregator reaches every dependent application that loads any of its content, in one step.

• Dependency chain depth: how deep the provider's own dependencies run. The provider an application configured may itself fetch from a second provider, which depends on a third, which depends on a fourth. The Log4j case is the reference illustration: organizations were exposed to the Log4Shell vulnerability because the affected Log4j library sat several dependency layers below the components they directly depended on, often in software they had not previously known they were running. Aggregation depth runs across one layer; dependency chain depth runs through the layers themselves. There are five ways an adversary gets in.

• Account takeover: the provider's credentials or publishing access are compromised, and the adversary uses the legitimate publishing channel to deliver adversarial content. The credentials may be stolen, phished, leaked through a third-party breach, or harvested from a maintainer's personal infrastructure. The runtime sees a routine update from a trusted provider. The provider sees a routine publishing event from a credentialed account.

• Network-path hijack: the network path between provider and runtime is intercepted, and adversarial content is substituted in transit. BGP hijack, DNS poisoning, certificate-authority compromise, and on-path interception in network segments under adversary control all do this. TLS narrowed but did not eliminate the surface; certificate-authority and DNS-level compromise remain in scope, and many non-browser Client Runtimes ship with weaker default certificate pinning than the major browsers. The narrowing is smaller than it appears, because transport encryption protects the path and not its ends, and modern delivery arranges for a third party to hold one of the ends. A content delivery network terminates TLS at its edge: the edge decrypts the resource, holds it in plaintext, and re-encrypts it for the client. That is an interception position, occupied lawfully, established by contract, and invisible to the user and frequently to the application owner as well. Transport encryption does not eliminate the intermediary position. It relocates that position from any party able to reach the wire to the delivery provider the application owner has contracted with, inside the trust boundary rather than outside it. Whoever holds that position holds the plaintext, and the legal regimes described in the URL Overtrust analysis reach it there: national intercept regimes place their obligations on whoever holds the traffic in readable form, which for CDN-delivered content is the delivery provider.

• Ownership change: the provider is acquired or its ownership changes, and legitimate new owners use the legitimate publishing channel to deliver adversarial content. The Polyfill.io case (2024) is a real-world example: a long-trusted CDN domain was acquired by Funnull, a China-linked CDN operator (later sanctioned by the U.S. Treasury's OFAC in 2025 for facilitating large-scale scam and money-laundering infrastructure; see Silent Push, Triad Nexus), and the new ownership used the legitimate publishing channel to deliver selectively-targeted malicious content to a population of dependent sites. Acquisition leaves the publishing channel intact; the adversary inherits trust along with ownership.

• Insider compromise: the provider's personnel are the threat actor. Insiders may be recruited adversaries placed deliberately, existing employees turned through coercion or financial inducement, or contractor personnel with legitimate access to publishing channels. Provider organizations vary widely in personnel vetting, in access controls on supply-chain-critical roles, and in monitoring of routine insider actions, and many lack threat-modeling that anticipates nation-state or organized-crime placement.

• Cyber exploitation: technical compromise of the provider's infrastructure, code, build pipeline, or dependencies through exploitation of vulnerabilities. The compromised provider continues to operate normally from its own perspective; the adversary's foothold sits inside the provider's systems and uses the provider's infrastructure to publish adversarial content. Cyber exploitation differs from account takeover (which uses legitimate credentials obtained illegitimately) and from ownership change (which uses legitimate ownership).

6.3: Provider Reach and Defendability

Provider reach is measured in dependent applications, not in user counts or transaction volumes. A CDN serving a hundred thousand sites reaches a hundred thousand dependent applications. A tag manager deployed across millions of properties (the websites and apps that embed it) reaches millions of deployed containers. An open-source package depended on by half the JavaScript ecosystem reaches every project in the transitive dependency graph that includes it. A mobile attribution SDK installed in tens of thousands of apps reaches the installed-app population and its active users. An AI-service endpoint consumed by thousands of products reaches the products that call it. User counts and transaction volumes follow from the dependent applications.

Attack routes and reach interact. A high-reach provider most often compromised through account takeover needs different defenses than a high-reach provider most often compromised through ownership change or cyber exploitation. The Reference Matrix Providers sheet scores each provider category by reach and by which attack routes apply, so a defender can read the per-category combination directly.

Defendability runs alongside reach. SRI and CSP are browser-specific. A provider that delivers content into a browser may be partially covered by SRI for its static script sub-resources; the same provider delivering the same content into a mobile WebView outside its host browser context, an Electron or Tauri shell, a smart-TV runtime, a vehicle infotainment system, an IoT dashboard, a productivity-tool extension host, or an AR/VR runtime is generally uncovered. Reading defendability for a provider therefore requires knowing the Client Runtime platforms it feeds. What holds inside browsers does not hold across the rest of the deployed Client Runtime landscape.

6.4: The Twenty Provider Categories

Per-provider details live in the Reference Matrix Providers sheet and the printable matrix sheets in the back matter.

Table 6.4: The twenty provider categories. Risk-condition applicability per category, with reach band.

Category	Agg	DCD	Def	ATO	NPH	OC	IC	CE	R
Code and Package Delivery	Yyes	Yyes	Llimited	Yyes	Yyes	Yyes	Yyes	Yyes	HM
Tagging and Analytics	Yyes	Yyes	Nno	Yyes	Llimited	Llimited	Yyes	Yyes	HM
Advertising	Yyes	Yyes	Nno	Yyes	Llimited	Llimited	Yyes	Yyes	B
Embedded Content	Yyes	Llimited	Llimited	Yyes	Llimited	Yyes	Llimited	Llimited	B
Style, Font, and Icon Delivery	Llimited	Llimited	Yyes	Yyes	Yyes	Yyes	Llimited	Llimited	B
Trust Widgets	Llimited	Llimited	Nno	Yyes	Llimited	Yyes	Yyes	Yyes	HM
Identity and Authentication	Llimited	Llimited	Llimited	Yyes	Yyes	Yyes	Yyes	Yyes	HM
Payments and Commerce	Llimited	Llimited	Llimited	Yyes	Yyes	Llimited	Yyes	Yyes	HM
Maps and Reference Data	Llimited	Llimited	Nno	Yyes	Yyes	Yyes	Llimited	Yyes	HM
Email and Messaging	Llimited	Llimited	Nno	Yyes	Llimited	Llimited	Yyes	Yyes	HM
Marketing and CRM	Llimited	Llimited	Nno	Yyes	Llimited	Llimited	Yyes	Yyes	HM
AI and ML Services	Yyes	Yyes	Nno	Yyes	Yyes	Yyes	Yyes	Yyes	HM
Customer Engagement	Llimited	Llimited	Nno	Yyes	Llimited	Yyes	Yyes	Yyes	HM
Data Brokers and Profiling	Llimited	Llimited	Nno	Yyes	Yyes	Yyes	Yyes	Yyes	HM
Translation and Localization	Llimited	Llimited	Llimited	Yyes	Llimited	Llimited	Yyes	Llimited	M
Sanctions, Watchlist, and Compliance Data	Llimited	Llimited	Nno	Yyes	Yyes	Llimited	Yyes	Yyes	M
Tracking and Attribution	Llimited	Llimited	Nno	Yyes	Llimited	Yyes	Yyes	Yyes	HM
Cloud Storage and Asset Hosting	Yyes	Llimited	Llimited	Yyes	Yyes	Yyes	Yyes	Yyes	B
Plugin and Extension Distribution	Yyes	Yyes	Llimited	Yyes	Llimited	Yyes	Yyes	Yyes	HM
AI-Generated Content Services	Yyes	Yyes	Nno	Yyes	Yyes	Yyes	Yyes	Yyes	HM

Y: routinely applies. L: applies in limited or specific cases. N: rarely or not applicable. Agg: aggregation depth. DCD: dependency chain depth. Def: defendability inside the browser via SRI and CSP coverage. ATO: account takeover. NPH: network-path hijack. OC: ownership change. IC: insider compromise. CE: cyber exploitation. R: reach band (B = billions of dependent applications and devices; HM = hundreds of millions; TM = tens of millions; M = millions and below).

Code and Package Delivery. CDNs serving JavaScript libraries, package registries hosting open-source modules, and module-host services that distribute application dependencies. The category feeds browsers, mobile WebViews, JavaScript runtimes inside Electron and Tauri shells, and the embedded JavaScript engines that ship inside smart-TV apps, vehicle infotainment systems, and other Client Runtimes that load JavaScript at runtime. Aggregation depth and dependency chain depth are both deep: a CDN serves thousands of libraries; each library has its own dependency graph. Ownership change is the concern (the Polyfill.io case); account takeover and cyber exploitation apply broadly across registry and CDN compromises.

Tagging and Analytics. Tag managers, analytics platforms, session-replay services, and the tag-distribution channels that fire scripts on page load. The category is primarily browser-and-mobile but reaches into productivity-tool surfaces and customer-engagement embeds wherever tags are deployed. The tag manager itself is an aggregator: dozens of vendor scripts can fire through one container, often with no review on the application side before they load. Account takeover, insider compromise, and cyber exploitation are the most common routes; ownership change occurs when a tag-publisher company is acquired and the resulting tag updates serve adversarial content.

Advertising. Ad networks, exchanges, and the demand-side and supply-side platforms that buy and sell advertising space automatically while a page is loading. The category reaches into browsers, mobile applications, smart-TV apps, in-app advertising surfaces, and connected-TV inventory. Ads are a long-running ATG concern (Magecart-class skimmer operations have used ad-tech infrastructure repeatedly), and the chain of trust between exchange, network, and ad is opaque to the consuming page. Account takeover, insider compromise, and cyber exploitation dominate; the ad-tech pipeline is itself an aggregator with many handoff points where adversarial content can enter.

Embedded Content. Social-media embeds, content embedded by pasting its URL (oEmbed and similar), video and audio embeds, and the iframe-based content channels that bring third-party-rendered surfaces inside the application page. The category is cross-platform: browsers, mobile WebViews, productivity-tool surfaces, and any Client Runtime that supports iframe-class embedding. The risk pattern is iframe content rendering with cookies, scripts, and access to embed-frame state that the host page cannot inspect. Account takeover at the embedded provider and ownership change of the embedding platform are the dominant routes.

Style, Font, and Icon Delivery. Web fonts, icon sets, and the design-system distribution surfaces that ship style assets. The category reaches into browsers, mobile WebViews, Electron and Tauri shells, smart-TV apps, productivity tools, and any Client Runtime that loads styles or fonts from a third-party host. Fonts can ship hinting code (executable instructions) and CSS can fetch additional resources at parse time, so the category is not purely passive. Network-path hijack and ownership change are the most operationally distinctive routes; account takeover applies broadly.

Trust Widgets. Chat widgets, comment systems, review-and-rating widgets, reCAPTCHA-class anti-abuse widgets, and the cross-platform reputational components that ship as embedded JavaScript and iframes. The category reaches across browsers, mobile applications, and any Client Runtime that admits widget-style integration. Trust widgets carry application-level trust by their nature (reCAPTCHA-class widgets are integrated as security primitives, not as decorative content), and the visibility-trust gap is wide. Account takeover, ownership change, insider compromise, and cyber exploitation all apply.

Identity and Authentication. Identity providers, SSO services, social-login providers, and the MFA service hosts that broker authentication into applications. The category is cross-platform and reaches into mobile shells, desktop applications, productivity tools, and increasingly into AI systems that are allowed to act on their own and that consume identity claims to call other services. Compromise of an identity provider produces direct authentication-bypass and impersonation effects that downstream applications cannot independently verify; the runtime accepts the claim because the protocol said the claim was valid. Account takeover at the operator level, network-path hijack on the auth flow, and insider compromise are the most operationally significant routes.

Payments and Commerce. Payment processors, buy-now-pay-later services, tokenization services, and the embedded checkout components that handle financial-transaction surfaces. The category reaches across browsers, mobile applications, in-store terminal interfaces, and any Client Runtime that integrates a payment surface. Magecart-class skimming operations have repeatedly compromised the payment-component layer; the surface attracts persistent, well-resourced adversary attention. Account takeover, network-path hijack, insider compromise, and cyber exploitation all apply.

Maps and Reference Data. Map-tile providers, geocoding services, weather data services, and the financial market-data feeds that ship reference data into runtime decision logic. The category reaches into browsers, mobile applications, vehicle infotainment systems, navigation surfaces in commercial fleet platforms, and the AR/VR runtimes that consume spatial reference data. Reference data is data-as-code in a particular sense: applications act on the returned values, and adversarial values produce adversarial behavior in the calling application. Account takeover, network-path hijack, and ownership change are the dominant routes.

Email and Messaging. Transactional email services, push-notification gateways, and SMS service providers that ship messaging primitives into application runtimes. The category is cross-platform across browsers, mobile applications, and the desktop and embedded surfaces that integrate notification delivery. The runtime exposure is at the SDK and template-rendering layer; messages can carry rendered HTML, scripts, and attachments that the consuming application processes. Account takeover, insider compromise, and cyber exploitation apply most directly.

Marketing and CRM. Marketing-automation platforms, CRM SDKs, and the customer-data-platform integrations that deliver script-and-API surfaces to applications. The category reaches across browsers, mobile applications, and any Client Runtime that integrates a marketing-automation tag. The risk pattern is wide deployment combined with high update cadence: marketing-automation rules and tag content change frequently and silently. Account takeover and insider compromise are the dominant routes.

AI and ML Services. Foundation-model API providers, vector-database services, embedding-service hosts, model-hub publishers, and the channels that distribute adapters, the small add-on files (LoRA and similar) that adjust how a model behaves, into the code paths that run inference. The category reaches across browsers, mobile applications, desktop shells, productivity tools, and increasingly into local-AI deployments inside the device itself. The category is structurally different from earlier categories because the runtime cannot validate inference output against intent, and the response is data the application acts on. Account takeover at the model-hub level, ownership change of a publisher, network-path hijack on the inference call, and cyber exploitation of the API or the model file all apply, and insider compromise inside the model-hub operator is a sustained concern.

Customer Engagement. Live-chat services, support widgets, scheduling and document-signing tools, and the customer-facing operational surfaces that integrate as iframe and script components. The category is cross-platform and reaches into browsers, mobile applications, productivity tools, and the embedded support surfaces inside enterprise SaaS clients. Customer-engagement components frequently run with elevated trust because the application has procured them as core operational tools. Account takeover, ownership change, and insider compromise are the most applicable routes.

Data Brokers and Profiling Services. Data-broker APIs, profiling services, and the third-party-data integrations that feed personalization and risk-scoring decisions into the application. The category is API-facing rather than script-facing and reaches into browsers, mobile applications, and the back-end-driven surfaces that personalize displayed content. Adversarial data returned by a broker can drive adversarial application behavior at the rendering layer; the runtime sees a routine API response and acts on the values. Network-path hijack, account takeover, and insider compromise are the dominant routes.

Translation and Localization. Localization platforms, translation API services, and the localized-string and locale-bundle distribution channels that ship language-specific content into applications. The category reaches across browsers, mobile applications, desktop shells, and any Client Runtime that loads localized content at runtime. Localization bundles can carry templated content that interprets at runtime, making the category a quieter Data-as-Code surface than scripts but no less consequential when compromised. Account takeover and insider compromise are the most common routes.

Sanctions, Watchlist, and Compliance Data. Sanctions-list providers, watchlist services, and the compliance-data feeds that drive regulatory and risk-control decisions inside applications. The category is API-facing and feeds browsers, mobile applications, and the back-end-driven compliance surfaces inside financial, healthcare, and government systems. Adversarial compliance data has direct downstream effects: a bad sanctions hit creates regulatory exposure; a missed sanctions hit creates regulatory exposure of a different kind. Network-path hijack, account takeover, and insider compromise are the dominant routes.

Tracking and Attribution. Mobile attribution SDKs, affiliate tracking services, and the cross-app and cross-device attribution channels that ship measurement code into mobile applications. The category is primarily mobile but reaches into web-and-mobile hybrid surfaces, and the SDK installation footprint is wide. Attribution SDKs run with broad access to device identifiers, network state, and event data; compromise produces direct privacy and exfiltration consequences. Account takeover, insider compromise, and ownership change are the dominant routes.

Cloud Storage and Asset Hosting. Object-storage services, image-hosting services, video-hosting services, and the asset-distribution surfaces that ship media into runtime pipelines. The category is cross-platform and reaches into browsers, mobile applications, AR/VR runtimes that consume 3D asset packs, and any Client Runtime that loads media or assets from a third-party host. Asset-hosting compromise is operationally distinctive because media can carry executable behavior (PDF JavaScript, USDZ behavior nodes, parseable formats with deserialization paths). Account takeover, network-path hijack, ownership change, and cyber exploitation all apply.

Plugin and Extension Distribution. Browser extension stores, IDE plugin marketplaces, productivity-tool extension stores, and the asset-distribution channels that ship plugin content into host runtimes. The category reaches across browsers, mobile shells with extension surfaces, desktop applications with plugin marketplaces (the Microsoft Store, the JetBrains Plugin Repository, Visual Studio Marketplace, and equivalents), and the productivity-tool extension stores that distribute add-ins. Plugin and extension content runs with elevated trust because the host application has explicitly admitted it. Account takeover, ownership change, insider compromise, and cyber exploitation all apply, and the marketplace itself is an aggregator with its own attack surface.

AI-Generated Content Services. Image-generation services, voice-synthesis providers, content-generation tooling, and the generated-content distribution surfaces that ship synthesized media into applications. The category is cross-platform and reaches into browsers, mobile applications, productivity tools, and any Client Runtime that integrates a content-generation API. The structural concern combines AI service compromise with media compromise: synthesized output is indistinguishable from authentic content at the rendering layer, and adversarial generation produces tailored deception output that the runtime treats as authentic. Account takeover, insider compromise, ownership change, and cyber exploitation all apply across the providers in this category.

6.5: Cross-Provider Patterns

The same aggregation patterns, defendability gaps, attack routes, and dependency dynamics repeat across categories. Eight patterns describe what the categories have in common.

• Aggregation depth as a multiplier: many of the categories above are aggregators: a CDN serving thousands of libraries, a tag manager firing dozens of vendor scripts through one container, a package registry holding millions of packages, an AI-service hub fronting models from many publishers, an asset-hosting service distributing media across thousands of dependent applications. Each of these categories concentrates risk the same way: one operator's failure becomes a failure in every application that depends on it.
• The defendability gap that widens outside the browser: SRI and CSP cover static-script and constrained-URL provider patterns well inside browsers. The gap widens for providers whose business model is delivering different content per request (tag managers, ad exchanges, model endpoints), for manifest-driven providers (web app manifests, OTA update manifests, AI tool manifests), and for AI-service providers whose responses are freshly generated model output rather than a known file with known contents. The gap widens further across non-browser Client Runtimes, where SRI and CSP analogs are largely absent at scale; the same provider serving the same content into mobile WebViews outside their host-browser context, Electron and Tauri shells, vehicle infotainment runtimes, IoT dashboards, productivity-tool extension hosts, AR/VR runtimes, or interactive runtimes that load user-generated content is generally uncovered.
• Insider threat as a dominant compromise pattern: no framework governing these providers requires the controls that would reach it. Vetting for publishing and build roles, access control on supply-chain-critical infrastructure, monitoring of routine insider actions that could mask Adversarial Placement and Access (APA), and threat modeling at the personnel layer are each available, and none is mandated. Whether a given provider has implemented any of them cannot be determined from outside, which is the operative point: a dependent application cannot verify the insider posture of a provider it has never inspected, and holds no mechanism to ask. The provider ecosystem is a high-leverage insider target precisely because so few providers have controls calibrated for the threat, and the leverage compounds where the targeted role sits in a publishing channel that reaches thousands or millions of dependent applications.
• Cyber exploitation and the misattribution layer: many provider compromises are achieved through cyber exploitation of the provider's own infrastructure, code, build pipeline, or dependencies. When the resulting ATG event is attributed to the compromised provider rather than to the underlying adversary, the defensive response lands on the wrong layer. The actual adversary is obscured behind the visible provider name and may continue to operate against the same provider, or against analogous providers, from positions the misattribution did not surface.
• Dependency chains and transitive risk: providers depend on providers, which depend on providers. Provider inventory is necessary but not sufficient; the inventory must reach into the dependencies of the dependencies, transitively, and most provider inventories today do not.
• Which attack routes apply at which provider scale: account takeover dominates at small-to-medium provider scale, where individual maintainer credentials and per-team publishing access are the primary publishing surface. Ownership change is the increasingly observed route at large provider scale, where the entity itself is acquirable and the existing publishing channel has more value than any single credential or piece of infrastructure (the Polyfill.io case is the illustration). Insider compromise and cyber exploitation apply across both ends of the scale. Defensive priorities differ accordingly: small-to-medium providers warrant credential-and-publishing-channel focus, large providers warrant ownership monitoring and corporate-supply-chain awareness.
• AI services as an emerging gap: the AI and ML services category is growing rapidly in deployment, in the diversity of providers, and in the depth of integration into runtime decision logic. Established defendability mechanisms have less coverage here than for traditional script delivery: inference responses are not pinnable hashes, model files are not script sub-resources, prompt and tool definitions are not constrained URLs. Local AI deployments compound the gap by moving the provider boundary inside the device, where the same defendability gap applies and detection is harder than at the network layer.
• The data-endpoint blind spot: many provider categories deliver data rather than code: data brokers, profiling services, sanctions and watchlist feeds, reference data, market data, inference output, localization bundles, identity claims. The Two-Stage Attack architecture exploits exactly these endpoints: the runtime fetches data from a trusted provider, the runtime acts on the values, and adversarial values produce adversarial application behavior at the rendering layer. Information manipulation, the dominant ATG attack mode, is most often delivered through data-endpoint providers rather than code-endpoint providers; the data endpoint is the channel and the runtime acting on the data is the mechanism.

6.6: Defense Across Providers

SRI hash policy works for the static script sub-resources delivered from the Code and Package Delivery category but does not work for the same-URL-different-content delivery pattern that defines tag managers, ad exchanges, and inference endpoints. CSP allowlists work for the constrained-URL pattern but not for runtime-mutable providers whose business model depends on serving different content per request. Certificate pinning narrows network-path hijack but does not narrow account takeover, ownership change, insider compromise, or cyber exploitation. Pinning is weak by default outside the major browsers. Tag-container governance reviews work for the tag-manager category but not for the ad-tech pipeline that runs through it. Extension-marketplace review processes work for plugin distribution but not for the open-source registries that feed every JavaScript runtime. Vendor compliance audits operate on the procurement timeline, not on the publishing-event timeline of an ATG operation.

Three patterns carry across.

• SSoT for runtime resources: the architectural pattern named at the language level applies again at the provider boundary. A reference for what each provider should be delivering, against which actual deliveries are continuously compared, makes content-swap detection a routine rather than an investigation. The implementation differs by provider category (a hash list for static scripts, a behavior baseline for tag containers, a manifest baseline for OTA bundles, a response-shape and value-range baseline for data endpoints, a baseline for how a model's output normally varies), but the primitive is the same: store the truth somewhere that is not the provider, and compare every load against it.
• Content-swap detection at the provider boundary: when the runtime accepts content from a provider, the application has the option to compare what arrived against what was expected. The compare can be implemented at the rendering surface, in the network layer, or at a service that tees provider responses for inspection. The pattern is reusable across provider categories: a script firing inside a tag container, another script loading from a CDN, a model returning an inference, a manifest delivering an OTA update, a font loading from a foundry, an extension updating from a marketplace. The runtime sees the same content the adversary delivered; a defender comparing against an expected baseline sees the deviation.
• Provider inventory, extended transitively: inventory of every provider an application depends on is the defensive prerequisite that most organizations do not currently meet. Knowing the providers is necessary but not sufficient. The Log4j case is the operative argument for going further: organizations were exposed to Log4Shell because the affected library sat several dependency layers below the components they directly depended on, often inside software they had not previously known they were running. Provider inventory must therefore extend into the dependencies of the dependencies, transitively. Most provider inventories today do not. The operational difficulty is significant, and the cost of not meeting it is the exposure surface Log4j made visible. Malice Without Malware lands at the provider boundary. If malicious is no longer defined by the file's authorship or the channel's reputation but by what the runtime is being made to do, then the provider boundary is one of the places that judgment must be made. Provider inventory, ownership monitoring across the inventory, content-swap detection at the boundary, and SSoT for what each provider should be delivering are the architectural patterns that put that judgment into practice at the provider level.

The gap is structural. The code that implements a defense does not carry from one provider category to the next, and the architectural patterns that do carry are not deployed at scale across the Client Runtime landscape. Browser-side coverage is the exception, and it stops at the browser.