Runtime control is the missing layer in modern software supply chains

At a glance

What this is: This analysis says the software supply chain is still being governed too much at build time and too little at runtime, where scripts, AI inputs and browser-side components can alter behaviour or leak data.

Why it matters: For IAM and security teams, the key issue is that runtime controls determine what untrusted code can actually access, which is where browser-side data exposure and delegated access risks materialise.

Context

Runtime software risk is the gap between what security teams believe was approved during build and what actually executes in production. The article argues that modern applications now depend on third-party scripts, AI inputs, containers and orchestration layers that can change behaviour after deployment, which means pre-release controls alone no longer define the real attack surface.

That creates a governance problem for IAM-adjacent teams because browser-side code can read, modify or exfiltrate live data, while delegated access through scripts and integrations often escapes the same scrutiny applied to human access. The runtime question is not whether code was scanned once, but whether it is still constrained when it touches sensitive data and secrets.

Key questions

Q: What breaks when supply chain compromises are only checked at build time?

A: Build-time checks miss malicious code that looks clean until it runs. A compromised package can pass scans, compile successfully, and still spawn unexpected processes, make new network calls, or drop payloads after installation. Runtime behavioral analysis is needed because the abuse often appears only when the trusted component executes in production.

Q: Why do browser-executed third-party scripts create supply chain risk?

A: Because they run inside the user’s session with access to page content, form fields and behavioural signals. That means the script is not just delivered content. It is governed code with real runtime privileges, so compromise can become data theft or session manipulation.

Q: How do teams know whether runtime policy enforcement is actually working?

A: Working enforcement shows up as blocked privileged changes, denied unsafe execution, and reduced lateral movement opportunity in the namespaces that matter most. If findings keep recurring without becoming policies, the programme is only observing drift, not controlling it. A good test is whether repeated posture issues disappear from production because they are denied earlier in the flow.

Q: When should organisations prioritize runtime controls over more scanning?

A: Organisations should prioritize runtime controls when data changes hands frequently, when AI agents or automations touch sensitive content, or when third-party handoffs are common. In those cases, the highest risk is not unscanned storage. It is uncontrolled movement by identities that already have legitimate access.

Technical breakdown

Why build-time controls miss runtime behaviour

Build-time controls such as SAST, SCA and CI/CD hardening examine code before release, but they do not observe what happens after a page loads or a service starts interacting with live data. Runtime components can load other scripts, pull in third-party libraries, call external services, or change their behaviour without any codebase change. That means the trusted state at approval time is not the same as the trusted state in production. In browser contexts, this matters because the page itself becomes the enforcement point, not just the repository or pipeline.

Practical implication: Shift governance from static approval to runtime policy enforcement wherever code can access live data or delegated credentials.

Third-party scripts as a supply chain and identity problem

Third-party scripts are not just an application risk. They are an access problem because they execute with the same browser privileges as first-party code and can inspect DOM content, storage and fields that may contain secrets or personal data. The article’s point about piggyback tags shows how one trusted script can silently expand the trust chain by loading additional code. That makes the browser a delegated execution environment where inventory alone is insufficient, because authority changes after the page is rendered.

Practical implication: Apply least-privilege rules to browser-side scripts and restrict access to specific fields, storage and actions.

AI inputs and runtime data leakage

The article extends runtime control into AI by warning that page content can be scraped into external models unless sensitive context is constrained upstream. In practice, this is an identity and data governance issue because the system deciding what to transmit is acting on behalf of the user or application without always inheriting the same policy boundaries. Once data leaves the browser or front end, it can no longer be governed as tightly as in-session access. The control point therefore shifts to the moment of collection and transmission, not after disclosure.

Practical implication: Filter sensitive content before AI tools or agents can ingest page data, prompts or contextual fields.

Threat narrative

Attacker objective: The objective is to exfiltrate sensitive browser-side data or alter application behaviour from within trusted runtime execution.

1. Entry begins when third-party scripts, browser widgets, AI-created code or runtime modules are loaded into a live application after build-time inspection has already passed.
2. Credential or data access occurs when those components can read form inputs, browser storage or DOM content, including passwords, payment details or contextual page data.
3. Escalation happens when trusted scripts load additional tags or change behaviour at runtime, broadening access beyond the original approval boundary.
4. Impact is data leakage, behavioural manipulation or hidden supply chain compromise that persists until runtime enforcement detects and blocks the action.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime enforcement is now a supply chain control, not an application add-on. The article’s central point is that pre-deployment tooling cannot govern code once it is live in the browser or execution environment. That means the relevant control boundary has moved to the point where data is assembled and consumed, which is also where identity, session and script authority become operationally real. Practitioners should treat runtime policy as part of supply chain governance, not as a separate web security concern.

