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 — 137 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 path blocking — credential directories and files are inaccessible to tool calls
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

Audit (SEL) records every decision at every step — it's 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. Windows does not currently have this OS-level layer — all other protections still apply.

Control how the agent gets permission to run tools. Configure from Settings → Security or the per-session Autopilot toggle.

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

137 built-in patterns block destructive operations and common credential-exfiltration paths. 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

Manage from Settings → Security — you can disable individual rules, disable all rules, or add your own custom patterns.

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
• Environment scrubbing — sensitive environment variables are stripped from agent subprocesses

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)
• 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.

• 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)

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 log is included in snapshots and 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 repo's security deep dive.