Runtime control is the missing layer in modern software supply chains

At a glance

What this is: This article argues that software supply chain risk now extends into runtime, where scripts, browser data, and AI inputs can create exposure after deployment.

Why it matters: For IAM, NHI, and broader security programmes, the key issue is that access and data handling controls must work at the point of use, not only during build and release.

By the numbers:

• 97% of AI projects contain vulnerable dependencies, highlighting how quickly AI supply chains inherit upstream weakness.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.

👉 Read Jscrambler's analysis of runtime risk in modern software supply chains

Context

Runtime risk is what remains after code has passed design and build controls but still executes with access to live data, browser state, and downstream services. That matters because modern applications now load third-party scripts, browser extensions, AI components, and service integrations that can behave differently once the page or workload is live. For identity and access teams, this is where runtime permissions, delegated trust, and data handling boundaries become operational rather than theoretical.

The article also shows why software supply chain governance is no longer only a code provenance issue. When browser-delivered components can read form inputs, load extra scripts, or transmit contextual data to external AI systems, the real control problem becomes what is allowed to execute and what it can access in-session. That is a direct governance issue for IAM-adjacent programmes, especially where secrets, session data, and human identity workflows overlap with NHI and AI-mediated access.

Key questions

Q: What breaks when browser execution is not governed at runtime?

A: Security teams lose control over what trusted scripts do with sensitive data. That gap allows over-collection, silent context expansion, and exfiltration from within apparently legitimate sessions, which means post-deployment approvals do not guarantee safe behaviour during actual customer interactions.

Q: Why do third-party scripts create more risk than static dependency lists suggest?

A: Static lists show what was approved, not what a script can do after it loads. Third-party scripts can access DOM content, browser storage, and form fields, and they can also load piggyback tags or additional code. That means the true risk is delegated runtime access, not the package name alone.

Q: How do security teams know if runtime protection is actually working?

A: Look for evidence that suspicious behaviour is detected fast enough to contain it before the session or workload expands the blast radius. Effective runtime protection produces actionable alerts, ties them to containment steps, and shows that abnormal access can be limited during active execution, not only reviewed afterward.

Q: Who is accountable when an AI browser exposes sensitive data or makes a bad decision?

A: The organisation remains accountable for the access path it allowed. Security, IAM, and data-governance teams should jointly define approval boundaries, logging requirements, and content restrictions before deployment. If the browser can act across regulated systems, then its governance must be explicit before use, not after failure.

Technical breakdown

Why runtime risk escapes pre-deployment controls

Runtime risk emerges because many security tools inspect code before release, while the actual behaviour of a page, container, or service mesh plugin only becomes visible once it is executing with real users and real data. A script can be benign at review time and still change behaviour later, load additional dependencies, or exfiltrate data from the DOM. That gap is structural: static analysis, dependency scanning, and CI checks reduce known issues, but they do not govern live execution paths.

Practical implication: security teams need controls that observe and constrain live execution, not just build artefacts.

How third-party scripts create hidden data exposure

Third-party scripts are risky because they are trusted to run inside the page while remaining controlled by another party. Once loaded, they can read browser storage, form fields, and page content, and they can also cascade by loading additional scripts through piggyback tags. That makes the browser a high-trust execution environment where data leakage can happen without any code change in the first-party application. The technical problem is not only visibility, but delegated behaviour that extends beyond the original approval boundary.

Practical implication: teams should treat externally sourced browser code as a live access surface with explicit data-access limits.

Why AI inputs and browser state need upstream governance

AI-related runtime risk appears when agents, plug-ins, or page-connected workflows can scrape contextual data before it is sent to an external model or service. If the input stream includes secrets, personal data, or operational context, the model ecosystem inherits the exposure even when the core application code is unchanged. This is why runtime governance for AI cannot stop at prompt filtering or model policy alone. It has to control what the surrounding system can collect, assemble, and transmit in the first place.

Practical implication: establish upstream data filters and session-scoped restrictions before AI-connected components can observe sensitive content.

Threat narrative

Attacker objective: The attacker wants to turn trusted runtime code into a data-exfiltration or workflow-manipulation channel inside live sessions.

1. Entry occurs when a trusted third-party script, browser component, or runtime plugin is loaded into production without continuous behavioural inspection.
2. Escalation happens when the component uses its in-page privileges to read form fields, browser storage, DOM content, or other live session data beyond the original security review.
3. Impact follows when the component exfiltrates sensitive data, loads additional code, or manipulates business workflows without the user or security team seeing a policy violation in time.

NHI Mgmt Group analysis

