Many losses do not involve a stolen key at all. The victim signed a permission once, months earlier, and the contract used it exactly as designed.
Contracts cannot take tokens without permission
Token balances live in the token's own contract, and an application wanting to move them must be authorised by the holder first.
That authorisation is a separate transaction recording an allowance: this contract may move up to this quantity of this token from my address.
The trade or deposit that follows is a second transaction which relies on the allowance already granted. This is why a first interaction with an application usually requires two confirmations rather than one.
Unlimited allowances became the default
Approving exactly the needed amount means a new approval before every interaction, doubling the transaction count and the fees.
Interfaces therefore began requesting the maximum possible value, so one approval covers all future use.
The convenience is real and so is the exposure: the permission remains valid for every token the address will ever hold, indefinitely.
Permissions outlive the reason for granting them
An allowance does not expire, and it is not cancelled by disconnecting a wallet from a site, which only ends a local session.
Users accumulate dozens of standing permissions across applications they stopped using long ago and have forgotten entirely.
If any of those contracts is later upgraded maliciously or exploited, every address that granted it can be emptied without further interaction.
Signature-based approvals shift the risk
Newer schemes let a user sign an off-chain message granting permission, which the contract submits alongside its own call, saving a transaction.
The signature carries an expiry and a specific amount, which is an improvement, but it is also approved through a message prompt rather than a transaction.
Those prompts look less consequential than sending funds, and phishing sites exploit exactly that impression to obtain signatures granting broad permissions.
Hygiene is periodic rather than one-off
Allowances can be revoked by setting them to zero, which is an ordinary transaction and costs a fee per token per contract.
Reviewing outstanding permissions occasionally, and revoking anything unrecognised, limits how much a future compromise elsewhere can reach.
Separating funds across addresses achieves the same in a different way, since an approval only ever exposes the balance of the address that granted it.
Neither measure prevents a bad approval being signed in the first place, which is why the confirmation screen remains the point where the loss is actually avoided.