TL;DR: Drift, Hyperbridge and Kelp DAO lost a combined $578 million in 2026 because transactions passed every normal security check while privileged actions remained unconstrained at execution time, according to Hypernative. The failure is not authentication alone, but the absence of policy boundaries on what a valid authorization can do once it is trusted.
At a glance
What this is: This analysis argues that major DeFi losses in 2026 came from valid signatures, proofs and attestations that still enabled unsafe state changes.
Why it matters: It matters because IAM, PAM and workload governance teams must distinguish between proving who or what acted and constraining what that actor is allowed to do once trusted.
By the numbers:
- Drift Protocol lost $285 million.
- Kelp DAO lost $292 million and triggered $13 billion in DeFi withdrawals over the 48 hours that followed.
Context
DeFi protocols can authenticate a transaction correctly and still fail at governance if they do not constrain what a valid privileged action is allowed to change. The core problem is not only key custody or signer hygiene, but the lack of operational limits around state-changing actions once authorization succeeds.
That gap becomes more visible in systems where governance, bridge validation and treasury controls are all expressed as executable logic. In those environments, a trusted actor can move the system into an unsafe state without any code bug or signature failure. SaaS security risks does not solve this problem, but the access-and-configuration lens is useful here because the failure starts when trusted paths are left over-broad.
For practitioners, this is a reminder that the security question shifts from “was the action authenticated?” to “what could that authenticated action do?” That distinction is atypical only in mature control designs; it is still common in protocols that rely on point-in-time review rather than runtime constraints.
Key questions
Q: What breaks when a protocol trusts valid signatures without constraining the resulting action?
A: Authentication can still succeed while the protocol enters an unsafe state. That failure lets a legitimate signer, proof or attestation trigger actions that mint too much value, remove safeguards, or change governance settings in ways the system never intended to allow. The control gap is not identity proof. It is the absence of bounds on what authorized input can do once accepted.
Q: Why do audits miss some onchain attack paths?
A: Audits usually confirm that code behaves as written, but they do not keep pace with changing governance settings, signer sets, challenge windows or execution thresholds. A configuration can be technically valid and still expand risk materially. Practitioners need controls that continuously validate the operational envelope, not just the codebase.
Q: How do security teams tell whether policy enforcement is working in a protocol?
A: Look for evidence that unsafe transactions are blocked before state changes occur, even when authentication or proof verification succeeds. Effective enforcement should stop oversized mints, instant admin changes, and excessive withdrawals without relying on manual review. If privileged actions always complete once signed, policy is not constraining execution.
Q: What should teams do when privileged actions can change protocol state too freely?
A: Reduce the blast radius by separating permission to act from permission to change state, then define caps, delays and reconciliation checks around the highest-risk functions. The point is to make unsafe outcomes impossible or at least non-trivial, even when the actor is legitimate. That is a governance design choice, not just an operational one.
Technical breakdown
Why valid signatures can still produce unsafe outcomes
In onchain systems, signatures, proofs and attestations often answer only the identity question: did an authorized party or trusted component produce this transaction? They do not automatically answer the authorization question: is the resulting state change safe? When a protocol accepts a privileged instruction, the code may be correct even if the operational result is dangerous. That is why a transaction can pass every conventional check and still drain funds, inflate supply or unlock treasury actions. The failure lives above the code layer, in the policy envelope surrounding it. Read Top 10 Cloud Security Risks.
Practical implication: Model privileged actions as bounded operations, not as binary allow or deny events.
Why audits miss operational envelope drift
Audits usually verify whether code behaves as written at a point in time. They do not continuously validate whether governance parameters, signer sets, challenge windows or rate limits still match the original security intent. A zero-second timelock, a migrated council, or a single verification path can all be “correct” from a code perspective while still expanding the attack surface. Operational drift is especially dangerous because it looks like legitimate configuration, not a defect. The result is a protocol that remains functional but becomes easier to abuse as settings accumulate.
Practical implication: Treat configuration drift as a control failure and review governance parameters as aggressively as code.
How policy enforcement closes the gap at execution time
Policy enforcement is different from monitoring because it can stop an action at the moment it is about to change state. In the incidents described, a minimum challenge period, a supply cap, a multi-attestation requirement, or a cooling-off rule would have constrained the final step even after initial authorization succeeded. This is the architectural difference between detecting risk and bounding impact. Monitoring can surface staging behaviour early, but only enforcement can prevent a valid request from producing an invalid outcome.
Practical implication: Define hard execution limits for privileged actions that can move value, mint assets or alter governance state.
Threat narrative
Attacker objective: The attacker’s objective is to convert valid authorization into unauthorized economic impact by forcing the protocol to accept unsafe state changes.
- Entry occurred through legitimate governance authority, a forged proof that passed verification, or a trusted cross-chain attestation that the protocol accepted as valid.
- Privilege was then exercised through approved paths that allowed market listing changes, asset administration, minting, or escrow release without additional scrutiny.
- Escalation happened because each action changed protocol state in a way that the system treated as authorized, even when the cumulative effect was unsafe.
- Impact was the rapid loss of funds, inflated supply, or forced withdrawals at scale.
Breaches seen in the wild
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
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
Authentication without bounded authorization is the real failure mode here. These incidents show that proving who signed, verified or attested is no longer enough when the resulting action can still create unsafe protocol state. The industry has over-invested in identity proof and under-invested in execution constraints. Practitioners should treat this as a governance design problem, not a signer quality problem.
Operational envelope drift is the named concept practitioners should watch. A protocol can remain technically correct while its effective security boundary expands through zero-delay timelocks, signer churn, permissive market parameters or single-path attestation logic. That boundary drift is hard to see in audits because it appears as normal configuration. Teams need to govern the space between approval and effect, not just the code that executes it.
The trust assumption failed at the point where trusted input became irreversible state. In OAuth token theft and in these onchain incidents, the deeper issue is the same: trusted authority was allowed to trigger downstream actions with too few constraints. The identity of the actor mattered, but the impact came from what that actor was permitted to do once trusted. Practitioners should separate authentication success from state-change safety.
Policy enforcement now belongs alongside monitoring as a core control pattern. Monitoring gives teams warning before execution, but the losses here were created by the execution itself. Mature governance must therefore pair observability with hard limits on minting, withdrawals, cross-chain acceptance and governance changes. That is the control model that changes the loss profile.
What this signals
Bounded authorization is becoming the control model that matters most. In protocol environments, the decisive question is no longer whether an actor is legitimate, but whether legitimacy is paired with limits on what can be changed. Security programmes that stop at authentication are still leaving the largest loss path open.
Runtime policy must now sit beside identity controls. Governance teams need to think in terms of execution envelopes, not only signer integrity or proof validity. That means defining what a trusted action can never do, even if it is otherwise accepted by the system.
Operational drift is the hidden risk multiplier. The more a protocol relies on mutable configuration, the more a small governance change can create a large economic exposure. Practitioners should treat timelocks, signer composition and cross-chain thresholds as continuously enforced control points, not static settings.
For practitioners
- Define execution limits for privileged actions Set hard constraints on actions that can mint, withdraw, reconfigure or change governance state so a valid authorization cannot produce an unsafe outcome.
- Review governance parameter drift continuously Track timelocks, signer composition, challenge periods and market thresholds as living controls, not one-time audit artifacts.
- Add supply and value reconciliation checks Require onchain checks that compare requested value movement against source balances, supply ceilings and protocol-specific invariants before execution.
- Separate proof verification from state-change approval Treat verified proofs as input only, then apply a second policy layer before the protocol commits to irreversible state changes.
Key takeaways
- The article’s central risk is not broken verification but trusted execution without enough constraints on the resulting state change.
- The losses cited across three incidents show that the same failure pattern can produce both direct theft and large downstream market impact.
- Practitioners need hard policy limits around privileged actions because authentication alone does not prevent unsafe protocol outcomes.
Related NHI Mgmt Group resources: Top 10 Cloud Security Risks · Top 10 Data Security Risks · Top 10 SaaS Security Risks
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The incidents hinge on trusted authority being used to move through privileged paths. |
| Recommendation — Map privileged-path abuse to TA0006 and TA0008, then hunt for escalation through legitimate governance actions. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about valid access that still enables unsafe outcomes without tighter authorization boundaries. |
| Recommendation — Apply PR.AA-05 to ensure entitlements limit what an authorized actor can actually change. | ||
| CIS Controls v8 | CIS-5 — Account Management | Signer churn and privileged path expansion make account and authority governance central to the risk. |
| Recommendation — Use CIS-5 to review and revoke stale privileged access and governance authority. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | The core issue is how trusted identities and authorities are managed across privileged protocol paths. |
| Recommendation — Apply IAM governance to separate authentication success from irreversible state-changing authority. | ||
Key terms
- Operational Envelope: The operational envelope is the range of states and actions a system is actually allowed to reach once legitimate access is granted. In DeFi and other automation-heavy environments, this includes timelocks, caps, thresholds and approval paths that can be narrower or wider than the code alone suggests.
- Bounded Authorisation: Bounded authorisation means an identity is only allowed to operate inside explicit limits for task, scope, and time. For AI agents, this is the core governance pattern because privilege must be constrained to the session or workflow in which the agent is permitted to act.
- Policy Enforcement Layer: The control plane that decides whether a tool call, request, or action is allowed. It is distinct from model reasoning because it produces deterministic allow or deny decisions, which is essential when an AI system can act faster than a human reviewer.
- Governance Evidence Drift: The gap that appears when written governance controls lag behind the actual state of AI access, ownership, and activity. It is a practical audit problem because a policy can still exist while permissions, data exposure, or accountability have already changed underneath it.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management and identity lifecycle control. It helps practitioners connect identity governance to the wider security programmes they run.
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