Control the Loop: Permissions, Verification, and Self-Improvement
As JiuwenSwarm moves from a local workflow to a distributed, Skill-using system, the cost of an unchecked action grows. This chapter examines how the system decides whether a tool call is allowed, how planning and verification separate intention from mutation, and how different forms of continuity and improvement are kept apart. The practical result is a way to inspect an autonomous run: where was the action authorized, what boundary did it cross, what was checked, and can a proposed improvement be reviewed or reversed?
A tool call is a policy decision
JiuwenSwarm's permission model uses three user-facing action levels: allow, ask, and deny. Allow permits the call to proceed directly. Ask pauses for confirmation. Deny rejects the call. This is more useful than a single “safe mode” switch because the decision can depend on the tool, its parameters, the command or path involved, and the runtime channel.
The policy engine can begin with a whole-tool baseline and then evaluate parameter-level rules. A rule may match a shell command, a path, or another supported argument pattern. Built-in rules provide a separate high-risk layer for destructive deletion, disk and partition writes, download-and-execute patterns, obfuscated execution, reverse shells, privilege escalation, exfiltration, remote execution, resource abuse, and shutdown. The repository includes an explicit deny for shutdown or reboot operations. These rules are not merely warnings in a prompt; they participate in the decision before the tool runs.
Precedence matters. A whole-tool deny stops the call before later parameter rules can make it more specific. A built-in deny cannot be canceled by a user approval override. User parameter-level denial is applied before approval overrides as well. If no deny has already ended the decision, a matching approval override can allow a previously reviewed pattern. Otherwise, the engine combines the applicable results and chooses the stricter allow-or-ask level. A shell command that appears harmless at the tool level can still be escalated to confirmation when it contains chaining or injection-risk operators.
Paths outside the agent workspace add a second boundary. The external-directory checker evaluates whether a path or shell command reaches outside the configured workspace, then combines its result with the current permission level using the stricter outcome. This prevents an approval that was appropriate for a workspace-local operation from silently authorizing the same tool against an unrelated directory.
The result is a decision path rather than a single question:
- identify the tool and relevant arguments;
- apply the whole-tool baseline;
- check built-in and user parameter rules;
- stop immediately on a decisive deny;
- apply only the approval override that survives those earlier checks;
- combine the result with external-directory restrictions;
- ask for confirmation when the remaining policy requires it.
The exact implementation is supplied partly by the openJiuwen Harness dependency, and permission checks can be channel-dependent.