No Answer Should Never Mean Full Access

I had a system for deciding how much a task was allowed to do on its own. Some tasks needed a person watching every step. Others had been cleared to run further without anyone standing over them. The setting that recorded which was which started out as optional, meaning simply: nobody has decided yet.

That looked harmless while I was first wiring it together. It wasn’t. The part of the system that turned that setting into an actual instruction treated “nobody has decided yet” as the same thing as “run with no restrictions at all.” An access level nobody had chosen silently became the widest access level available, on exactly the two situations where it mattered most: a task starting on its own, and a task picking back up after being interrupted.

That’s backwards. Nobody having decided is not a harmless placeholder. It’s a decision that was never made, and treating it as full permission is the same as making the riskiest possible decision by default.

It got worse on restart

A task starting fresh usually had its access level passed in from whoever set it up. A task that had been interrupted and picked back up didn’t have that same guarantee. When a task resumed, it could come back with no access level attached at all, and the system quietly used the widest, least restricted setting again, without anyone choosing that.

I had a permission system that looked complete on paper, with a real gap sitting in the two places most likely to run without anyone watching.

The fix that would have half-worked

My first idea was to patch the one spot where the problem first showed up, and require an access level to be set there specifically. That would have closed that one door. It wouldn’t have touched every other way a task could start or resume, and it would have left the actual decision about access scattered across several different places, each capable of getting it slightly wrong in its own way.

My second idea was to keep the “nobody decided yet” setting, but change what it meant, so an unset value defaulted to the narrowest access instead of the widest. That’s safer, but it still leaves the door open. Some future addition to the system could still treat an unset value as valid and move ahead with it. I didn’t want a safer default. I wanted no default at all.

What actually fixed it

The real fix removed the possibility of an unset value ever reaching the point of deciding anything. Every task now has to go through one single place that resolves access, and that place only produces two outcomes: a person is directly present and has approved it, or the task has explicitly cleared the requirements to run on its own at a defined level. There’s no third outcome that means “run wide open because nothing was specified.”

Every place a task can start or come back after an interruption now has to hold one of those two outcomes before it’s allowed to proceed. If it doesn’t have one, it doesn’t run. No fallback, no assumption, no quiet default standing in for a decision nobody actually made.

Where AI fits

An assistant is useful for auditing this kind of thing: finding every place a task can start or resume, checking whether each one is guaranteed to have an explicit, confirmed access level, and flagging anywhere an unset value could sneak through as permission. It shouldn’t be the one deciding what the correct access level is, and it shouldn’t change a permission setting on its own.

The human decision

A person decides how much access any given task actually deserves, and who’s allowed to widen that later. That’s a real judgment call about risk, and it belongs with someone accountable for the outcome, not buried in a default value nobody chose.

The lesson

Nobody having decided what a task is allowed to do should mean the task doesn’t run, not that it runs with no restrictions. If your process has a setting that can be left unset, especially one connected to access or permission, check what happens when it’s missing on every path, including the ones that restart or resume, and make sure “missing” refuses instead of quietly opening the door.

The paired Build Log walks through the exact default that had gone unnoticed, the two half-fixes that were rejected, and the single access check that now has to succeed before anything, anywhere in the system, is allowed to run.

dxdev LESSON · paste into your AI agent

LESSON: An unset permission should refuse, not default to full access

WHAT TO SHARE:
A de-identified description of how a task, account, or process gets its level of access, including any point where it can start, restart, or resume, and what happens if that access level was never explicitly set.

ASK YOUR AGENT TO:
1. Find every place a task or process starts, restarts, or resumes, and check whether it's guaranteed to carry an explicit, confirmed access level each time.
2. Identify what currently happens when that access level is missing or wasn't set, and whether that missing case is treated as more permissive than it should be.
3. Recommend replacing any "missing means allowed" behavior with a hard refusal until access is explicitly confirmed.
4. Check whether access decisions are being made in more than one place, and whether they could disagree with each other.

RETURN:
A list of every start or resume path checked, which ones allow an unset access level to proceed, and a recommendation for where access should be confirmed once, in one place, before anything runs.

BOUNDARY: Do not change any permission or access setting yourself. A person reviews the findings and decides what the correct access level should be.