Good catch — this is a real gap in the boundary story as written, and worth spelling out.
The precise framing: isInScope gates the granting of authority (the approve call dispatched through execute), but a standing ERC-20 allowance is authority that lives in the token contract, outside the Agent’s enforcement perimeter. Once granted, the spender’s transferFrom is a transaction between the token and the spender — the Agent is not in the call path, so no Scope check or reasoning record can apply. Scope tightening and setExecutor(account, false) bound future dispatches, not residual authority.
I don’t think this is fixable at the interface level without over-constraining implementations, so I’ll add a Security Considerations paragraph to the PR — “Residual approvals outlive the Scope” — covering:
The failure mode made explicit: disabling an Executor or tightening the Scope does not claw back previously granted allowances; allowance revocation must be treated as part of any Executor rotation or Scope change.
Mitigations: prefer transaction-scoped approvals (approve exact amount, spend, zero it in the same bundle) or expiring-permit schemes so standing allowances never accumulate; revoke outstanding allowances via execute before rotating the Executor; integrators can enumerate residual authority off-chain from each token’s Approval events.
The ordering subtlety your question surfaces: revocation itself goes through execute, so an Agent whose only Executor was just disabled has no live revocation channel until the Owner enables a cleanup Executor and scopes it for approve(spender, 0). The Owner is never bricked, but the safe ordering is revoke-then-rotate, and the spec should say so.
Whether an implementation offers an Owner-callable “revoke-all” convenience stays implementer-defined (§7), consistent with how the sweep/rescue surface is handled. Will update the PR and note it here.
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | ERC-TBA: Agent Credit Backers | 0 | 8.78 | 26-10-2026 |
| 2 | ERC-8226: Regulated Agent Mandate | 0 | 8.97 | 14-08-2026 |
| 3 | A map of the agent-mandate ERCs — what each one actually does | 0 | 11.48 | 14-08-2026 |
| 4 | ERC-8370: Inheritable Agent Mandates | 0 | 8.79 | 14-08-2026 |
| 5 | ERC-8354: Confidential Agent Policy Verdicts | 0 | 12.87 | 24-07-2026 |
| 6 | ERC-8004: Trustless Agents | 0 | 8.54 | 27-07-2026 |
| 7 | Proposing a family of candidate ERC interfaces for titled asset infrastructure — architecture review | 0 | 7.85 | 27-07-2026 |
| 8 | ERC-8335: Account-Level Transfer With Authorization | 0 | 7 | 10-07-2026 |
| 9 | ERC-8337: Agent Memory State | 0 | 7.65 | 26-07-2026 |