Permission policies

Deploy permission policies to your fleet to restrict what the agent can do. You can block dangerous shell commands, deny web access, or force prompts for specific capabilities. These rules take precedence over a user's own permission settings.

When an admin rule and a user rule target the same capability, the more restrictive effect wins:

deny > ask > allow

An admin deny blocks the operation regardless of what the user's personal permissions allow. An admin ask forces a prompt even if the user has an allow rule for that capability.

Admin policies can only use deny or ask, never allow. They can restrict access but cannot grant it. This holds for every grant path a session can carry, including policy presets requested by a client: a preset allow never overrides an admin deny or ask.

Place a JSON policy file at the OS-protected path for your platform. These paths require administrator or root access to modify, which keeps the policy out of reach of a standard user account. The policy applies to every Kiro surface on the machine, because the IDE and the CLI read the same file.

sudo mkdir -p "/Library/Application Support/Kiro"
sudo nano "/Library/Application Support/Kiro/managed-settings.json"

{
  "rules": [
    { "capability": "web_fetch", "effect": "deny" },
    { "capability": "shell", "match": ["rm *", "sudo *"], "effect": "deny" }
  ]
}

Restart Kiro for the policy to take effect.

Each rule follows the same schema as user-authored permissions:

For the full list of capabilities and pattern syntax, see Permissions.

{
  "rules": [
    { "capability": "web_fetch", "match": ["*"], "effect": "deny" },
    { "capability": "web_search", "effect": "deny" },
    { "capability": "shell", "match": ["curl *", "wget *"], "effect": "deny" }
  ]
}

Prevents the agent from fetching URLs, searching the web, or using shell commands that could exfiltrate data.

{
  "rules": [
    {
      "capability": "web_fetch",
      "exclude": ["docs.aws.amazon.com", "*.amazonaws.com", "*.github.com"],
      "effect": "deny"
    }
  ]
}

Denies web fetch to any domain except those in the exclude list. Domains matching the exclude patterns have no admin rule, so they fall through to the user's own permissions, which may allow or ask.

{
  "rules": [
    { "capability": "mcp", "effect": "ask" }
  ]
}

Even if a user has { "capability": "mcp", "effect": "allow" } in their personal permissions, the admin ask wins, so every MCP tool call prompts for confirmation.

{
  "rules": [
    {
      "capability": "shell",
      "match": ["rm *", "sudo *", "chmod *", "chown *", "mkfs *"],
      "effect": "deny"
    }
  ]
}

{
  "rules": [
    {
      "capability": "fs_write",
      "match": ["~/**"],
      "exclude": ["~/.kiro/**"],
      "effect": "deny"
    }
  ]
}

Blocks the agent from writing to the user's home directory (except Kiro's own config directory), even if the user has broader write permissions configured.

Permission policies are validated when Kiro starts:

• Malformed JSON: The entire file is rejected and Kiro fails closed. All tool calls are denied until the file is fixed or removed.
• Invalid effect: Rules with effect: "allow" are rejected (admin policies only permit deny and ask). The entire file fails, with the same fail-closed result.
• Unknown capabilities: Rules with unrecognized capability names are skipped with a warning, but the remaining valid rules still load. This allows newer policies to work on older Kiro versions.
• Unknown fields: Rules with extra fields not in the schema cause the entire file to be rejected. This prevents typos (like effct instead of effect) from silently disabling admin rules.

After deploying the policy:

1. Restart Kiro on a test machine
2. Confirm no policy-validation warning appears on startup. Kiro notifies the user if the policy file failed to load
3. Attempt an action that should be denied (e.g., ask the agent to search the web if you denied web_search)
4. Verify the agent reports a denial with the rule source showing "administration"

When a tool call is denied by an admin policy, the user sees a message indicating the restriction is managed by their organization and that their own permission settings cannot override it.

Permission policies work alongside Kiro's other enterprise governance features:

• Model governance controls which AI models are available
• MCP governance controls which MCP servers users can connect
• Web tools governance disables web tools entirely from the console
• Managed updates controls which IDE versions reach your fleet

Use permission policies when you need pattern matching, allowlisting, or capability-specific restrictions. To turn a whole feature on or off, use the console governance settings instead.