🔐 Kilo Code Security Posture

What Kilo Code can access by default

Kilo runs as your IDE user (or your shell user for the CLI). That means it inherits whatever the parent has access to:

• Filesystem: any file your editor can open
• Shell: any command you can run (orchestrator's debugger uses this for tests/lints)
• Network: outbound to OpenRouter or whichever providers you've configured
• Git: Kilo can stage, commit, and push as you (most users disable push by default in settings)

This is the IDE-permission-inheritance trap — Kilo isn't sandboxed by default. If you wouldn't run an arbitrary script as your dev user, don't let Kilo execute one without review.

Where your prompts actually go

Default routing (OpenRouter):

1. Your IDE → Kilo extension → OpenRouter API
2. OpenRouter forwards to the chosen provider (Anthropic, OpenAI, Google, etc.)
3. Provider response → OpenRouter → Kilo → IDE

Two parties see your prompt: OpenRouter and the chosen provider. OpenRouter publishes a privacy policy and doesn't train on traffic, but for sensitive code you may prefer direct provider keys (one-hop instead of two).

BYO direct keys path:

1. Your IDE → Kilo extension → provider directly (e.g. Anthropic API)
2. Provider response → Kilo → IDE

One party sees your prompt: the provider. Strictly fewer hops.

Apache-2.0 audit posture

Source code at github.com/Kilo-Org/kilocode. The Kilo CLI is MIT. You can: read every line, fork it, build from source, run from your fork. Independent security reviews so far have been positive — no known critical CVEs as of April 2026.

Even with open source, you should pin versions. New releases ship roughly weekly; auto-update is on by default. Production users should pin to a known-good version and update on a deliberate cadence (we do every 2 weeks after the release notes pass review).

Pre-prod hardening checklist (10 min)

1. Pin Kilo version. Disable auto-update in settings; bump manually after reading release notes.
2. Use a dedicated dev user. Don't run Kilo as the same OS user that owns your SSH keys, browser profile, and password manager. Standard agent rule.
3. Disable git push by default. Settings → Git → "Allow push" off. Force a manual review-and-push after Kilo's commits.
4. Set per-task budget cap. kilo.task_budget_usd = 2.00 prevents a runaway orchestrator from burning $50.
5. Scope BYO API keys narrowly. If you BYO an Anthropic key, create a dedicated workspace for Kilo. Don't reuse your main key.
6. Review skill allowlist. Kilo's tool list defaults to powerful capabilities (file, shell, network, git). For a production-adjacent repo, restrict to read-only first, expand as needed.
7. Audit OpenRouter routes. If you're using OpenRouter, check which providers your traffic touches — some niche models route through aggregators with weaker privacy postures.
8. Don't paste secrets into Kilo prompts. Same rule as any agent — see our secrets guide.
9. Separate profile per repo. Use Kilo profiles to isolate work-vs-personal-vs-OSS contexts.
10. Log review. Kilo's trace pane is your audit log. Skim it weekly. Anomalies (commands you didn't expect, files touched outside the task scope) are early signs.

Comparison vs other agents

For high-stakes production work where the agent touches credentials or money, IronClaw's default-deny model is genuinely safer than either Kilo or Claude Code. For development workflows, Kilo's flexibility is fine if you do the hardening pass above.

Next

• Cross-platform security hub — 8 deep-dive topics applicable to Kilo too
• Secrets & credentials — never in prompts
• Skill allowlisting — applies to Kilo's tool list
• 15-minute hardening checklist — generic version