Why do unrevoked approvals and unverified contracts create outsized loss risk in on-chain workflows?

Why This Matters for Security Teams

On-chain approval risk is not just a wallet hygiene issue. It is a control problem that affects asset custody, transaction integrity, and the blast radius of any compromised signer or dApp. Once an approval is granted, the spender may retain authority until it is explicitly revoked, so the security posture depends on continuous entitlement governance rather than a single successful transaction. That is why NHIMG treats approvals as persistent authorisations, not one-time events.

The risk becomes outsized when the approved contract is unverified, because there is no reliable basis for assessing what the code will do with that authority. In practice, teams often assume the visible interface reflects the real execution path, but attackers exploit the gap between user intent and contract behaviour. Control expectations map well to the NIST Cybersecurity Framework 2.0, especially where identity, access, and continuous monitoring intersect.

In practice, many security teams encounter approval abuse only after assets have already been drained, rather than through intentional permission review.

How It Works in Practice

Most on-chain workflows separate the act of using a service from the act of authorising it. A token approval or delegated permission can remain active long after the initial action completes, which means the contract can later move funds without a fresh user prompt. If the contract is verified and reviewed, the exposure is at least bounded by code transparency. If it is unverified, the user is extending trust to an opaque execution environment.

That creates a practical governance problem: the approval is often treated like a temporary session, but technically it behaves more like standing access. Security teams should therefore think in terms of lifecycle controls, not just transaction reviews. Stronger programmes usually combine allowance scoping, periodic revocation checks, signer separation, and monitoring for unusual spend patterns. The OWASP Non-Human Identity Top 10 is useful here because it frames machine-to-machine access as a governance issue, not just a token issue.

• Limit approvals to the minimum asset scope and duration that the workflow actually needs.
• Prefer verified contracts with source code and deployment metadata that can be independently checked.
• Track approvals as persistent entitlements and review them on a schedule, not only after incidents.
• Alert on abnormal allowance increases, new spenders, and contracts that request broad permissions.
• Use separate operational wallets or bots for high-risk actions so one compromise does not expose all assets.

For implementation discipline, security baselines in NIST SP 800-53 Rev 5 Security and Privacy Controls are a good analogue for access enforcement, change control, and auditability. These controls tend to break down when wallets are shared across automation, trading, and treasury functions because authority becomes too broad to attribute cleanly.

Common Variations and Edge Cases

Tighter approval controls often increase operational friction, requiring organisations to balance user convenience against the risk of accidental or malicious authority retention. That tradeoff is especially visible in high-frequency workflows, where repeated approvals can degrade user experience and encourage over-permissioning as a shortcut.

There is no universal standard for this yet, but current guidance suggests treating unverified contracts as elevated risk unless a separate trust signal exists, such as audited source code, known deployment lineage, or strong governance over the publisher. In some environments, a contract may be formally verified but still operationally risky if the governing key set or upgrade path can change behaviour later. This is where the identity bridge matters: the approval is effectively a non-human identity with delegated authority, and that authority can outlive the human who granted it.

Edge cases also arise with bots, custodial wallets, and automated treasury systems. Those environments may need long-lived permissions to function, but long-lived does not have to mean unconstrained. Best practice is evolving toward scoped permissions, explicit renewal, and continuous attestation of contract legitimacy. Where financial exposure is material, the control intent aligns with the NIST Cybersecurity Framework 2.0 and the broader entitlement discipline reflected in identity-governance programmes.

In the most fragile setups, this guidance breaks down when automated wallets must interact with fast-changing contracts on permissionless networks because code verification, revocation, and monitoring cannot keep pace with execution.

Related resources from NHI Mgmt Group

• Why do developer identities create outsized supply chain risk?
• Why do AI-generated package choices create more supply chain risk than normal developer workflows?
• Why do typosquatted packages create outsized supply chain risk?
• Why do CI and package-maintainer secrets create outsized supply chain risk?