Security

Crew gives an AI agent real tool access — file reads, shell commands, web browsing. The security model is defense-in-depth: multiple independent layers, each enforced at the runtime boundary rather than relying on prompt instructions alone.

Every tool call passes through these checks in order:

1. Owner lock — channel gateway rejects unauthorized users before the message reaches a session
2. Denied commands — built-in and configured patterns block destructive operations (checked before asking for approval)
3. Governance ceiling — Policy ∩ Profile (tightest-wins) — cannot be loosened by the agent or app
4. Sensitive paths and sandbox masks — direct file tools block protected paths, and the OS sandbox masks protected credential locations from subprocesses
5. Tool approval — interactive review, trust escalation, or Autopilot (only fires after deny checks pass)
6. Input validation — MCP schemas, type checks, length limits, unicode normalization
7. OS sandbox — process-level filesystem isolation via Linux namespaces or macOS Seatbelt
8. Output redaction — credential patterns scrubbed from response before reaching any chat surface

The security event log records every decision at every step. It is cross-cutting, not a sequential gate.

The OS sandbox hides credential paths from agent subprocesses. Configure from Settings → Security or via kirocrew config set agent.sandbox <mode>.

On Linux the sandbox uses user/mount namespaces. On macOS it uses Seatbelt profiles.

The sandbox is fail-closed when Crew cannot apply it. On Linux, this includes armv7l, riscv64, ppc64le, and s390x, or a libc without prctl. On Windows, it applies when Kiro CLI's internal sandbox is off. In these cases, Crew refuses to start the agent unless you explicitly set agent.sandbox to off or set agent.sandbox_allow_unsandboxed_exec to true.

Control how the agent gets permission to run tools. Configure from Settings → Security or the per-session Autopilot toggle. When Crew blocks a call, its refusal tells the agent which action is allowed instead of leaving it to retry the same request.

Denied commands and sensitive-path blocks are never bypassed — even in Autopilot mode.

When several tool calls wait on you at once, one click approves or rejects all of them. The confirmation lists every command it covers.

You can also reject a single call and keep reviewing the rest, rather than declining the entire batch. A rejection applies only to that call, so the agent can revise it and ask again.

If a restart ends an active time-limited auto-approve grant, Crew reports that the grant was dropped. If a tool call is declined by the host rather than a person, Crew names the cause, such as an expired approval, exhausted turn budget, or failed Slack delivery.

Long shell commands show a readable summary of what the command does. The verbatim command is one hover away.

When you use the Claude Code harness, a tool already pre-approved in Claude's own settings bypasses Crew's approval flow. Crew's deny rules and audit log do not observe that call. Codex refuses to start when agent.sandbox is off, because Crew remains its OS-level sandbox boundary.

kirocrew chat displays tool permission prompts inline. Turns no longer hang silently until they time out when running from the terminal.

Built-in patterns block destructive operations and common credential-exfiltration paths before approval. Examples:

• rm -rf /, rm -rf ~
• git push to protected branches (main, mainline)
• cat ~/.aws/credentials, cat ~/.ssh/id_rsa
• curl 169.254.169.254 (IMDS metadata)
• aws ec2 terminate-instances, cdk destroy, DROP TABLE
• echo $AWS_SECRET*, credential-revealing commands

The matcher continues to enforce deny rules through shell quoting, escapes, command substitution, and wildcard-spelled program names. It no longer blocks ordinary work just because it resembles a risky command: recursive grep in a worktree, a cd followed by a pipe, and heredocs containing backticks run normally.

Manage rules from Settings → Security → Denied Commands. You can disable eligible individual rules by ID, disable all non-pinned rules, or add custom patterns. Rules contributed by your edition are tagged in the list and can also be switched off by ID.

Credentials are protected at multiple levels:

