Attackers use a governance attack to capture voting power and push proposals that benefit them, such as draining treasury funds or changing protocol rules. They may borrow tokens, buy votes, or compromise delegate accounts. Defenders should check quorum rules, voting thresholds, timelocks, proposal execution limits, and concentration of voting influence.
How governance attacks work in practice
A governance attack is less about breaking cryptography than about changing who gets to decide. Attackers try to accumulate enough voting power, delegation influence, or proposal support to move protocol decisions in their favour, often by borrowing tokens, buying votes, or taking over delegate accounts. The core security problem is that governance legitimacy can be manipulated even when the protocol code still behaves as designed.
In practice, the attacker’s goal is usually to convert temporary influence into durable control. That can mean pushing a treasury drain, altering upgrade rules, weakening safeguards, or authorising changes that benefit the attacker before defenders can react. Because governance systems often treat voting power as authority, the attack path targets the authority model rather than the application layer.
Governance attacks are especially dangerous in systems where proposal execution is fast, treasury balances are large, or voting influence is concentrated among a small set of delegates and large holders. The same mechanisms that make decentralised governance flexible, token voting, delegated voting, quorum thresholds, and executable proposals, can also create a single point of failure when influence is captured.
When the governance process is the control plane, Web3 and Crypto Security Guide is the right starting point for understanding how treasury control, delegate security, and protocol decision-making interact.
What makes these attacks effective
Attackers usually do not need to “hack the chain” to succeed. They exploit the social and procedural parts of governance: short notice periods, weak quorum design, low participation, proposal fatigue, and voters who delegate without strong oversight. If enough voting influence can be assembled for one proposal cycle, the attacker may only need a brief window to pass malicious changes.
Borrowed voting power and token concentration make the problem worse because governance influence can be rented, aggregated, or redirected faster than many communities can respond. In some systems, compromised delegate credentials are even more valuable than raw token holdings because they let the attacker act with trusted authority inside the decision process.
That is why governance security is partly an access-control problem. The attacker is not only trying to win a vote, but to gain a decision right that the rest of the system will accept as legitimate.
The most relevant external threat context is captured in CISA cyber threat advisories, which help teams track the wider tactics used to compromise accounts, influence trust relationships, and turn access into impact.
OWASP Non-Human Identity Top 10 is also useful where governance tooling, delegate automation, or treasury workflows rely on credentials, tokens, or other machine-held secrets that can be abused to influence proposals or execution.
Where defenders should focus first
The first check is whether voting power can be concentrated faster than the community can detect and respond. Quorum rules, proposal thresholds, timelocks, and execution limits only help if they are set to create real friction between malicious control acquisition and irreversible action. If the system lets a captured majority act immediately, the defender has little room to recover.
Defenders should also review who can propose, who can delegate, who can execute, and whether delegate accounts are protected with stronger controls than ordinary user accounts. A governance system is only as strong as the weakest trusted participant, especially when one compromised account can influence treasury movement or protocol upgrades.
Concentration of voting influence deserves ongoing monitoring, not just periodic review. A proposal can be technically valid and still be operationally unsafe if it depends on a narrow coalition, unusually high borrowed voting power, or participants whose incentives are easy to manipulate.
Practitioner Guidance: Treat governance like an enforceable control path, not a forum discussion. If a proposal can change treasury access or protocol rules, require the same level of scrutiny you would apply to a high-impact production change, including threshold review, delay windows, and account protection.
What to verify: Confirm that quorum and execution rules still create a meaningful delay between proposal approval and effect. Verify that delegate accounts, multisigs, and proposal executors are protected against simple takeover and that emergency intervention is possible before irreversible execution.
Decision rule: If voting influence can be rented, borrowed, or rapidly concentrated, treat the environment as high risk even when the governance process appears formally compliant. If execution is immediate, prioritise hardening the path from vote to action over debating whether a malicious proposal will “probably fail.”
Practitioner takeaway: The real control objective is not just preventing bad proposals, but preventing temporary influence from becoming irreversible authority before anyone can react.
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 CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Governance attacks rely on account takeover and delegated authority abuse. |
| Recommendation — Review and restrict privileged governance accounts and revoke unused delegated access. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Voting and execution authority should be limited to the minimum needed for governance roles. |
| IA-5 — Authenticator Management | Delegate account compromise and token abuse depend on credential lifecycle weaknesses. | |
| Recommendation — Limit proposal and execution powers to the smallest set of approved governance actors. Rotate and protect governance credentials, tokens, and signing secrets on a strict lifecycle. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Governance tooling and treasury automation can be abused when machine credentials have excess authority. |
| Recommendation — Reduce governance service accounts and automation credentials to least privilege. | ||
| MITRE ATT&CK | T1098 — Account Manipulation | Attackers may alter delegate or privileged accounts to gain governance influence. |
| Recommendation — Monitor for account changes that expand governance influence or delegate authority. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org