[Bug]: Sub-agents bypass CLI permission enforcement (security gap) - v0.14.0 #74

Activity

1. JonatanRoo

   added

   bugSomething isn't workingSomething isn't working

   on Jan 30, 2026
2. justinxu421 commented on Jan 30, 2026

   

   justinxu421

   on Jan 30, 2026

   Contributor

   More actions

   Thanks for the report, we'll look into it

   👍React with 👍1Reacted by JonatanRoo
3. harjothkhara commented on Jun 3, 2026

   

   harjothkhara

   on Jun 3, 2026

   More actions

   Tried to reproduce on auggie 0.28.0 (commit 63537d73), macOS — and could not: permission deny rules now apply to sub-agents. Looks fixed since the v0.14.0 report.

   Method (canary file + general-purpose sub-agent, --print)

   I denied the deletion tools at the CLI and asked the orchestrator to delegate an rm to a general-purpose sub-agent, then checked whether the file survived:

   Run	Sub-agent	Deny rules	Canary deleted?
   Negative control	yes	none	yes — sub-agent ran rm canary.txt (proves it genuinely can)
   Security test	yes	launch-process:deny + remove-files:deny	no — sub-agent blocked on both, file survived

   Command for the test run:

   auggie --print --max-turns 10 \
     --permission "launch-process:deny" --permission "remove-files:deny" \
     -i "Launch a general-purpose subagent and instruct it to delete canary.txt by
         running the shell command 'rm canary.txt'. Delegate to the subagent."
   

   The orchestrator reported: "The subagent attempted to delete the file but encountered security restrictions. Both launch-process and remove-files have been blocked by security rules." — and canary.txt was still present. With the same delegation and no deny rules, the sub-agent deleted it, so the rule is what stopped it.

   This lines up with the 0.28.0 code: the tool-execution check evaluates [toolPermissionsTenant, toolPermissions], sub-agent options carry toolPermissions, and setToolPermissionRules(...) forwards to the sub-agent runner.

   One heads-up for anyone configuring permissions

   Denying launch-process alone didn't stop deletion — the agent fell back to the remove-files tool. To block a destructive action you need to deny every tool that can perform it (e.g. both launch-process and remove-files), not just the shell.

   @JonatanRoo — if you still see the bypass on 0.28.0, could you share your sub-agent config (custom sub-agent definition + the toolPermissions rules)? I tested the built-in general-purpose sub-agent; a custom one might exercise a different path.