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

For gated auto-merge projects with a verified test command and configured required checks, Keelen's merge path requires a test-before-implementation proof, an independent adversarial review of the diff, a clean-checkout test run, and CI-green status 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.

Where the GitHub App has the required administration permission, Keelen can configure default-branch protection to require your established checks. Review the resulting GitHub protection settings for the repository; administrator bypass behavior is controlled there.

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. In the PR modes, development work is recorded as a pull request; branch-only work is pushed as a branch without one.

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 a one-repository, roughly-one-hour GitHub token for the configured delivery policy. Those credentials are revocable and 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, review modes, and 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.