Portfolio → Tetherlock
An access-control component for a local workspace. It lets the host application open the workspace only when three things are true at the same time: the person signed in is allowed in, a signed token is on the inserted drive, and the password matches. When a later check finds the drive gone, it tells the application to lock the workspace.
Swipe sideways to see the whole diagram.
A local workspace needs both an opening rule and a rule for ending access when the required drive is no longer present.
For this personal project, I set the access rules, key design, and lock lifecycle, reviewed designs, and tested through use. AI coding agents implemented the module.
Inspect the real command and test output and key-design decisions, alongside the host application's responsibilities and limits.
A design write-up with real command and test output. The source is on GitHub; there is no recording or third-party audit. Where something is designed but unproven, this page says so.
A local workspace holds sensitive files. It should open only when three things are true at the same time: the person signed in is allowed in, the right drive is plugged in, and they know the password. It should close again as soon as the drive leaves.
The account must be allowed in, a signed token must be on the drive, and the password must match. If the account is not allowed in, the password prompt never appears.
Every open workspace is re-checked on each cycle. A missing, replaced or no-longer-valid token locks that workspace, and only that one.
A separate maintenance token lists exactly what it allows. The session ends on its own after 30 minutes by default, or the moment the drive is removed.
Swipe sideways to see the whole diagram.
Swipe sideways to see the whole diagram.
An open area is re-checked on every cycle. If the drive is removed, the token is replaced, expires or was signed by a key that has been phased out, or the account is no longer allowed in, that area locks and the application is told to close it. Areas opened by other drives stay open. Closing screens and refusing data operations is the application's job; Tetherlock tells it when.
A separate token lists the capabilities it allows, and only ones the application recognises are granted. The session lives in memory, lasts 30 minutes by default, and every use re-checks the clock and the token. Removing the drive ends it before the next action.
Real command and test output with freshly generated demo keys, captured 2026-09-22 and 2026-09-26. Paths are shortened and the drive serial number is hidden. Tap a screen to open it full size.
Typing a password takes seconds, and in that time the drive can be pulled or swapped for another at the same drive letter. So the token is re-read and re-verified after the password and before anything opens.
Rejected: checking the drive once, before the prompt, and trusting that result afterwards.
There is no recovery key and no bypass. The only code that grants access runs after the password check. The cost is accepted: lose every signing key, and trust has to be set up again from scratch.
Rejected: an emergency override “so it can always be recovered”. A backdoor becomes the easiest way in.
If a check fails with an unexpected error, or a token turns unreadable while the area is open, the area is locked first and the error is reported after. The owner may occasionally have to unlock again.
The other way round, staying open until someone looks, leaves the door open for as long as nobody notices.
Tetherlock decides whether a protected workspace may open, and closes it again. It does not encrypt the files inside: the workspace password is checked, but it is not an encryption key. Keeping the drive's contents unreadable is the job of full-disk encryption. It also cannot tell a drive from an exact bit-for-bit copy of it.
If this is the kind of thinking you want on your team, the same reasoning shows up in AI Control Center, where an approval only counts against the exact version of the work it was given for.