Blockaid’s Midas case shows policy-only controls miss transaction risk

At a glance

What this is: Blockaid describes how Midas paired transaction simulation, threat intelligence, and monitoring to close the gap left by policy-based allowlists in MPC-controlled onchain operations.

Why it matters: It matters because identity and transaction governance for high-risk financial workflows cannot rely on permission checks alone when malicious activity can still occur inside approved paths.

By the numbers:

• Blockaid's Cosigner now secures 100% of Midas contracts, indicating full contract coverage for signing-time validation.
• Fordefi's setup included more than 75 policy rules, over 100 recipients, and more than 200 approved assets.

Context

MPC-based transaction controls in onchain finance reduce exposure, but they do not automatically tell operators whether an approved action is actually safe. In environments where strategy managers, contracts, recipients, and assets all change constantly, the governance gap is not simply authorisation. It is the difference between a transaction being permitted and a transaction being trustworthy.

This article is about that control gap in a DeFi operating model. Midas uses appointed strategy managers, contract administration, and signing workflows that resemble high-risk privilege management, where one weak policy rule or one compromised counterparty can affect funds and downstream positions. The identity lesson is that high-value workflows still need runtime verification, not just static policy design.

Key questions

Q: What breaks when allowlists are the only control for onchain transactions?

A: Allowlists prove that a transaction matches pre-set permissions, but they do not prove the transaction is safe at runtime. That leaves teams exposed to malicious payloads, compromised counterparties, or changed protocol conditions that were not visible when the rule was written. The control failure is confusing permission with trust.

Q: Why do approved onchain transactions still create security risk?

A: Because approval checks are static, while transaction risk is dynamic. A transaction can be valid under policy yet still interact with a compromised asset, a depegged token, or a hostile counterparty once it executes. Risk appears at the moment of signing and then again as the surrounding ecosystem changes.

Q: How can security teams tell whether transaction governance is working?

A: Look for two signals: unsafe actions being blocked before signature, and benign actions passing with minimal manual review. If operators still verify every address by hand, the control model is too weak or too labour intensive. Effective governance reduces noise while improving inspection of truly risky transactions.

Q: Who should own incident response when an onchain exploit alert fires?

A: Ownership should sit with the security or operations function that can confirm whether the alert reflects a real threat, then coordinate with strategy managers and technical responders. In delegated investment environments, the practical model is shared accountability, but the response trigger must be explicit and tied to security evidence.

Technical breakdown

Why allowlists fail at transaction trust

A policy allowlist answers one narrow question: is this action pre-approved? It does not answer whether the transaction content, destination, or counterparty is safe at runtime. In MPC wallet environments, the signing boundary is the critical control point because the signature releases value. That means a transaction can be fully compliant with policy and still be malicious if the payload has been manipulated, the recipient later becomes hostile, or the execution path behaves differently than expected. Transaction security therefore needs both authorisation and behavioural validation.

Practical implication: teams should treat allowlists as a baseline control and add signing-time simulation plus threat detection for high-value transactions.

How transaction simulation changes the control model

Simulation creates a pre-signing view of what a transaction will actually do, including the assets touched, the counterparties involved, and the onchain state it will affect. That shifts security from static approval logic to runtime inspection. In this model, the control is not just whether a role is allowed to act, but whether the specific action is consistent with expected behaviour at the moment of execution. For financial platforms, that is closer to privileged session control than simple access permissioning, because the risk materialises when the action is executed, not when the role is assigned.

Practical implication: validate sensitive transactions at execution time, not only when roles, policies, or recipients are configured.

Why ecosystem monitoring matters after signing

Onchain risk does not stop at the wallet boundary. A DeFi protocol can be exploited, a stablecoin can depeg, or a counterparty can become linked to attacker infrastructure after a transaction policy was written. Continuous monitoring is therefore an external risk control that watches the ecosystem around the transaction rather than the transaction alone. This is especially relevant in multi-protocol strategies, where one approved exposure can become unsafe because the surrounding market or dependency shifts. The control problem is dynamic exposure, not just transaction approval.

Practical implication: monitor counterparties, protocols, and market dependencies continuously so incident response can trigger before losses cascade.

Threat narrative

Attacker objective: The objective is to push a malicious onchain transaction or exposure path through approved controls and create financial loss before operators can detect the misuse.

