Kilo Code

Kilo runs as the developer's OS user and uses whatever credentials that user has. Shell commands and local MCP servers inherit the full process environment, with only Kilo's own server and config variables stripped, so cloud keys, GitHub tokens and provider API keys in the environment reach every subprocess. There is no scoped identity or per-request authorization beyond the tool permission rules. Protection of the project's own configuration against agent writes is not tamper-resistant, which lets the agent widen its own permissions for later sessions.

The permission engine itself is well built: shell commands are parsed with tree-sitter, each sub-command is matched against allow/ask/deny rules, and prompts show the exact command or file diff. But the default code agent allows everything not explicitly listed, so file edits and writes, web fetches and all MCP tools run without asking. The default shell auto-approve list is not a strict boundary, which lets some commands have side effects without a prompt. A cloned repository's kilo.json can also set permissions to allow everything with no trust prompt.

File tools check that paths stay inside the project, but path containment is not a strict boundary. The shell tool takes arbitrary command strings filtered by wildcard rules, and webfetch accepts any URL with no block on internal or metadata addresses. MCP tools get no validation layer. In the default agent, shell, edit, write, web fetch and MCP are all available.

By default, shell commands, workspace scripts and local MCP servers run directly on the host as the user, with the full environment. Kilo ships a real OS sandbox (bubblewrap on Linux, Seatbelt on macOS) that makes the filesystem read-only except the workspace, denies network by default, fails closed when unavailable, and requires an interactive human reply to escalate, and a project config can only tighten it. It is off unless the user enables it, so it scores as an opt-in control.

Nothing in the code distinguishes untrusted content (web pages, files, MCP results) from the user's instructions. In the default agent, webfetch to any URL runs without approval, so a hijacked session can send data out in a URL. It can also read environment secrets through the auto-approved printenv and make lasting changes without a prompt through auto-allowed edit and write tools; gaps in the shell auto-approve list widen this further. Leaking data and taking irreversible actions are both possible without a human involved.

Project files load automatically with no trust prompt: kilo.json/opencode.json can add permission rules and MCP servers, any .ts/.js file in .kilo/plugin is imported as code, and AGENTS.md is injected as instructions. Kilo does restrict project config from reading environment variables and outside files, and the optional memory feature is off by default, asks before saving, filters secrets and lives outside the project. Because protection of those project files against agent writes is not tamper-resistant, one injection can persist into every later session, and to every user of a repo if committed.

Plugins declared in any config, including a cloned project's kilo.json, are installed from npm at their latest version and imported into the Kilo process, and plugin files in the project's .kilo/plugin folder are imported directly. Local MCP servers from project config are launched automatically on the host with the inherited environment. There is no pinning, integrity check or consent step, so opening a malicious repository is enough to run its code with everything Kilo can reach.

Provider credentials are stored in a plaintext JSON file with owner-only permissions, and a few paths mask secrets (memory writes, remote error reports). Nothing redacts secrets in subprocess environments or model-bound tool output, and printenv is auto-approved so environment secrets can reach the model. PostHog usage telemetry is on by default, and when signed in to Kilo every message and tool part is synced unredacted to Kilo's session-ingest service unless an environment variable opts out.

Every tool call, including MCP tools and sub-agent sessions, is stored as a structured record in a SQLite database outside the project: input, output, status, start and end time, and why it was allowed or denied (manual approval, which rule, and whether it came from global config, project config or auto-approve mode). Sub-agent sessions link to their parent. The database is written per action but is an ordinary file in the user's data directory, so a shell command running as the same user could alter it, and there is no tamper evidence or off-host export by default.

There is no default step, time or cost limit on a session: the step limit defaults to infinity and the only cost control is an optional, non-blocking alert in the terminal UI. Shell commands have a 2-minute default timeout that the model can raise, and repeated identical tool calls trigger a prompt. Stopping a session kills running shell commands, but the model can start persistent background processes that outlive the session.