This one is a pattern, not an event, and it is assembled from three cases you have already read.
Ronin, March 2022. A validator permission granted for a genuine operational reason in late 2021, intended to be temporary. It lapsed in November. The allowlist entry was never removed. Four months later it supplied the fifth of five signatures required for a $625M withdrawal.
Ledger Connect Kit, December 2023. A former employee's package-registry account, whose access had never been revoked, used to publish a wallet drainer into the front ends of several major protocols.
3Commas, 2022. Roughly 100,000 API keys, a great many belonging to bots their owners had stopped using, leaked and still working.
In all three the grant was correct when it was made.
And in all three, nobody made a bad decision about it afterwards, because nobody made any decision about it afterwards.
The failure is structural rather than personal. Granting access is prompted, deliberate, and takes seconds: something asks, you consider, you approve. Removing access is unprompted, effortful, and depends entirely on somebody remembering.
Any system with that asymmetry accumulates live access indefinitely. Yours is doing it now.
This is the last lesson of the last Freshman course, and it is deliberately the least technical. Mechanisms change. The asymmetry does not.
Why a policy rather than a decision
You will not be at your best when a grant is requested.
The request arrives when something you want is one approval away. It arrives at the end of a process you have already invested in. It frequently arrives with urgency attached, and F106-02 established what urgency is for.
Judgment is exactly the faculty these attacks are built to defeat. A rule decided in advance, in a calm hour, runs without it.
So the output of this lesson is a written page, in the same spirit as F104-06's specification and F110-06's continuity plan. Three of the four artefacts you leave the Freshman level with are documents, and that is not an accident.
Four fields for every grant
Scope: the minimum that works. Read-only unless writing is required. A limit rather than unlimited. One token rather than a wallet. F109-02's finding is that a portfolio tracker asking for trade permission has told you something.
Owner: which tier does this touch? F104-02's architecture is the containment, and this field is what makes it real. A grant on the burner is a shrug. A grant on the vault requires a reason you would defend to somebody else.
Expiry: a date. Since the mechanism will not expire it, per F109-01, the date lives in your calendar. "Until I stop using this" is not a date and it is exactly what Ronin had.
Reason: one line. What it is for. This is the field that makes the review possible, because a grant with no recorded purpose is one you will never confidently revoke, and unexplained entries survive every audit by default.
These are decided. They are not assessed at the moment of the request, which is the point of writing them down.
Never grant unlimited when a limit works. The convenience is one extra approval later. The exposure is everything in that token.
Never grant withdrawal or transfer permission to an automated service. No exceptions at this level. Trade permission is already sufficient to drain an account, per F109-02, so anything beyond it is a second complete loss added to the first.
Never approve a request you did not initiate. The direction is the tell, exactly as in F104-03. You go to the service; the request does not come to you.
Revoke on any incident anywhere in your stack, immediately, without waiting for confirmation. The 3Commas users who revoked on the October reports kept their money. The ones who waited for the 28 December confirmation, eighteen days after the company said it had found no evidence, did not.
The quarterly review
A procedure with a defined output, not an intention. Thirty minutes, four times a year, in a calendar entry with a reminder.
1. Pull the inventory. F109-01's five channels: on-chain approvals per wallet, API keys per venue, sessions and connected sites, OAuth links, and any account delegation.
2. Compare against the register. Anything present that is not in your written register is the finding. It got granted without going through the policy, and that is worth knowing about the policy as much as about the grant.
3. Apply the question. For each entry: would I grant this today? If no, revoke. This resolves most of a list faster than any scoring exercise.
4. Revoke everything expired, everything unexplained, and everything belonging to a service you have stopped using.
5. Write the date on the register, so the next review knows what has already been looked at.
The output is a revised register and a set of revocations, and F109-L is this performed once with evidence captured before and after.
Costs, honestly
Revocation is not free and pretending otherwise is how a policy gets abandoned in month three.
On-chain revocations cost gas. Dozens of stale approvals on an expensive chain can cost real money, and the honest response is to prioritise: revoke by exposure, largest first, and accept that a stale approval on an empty burner can wait.
Rotating API keys costs reconfiguration. Whatever used the old key stops working until you fix it. Budget the time or you will defer it indefinitely.
Terminating sessions costs a login, and nothing else, which is why F109-03 says be aggressive there and nowhere else in this course does.
Prioritise by what a grant can reach. A vault-tier grant gets revoked regardless of cost. A burner-tier grant on a dead protocol can wait for a cheap block.
Closing the Freshman level
You started this level not knowing what a blockchain guaranteed. You now have the machine, the money question, the keys, an architecture, the signing discipline, a threat model, venues, records, delegation, a continuity plan, and the verification habits for an era where the face and the voice cannot be trusted.
The gate is the Custody Practical: the three tiers built with real funds, the wipe drill survived, the written threat exam, the continuity plan, the access audit, and F106-L, The Gauntlet, where six to ten simulated attacks arrive across fourteen days without warning and the pass standard is a 100 percent catch rate on the critical ones, because in this domain a 90 percent catch rate is a total loss with extra steps.
What the level was actually for is narrower than the syllabus suggests, and it is worth stating plainly at the end.
You will not lose money to theft, error, or misunderstanding. Not because you became clever enough to detect every attack, which nobody is, but because you have built procedures that work when your judgment is compromised, and because you have written down the decisions rather than leaving them to be made at the worst possible moment by somebody under pressure.
That is the whole discipline. Everything above the Freshman level assumes you have it.
Decide grants in advance, because the request arrives at the attacker's chosen moment and judgment is the faculty the attack is designed to defeat. Give every grant four fields: the minimum scope that works, the tier it touches, an expiry date in your calendar since the mechanism will not supply one, and a one-line reason so that the next review can act on it. Then run the review quarterly, revoke anything expired, unexplained or belonging to a service you have stopped using, and prioritise by what a grant can reach rather than by what it costs to remove. The structural fact underneath all of it is that granting is prompted and instant while revoking is unprompted and effortful, which is why Ronin, Connect Kit and 3Commas all lost to access that was correct when it was granted and that nobody ever decided to end.