1. Entry occurs when an approved or apparently compliant transaction enters the MPC signing workflow and reaches the validation boundary.
2. Credential or policy abuse happens when allowlists and role assignments are insufficient to distinguish a legitimate action from a malicious one at runtime.
3. Impact follows when a harmful transaction is signed, or when a compromised protocol or counterparty propagates loss across adjacent DeFi positions.

Breaches seen in the wild

• Zacks breach claim 2025: A hacker leaked 12 million Zacks accounts in 2025, claiming domain admin access in 2024; HIBP verified the data, Zacks has not confirmed.

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

Transaction governance for onchain finance is now a runtime discipline, not a policy exercise. Static allowlists can reduce obvious misuse, but they cannot determine whether an approved transaction is safe at the moment of signing. In environments where value moves through MPC workspaces, the decisive control is runtime validation of intent, destination, and counterparty. Practitioners should treat transaction governance as a live control plane, not a spreadsheet of permissions.

Policy depth does not eliminate detection blind spots. More than 75 rules, 100+ recipients, and 200+ approved assets may improve precision, but they also increase configuration burden and blind operators to post-approval risk. The governance assumption that pre-authorised equals safe breaks down once transaction behaviour can be manipulated after policy creation. Teams need controls that inspect the transaction itself, not just the permission source.

Continuous ecosystem monitoring is the missing layer in DeFi strategy operations. A strategy can be valid at approval time and still become unsafe if a protocol depegs, is exploited, or is linked to attacker infrastructure later. That makes external monitoring part of identity and access governance for financial operations, because access decisions and exposure decisions are inseparable. Practitioners should extend control thinking from signing events to the broader dependency landscape.

Managed onchain operations need incident triggers tied to security evidence, not manual escalation alone. The article shows a mature pattern where exploit detections feed a defined response protocol and joint investigation. That is the right direction for teams with delegated strategy managers, because operational speed without response triggers creates avoidable dwell time. The field should move toward evidence-driven escalation for transaction and ecosystem anomalies.

What this signals

Transaction-level verification is becoming a governance requirement for onchain platforms. The important shift in this case is not the number of policies, but the fact that runtime validation sits between approval and signature. That pattern should inform any programme handling delegated financial actions, because the trust decision must happen where value is actually released.

Onchain operations now need security controls that follow the dependency graph. If a strategy touches multiple protocols, the relevant control boundary extends beyond the wallet to the surrounding DeFi ecosystem. Teams should assume that exposure can emerge from third-party events after policy approval, which makes continuous monitoring part of operational governance.

Managed strategy platforms are developing a new control pattern: runtime review plus event-driven response. The strongest signal here is that detection feeds a formal incident protocol instead of remaining an isolated alert. That is the model practitioners should copy when delegated actors, external protocols, and financial exposure all intersect.

For practitioners

• Implement signing-time transaction simulation Validate every high-risk onchain transaction at the moment of signing so the system evaluates what the action will actually do, not just who approved it.
• Separate policy enforcement from threat detection Keep allowlists and role rules, but add a second control that inspects transaction behaviour, counterparties, and decoded simulation results.
• Continuously monitor ecosystem dependencies Track the DeFi protocols, assets, and counterparties that a strategy touches so protocol exploits or depegs are detected before they cascade into losses.
• Trigger incident response from exploit detections Define exploit alerts as formal incident inputs, then require joint investigation and documented escalation when a transaction or protocol alert fires.

Key takeaways

• Policy-based allowlists reduce obvious misuse, but they do not prove that an approved onchain transaction is safe at runtime.
• The operational gap is between permission checking and behavioural threat detection, especially when strategy managers and DeFi dependencies change quickly.
• Teams need signing-time validation, continuous ecosystem monitoring, and explicit incident triggers if they want delegated onchain operations to scale safely.

Key terms

• Multi-Party Computation Workspace: A Multi-Party Computation workspace is an environment where signing authority is split across multiple parties or systems before a transaction can be approved. In practice, it is used to reduce single-point compromise risk, but it still needs strong policy, runtime validation, and monitoring around every sensitive action.
• 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.
• On-Chain Monitoring: On-chain monitoring is the process of observing blockchain transactions and related activity for risk, compliance, or operational signals. In regulated environments, it must be linked to internal records and escalation workflows so teams can investigate activity, not just observe it.
• Delegated Strategy Manager: A delegated strategy manager is a person or team granted authority to operate investment strategies within defined policy boundaries. The security challenge is that legitimate operational delegation can become high-risk privilege if transaction scope, approval logic, and incident escalation are not tightly governed.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners build stronger control models for delegated access, runtime verification, and identity-driven risk reduction.