Permission policies

Deploy permission policies to your fleet to restrict what the agent can do — block dangerous shell commands, deny web access, or force prompts for specific capabilities. These rules are enforced at the agent level and cannot be overridden by individual users.

When an admin rule and a user rule target the same capability, resolution is simple:

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. Admins restrict; they don't grant.

Place a JSON policy file at the OS-protected path for your platform. These paths require administrator or root access, so regular users cannot modify them. The policy applies to every Kiro surface on the machine — both 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 — 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 — 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 cannot be overridden.

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

• Model governance — control which AI models are available
• MCP governance — control which MCP servers users can connect
• Web tools governance — console toggle that disables web tools entirely
• Managed updates — control which IDE versions reach your fleet

Permission policies give you fine-grained control over the agent's behavior at the capability and pattern level. For simple on/off toggles, the console-based governance settings may be sufficient. Use permission policies when you need pattern matching, allowlisting, or capability-specific restrictions that the console doesn't offer.