What happens to your code and keys.

One VM per run, destroyed afterward

Every iteration boots its own isolated VM. That covers both a planning pass and a dev run. The machine has no lasting disk. When the run ends, the machine is destroyed. The cloned repo, any credentials on disk, and all intermediate state go with it.

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 traffic they send leaves through a forward proxy. That proxy has a list of about twenty allowed hosts. The list holds your AI provider's API, GitHub, and the package registries a build needs. Only HTTPS is allowed. Everything else is refused.

We log every request. That includes the allowed ones and the denied ones. A denied request to a new host is the exfiltration signal we watch for.

GitHub access is scoped per run

You connect with the official Keelen GitHub App. You choose which repositories it can see. We save the install only after you prove, with your own GitHub login, that you control them.

Each iteration gets a fresh token for one repository. It lasts about one hour. It can write repository contents and pull requests. The token can read checks, actions, statuses and metadata. It cannot edit your CI workflow files. The App's private key never leaves our API. Only that short token for one repo reaches a machine.

We strip the token from the clone config right after checkout. It is not left in .git/config while your code and tests run.

Credentials are encrypted, scrubbed, and revocable

We encrypt your model keys and tokens at rest the moment you connect them. Each credential type has its own key. Keys can be rotated with no downtime. If any encryption key is missing, the API will not start.

We scrub secrets from logs. That happens on every write and every read. It covers our logs and the copies you download. We also scrub known token formats by pattern. We redact the real runtime values of connected credentials, whatever their format.

Revocation takes effect at once. Uninstall the GitHub App and access stops. Delete a model key in Settings and we remove it from our database right away.

Runs execute as an unprivileged user

The code that runs each iteration uses a non-root user inside the VM. A project can also turn on a stricter jail. That jail runs the coding agent and your test commands under a second user. This second user cannot read the code that runs the loop.

Checks before merge

Some projects use gated auto-merge. Those projects need a verified project test command and required checks set up. New tests must fail before the code change. An independent model reviews the diff with no context from the run that wrote it. The suite runs on a clean checkout. Nothing merges over a red required CI check. A review window comes before gated auto-merge.

When the guards are on and can check the change, they block detected assertion removal or weakening within their supported scope. Supported exceptions can let those changes through. A declared exception does not prove a human approved it. The guards can be turned off. Missing inputs can make them skip the check. They do not catch every way a test can lose meaning. The tests and code still need human review.

If the GitHub App has the admin permission, Keelen can set branch protection. Then your established checks are required. Check the GitHub protection settings for the repo. Admin bypass rules live there too.

You hold the brakes

You choose the merge policy for each project. The choices are gated auto-merge, manual merge or branch only. Plan review is a separate opt in. When it is on, a human approves the plan before any code is written. With manual merge, Keelen opens the PR and you click merge. Branch only mode produces a branch with no PR. You can pause one project or all projects. A real dead end can become a plain English decision card and pause the project.

What we store

Here is what we keep. We store your account email, encrypted credentials, project settings, iteration logs, pull request metadata, and timeline metrics. The logs are scrubbed of secrets. Your repository content lives in your GitHub account. It also sits on the single use VM for a short time, then that VM is destroyed. We do not train models on your code. Your AI usage goes straight to the provider whose key you connected.

Honest limitations

The coding agent must run with the keys it needs. Those are your model key, which is the agent's login to your AI provider, and a GitHub token for one repository. The token lasts about an hour. It follows the delivery policy you set. You can revoke both. They stay in the scope above. The egress allow-list limits where anything can go. You are still giving an agent write access to one repository. That is why the gates, the review modes, and the revocations exist.

We are a young product. We do not yet hold formal certifications such as SOC 2. If your security team has questions, write to security@keelen.ai. We will give you specific answers.

Report a vulnerability

Send security reports to security@keelen.ai. Tell us the affected surface. Include the steps to reproduce and what an attacker could get. We answer every report. We aim for a first reply within 3 business days.

In scope are the Keelen web app at keelen.ai, the Keelen API, and the Keelen MCP server. Out of scope are our third party providers. Report those to the provider. Also out of scope is 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, change, or take another customer's data. Stop once you have proved the finding. Give us a fair amount of time to fix it before you publish.