TL;DR: Programmable onchain compliance is moving from static reporting to real-time enforcement, with Predicate now able to block transactions against continuously updated signals on stolen funds, active exploits and malicious smart contracts before execution, according to Blockaid. The control problem is not policy design alone but whether risk data can outrun laundering and transaction speed.
At a glance
What this is: This is a partnership analysis of programmable onchain compliance, where Predicate can use Blockaid’s real-time risk exposure data to stop high-risk transactions before execution.
Why it matters: It matters because compliance controls in onchain finance fail if address risk is assessed on a batch cadence, which is directly relevant to governance over transaction approval, sanctions screening, and exposure management.
By the numbers:
- Since 2025, Blockaid scanned over 6.3 billion transactions and blocked 585 million attacks.
Context
Onchain compliance only works when the risk signal arrives before the transaction settles. Static lists and batch-refresh workflows are useful for sanctions and known-entity screening, but they are poorly matched to exploit-driven laundering, where the risky address may only exist for minutes.
The article argues that the governance gap is temporal as much as it is technical: controls often know who is bad, but not fast enough to catch when funds become bad in motion. That makes real-time enforcement a compliance design problem, not just a monitoring problem.
Key questions
Q: What breaks when onchain compliance relies on batch-refreshed risk data?
A: Batch-refreshed data breaks when the threat appears and disappears inside the refresh window. In exploit-driven laundering, the address can be high risk before the next update arrives, so the policy engine may approve a transaction that should have been blocked. The failure is temporal: controls know the category, but not in time to act.
Q: Why do live exploit signals matter more than static blacklists for onchain transactions?
A: Static blacklists are useful for durable risk, such as known sanctioned actors, but they are weak against incident-driven abuse because the risky address may only become visible when the exploit starts. Live exploit signals let policy act on current behaviour rather than yesterday’s classification, which reduces the chance of approving active laundering paths.
Q: How can teams tell whether policy enforcement is actually working?
A: The clearest signal is whether policy checks, remediation actions, and exceptions are captured in one audit trail that matches what is happening across identities and applications. If teams cannot trace a deviation from detection to resolution, enforcement is fragmented. Working governance should produce evidence continuously, not only at audit time.
Q: What is the difference between sanctions screening and exploit-linked risk screening?
A: Sanctions screening evaluates durable status that changes relatively slowly and can be maintained on a scheduled cadence. Exploit-linked screening evaluates incident-driven exposure that can emerge and propagate within minutes, so it depends on live telemetry and inline enforcement rather than periodic list refreshes.
Technical breakdown
Why batch-refreshed risk data lags exploit-driven laundering
Batch-refreshed risk intelligence works when the threat is stable, such as a sanctions designation or a known actor list. It breaks down when the attack signal is created by the exploit itself, because the risky address, wallet cluster, or draining path may not exist in the policy data until the incident is already underway. That creates a timing gap between detection and policy evaluation. In onchain environments, attackers can chain swaps, bridges, and mixers quickly enough that delayed enrichment produces false confidence. The technical issue is not only detection quality but propagation latency from signal generation into the policy engine. See the Exposure Management and CTEM Guide.
Practical implication: Design policy decisions around signal freshness, not just signal content.
How real-time policy engines change transaction control
A real-time policy engine evaluates an address against live risk signals at the moment a transaction is about to execute, rather than waiting for a scheduled refresh. In this model, the policy does not merely log exposure after the fact. It can return a verdict and block or allow the transaction inline. That matters for multi-step workflows where the exposure category, value at risk, and affected address can change between initiation and final signing. The control surface becomes the transaction itself, which is where enforcement belongs if the threat moves faster than reporting cycles. Read Top 10 Data Security Risks.
Practical implication: Move from after-the-fact review to inline enforcement at execution time.
Why custody and DeFi exposure need continuous monitoring
Custody and DeFi positions introduce a different control problem because exposure is not always attached to a single transfer. Liquidity pools, token positions, and associated counterparties can become risky as ecosystem conditions change around them. Continuous monitoring is therefore a posture problem, not only a transaction problem. If the surrounding pool becomes toxic, a previously acceptable position can turn into a governance issue without any new user action. That is why the article treats real-time signals as relevant across inflows, outflows, and custody. The underlying mechanism is continuous re-evaluation of risk state, not one-time screening.
Practical implication: Continuously reassess positions that can become risky without a new transaction.
Threat narrative
Attacker objective: The objective is to move stolen value through onchain infrastructure before compliance controls can recognise the address as risky.
- Entry occurs when funds linked to an active exploit enter the screening path before batch-refreshed risk data has updated.
- Escalation happens as the attacker moves value through swaps, bridges, and mixers faster than the compliance policy can refresh its view.
- Impact is a transaction that clears on a stale signal, allowing laundering or exposure transfer that the policy was meant to stop.
Breaches seen in the wild
- Gravity SMTP CVE-2026-4020 API Keys Exposure: CVE-2026-4020 in Gravity SMTP exposes API keys via single HTTP request across 100,000 WordPress sites.
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
Real-time enforcement is now a governance requirement, not an optimisation. The article shows that static policy logic is no longer enough when the underlying risk signal can change in the same minute as the transaction. Compliance teams need to think about freshness, propagation, and execution latency as part of control design. That makes policy infrastructure an operational control plane, not a reporting layer.
The decisive failure mode is stale risk state. The problem is not that sanctions, entity attribution, or compliance rules are invalid. The problem is that exploit-linked addresses become relevant only at incident speed, while many policy stacks still assume a slower data lifecycle. Exposure management is therefore as much about signal timeliness as it is about coverage.
Onchain compliance is converging with security operations. When a policy engine consumes exploit signals, wallet risk, and malicious smart-contract telemetry in real time, the boundary between compliance enforcement and threat response narrows. That has direct implications for governance ownership, because the team responsible for compliance decisions now depends on the same live intelligence used for security response.
Continuous risk evaluation is the new control concept for onchain finance. The article points to a shift from screening known bad actors toward evaluating moving exposure states across addresses, contracts, and liquidity pools. That is a stronger model for regulated markets, but it also raises the bar for evidence, latency tracking, and exception handling. Practitioners should treat risk freshness as a control objective.
From our research library:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- Read next: Exposure Management and CTEM Guide
What this signals
Signal freshness is becoming a control objective. Onchain teams should stop treating enrichment delay as a backend issue and start measuring it as part of compliance effectiveness. A policy that cannot consume live exploit signals quickly enough is not a complete control, even if its rules are correct.
Continuous exposure evaluation will matter more than static approval lists. The governance model is shifting toward checking whether an address, pool, or transaction path is risky at the moment of execution, not whether it was once approved. That is a better fit for onchain finance, where conditions mutate faster than review cycles.
Developer behaviour still shapes control quality: Only 44% of developers are reported to follow security best practices for secrets management, according to the State of Secrets in AppSec. In adjacent onchain systems, the same operational gap shows up as stale policy inputs, weak change discipline, and delayed enforcement.
For practitioners
- Define freshness thresholds for onchain risk data Set maximum acceptable delay between exploit detection and policy enforcement, then test whether your current screening stack meets it during active incident windows.
- Enforce inline transaction blocking for high-risk addresses Require the policy engine to evaluate the gaining address before execution, not after settlement or batch review.
- Separate stable screening data from incident-driven signals Treat sanctions and known-entity data as durable inputs, but route exploit-linked addresses and drainers through a live signal path with no batch delay.
- Monitor custody and liquidity positions continuously Re-check pools, token positions, and counterparties as conditions change, because exposure can rise without any new transfer from the user.
Key takeaways
- Onchain compliance fails when the policy engine sees risk later than the blockchain sees movement.
- The article’s core evidence is that stolen funds and exploit-linked addresses can move through swaps, bridges, and mixers within minutes.
- Practitioners should treat signal freshness, inline blocking, and continuous exposure monitoring as control requirements, not optional enhancements.
Related NHI Mgmt Group resources: Exposure Management and CTEM Guide · Top 10 Data Security Risks · Gravity SMTP CVE-2026-4020 API Keys Exposure
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | The article centres on policy and signal integration across transaction surfaces, where misconfiguration can leave stale enforcement gaps. |
| Recommendation — Validate policy integrations and request paths so live risk signals cannot be bypassed by stale or misrouted enforcement logic. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Transaction allowance is an authorization decision, and the article focuses on deciding when a transaction should be denied. |
| Recommendation — Apply authorization controls at transaction time so high-risk addresses are denied before execution. | ||
| CIS Controls v8 | CIS-5 — Account Management | Address screening and policy enforcement depend on accurate identity and exposure governance over accounts and counterparties. |
| Recommendation — Maintain current account and address inventories so compliance decisions are made against up-to-date exposure data. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The article describes exploit-linked laundering paths that follow incident exploitation and value movement. |
| Recommendation — Map exploit-to-laundering activity to credential access and exfiltration patterns in detection and response workflows. | ||
Key terms
- Real-Time Risk Exposure: A live risk state that updates as new exploit, theft, or malicious-address signals appear. In onchain compliance, it is the difference between screening an address once and evaluating whether that address is risky at the exact moment a transaction is about to execute.
- Batch-Refresh Cadence: A scheduled update cycle for compliance or intelligence data. It is efficient for stable facts such as sanctions lists, but it is poorly suited to fast-moving exploit activity because the policy layer can lag behind the attacker’s movement.
- Inline Transaction Enforcement: A control pattern that evaluates and can block a transaction before it executes. In regulated onchain workflows, this shifts compliance from after-the-fact review to decision-time enforcement, where the risk signal must be current enough to matter.
- Exposure freshness: Exposure freshness is the amount of time a security finding remains representative of the live environment. When systems change frequently, freshness drops fast, which means the gap between testing and remediation becomes a direct risk factor.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org