TL;DR: Web3 changes theft prevention because attackers can study public networks, exploit composable infrastructure, and extract value in minutes rather than weeks, while cyber, fraud, and compliance risks now converge in a single transaction flow, according to Blockaid. Real-time prevention, not reactive response, becomes the baseline when ownership is direct and intermediaries disappear.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Blockaid's blog post: Onchain security needs real-time prevention because public networks, composable infrastructure, and fast-moving value flows compress attacker timelines.
Why it matters: It matters to IAM and security teams because onchain environments collapse the distance between reconnaissance, misuse, and loss, which changes how trust, monitoring, and control boundaries must be designed.
Context
Onchain security is the governance problem of protecting value when ownership, transfer, and execution happen without traditional intermediaries. In that model, the usual assumptions behind perimeter controls, delayed review, and post-incident recovery stop holding, especially when adversaries can observe activity publicly before they strike.
Web 3 changes the security equation by combining transparent infrastructure with direct asset ownership and rapid settlement. That creates a new kind of access problem: not just who can authenticate, but who can see, influence, or exploit transactions before value moves.
The article's starting position is typical for the space in that it treats speed, transparency, and composability as structural risks rather than isolated weaknesses.
Key questions
Q: How should teams prevent onchain losses when transactions settle too fast for manual review?
A: Teams should move controls to the point of action. That means simulating transactions, validating approvals, and enforcing policy before signing or wallet connection, because once value is broadcast the response window is often too small to matter. Real-time prevention matters more than after-the-fact investigation in onchain environments.
Q: Why do public blockchain networks increase security risk even when the code is open and auditable?
A: Public visibility gives attackers free reconnaissance. They can study balances, contract behaviour, wallet patterns, and timing without breaching a private environment, which shortens planning cycles and improves targeting. Open code is useful for review, but it also gives adversaries a stable surface to analyse and manipulate.
A: The main sign is fragmented ownership. If exploit response, sanctions screening, wallet security, and fraud operations sit in different queues with different metrics, attackers can move across them faster than the organisation can correlate the event. A unified transaction-risk view is the stronger operating model.
Q: How do security, fraud, and compliance teams share accountability for onchain transactions?
A: They need a common control objective: stop unsafe value movement before it happens. Security owns technical enforcement, fraud owns behavioural and social indicators, and compliance owns illicit flow and sanctions exposure, but the programme fails if those responsibilities are not joined at the transaction layer.
Technical breakdown
Why public blockchains expand attacker reconnaissance
Public blockchains expose transactions, balances, and contract activity to anyone who can inspect the ledger. That turns reconnaissance into a low-friction exercise, because attackers do not need to breach a private network to identify high-value targets or study behavioural patterns. In practice, the security problem is less about hiding data and more about reducing what an attacker can infer from visible state. This also changes fraud planning, because wallet movement, contract interaction, and timing patterns can all be profiled before exploitation. The result is a threat model where observation itself becomes part of the attack path.
Practical implication: Treat publicly observable transaction patterns as attack surface and design detection around pre-execution risk signals.
How composable infrastructure creates chained exposure
Blockchain systems rely on open-source code, smart contracts, wallets, bridges, and other dependencies that can each become a manipulation point. Because the stack is composable and frequently upgradeable, every dependency can amplify risk across the full transaction path. A weakness in one component is rarely isolated, because downstream contracts, integrations, and wallets may all inherit the same exposure. This is why immutable code is not the same as secure code: deployment freezes logic, but it does not freeze adversarial discovery. The security model has to assume that every connected component can be tested, abused, and chained into a broader exploit path.
Practical implication: Map transaction-critical dependencies and test them as a chain, not as separate components.
Why minutes-to-loss changes the control model
Traditional financial crime controls often assume there is enough time to detect, investigate, and block suspicious activity after an event begins. Onchain environments compress that window to seconds or minutes, which means reactive controls arrive too late to matter. This is the core operational difference: value can move, be laundered, and disappear before a human review cycle starts. That demands controls that intervene before signing, before broadcast, or at the point of wallet connection. In governance terms, the control point shifts left into the transaction lifecycle itself, where decisions are still reversible. Read Zero Trust for AI Agents.
Practical implication: Move enforcement to pre-signing and pre-connection checkpoints rather than relying on after-the-fact review.
Threat narrative
Attacker objective: The attacker seeks to extract and move digital assets before defenders can reverse or meaningfully contain the transaction.
- Entry begins with public reconnaissance against wallets, contracts, dApps, or social channels that expose target patterns and trust cues.
- Credential or transaction authority is then abused through malicious contracts, compromised front ends, or fraudulent prompts that lead a user to sign unsafe actions.
- Impact follows quickly as funds are moved, drained, or laundered before traditional monitoring or investigation can intervene.
Breaches seen in the wild
- Meta Muse agent hijack 2026: An undocumented Muse setting let local malware hijack Meta's personal AI agent, steal its authentication material and abuse user access.
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
Onchain security is really identity governance under extreme time pressure: the control problem is no longer just asset protection, but deciding what principals can act, sign, or delegate before value leaves the system. When the principal is a wallet, a smart contract, or a multisig signer, the governance model has to account for machine-speed execution and public observability. That makes service account security a useful analogue, because both domains depend on scoped authority, lifecycle control, and revocation discipline. Practitioners should treat onchain permissions as governed identities, not just cryptographic objects.
Transaction observability is now a security primitive: the article shows that detection quality depends on how well teams can correlate onchain, offchain, behavioural, and social signals. That is a broader shift in security architecture, because the strongest signal may emerge before a malicious transaction exists in the chain. The market is moving toward systems that simulate, score, and block activity at the point of action rather than after settlement. Practitioners should design for decision-time enforcement, not post-event forensics.
The real governance gap is the false separation of cyber, fraud, and compliance: the article is right to collapse these into one operating model, because attackers already do. A smart contract exploit can become a laundering path and a sanctions issue within the same sequence, which means siloed ownership creates blind spots. This is especially relevant for financial institutions building onchain capabilities, where control ownership often sits across security, compliance, and product teams. Practitioners should align these functions around a shared transaction-risk model.
Real-time prevention is the named concept this category now needs: the article makes clear that onchain risk is not a detection problem with a slower clock, but a prevention problem with an abbreviated one. The implication is that control effectiveness depends on whether enforcement occurs before a transaction can clear, not after alerts are raised. For security programmes, that changes what counts as a control failure and what counts as a successful block. Practitioners should measure whether prevention happens before loss, not whether events are eventually observed.
What this signals
Onchain operations will keep pushing security teams toward decision-time controls: the more value moves through wallets, dApps, and smart contracts, the less useful delayed review becomes. Programmes that still separate monitoring from enforcement will struggle to contain loss when transaction time compresses.
The category is also redefining what identity means in practice: wallets, multisig signers, and protocol-controlled authorities behave like governed principals, even when they are not human. That makes lifecycle control, scoped authority, and revocation discipline central to any serious onchain programme.
Cross-functional ownership is becoming a requirement, not a preference: onchain risk now spans security, fraud, and compliance in one flow, so teams that keep those functions siloed will miss chained attacks. The governance model has to follow the transaction, not the org chart.
For practitioners
- Map transaction approval points Identify every place where a user, signer, or automated workflow can authorize value movement, then classify which of those points still rely on post-event review.
- Simulate and score transactions before signing Use pre-execution analysis to inspect approvals, contract interactions, and fund flows so suspicious outcomes can be blocked before broadcast.
- Unify fraud, compliance, and cyber review Create one operating view for exploit patterns, sanctions exposure, and behavioural fraud so teams do not hand off the same event across separate queues.
- Harden multisig and MPC operations Apply policy enforcement to live wallet operations so privileged signatures cannot be used to move funds outside approved conditions.
Key takeaways
- Onchain security fails when teams rely on post-transaction detection for threats that complete in seconds.
- The article frames cyber, fraud, and compliance as one attack surface rather than three separate programmes.
- Practitioners need pre-signing enforcement, transaction simulation, and shared ownership across security and compliance teams.
Related NHI Mgmt Group resources: Zero Trust for AI Agents · Service Account Security Guide · Identity Fraud Prevention Guide · Serverless Security Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Onchain wallets and signers require governed authorization before value moves. |
| Recommendation — Apply PR.AA-05 to scope and review wallet and signer permissions before transaction approval. | ||
| CIS Controls v8 | CIS-5 — Account Management | Wallets, multisig signers, and operational authorities need lifecycle management and revocation. |
| Recommendation — Manage onchain principals with CIS-5 discipline so access is inventoried, owned, and removed when no longer needed. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The article describes reconnaissance, authority abuse, and rapid asset removal as the attacker path. |
| Recommendation — Map onchain abuse patterns to TA0006 and TA0010 to prioritise pre-loss detection and containment. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | The article's dApp, wallet, and transaction surfaces depend on correctly configured trust and enforcement controls. |
| Recommendation — Hunt for misconfigured transaction and wallet surfaces under API8-style controls before attackers exploit them. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Onchain actors should hold only the authority required for each transaction or workflow. |
| Recommendation — Use AC-6 to reduce signer and wallet authority to the minimum needed for each onchain action. | ||
Key terms
- On-Chain Security: On-chain security is the set of controls used to protect blockchain activity, smart contracts, transactions, wallets, and assets while they are live on the network. It focuses on preventing, detecting, and mitigating exploits in real time, where traditional server or cloud security tools cannot see or intervene.
- Transaction Simulation: Transaction simulation is a pre-execution control that evaluates a withdrawal or transfer before it is signed and broadcast. It can expose abnormal routing, risky recipients, or suspicious value movement, giving defenders a chance to block or escalate before funds leave the control boundary.
- Multisig and MPC Operations: Multisig and MPC operations govern how multiple signers or cryptographic participants authorize a wallet action. In security terms, they are control points for high-value authority, so policy, approval context, and operational discipline matter as much as key material.
- Real-Time Risk Prevention: Real-time risk prevention is the practice of evaluating access changes as they happen and blocking or flagging risky actions before they create exposure. In identity programmes, it depends on current context, policy logic, and event-driven controls rather than waiting for a later review cycle to surface the problem.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management through an independent practitioner lens. It helps security teams connect identity controls to the broader governance problems that affect modern digital systems.
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