• Sensitive paths blocked — the agent cannot read .aws, .ssh, .gnupg, .env, and other credential files through tool calls
• Output redaction — AWS keys, private key headers, Slack tokens, GitHub tokens, database connection URIs, and 15+ other credential patterns are scrubbed from every output surface before reaching chat
• Redaction before truncation: credentials are redacted before long text is shortened, so a secret that straddles a truncation boundary never leaks into audit rows, logs, dashboard payloads, or Hook output
• Safe diagnostic output: logs escape control characters, and sign-in URLs with valid authorization parameters are not rejected as bare secrets
• Environment scrubbing — sensitive environment variables are stripped from agent subprocesses

Secrets live in an encrypted vault instead of your config file. Manage them from Settings → Secrets in the dashboard: values stay masked in the UI and are never sent to the browser, so the dashboard shows only each secret's name.

• Encrypted at rest: the vault stores each value under authenticated encryption, keyed to a local key file
• Masked in the UI: the Settings API returns only secret names, so no stored value is sent to the browser through the secrets management surface
• Withheld from agents: a fixed list of credential environment key names is scrubbed from agent subprocesses

An MCP server's environment can name a stored secret as secret://NAME. The value is resolved from the vault at spawn time, so the secret never sits in on-disk config:

{
  "mcpServers": {
    "example": {
      "command": "example-server",
      "env": {
        "API_TOKEN": "secret://EXAMPLE_API_TOKEN"
      }
    }
  }
}

If the named secret is missing from the vault, the spawn fails rather than starting the server without it.

Each messaging channel is locked to authorized users:

• Slack — KIROCREW_OWNER_ID (single owner)
• Discord — deny-by-default allowlist of user IDs
• Telegram — allowlist of numeric user IDs
• Teams — allowlist of Azure AD emails / object IDs
• Webex — allowlist of emails
• WeCom — allowlist of userids (or explicit allow_all_users opt-in)
• WeChat — allowlist of user IDs (default denies everyone)
• WhatsApp: linked to a single personal account by QR code
• iMessage: deny-by-default with an explicit handle allowlist (macOS only)
• Feishu (Lark): allowlist of authorized users
• Dashboard — token-authenticated (every request requires a valid token)

Non-authorized messages are silently dropped and recorded in the audit log.

Optional policy and profile files compose with a tightest-wins model. A running app or agent can narrow the allowed scope but cannot loosen the ceiling. In every sandbox mode, the security policy, admission policy, profiles, and denied-command list are mounted read-only, so a sandboxed script, Hook, or command cron cannot rewrite those controls.

• Policy — enterprise-level ceiling (loaded from ~/.kiro/crew/security_policy.json)
• Profile — per-surface or per-task narrowing (loaded from ~/.kiro/crew/profiles/)
• Effective = Policy ∩ Profile (tightest wins)

Administrators can publish one security_policy.json at a URL and have every host fetch, cache, and periodically refresh it. A policy change takes effect fleet-wide without a restart or a host visit. If the source is unreachable, hosts keep using the cached copy. A document that fails validation is rejected rather than lowering the running ceiling.

On an enterprise Kiro account with an administrator-configured MCP registry, org-level MCP controls take effect, including version pins. Personal accounts are not affected.

Administrators can authorize their own OAuth providers by configuration, without waiting for a release to add one.

Inspect from the CLI:

kirocrew policy show        # display effective policy
kirocrew policy validate    # check policy files for errors
kirocrew policy explain     # explain how a tool call would be evaluated

Every tool call, approval, denial, and security event is recorded. Inspect from the CLI:

kirocrew security events    # view recent security events
kirocrew security audit     # view the audit trail
kirocrew security verify    # verify audit-log integrity

The audit trail can be reviewed from the dashboard under Settings → Security.

• Keep agent.sandbox at auto or strict — don't run with off unless you have a specific reason
• Use Autopilot sparingly — it's convenient but removes the human gate for tool calls
• Don't paste credentials into chat — redaction catches output, but input is your responsibility
• Review denied-command customizations — disabling deny rules weakens protection
• Use governance profiles for shared/team deployments to enforce a ceiling

For the full security architecture including implementation details, see the KiroCrew repository.