What happens to your code and keys.

One VM per run, destroyed afterward

Every iteration — a planning pass or a dev run — boots its own isolated virtual machine. The machine has no persistent disk: when the run ends, it is destroyed, and everything on it goes with it — the cloned repo, any credentials on disk, all intermediate state.

Nothing about your project lives on a shared, long-running worker. There is no warm pool that once held someone else's code.

The network is deny-by-default

Iteration VMs have no direct internet access. All outbound traffic passes through a forward proxy with an explicit allow-list of roughly twenty hosts: your AI provider's API, GitHub, and the package registries builds need. HTTPS only. Everything else is refused.

Every request — allowed and denied — is logged. Denied requests to novel hosts are the exfiltration signal we monitor for.

GitHub access is scoped per run

You connect through the official Keelen GitHub App and choose exactly which repositories it can see. We store the installation only after verifying, with your own GitHub session, that you actually control it.

Each iteration then gets a freshly minted access token scoped to one repository, valid for roughly one hour, with four permissions: repository contents, pull requests, read-only checks, and read-only metadata. It has no permission to modify your CI workflow definitions. The App's private key never leaves our API — only the short-lived, single-repo token ever reaches a machine.

The token is stripped from the clone configuration immediately after checkout, so it is not sitting in .git/config while your code and tests run.

Credentials are encrypted, scrubbed, and revocable

Model keys and tokens are encrypted at rest the moment you connect them, under independent encryption keys per credential type, with support for no-downtime key rotation. The API refuses to boot if any encryption key is missing.

Secrets are redacted from logs at every write and read path — ours and the copies you can download. Known token formats are pattern-scrubbed, and the literal runtime values of connected credentials are redacted regardless of format.

Revocation is immediate: uninstall the GitHub App and access stops; delete a model key in Settings and it is removed from our database at once.

Runs execute as an unprivileged user

The wrapper that orchestrates each run executes as a non-root user inside the VM. Projects can additionally opt into a stricter privilege jail that runs the coding agent and your test commands under a second, further-restricted user account that cannot read the orchestration code at all.

The merge path is gated, and the gates are not optional for the AI

Nothing reaches your default branch without passing the verification gates: a mechanical proof that new tests fail before the implementation and pass after it, an independent adversarial review of the diff, your own test suite on a clean checkout, and a CI-green requirement at merge time.

The loop is contractually forbidden from weakening your checks — it may not skip a failing test, mark a check non-required, or add continue-on-error to get to green. Where it cannot fix the real problem, it stops and asks you.

Once your repository has CI, Keelen also configures branch protection on your default branch to require your own established checks — so even an administrative merge cannot land red code.

You hold the brakes

Per project, you choose the autonomy level: gated auto-merge, plan review (product and/or developer sign-off on every plan before code is written), manual merge (Keelen opens the PR, you press the button), or branch-only (no PRs at all). You can pause a single project or your entire fleet at any time, and every action the loop takes lands as a pull request in your repository — in the open, in your audit history.

What we store

On our side: your account email, encrypted credentials, project configuration, iteration logs (secret-scrubbed), pull-request metadata, and timeline metrics. Your repository content lives in your GitHub account and, transiently, on the single-use VM that is destroyed after each run. We do not train models on your code; your AI usage goes directly to the provider whose key you connected.

Honest limitations

The coding agent necessarily runs with the credentials it needs to do its job: your model key (it is the agent's authentication to your AI provider) and the one-repo, roughly-one-hour GitHub token (it must push branches and open PRs). Those credentials are exactly as revocable and as scoped as described above, and the egress allow-list bounds where anything could go — but an autonomous agent with write access to one repository is precisely what you are granting. That is why the gates, the review modes, and the one-click revocations exist.

We are a young product and do not yet hold formal certifications such as SOC 2. If your security team has questions, write to security@keelen.ai — we answer with specifics, not adjectives.

Report a vulnerability

Send security reports to security@keelen.ai. Include the affected surface, the steps to reproduce it, and what an attacker gets. We answer every report, and we aim to send a first response within 3 business days.

In scope: the Keelen web app at keelen.ai, the Keelen API, and the Keelen MCP server. Out of scope: our third-party providers (report those to the provider), and anything that needs physical access or a stolen account.

Please do not run automated scanners, fuzzers, or load tests against production. They cost us real capacity and they bury the signal we watch for. Tell us what you want to test and we will work out a safe way to do it.

Please do not access, modify, or exfiltrate another customer's data. Stop at the point where you have proved the finding, and give us a reasonable window to fix it before you publish.