Runtime interception is the ability of injected code to observe, alter or redirect application behaviour while the program is running. In browser and hybrid app contexts, that can mean modifying network requests, changing transaction details or capturing secrets without visibly breaking the user experience.
Expanded Definition
Runtime interception is a post-deployment control point where injected code hooks application execution and inspects or alters behaviour while the program is live. In NHI security, it often sits inside browser extensions, mobile wrappers, automated agents, or instrumentation libraries that can see requests, responses, tokens, and UI state.
The term is used more broadly than classic debugging or observability, because the interceptor may change control flow, suppress checks, rewrite payloads, or capture secrets without breaking the user experience. That makes it adjacent to tampering, code injection, and man-in-the-app techniques, but not identical to them. Definitions vary across vendors, especially when products blur monitoring, policy enforcement, and active manipulation.
For governance, the key question is not whether interception exists, but whether the injected code has authority over secrets, network calls, and business actions. The most common misapplication is treating runtime interception as harmless instrumentation, which occurs when teams ignore that the same hook capable of logging requests can also redirect transactions or exfiltrate credentials.
For broader control framing, NIST Cybersecurity Framework 2.0 helps organisations map runtime interception risk to access, monitoring, and recovery outcomes, while NIST Cybersecurity Framework 2.0 provides a practical reference point for governance alignment.
Examples and Use Cases
Implementing runtime interception rigorously often introduces trust and performance overhead, requiring organisations to weigh faster inspection and policy enforcement against the risk of expanding the application’s attack surface.
- A browser extension intercepts API calls, rewrites a checkout amount, and sends the altered request while the page still appears normal to the user.
- A hybrid mobile app wrapper captures session tokens from in-memory requests, enabling an attacker to reuse the NHI path without touching the backend directly.
- An injected agent logs outbound secrets and certificate material for debugging, but the same hook can be repurposed to siphon API keys from runtime memory.
- A security control blocks unsafe domains by intercepting requests at runtime, but improper scoping can also suppress legitimate authentication redirects and break SSO flows.
- In an incident response case, investigators trace a compromised service workflow back to injected code similar to the techniques discussed in ASP.NET machine keys RCE attack and Gladinet Hard-Coded Keys RCE Exploitation, where runtime abuse turned latent access into active compromise.
Because runtime interception can be used defensively or offensively, practitioners should pair it with signed code, strict scope limits, and telemetry that can detect unexpected hooks.
Why It Matters in NHI Security
Runtime interception matters because NHI compromise often happens at the moment secrets are used, not when they are stored. Once injected code can observe traffic or alter execution, service accounts, API keys, and session tokens become exposed through the application’s own trust boundary. That is especially dangerous in browser-based and agentic workflows where the identity is non-human, the activity is machine-speed, and detection windows are short.
NHIMG research shows that 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, which illustrates how interception turns a transient runtime weakness into business impact. The risk is amplified when organisations already have weak visibility into service accounts or keep long-lived credentials in code and configuration. In that environment, runtime interception can quietly convert an otherwise valid NHI into an attacker-controlled execution path.
Security teams should treat interception as an identity event as much as an application event, because it can change what an NHI is allowed to do in practice. NIST Cybersecurity Framework 2.0 is useful here for tying detection and response to asset and identity governance, while the underlying NHI exposure patterns are well documented in the Ultimate Guide to NHIs. Organisations typically encounter the operational cost of runtime interception only after a token theft, request tampering, or fraud event, at which point the term becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Runtime interception often exposes or manipulates NHI secrets in application memory. |
| OWASP Agentic AI Top 10 | A-07 | Agentic workflows can be redirected by runtime hooks that change tool calls or outputs. |
| NIST CSF 2.0 | PR.AA-01 | Identity assurance and access control are weakened when runtime code can alter authenticated actions. |
Treat runtime interception as an identity integrity risk and enforce stronger action validation.