Browser-side execution creates a delegated trust problem that conventional inventories cannot solve. A script inventory can tell you what is present, but not whether a trusted component has begun reading payment fields, loading piggyback tags or exfiltrating DOM data. This is the same governance failure pattern seen in other identity-heavy environments: once delegation exists, oversight must follow the delegated action, not the nominal owner. The practical conclusion is that access scope must be enforced continuously, not merely approved.

AI inputs widen the runtime governance boundary into data handling and prompt exposure. The article correctly treats AI-created code and AI-connected inputs as supply chain concerns because they can introduce new attack surfaces after approval. Where AI tools scrape page content or contextual data, the security issue is not only model risk but the unauthorised transfer of sensitive runtime information. This is where identity, data security and software supply chain governance intersect, and teams should govern that intersection explicitly.

Continuous evidence changes the control objective from trust to proof. The strongest governance shift in the article is its demand for audit-ready telemetry that demonstrates policy enforcement during live sessions. That matters because questionnaires and static attestations do not prove that a script was blocked from a form field or that an AI input was filtered before transmission. Security teams should value runtime evidence as the real control outcome.

Runtime control gap: this is the failure mode the article exposes, where approved code still behaves unsafely after deployment because enforcement stops at build time. The gap is structural, not procedural. Practitioner response should focus on constraining live actions rather than endlessly expanding pre-release review.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: CI/CD Pipeline Identity Security Guide

What this signals

Runtime control is becoming the missing enforcement layer in software supply chain governance. For practitioners, the key change is that approval alone no longer proves safety once code executes in the browser or loads downstream components. Teams that govern only build artefacts will continue to miss the live-session point where sensitive data, scripts and delegated actions intersect.

Identity and access governance now extends into the page itself. When a script can access form inputs, storage or contextual data, it is effectively operating under a delegated runtime identity that deserves explicit scope control. That is why browser-side least privilege and runtime audit evidence belong in the same control conversation as secrets, access reviews and supply chain assurance.

For practitioners

• Implement runtime policy at the browser edge Constrain scripts at the point of data entry so they can only access approved fields, cookies or storage locations during the live session.
• Restrict third-party script privileges Move from inventory-only tracking to granular execution rules that limit what each script can read, load or exfiltrate once the page is rendered.
• Filter AI-bound context before transmission Prevent sensitive or proprietary data from being scraped into external AI models by controlling the contextual information available to the agent or integration.
• Monitor for behavioural drift in trusted components Block any runtime change where an approved analytics, tag management or helper component starts touching payment, authentication or other sensitive workflows.
• Replace static evidence with live enforcement telemetry Generate audit-ready proof that runtime controls were active during each session rather than relying on questionnaires or build-time scan results.

Key takeaways

• The article argues that software supply chain governance fails when it stops at build time, because live code can still change behaviour and leak data after deployment.
• Runtime risks are especially important in browser contexts, where third-party scripts and AI inputs can access sensitive page data without the same scrutiny as first-party code.
• The practical control shift is toward continuous enforcement, narrow runtime privilege and evidence that proves policies held during live sessions.

Key terms

• Runtime Enforcement: Runtime enforcement is the practice of blocking malicious behaviour while software is running, rather than only detecting it after the fact. It monitors process activity, network actions, and privilege changes so a live attack can be interrupted at the point of execution.
• Shadow Code: Shadow Code is the set of third-party scripts, libraries, and browser-loaded components that operate inside production but outside normal development oversight. These components may be approved in principle yet still create hidden access paths once they execute with real user data.
• Behavioural Drift: Behavioural drift is the gradual change in what an identity does compared with what it was originally approved to do. For AI agents, drift can come from prompt changes, model updates, expanded integrations, or altered workflows, which makes access review alone an incomplete control.
• Delegated runtime privilege: Delegated runtime privilege is access granted to a non-human actor to perform actions on behalf of an organisation during live execution. For AI agents, the risk is not the permission itself but the combination of breadth, timing, and lack of external control over how that access is used.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners connect identity controls to the broader security programmes that runtime risk now depends on.