Cowrie Research

stored-privileged-approval-expiry-and-revocation-discipline

12 min read

Stored-Privileged-Approval Expiry and Revocation Discipline

  • Name: stored-privileged-approval expiry and revocation discipline
  • Category: control-surface reference / signing-workflow design checklist / delayed-execution safety reference / privileged-approval lifecycle note
  • Summary: Healthy systems do not treat previously collected privileged approvals as timeless authority. Durable nonces, queued multisig proposals, pre-signed admin bundles, partially collected threshold transactions, and similar stored approval objects should behave like perishable capabilities with explicit expiry, inventory, cancellation, signer-set versioning, and security-event invalidation. Otherwise an attacker who harvests one valid approval can simply wait until monitoring is weaker, signer membership changes, or the best cash-out moment arrives. This note exists to preserve the positive design target behind incidents like Drift, Bybit, Radiant, and WazirX: the right question is not only what exact object did signers approve? but also why was that object still executable later under materially different conditions, or after the signer-facing environment had already become suspect?
  • Why this note exists:
    • Many systems now ask the identity question — what exactly are we signing? — but still under-specify the time question: how long should this remain live, and what kills it early?
    • Stored privileged approvals are dormant root authority. They deserve the same inventory, expiry, revocation, and blast-radius design as live admin keys.
    • The healthy move is to make freshness and revocation part of the same security object as the approved payload, instead of leaving them as operator habit or incident-response folklore.

The six joints a healthy stored approval should keep fused

  1. Exact approval object
    • The system should know exactly what was approved: target, code identity when relevant, call primitive, calldata or action bundle, nonce semantics, and any delayed-execution wrapper.
    • There is a pending transaction somewhere is not a usable security description.
  2. Freshness window
    • Every stored privileged approval should carry a bounded lifetime appropriate to its blast radius.
    • High-impact admin actions should age out quickly enough that a harvested approval cannot wait for a calmer day.
  3. Revocation path
    • Cancellation should be explicit, fast, observable, and operationally easier than execution.
    • A system that can create stored privileged approvals faster than it can invalidate them has already biased itself toward attacker persistence.
  4. Signer-set and environment version
    • Approval validity should be tied to the signer set, policy engine, transaction-authoring surface, and security posture that existed at review time.
    • Signer rotation, custody-dashboard compromise, browser-delivery compromise, or security-council reconfiguration should not leave old privileged approvals equally live by default.
  5. Outstanding inventory
    • Operators and monitors should be able to enumerate every still-executable privileged object: durable nonce accounts, queued proposals, pending multisig transactions, partially signed bundles, or stored admin payloads.
    • If responders cannot answer what dangerous approvals are still alive right now?, they do not yet control the incident.
  6. Consumption semantics
    • Execution should clearly consume or retire the approval object, and stale or superseded objects should not remain replayable through adjacent queues, nonce reuse, or delayed relay machinery.
    • One approval should imply one bounded execution story, not one lingering class of future opportunities.

Three approval-lifetime questions healthy systems should not collapse

  • Is this the exact privileged object operators meant to approve?
  • Should that object still count as fresh under the signer set, coordinator, browser, nonce, and incident state that exist now?
  • If it is still fresh enough to exist, how much authority should it still be allowed to retain right now?
  • Many custody failures answer only the first question. They preserve object identity better than they preserve freshness, and they preserve freshness better than they preserve remaining authority budget.
  • Delayed-execution systems fail open when they treat identity, freshness, and surviving privilege scope as one binary signature valid fact.
  • The healthy move is to force those three checks to shrink separately: identity pinning proves what the object is, expiry and revocation prove whether it should still live, and privilege-lane / loss-budget design proves how much damage it could still do before containment.