Runtime control has become the missing governance layer in software supply chains. Pre-release assurance no longer covers the full attack surface because browser code, orchestration layers, and AI-connected components keep executing after deployment. That changes the control objective from checking what was shipped to constraining what is allowed to happen in-session. Practitioners should treat runtime policy as part of supply chain governance, not a separate optimisation.

Browser execution now behaves like a delegated identity surface. A third-party script or AI-connected component may not be a human user, but it can still read data, load additional resources, and influence downstream actions. That is an identity and access problem as much as an application security problem because trust is being extended to software entities that operate with practical privileges inside the session. The relevant control question is who or what is allowed to see and move data once the page loads.

Shadow Code: the hidden runtime dependency layer is now a distinct governance concept. Shadow Code is the collection of scripts, libraries, and browser-loaded components that appear harmless during review but acquire meaningful access once executed in production. This creates policy drift between approved software and live behaviour, which is exactly where traditional inventory-based controls lose effectiveness. Security teams should map this as a runtime trust boundary and require explicit enforcement for every component that can observe user data.

AI input governance must move upstream of model calls. If external AI systems can scrape page context before a policy decision is made, the organisation has already lost control of the data boundary. That means AI governance, secrets protection, and privacy controls need to operate at collection time, not just at transmission or storage time. Practitioners should align this with NIST AI RMF GOVERN and data handling controls in NIST SP 800-53.

Continuous evidence is becoming the new standard for runtime assurance. Manual questionnaires cannot prove that a script was blocked from a payment field or that a browser component was prevented from reading a secret. Real-time telemetry and audit-ready enforcement records are becoming necessary to demonstrate control effectiveness. Security leaders should expect runtime evidence to inform both incident response and supplier governance.

What this signals

Runtime risk shifts the practitioner question from whether code was reviewed to whether the live session is being governed continuously. That matters for identity and access teams because many of the same weaknesses that affect secret sprawl also show up in browser state, delegated trust, and AI-connected data flows. The control model should be judged by what it blocks in production, not by what it approved during build.

Shadow Code: the useful analytical concept here is the hidden layer of third-party browser execution that behaves like an unmanaged access path. Once teams recognise scripts and runtime plug-ins as active trust dependencies, they can align browser controls with NIST Cybersecurity Framework 2.0 and OWASP Non-Human Identity Top 10 thinking. The programme implication is that runtime telemetry and policy enforcement need to sit alongside IAM, not outside it.

For practitioners

• Enforce runtime policy at the browser boundary Define what each script, widget, or plugin may read or transmit in live sessions, with explicit restrictions on form fields, cookies, local storage, and DOM content. Use policy enforcement that blocks disallowed access when execution begins, not after a review cycle.
• Classify third-party scripts as live trust dependencies Inventory every externally sourced browser component that can modify the page or load additional code, then assign an owner and review cadence. Remove any component that cannot be tied to a business need and a specific data-access boundary.
• Restrict AI-connected components to approved context Filter sensitive content before browser-connected AI tools, plug-ins, or assistants can assemble prompts or scrape page state. The control objective is to prevent secrets, personal data, and internal workflow details from entering external model paths.
• Require real-time drift detection for trusted runtime components Monitor high-trust scripts for behaviour changes such as new field access, new outbound destinations, or unexpected library loading. Block the action immediately if the component starts acting outside its approved runtime profile.
• Replace vendor questionnaires with enforcement evidence Collect session-level telemetry that shows what was accessed, what was blocked, and which policies fired during live use. Use that evidence in supplier assurance reviews so governance is based on observed behaviour rather than declarations.

Key takeaways

• Runtime risk is not a build-time problem, because live scripts and AI-connected components can still expose data after deployment.
• The scale of the issue is visible in secret leakage and delayed remediation, which leaves exposure open long after detection.
• Security teams need continuous runtime enforcement and audit evidence if they want to govern browser data, third-party code, and AI inputs effectively.

Key terms

• Runtime Risk Dashboard: A runtime risk dashboard translates live workload activity, vulnerabilities, and enforcement outcomes into operational exposure metrics. It is more useful than static posture reporting because it reflects what is actually happening in production, not just what has been discovered in inventory scans.
• 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.
• 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.
• 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.

What's in the full article

Jscrambler's full article covers the operational detail this post intentionally leaves for the source:

• Specific examples of how browser-loaded scripts can leak form inputs, session data, and DOM content in live sessions.
• The runtime enforcement mechanics behind least-privilege execution for scripts, widgets, and AI-connected components.
• How continuous evidence is generated to prove that policies were enforced during production use.
• The operational checklist for detecting behavioural drift without breaking page functionality.

👉 Jscrambler's full article covers runtime enforcement, data leakage paths, and control gaps in browser execution.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives security practitioners a practical way to connect runtime trust decisions to identity governance across modern environments.