Tool Access Guards

Arguments are measured before any name is compared

evaluate reads the switch, classifies the call, measures its arguments, and only then compares the name.

With enabled false the guard allows at once. Classification runs extract_action_checked: a recognized but malformed action shape is refused, and every classified variant (FileAccess, FileWrite, NetworkEgress, ShellCommand, Patch, CodeExecution, and the rest) passes this guard to the guard that owns it. A generic call then has its serialized arguments counted by a byte-counting JSON writer, which counts bytes as they are written, and is refused above max_args_size: 1 MiB (1,048,576 bytes) by default.

Only then does is_allowed compare the name: the block list first, then the allow list when it is non-empty, then default_action.

Only calls that no extractor claims reach the lists

ToolAction::McpTool is the fallback category; a tool cannot opt into it. crate::action::extract_action_checked tries a network extractor, then filesystem, shell, code execution, browser, database, memory write, memory read, and external API. Each reads the tool name, and sometimes the argument shape, for its own naming conventions. A call none of them claims falls through to:

Ok(ToolAction::McpTool(
    self.tool_name.to_string(),
    self.arguments.clone(),
))

A custom MCP-server tool, a vendor-specific name, anything shaped unlike read_file, http_request, or apply_patch, lands here. Argument shape leaves a call where its name put it: custom_tool invoked with { "path": "/etc/shadow" } stays McpTool, so ForbiddenPathGuard never sees it and these lists decide.

The same routing explains the default block list. The direct name helper blocks shell_exec, but runtime extraction classifies a valid shell call as a shell action, which skips these lists. Capability scope and ShellCommandGuard constrain that request.

The block list answers first, and a non-empty allow list refuses every other name

The default block list is a starting set of four generic capability tools that many MCP servers expose: shell_exec, run_command, raw_file_write, and raw_file_delete. allow starts empty and default_action is Allow, so every other generic name passes. A non-empty allow switches the guard to allowlist mode, as in this policy:

hushspec: "0.1.0"
rules:
  tool_access:
    enabled: true
    allow:
      - read_file
      - list_directory
      - search_files
    block:
      - shell_exec
      - raw_file_delete
    default: block
    max_args_size: 524288

Unlisted generic tool actions now default to deny, and default_action matters only while allow stays empty. The compiled scope also leaves write_file out of authority. write_file is a file action, so the scope check refuses it before this guard's lists could.

Membership is exact string equality on a HashSet<String>. Blocking shell_exec leaves shell_exec_v2 and Shell_Exec open, so add every name and alias your MCP server exposes to block.

A case table makes the split between the two checks visible. An unlisted generic tool reaches this guard and is refused by name; write_file never does, because the scope refuses it first:

policy: ./policy.yaml
server: workspace
cases:
  - name: listed tool
    tool: search_files
    params: {query: "refund_window"}
    expect: allow
  - name: unlisted generic tool
    tool: export_prices
    params: {format: csv}
    expect: deny
    code: mcp-tool
  - name: file write outside the scope
    tool: write_file
    params: {path: /workspace/src/pricing.py}
    expect: deny

chio policy test

policy   ./policy.yaml
PASS  listed tool                    allow
PASS  unlisted generic tool          deny   guard mcp-tool
PASS  file write outside the scope   deny   outside the grant
3 cases: 3 passed

McpToolGuard runs fifth of seven in the default pipeline

GuardPipeline::default_pipeline() registers it after the path allowlist and before the secret scanner:

pub fn default_pipeline() -> Self {
    let mut pipeline = Self::new();
    pipeline.add(Box::new(crate::ForbiddenPathGuard::new()));
    pipeline.add(Box::new(crate::ShellCommandGuard::new()));
    pipeline.add(Box::new(crate::EgressAllowlistGuard::new()));
    pipeline.add(Box::new(crate::PathAllowlistGuard::new()));
    pipeline.add(Box::new(crate::McpToolGuard::new()));
    pipeline.add(Box::new(crate::SecretLeakGuard::new()));
    pipeline.add(Box::new(crate::PatchIntegrityGuard::new()));
    pipeline
}

The second default set, default_runtime_guard_profile(), leaves it out: that constructor's pre_invocation_guards list holds InternalNetworkGuard, AgentVelocityGuard, and an AdvisoryPipeline.

Pair it with the guards for classified actions. ShellCommandGuard and CodeExecutionGuard read shell and code actions, and this guard reads the remaining names and their argument sizes. An innocently named custom tool can still have internal effects, which the host mediates.

Read more in Default Pipelines, which covers both default sets.

Tool access guard reference

pub enum McpDefaultAction {
    #[default]
    Allow,
    Block,
}

pub struct McpToolConfig {
    pub enabled: bool,
    pub allow: Vec<String>,
    pub block: Vec<String>,
    pub default_action: McpDefaultAction,
    pub max_args_size: Option<usize>,
}

// ...

pub enum ToolDecision {
    Allow,
    Block,
}

pub struct McpToolGuard {
    enabled: bool,
    allow_set: HashSet<String>,
    block_set: HashSet<String>,
    default_action: McpDefaultAction,
    max_args_size: usize,
}

impl McpToolGuard {
    pub fn new() -> Self;
    // ...
    pub fn with_config(config: McpToolConfig) -> Self;
    // ...
    pub fn is_allowed(&self, tool_name: &str) -> ToolDecision;
}

impl Default for McpToolConfig {
    fn default() -> Self {
        Self {
            enabled: true,
            allow: vec![],
            block: vec![
                "shell_exec".to_string(),
                "run_command".to_string(),
                "raw_file_write".to_string(),
                "raw_file_delete".to_string(),
            ],
            default_action: McpDefaultAction::Allow,
            max_args_size: Some(default_max_args_size()),
        }
    }
}

Next: govern the calls that leave this guard