What sound design looks like

  • High-blast-radius actions prefer just-in-time approval over long-lived stored authority. The safest root action is the one that expires before the attacker finishes reconnaissance.
  • Stored approvals have explicit TTLs, approval timestamps, signer-set versions, and machine-visible expiry state instead of valid until someone remembers to cancel it semantics.
  • Freshness and scope are separate checks. A queued approval that still matches the reviewed payload should not automatically keep yesterday’s authority class, signer-set assumptions, or loss budget if the surrounding environment has drifted.
  • Cancellation and execution live on equal footing operationally. Teams can enumerate pending privileged objects, cancel them in bulk, and prove that the invalidation actually propagated.
  • Security events automatically change approval validity. Signer rotation, proposal-service compromise, browser compromise, lost device, suspicious retry, or policy-engine drift should invalidate or at least force re-attestation for outstanding root actions.
  • Recovery from signer-intent incidents is specific and aggressive: once review-surface integrity is in doubt, responders treat queued proposals, partially collected signatures, durable-nonce admin payloads, cached transaction objects, and coordinator-held root actions as already-compromised authority until proven dead.
  • Delayed execution lanes stay narrow. If an action must remain live after review, it should be tightly bound to one exact execution envelope rather than to open-ended admin capability.
  • Monitoring cares about pending authority, not only executed authority. A live but unexecuted admin bundle is already part of the control surface.

Healthy architectural shapes

1. Fresh-review-only root actions

  • The cleanest design for upgrades, owner changes, module installs, market listings, oracle rewrites, or mint-right changes is often sign close to execution or do not sign yet.
  • If the workflow does not need delay, do not manufacture one by storing dangerous approvals indefinitely.

2. Expiring stored approvals with forced re-attestation

  • If delayed execution is required, approvals should carry explicit expiry and require fresh quorum after that point.
  • Re-attestation should mean more than replaying old signatures through a new coordinator; it should recreate a real review moment under current signer and policy conditions.

3. Cancellation-first pending-action queues

  • Queues should be built so that listing, inspecting, and canceling pending privileged objects is easy for humans and for automated monitors.
  • The operator experience should make suspicious queued authority feel like an urgent object to clear, not archival background state.

4. Security-event-triggered mass invalidation

  • Systems should support one clean invalidate all outstanding approvals for class X / signer set Y / environment version Z response.
  • Incident response should not require responders to rediscover every durable nonce, stored proposal, or half-collected transaction by hand.

5. Privilege-tiered approval lifetime

  • Routine treasury payments, medium-risk parameter changes, and root-control mutations should not all inherit the same pending-validity horizon.
  • The more durable the authority the action creates, the less acceptable long-lived pre-approval becomes.

6. Privilege-class lane partitioning

  • High-blast-radius actions should not share the same delayed-execution lane as routine payouts just because the signing stack makes that operationally convenient.
  • Durable nonce accounts, proposal queues, coordinator namespaces, and offline-signing workflows should be partitioned by privilege class so a harvested approval from a normal ops lane cannot later authorize ownership transfer, module install, market listing, oracle rewrite, or mint-right expansion.
  • The healthiest root-control lane is sparse, short-lived, separately monitored, and easy to drain or rotate after use.

Failure-prevention checklist

  • Inventory every surface that can store future privileged authority: durable nonces, pending multisig transactions, queued Safe or Squads proposals, offline-signed bundles, delayed relays, timelock-adjacent admin wrappers, and partially collected threshold payloads.
  • Assign explicit maximum lifetimes by action class. Owner changes, upgrades, module installs, market listings, oracle rewrites, minter grants, and withdrawal-limit changes should usually have the shortest validity windows.
  • Make signer-set changes, policy-engine changes, custody-dashboard compromise, browser-delivery compromise, and device-loss response automatically invalidate or quarantine outstanding privileged approvals.
  • Bind each stored approval to one machine-checkable execution envelope and one signer-set / environment version. Freshness without identity is weak; identity without freshness is still dangerous.
  • Re-attestation should recreate a real review moment under the current signer and environment version, not merely replay cached signatures or extend the TTL around an old privileged envelope.
  • Keep pending-approval inventory observable: emit hashes, creation time, expiry time, action class, cancellation state, and signer-set version so monitors can treat dormant root authority as live risk.
  • Ensure cancellation is materially easier than execution. If a suspicious approval is harder to kill than to broadcast, the workflow is attacker-favorable.
  • Alert on aged pending privileged objects, especially those nearing or exceeding their intended review horizon.
  • Tie pending-authority lifetime to privilege budget. Approvals that can rewrite ownership, implementations, withdrawal limits, collateral admission, or mint rights should die fastest and live in the sparsest queue.
  • Require fresh re-review after unexplained signing anomalies, retries, wallet glitches, simulation mismatch, or any suspicion that the review surface was compromised.
  • Separate routine transfer queues, durable nonce accounts, and proposal coordinators from root-control queues so blind-sign or dashboard compromise cannot quietly harvest long-lived upgrade authority inside ordinary payment workflows.
  • Rehearse incident response for harvested but not yet executed approvals as a first-class scenario, not as a strange edge case.
  • For signer-intent incidents, include proposal-service drains, Safe / Squads queue review, durable-nonce invalidation, pending-bundle cancellation, and explicit proof that no partially collected root-action object survived the cleanup window.

