The Silent Default That Let My Agents Skip Every Permission Check

Jun 5, 2026 · 4 min read

On June 5, commit commit-9547 closed an authority hole that had given every agent the same answer when it asked for permission: skip the checks.

I had built a proposal store so agents could take approved work and dispatch it without waiting for me to manually re-enter the same instruction. A proposal had a handoff, required capabilities, a trust context, and a dispatch posture. Approval turned that proposal into a bridge session.

The problem was not in the proposal store. It was in a default lower down the stack.

The bridge engine represented posture as posture | null. That looked harmless while I was wiring the first paths. null meant that no explicit posture had been chosen yet. But the code that turned a posture into permission arguments treated null as the unrestricted CLI path:

--dangerously-skip-permissions

That was backwards. Missing authority was not a temporary state. It was an authorization failure.

It was worse on resume. A fresh spawn could carry posture in from the caller. A recreated session had no equivalent guarantee. When send() rebuilt a session, it could do so with no posture at all, and the bridge silently used the unrestricted argument again. I had a permission system on paper, and a bypass on the two paths that mattered most: autonomous dispatch and resume.

The diagnostic was a type with an unsafe meaning

The first symptom was not an error. It was the absence of one.

I expected an autonomous act with no resolved posture to be rejected before a session existed. Instead, the bridge ran. Tracing the call chain showed the sequence: approveAndDispatch assembled its own capability gate and posture, spawnFresh() accepted an optional posture, and permissionArgs() accepted null. Once that null reached the argument builder, the engine selected unrestricted mode.

The proposal store knew whether a proposal was approved. The bridge knew how to launch or resume a process. Neither one owned the complete question: may this act run with these capabilities, under this trust context, in this area?

My first option was to tighten the proposal store. I could have made approveAndDispatch require a posture and added another guard before it invoked the bridge. That would have fixed autonomous dispatch, but not interactive calls from /api/bridge/spawn, message sends through /:sid/message, or session recreation. It also would have left several places responsible for assembling the same policy.

The second option was to preserve the nullable field and change its meaning. null could have mapped to an enforced posture instead of unrestricted mode. That was better, but absence would still look valid. A later caller could forget to resolve authority, receive an implicit posture, and continue. I did not want a safer fallback. I wanted no fallback.

The third option was the one I shipped: introduce a single authority object and make every act obtain one before it can run.

Authority is now an object, not an optional hint

The new server/actAuthority.ts exports one function:

authorizeAct({ act, trust, required, areaKey })

It composes the existing capability gate with dispatch posture and returns an explicit ActAuthority. It has two valid outcomes.

An interactive act, with the operator present and authenticated through the vault key, receives explicit trusted authority. An autonomous act receives an enforced posture only after its requested capabilities pass the gate. Otherwise authorizeAct() refuses the act.

There is no result that means “run unrestricted because nobody specified anything.”

The old type made omission easy to pass through several functions. The new type forces resolution at the boundary. The caller either holds an ActAuthority, or it does not get to cross into the bridge.

In bridgeEngine.ts, permissionArgs() now throws if it receives no authority. spawnFresh() and send() guard up front as well. The change to send() was important. It now accepts the authority explicitly, so re-creating a session cannot silently forget the authority that launched it.

The API routes resolve interactive authority before touching the bridge. Both /api/bridge/spawn and /:sid/message call authorizeAct() and pass the returned object through. The proposal store resolves autonomous authority through that same function in approveAndDispatch, rather than inlining its own gate and posture logic.

interactive API route -> authorizeAct(...) -> ActAuthority -> bridge
proposal approval -> authorizeAct(...) -> ActAuthority -> bridge

Every spawn and every resume needs an authority resolved for the act in front of it.

I kept the handoff contract and changed the invariant

I did not use this fix as an excuse to rewrite dispatch. The existing SpawnFn(handoff, posture) contract stayed intact. That preserved the proposal store’s tested handoff behavior while moving the policy decision out of the store and into the authority module.

The existing lock layer already funnels mutation routes. authorizeAct() exposes act: "mutation" as the extension point for the same pattern. The immediate hole was spawn and resume. The new boundary gives mutations a place to attach without pretending they were already covered.

The implementation touched four files: 175 insertions and 29 deletions. The new authority module accounts for 101 lines. That is safer than scattered guards because duplicated policy invites regression. A future dispatch path makes one explicit call, not a checklist of posture, capability, and trust conditions.

The verification was unglamorous, which is exactly what I wanted. tsc --noEmit reported the same nine pre-existing errors and no new ones. proposalStore.test.ts passed all 6 of 6 cases, preserving the existing gate behavior. The full suite still had eight failures, all reproduced at commit commit-58C7: stale nodes.test.ts cases and two live OpenAI tests with no key. tsx-watch reloaded cleanly on port 3010.

The original bug was a silent default. The fix is a loud invariant. If an act has not been authorized, the bridge cannot turn that absence into permission to run.

AI Skills

Use this lesson with the AI assistant you already use

A permission field typed as optional was meant to mean not yet chosen, but the code turning it into CLI arguments treated the missing value as the fully unrestricted mode, on exactly the two paths that mattered most: autonomous dispatch and session resume.

Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.

Optional: for a visual report and saved memory, run /dxdev first. Don’t have it? Get it at dxdev.com/skills/dxdev. The prompt works without it.

dxdev LESSON · paste into your AI coding agent
LESSON: A nullable authority field that silently maps missing permission to the unrestricted path turns nobody decided into run with no checks
SOURCE: dxdev.com/blog/2026-08-22_fail-closed-agent-authority
WHAT HAPPENED: A dispatch posture field was typed as optional, meant to represent that no explicit authority had been chosen yet. The code that converted posture into permission arguments treated that missing value as the unrestricted mode, meaning an absence of authorization silently became maximum authorization on exactly the two paths that mattered most, autonomous dispatch and session resume, where a recreated session had no guarantee of carrying its original posture forward at all. A first considered fix, tightening only the proposal store that had triggered the bug, would have missed other entry points like interactive API routes and message sends. A second option, changing what the missing value meant, was rejected because an absent value would still look like a valid one to some future caller. The actual fix introduced a single authorization function returning an explicit object with exactly two valid outcomes, trusted for an interactive act or enforced for an autonomous one after its capabilities pass a gate, and no outcome meaning run unrestricted because nothing was specified; every spawn and resume path now throws if it does not hold that object rather than silently defaulting.
THE RULE: A nullable or optional field representing an authorization decision is a bug waiting to happen the moment any code path treats its absence as a valid, permissive default; the fix is not reinterpreting what the missing value means, since absence can still slip through unnoticed, but eliminating the possibility of proceeding without an explicit, resolved authority object at every entry point, including resume and recreation paths, not only the one where the bug was first found.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Any authorization or permission field typed as optional or nullable where the consuming code has a default behavior for the missing case, especially one more permissive than the least-privileged option.
      2. Any authority or permission decision resolved independently in more than one place, such as a proposal store, an API route, and a resume path, rather than through one shared function every caller must go through.
      3. Any session or process resume or recreation path that has not been confirmed to carry forward the same authorization context as the original spawn.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.

Send us what your agent found →

Prefer to talk it through first? See the AI workflow assessment or get in touch.

Lesson: A nullable authority field that silently maps missing permission to the unrestricted path turns nobody decided into run with no checks

Choose your next level of detail

Want the practical version?

How AI Helps starts with the work problem, what improves, and where human judgment still matters.

See how AI helps Start a conversation