They often assume a blocked domain or flagged URL is enough to stop the campaign. In practice, AI-assisted attackers can change those indicators quickly while reusing the same technique. That means IOC-only defence leaves the underlying behaviour untouched and repeatedly relearned.
Why Security Teams Misread IOC-Based Browser Defence
IOC-based browser defence is useful for spotting known bad domains, hashes, and URLs, but it only addresses the observable marker, not the attacker’s method. That gap matters because modern browser abuse often relies on fast-changing infrastructure, redirects, and payload delivery chains that can be swapped out without changing the underlying campaign. NIST’s NIST Cybersecurity Framework 2.0 still points teams toward detection and response outcomes, but those outcomes depend on recognising behaviour, not just cataloguing indicators.
For browser defence, the common mistake is treating a blocklist as a control plane. In reality, defenders need visibility into how the browser is being used, what it is allowed to execute, and which identity or session is driving the activity. That is especially important where NHIs, automation, and browser-based workflows intersect, because the same action can be replayed through new infrastructure in minutes. NHI Management Group’s Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a reminder that identity and session control often matter more than static IOCs. In practice, many security teams encounter browser abuse only after the campaign has already rotated indicators and moved to the next delivery path.
How Behaviour-Focused Browser Defence Works
Effective browser defence starts by shifting from “what URL was seen” to “what action is being attempted.” That means pairing IOC feeds with controls that can evaluate runtime context, such as destination reputation, script behaviour, session risk, and whether the browser action matches expected user or workload intent. This aligns with the current direction of the NIST Cybersecurity Framework 2.0, which emphasises continuous improvement rather than one-time signatures.
For browser-centric attacks, teams usually get better results when they combine several layers:
- reputation blocking for known malicious infrastructure
- navigation and download controls for high-risk file types and redirect chains
- browser isolation or sandboxing for untrusted sessions
- policy checks based on identity, device posture, and session purpose
- detection of anomalous behaviour such as rapid tab spawning, unusual form submission, or tool-driven automation
This is where NHI visibility becomes important. If a browser session is tied to an API key, automation account, or delegated service identity, then static IOCs may miss the actual execution path. The Ultimate Guide to NHIs also reports that 71% of NHIs are not rotated within recommended time frames, which increases the window in which a repeatedly used browser-based tactic can keep working even after an IOC is blocked. Teams should therefore tune detections around repeated behaviour, not just repeated indicators. These controls tend to break down in highly dynamic SaaS environments because redirects, embedded content, and automation traffic can blur legitimate and malicious browser activity.
Where IOC-Only Thinking Breaks Down
Tighter browser filtering often increases operational overhead, so organisations have to balance user friction against reduction in repeatable attack paths. That tradeoff becomes sharper when business workflows depend on dynamic content, third-party SaaS, or user-driven exception handling. Best practice is evolving, but there is no universal standard for relying on IOCs alone because indicator freshness is too short-lived for many modern campaigns.
Two edge cases come up often. First, security teams may block the initial malicious domain while missing the same campaign delivered through new infrastructure, URL shorteners, or compromised trusted sites. Second, browser defence can look strong on paper while automation or delegated access keeps the underlying behaviour intact. In those environments, current guidance suggests focusing on session governance, deny-by-default for risky actions, and faster revocation of credentials or tokens associated with suspicious browser activity. If the team cannot see which identity initiated the browser action, IOC-based defence will remain partial rather than preventive.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A03 | IOC-only defence fails when autonomous browser actions change faster than indicators. |
| CSA MAESTRO | GOV-1 | Governance must cover dynamic browser behaviour, not just known malicious indicators. |
| NIST AI RMF | Risk management must address changing attacker behaviour beyond fixed IOCs. |
Use AI RMF to assess evolving browser abuse patterns and update controls based on observed behaviour.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
