TL;DR: Multisig wallets are governance controls, not security controls, because legitimate quorum can still approve malicious contracts, hidden allowances, or transactions that fail on the next block, according to Hypernative. The operational gap is pre-transaction policy and real-time monitoring, which together catch risks that signer quorum alone cannot see.
At a glance
What this is: This is an analysis of why multisig alone does not secure institutional treasury operations and why transaction-level policy enforcement is needed to catch malicious contract interactions and hidden approval risk.
Why it matters: It matters because treasury and IAM teams overseeing digital assets need controls that evaluate transaction intent, not just signer quorum, if they want to prevent approved actions from becoming loss events.
Context
Multisig wallets create quorum-based approval, but they do not inspect the security meaning of the transaction being signed. In treasury and DeFi operations, that leaves a gap between who approves a transfer and what the transfer actually does once it lands onchain.
The governance problem is not just access control. It is whether the organisation can detect malicious contract interaction, hidden allowance grants, and post-signature exploitation before funds move or a position is exposed. That is the control boundary this article examines.
Key questions
Q: What fails when multisig wallets are treated as the only treasury control?
A: The failure is assuming quorum equals security. Multisig can stop unilateral movement, but it cannot tell whether a legitimate transaction interacts with a malicious contract, hides an allowance change, or opens a loss path in the next block. Treasury governance fails when signer approval is mistaken for transaction safety.
Q: Why do legitimate treasury approvals still create loss risk in DeFi?
A: Because the risk often sits inside the transaction, not in the signer set. A routine-looking vault deposit or rebalance can still trigger malicious contract logic, exploit hidden authorisation, or interact with a protocol that becomes unsafe immediately after execution. The approved action is valid, but its economic effect is not safe.
Q: How can treasury teams tell if pre-transaction policy is actually working?
A: It is working when risky transactions are blocked or routed before signing, auto-approval is limited to genuinely low-risk activity, and reviewers are not flooded with noise. The useful measure is whether the policy reduces manual load without allowing dangerous contract interactions to pass through unexamined.
Q: What is the difference between multisig governance and pre-transaction enforcement?
A: Multisig governance decides who must approve a transaction. Pre-transaction enforcement decides whether the transaction should be allowed at all based on its intent, contract behaviour, and embedded risk. One is an approval mechanism, the other is a security decision layer that can stop harmful actions before they are signed.
Technical breakdown
Why multisig governance is not transaction security
A multisig wallet ensures that multiple signers must approve an action, but it does not judge the semantic risk of the transaction. In DeFi, a transaction can be formally valid and still be dangerous if it routes into a malicious contract, embeds a Permit or IncreaseAllowance action, or triggers an exploit after execution. The control problem is therefore not quorum, but interpretation: the system must understand what the transaction will do, not just whether enough signers approved it. Practical implication: treat multisig as an approval mechanism, not a security decision layer.
Practical implication: add policy evaluation before signatures are committed, not after quorum is reached.
How pre-transaction policy changes treasury enforcement
Pre-transaction policy turns treasury approval into a rules-based enforcement step. The article describes a flow where detected risk determines whether a transaction is auto-approved, routed to human review, or blocked before funds leave the vault. That matters because manual review cannot keep pace with high-volume treasury activity, yet approval on autopilot creates blind spots. The enforcement logic has to inspect transaction intent, protocol context, inner-call risk, and address reputation before signing occurs. Practical implication: move the decision point earlier in the workflow so risky transactions never reach the signer queue. See the AI Agent Authorisation Guide.
Practical implication: route only policy-exception transactions to humans and enforce blocks at the point of execution.
Why real-time monitoring must sit beside wallet control
Real-time monitoring covers the period after a position is opened, which is where many treasury losses emerge. A treasury can hold a valid position and still be exposed to protocol failure, liquidity shifts, or address reputation changes that appear later. The article’s monitoring model treats treasury exposure as a graph of dependencies across wallets, vaults, protocols, and strategies, not as a static asset list. That architecture matters because detection after execution is still useful when the threat emerges after signing. Practical implication: instrument monitoring across every treasury node that can change exposure after the transaction clears.
Practical implication: monitor post-signature exposure as a living dependency graph, not a static holdings list.
Threat narrative
Attacker objective: The attacker’s objective is to convert a valid-looking treasury approval into unauthorized asset loss or exploitable protocol exposure.
- Entry occurs through a legitimate treasury transaction that passes quorum, but the contract or payload is malicious or deceptive.
- The attacker abuses approved transaction content, hidden allowances, or protocol behaviour to create unauthorized economic exposure.
- Impact follows when funds are drained, approvals are abused, or a protocol exploit converts a normal-looking transaction into a loss event.
Breaches seen in the wild
- Lottie Player npm compromise 2024: A compromised developer npm token let attackers publish three Lottie Player versions that pushed a crypto wallet drainer to websites.
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
Multisig is a governance control, not a security control: quorum limits unilateral movement, but it does not evaluate the risk content of what gets signed. That distinction matters because treasury losses in DeFi often come from valid approvals, not stolen keys. Practitioners should stop treating signer quorum as the final security boundary.
Transaction intent is the new control plane: The important question is no longer only who can sign, but what the signed action will do across contracts, allowances, and protocol state. That shifts treasury security from identity approval to semantic enforcement. Teams that do not inspect intent are relying on a control that can be perfectly followed and still fail.
Identity blast radius in treasury operations is measured by exposure graph, not wallet count: A treasury managing many vaults across protocols inherits risk through every dependency it touches. The relevant unit of governance is the chain of interactions that can amplify one permitted transaction into a broader loss event. That means treasury governance must be modelled as connected operational exposure, not separate wallets.
Pre-transaction enforcement closes the gap that signer review cannot: Manual approval frameworks break under transaction volume, while automatic approval without policy creates blind trust. The stronger pattern is to define the risky boundary before signature, where malicious contract interaction and allowance abuse can still be blocked. Treasury teams should redesign governance around pre-commit evaluation, not post-commit explanation.
Read next: AI Agent Authorisation Guide
What this signals
Treasury programmes that rely on quorum alone are likely to discover that approval authority and security authority are not the same thing. The control boundary is moving toward decision-time inspection, where policy has to understand contract behaviour before the signer touches the transaction.
Transaction intent governance: The next maturity step is not more signer coordination, but stronger interpretation of what each transaction means operationally. Teams that can classify, route, and block by intent will be better positioned to manage treasury risk across DeFi, vaults, and custody stacks.
For practitioners
- Define transaction intent as a policy object Classify each treasury transaction by the contract, call path, allowance change, and protocol context before it reaches signer review.
- Block on hidden approval risk Flag Permit, IncreaseAllowance, inner-call, and other embedded authorisation changes as policy-relevant events, not benign transaction details.
- Separate auto-approve from human escalation Use a tiered routing model so only no-risk transactions are approved automatically, low and medium risk route to reviewers, and high risk is blocked or escalated.
- Monitor treasury exposure as a dependency graph Track each wallet, vault, protocol, and strategy as a node whose risk can change after execution, especially when positions span multiple chains.
Key takeaways
- Multisig wallets reduce unilateral action, but they do not evaluate whether a legitimate transaction is economically safe.
- The article shows that treasury loss can follow valid quorum when contract intent, hidden allowances, or protocol state are not inspected before signing.
- The practical control shift is from signer-centric governance to pre-transaction enforcement and continuous exposure monitoring.
Related NHI Mgmt Group resources: AI Agent Authorisation Guide · Zero Trust for AI Agents · Crypto Scam and Drainer Guide · Web3 and Crypto Security Guide
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 MITRE ATT&CK address the attack and risk surface, while CSA Cloud Controls Matrix and 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-05 — Overprivileged NHI | Treasury signers and wallet controls need tighter scope than quorum alone. |
| NHI-10 — Human Use of NHI | Human signers are still making NHI-level treasury decisions through wallets and vaults. | |
| Recommendation — Limit treasury approval paths so no signer or wallet can authorise beyond policy scope. Govern human-operated wallet approvals as NHI decision points, not informal manual checks. | ||
| MITRE ATT&CK | TA0006; TA0040 — Credential Access; Impact | The article centres on approved actions turning into loss events through abused transaction paths. |
| Recommendation — Map treasury approval abuse to credential access and impact tactics when reviewing detection coverage. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Treasury wallet approval and transaction governance sit within access and authorization control design. |
| Recommendation — Apply IAM governance to approval workflows that authorize treasury transactions. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about whether treasury permissions and approvals are enforced at the right boundary. |
| Recommendation — Review entitlements so transaction authority is constrained by policy before execution. | ||
Key terms
- Multisignature Wallet: A multisignature wallet requires more than one approval before a transaction can execute. It reduces single-point compromise by distributing signing authority across multiple keys or approvers, but it still depends on strong identity governance for the people and systems involved.
- Pre-Transaction Policy: Pre-transaction policy is the set of rules that evaluates a transaction before it is signed or executed. It is used to decide whether to approve, route for review, or block the action based on contract behaviour, allowance changes, and protocol-specific risk.
- Transaction Intent: The decoded business action that a system is actually about to perform, such as a payment, trade, or signing event. For autonomous agents, intent is the object that must be authorised, because the agent's stated goal may differ from the executable transaction.
- Exposure Graph: A continuously updated map of how assets, identities, permissions, and trust paths connect across an environment. It is used to show how isolated misconfigurations become an attack path when chained together, especially in cloud, SaaS, and identity-heavy estates.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
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