PermissionRule maps a specific tool and call pattern to one of three behaviors: ALLOW, DENY, or ASK. Rules are evaluated with the highest priority in every mode: deny and ask rules first, allow rules after the tool’s own checks.
Each rule consists of the following fields. When the permission engine evaluates a rule, it calls the tool’s match_rule() method with rule_content and the actual call input to determine whether the rule applies.
str
required
Tool this rule applies to:
"Bash", "Read", "Write", "Edit", or any custom tool name.str | None
required
Match pattern, whose semantics depend on
tool_name:- Bash: wildcard prefix pattern (
npm run:*matchesnpm run build,npm run test) - Read / Write / Edit: glob pattern (
src/**/*.pymatches any.pyundersrc/) - Other tools: exact JSON-serialized parameter match
PermissionBehavior
required
ALLOW, DENY, or ASKstr
required
Origin of the rule:
"userSettings", "projectSettings", "session", etc.Pattern Examples
rule_content is consumed by each tool’s match_rule() method and auto-generated by ToolBase.generate_suggestions(). Because both methods are part of the tool interface, each tool can define its own pattern syntax and matching logic independently.
For AgentScope’s built-in tools, the patterns are as follows:
- Bash
- File Tools (Read / Write / Edit)
Matches against the
command parameter. Pattern format is COMMAND_PREFIX:*: the prefix is the leading token of the command, and * matches any arguments that follow.Configure Rules
Rules enter the engine in two ways: statically at initialization, or dynamically when the user accepts a suggested rule at runtime. At initialization: pass rules intoPermissionContext when creating the agent:
UserConfirmResultEvent.rules; the agent adds them to the engine automatically:
An allow rule cannot override a tool-emitted safety ASK (
bypass_immune=True), such as a write into ~/.ssh/. See the safety check contract.