Managing tool permissions

You can use the /tools command to manage permissions for tools that Kiro uses to perform actions on your system. This provides granular control over what actions Kiro can perform.

Tools commands

To view the current permission settings for all tools:

$ kiro-cli chat
Kiro> /tools

This displays a list of all available tools and their current permission status (trusted or per-request).

Tool permissions have two possible states:

• Trusted: Kiro can use the tool without asking for confirmation each time.
• Per-request: Kiro must ask for your confirmation each time before using the tool.

To trust or untrust a specific tool for the current session:

Kiro> /tools trust read
Kiro> /tools untrust shell

You can also trust all tools at once with /tools trust-all(equivalent to the deprecated /acceptall command):

Kiro> /tools trust-all

The following image shows the status of the CLI tools when they are all in their default trust status.

The following tools are natively available for Kiro to use:

Available tools

When Kiro attempts to use a tool that doesn't have explicit permission, it will ask for your approval before proceeding. You can choose to allow or deny the action, or trust the tool for the remainder of your session.

Shell command trust levels

When Kiro asks to run a shell command, you can choose how broadly to trust it. Instead of trusting the entire shell tool, you get an interactive picker with tiered options scoped to the specific command. For example, if Kiro wants to run git pull --rebase, you see these options:

Press (↑↓) to navigate (⏎) to select scope
> Full command          → git pull --rebase
  Partial command       → git pull *
  Base command          → git *
  Entire Tool           → *

The trust tiers from most restrictive to least restrictive are:

After you select a tier, Kiro confirms the trusted pattern (for example, ✓ Trusted: git pull --rebase). The picker only shows tiers that are meaningfully different — if the command has no subcommand, the partial tier is skipped. For chained commands (pipes, &&), Kiro generates trust patterns for each command in the chain and deduplicates them.

Trusted patterns persist for the session and are stored as regex in the agent's allowedCommands setting. For more on how allowedCommands works, see Shell tool settings.

Read and write path trust levels

The read and write tools also support granular trust when accessing paths outside the current working directory. By default, both tools are trusted for the current working directory. When Kiro needs to read or write a file outside that directory, you get a picker with tiered options:

Press (↑↓) to navigate (⏎) to select scope
> Specific paths       → ~/.config/app/settings.json
  Complete directory   → ~/.config/app
  Entire Tool          → *

The trust tiers from most restrictive to least restrictive are:

Paths within the current working directory do not trigger the picker.

Default trust and permission examples

Each tool has a default trust behavior. read is trusted by default for the current working directory. When Kiro uses a tool, it shows you the trust permission being used. You can also specify trust permissions as part of starting a kiro-cli chat session.

Here are some examples of when to use different permission levels:

• Trust read: When you want Kiro to read files without confirmation, such as when exploring a codebase.
• Trust write: When you're actively working on a project and want Kiro to help you create or modify files.
• Untrust shell: When working in sensitive environments where you want to review all commands before execution.
• Untrust aws: When working with production AWS resources to prevent unintended changes.