# Your code and builds stay yours Source: https://latchkey.dev/security Security Each job runs alone on a machine that accepts no inbound connection, and every change Latchkey makes to your code arrives as a pull request you review. Last updated November 8, 2026 - [Read the full security architecture](/documentation/security-architecture) - 1 job per machine, then the machine is destroyed - 0 inbound connections a runner accepts - 0 pull requests Latchkey merges - AES-256 encryption on the secrets you store with Latchkey 01 · Isolation ## A machine of its own for every job Each job runs on its own virtual machine, with its own kernel and an encrypted disk. When the job ends, the machine is terminated and the disk deleted, and no machine ever runs a second job. 1. 01 Start A virtual machine no job has used 2. 02 Run Your job, alone on the machine 3. 03 Terminate Shut down for good, never reused 4. 04 Delete The encrypted disk goes with it Your code is checked out on a machine that runs only your job and is destroyed when it ends. What Latchkey keeps after a job is listed in the [Privacy Policy](/privacy) and the documentation. 02 · Network ## Runners reach out. Nothing reaches in. Each runner reaches the internet through its own public IPv4 address, used only for connections the runner opens, and its firewall has no inbound rules. Your build can still fetch packages and call your services. A pull request from a fork on Latchkey CI reaches only GitHub and a fixed set of public package registries. 03 · Credentials ## Credentials minted for each job Every credential Latchkey mints for a job is minted for that job alone and reaches no other workspace's data. Each ends with the job or within about an hour, except the token Docker uses for Latchkey's container registry, which lasts 12 hours. No long-lived GitHub token is ever placed on a runner. - Clone token read-only one repository about 1 hour - Job token this job only stored hashed ends with the job - Cache access this workspace only scoped up to 12 hours 04 · Secrets ## Your Latchkey secrets stay sealed Secrets you store with Latchkey are encrypted with AES-256-GCM, and Latchkey unseals one only for a running job with a step that names it. Its value is masked wherever it appears whole in the job's log, and no dashboard, CLI or API-key request returns it. Latchkey never calls GitHub's API for your Actions secrets. 05 · Changes ## Every change to your code waits for your review Latchkey commits only to new `latchkey/` branches it creates, then opens a pull request. It never pushes to your branches and never merges, so merging is always your call. 06 · Self-heal ## Self-heal works inside guardrails When a step fails, self-heal can only take actions from a fixed, checked list, and the AI gets no shell. If self-heal errors or times out, a failed step still fails. - Allowed `apt-get install -y libssl-dev` package on the fixed list - Allowed `retry the failed step` same step, same machine - Refused `sudo rm -rf /var/lib/docker` only one sudo command is allowed - Refused `LD_PRELOAD=/tmp/hook.so` unsafe environment variable - Refused `read ~/.ssh/id_rsa` sensitive path 07 · The basics ## And the rest, covered - Encrypted at rest Runner disks, build cache and artifacts are encrypted at rest. - Encrypted in transit Every public endpoint uses HTTPS, and our API requires TLS 1.2 or later. - Isolated caches A workspace's build cache is reachable only with credentials scoped to that workspace. - Retention periods Dependency caches expire after 14 days, artifacts and job logs after 7, heal records after 90 and proposed fixes after 365. - Scoped API keys API keys are read-only unless you choose more, stored as SHA-256 hashes, and shown once. - Workspace roles Owner, Admin and Member roles decide who can manage billing, members and integrations. - Sandboxed forks On Latchkey CI, pull requests from forks reach only GitHub and a fixed set of public package registries. - Runner time limit A backstop terminates any runner still running 8 hours after it starts. 08 · GitHub App ## The GitHub App, permission by permission You choose which repositories the app can see, and it holds no permission to read your Actions secrets. Here is every permission it asks for, and why. | Why | Permission | Access | | --- | --- | --- | | Run your jobs on Latchkey runners | Organization self-hosted runners | Read and write | | Read runs and logs, start a run you ask for, cancel a run | Actions | Read and write | | Read files, branches and pull requests, including the list of files a pull request changes, and propose changes as pull requests | Contents, Workflows, Pull requests | Read and write | | Report Latchkey CI results on your commits, and read the checks on them while you migrate from GitHub Actions | Checks | Read and write | | See each group your merge queue makes, so Latchkey CI can build the ones your workflow files run on | Merge queues | Read | | Read your organization's plan, Actions usage, GitHub-hosted runners and members | Organization plan, Organization administration, Members | Read | | Read basic repository details | Metadata | Read | | Remove webhooks Latchkey created on a repository | Repository hooks | Read and write | | Not used by any Latchkey feature today | Administration, Organization hooks | Read and write, unused | | Not used by any Latchkey feature today | Artifact metadata | Read, unused | No Actions secrets permission. ## Report and review ### Found a vulnerability? Email [security@latchkey.dev](mailto:security@latchkey.dev) and please report it privately, not in a public issue. - [security.txt](/.well-known/security.txt) ### Doing a security review? The documentation has the full detail. - [Security architecture](/documentation/security-architecture) - [Security and GitHub permissions](/documentation/security-and-permissions) --- Latchkey is CI your coding agents can run, read and fix: a standalone CI/CD platform with self-heal, a CLI and an MCP server. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt