When Unset Quietly Meant Unrestricted on Every Restart

We had a setting that decided how much a task could do on its own. Some tasks needed a person watching every step. Others had been cleared to run further without anyone standing over them. That setting started out optional, which simply meant nobody had decided yet.

It looked harmless while we were wiring things together. It wasn’t. The part of the system that turned the setting into an actual instruction treated “nobody has decided yet” as “run with no restrictions at all.” An access level nobody chose quietly became the widest one available. It did that in the two situations where it mattered most: a task starting on its own, and a task picking back up after an interruption.

That’s backwards. A decision nobody made is not a permission. Treating it as one makes the riskiest choice by default.

Restarts made it worse

A task starting fresh usually had its access level passed in by whoever set it up. A task that had been interrupted and resumed had no such guarantee. It could come back with no access level attached at all, and the system reached for the widest setting again without anyone choosing it.

On paper the permission system looked complete. The gap sat in the two places most likely to run with nobody watching.

Two fixes that would have half-worked

Our first idea was to patch the one spot where the problem showed up and require an access level there. That would have closed one door. Every other way a task could start or resume would still be open, and the decision about access would stay scattered across several places, each able to get it slightly wrong in its own way.

Our second idea was to keep the “nobody decided yet” setting but change its meaning, so an unset value fell back to the narrowest access instead of the widest. That’s safer, but it still leaves a door open. Some future addition could treat an unset value as valid and move ahead with it. We wanted no default at all.

What fixed it

We made it impossible for an unset value to reach the point of deciding anything. Every task now goes through one single place that resolves access, and that place produces only 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 is no third outcome that means “run wide open because nothing was specified.”

Every place a task can start or come back after an interruption must now 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 default standing in for a decision nobody made.

What an assistant is good for here

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

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

If your process has a setting that can be left unset, especially one tied to access or permission, check what happens when it’s missing on every path, including the ones that restart or resume. Make sure “missing” means the task does not 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.