Audit prompts

  • Which exact privileged actions can remain executable after the original signing session ends, and where are those pending objects stored or represented?
  • What proves a stored approval is still fresh rather than merely once valid?
  • Which signer-set change, coordinator compromise, browser compromise, or device-loss event automatically invalidates outstanding privileged approvals?
  • Can responders enumerate every still-live privileged object from chain state and coordinator state without relying on tribal memory?
  • How quickly can operators cancel a suspicious queued approval relative to the fastest possible attacker execution path?
  • Do pending approvals expire by default, or do they remain live until explicit cancellation forever?
  • Does re-approval actually recreate a fresh review moment under the current environment, or does the coordinator simply re-wrap, re-time, or re-broadcast an older privileged envelope?
  • Are identity, freshness, and remaining authority budget checked independently, or has the workflow collapsed them into one binary signature valid property?
  • Are high-blast-radius actions forced into shorter lifetimes or fresh-review-only workflows, or do they share the same persistence model as ordinary transfers?
  • Do root-control actions share durable nonce accounts, queued-proposal infrastructure, or coordinator state with routine payout workflows that operate under looser review habits?
  • If the system uses durable nonce or offline-signing machinery, what exact policy stops a harvested approval from waiting until signer rotation, lower staffing, or a better market window?
  • After a security incident, does the runbook invalidate outstanding approvals as aggressively as it rotates keys and freezes UIs?
  • If the signer-facing UI, transaction-service, proposal gateway, or custody coordinator may have shown one object while signing another, what exact bulk-revocation step kills every queued or partially collected privileged action before the attacker chooses a later broadcast window?
  • What evidence would let incident responders prove that no dangerous stored approval survived the containment step?

Lessons that should already be standard

  • Valid signature and currently acceptable authority are different properties.
  • Same payload, still fresh, and still entitled to this much authority are also different properties.
  • Expiry is not UX polish; it is a security primitive for delayed privileged actions.
  • Attackers like time separation because it turns one successful deception or compromise into many later execution choices.
  • Shared delayed-execution lanes erase privilege boundaries. If the same stored-approval machinery serves routine payouts and root-control mutation, attackers will aim for the quieter review lane and cash out in the louder authority domain.
  • Rotating signers without clearing queued privileged objects may leave the real blast radius largely intact.
  • Re-review that only extends time without recreating signer-intent and environment binding is just durable authority with better paperwork.
  • Pending authority belongs on the custody map. If it can still move admin truth later, it is part of today’s control surface already.
  • The safest delayed approval is the one whose lifetime, revocation path, signer-set assumptions, and surviving authority budget are explicit enough that responders can reason about it under stress.

Where this note helps most

  • Start here when the sharper design question is why was a previously collected privileged approval still live later?
  • Pair with blind-sign-payload-substitution when the exploit harvested the wrong approval object and then benefited from the fact that it stayed executable long after review.
  • Pair with signer-intent-truth-security-object when the primary question is what exact machine-checkable approval object human review should have preserved from proposal through execution.
  • Pair with execution-envelope-identity-pinning when delayed authority also failed to pin the exact target, code identity, or privileged call primitive across time.
  • Pair with privileged-action-lane-separation-and-ceremony-escalation when the more structural question is why the same stored-approval lane could authorize both ordinary payouts and durable control-plane mutation.
  • Keep timelock-action-bundle-commitment nearby as the governance-side cousin: that note is about whether delayed execution committed one exact action bundle, while this note is about whether a delayed privileged approval should have remained live at all.

Internal linkages

Control surface

Graph View

Backlinks