Using a token in most on-chain applications requires two steps: an approval, then the action itself. The approval is a permission that remains in place after the action is finished.
An approval is a stored allowance, not a one-off consent
Token standards keep a record of how much each spender is permitted to move on your behalf. Approving a contract writes a number into that record.
The contract then pulls the tokens when you trade or deposit. What remains afterwards is whatever allowance was not consumed.
Nothing expires. The allowance sits in the token contract until you or the spender changes it, regardless of whether you ever use the application again.
Unlimited allowances became the default for a reason
Each approval costs a fee, so approving exactly the amount needed means paying twice for every interaction with the same application.
Interfaces therefore began requesting the maximum representable amount once, which makes subsequent trades a single transaction. The convenience is real and so is the exposure.
The user sees one prompt either way, and the difference between approving a trade and approving an unbounded allowance is often a single line of technical detail in the confirmation screen.
The risk arrives later, through the spender
An allowance is only as safe as the contract holding it. If that contract is upgradeable, its behaviour can change after you approved it.
If it is exploited, the attacker inherits the ability to move tokens from every address that granted an allowance, up to the amount approved, without touching any private key.
This is why exploit losses often include wallets that had not interacted with a protocol for months. The permission was still live.
Revocation is a transaction of its own
Setting an allowance back to zero is a state change, so it requires a signed transaction and a fee like any other.
Disconnecting a wallet from a site does nothing. That action affects a browser session; the allowance lives on the chain and is unaffected.
Revocation also has to be done per token and per spender, so an address with a long history can carry dozens of separate permissions, each needing its own transaction to clear.
Compartmentalising limits the blast radius
Using separate addresses for experimentation and for holdings means an exploited approval reaches only the balance in the address that granted it.
An allowance can only ever move the tokens held by the address that granted it, so keeping a reserve in an address that has never approved anything places it outside this class of failure entirely.
Reviewing outstanding allowances periodically is the other half. The list tends to grow quietly, because every application asks once and never reminds you again.