# Security and GitHub permissions

> Exactly what the Latchkey GitHub App can read and change, how runner infrastructure is isolated, and how deletion works.

Source: https://latchkey.dev/documentation/security-and-permissions

## Summary

- Latchkey reads workflow runs/jobs and workflow YAML, plus specific build manifests (package.json, go.mod, Dockerfile) when diagnosing a failure; **never** your secrets or environment values.
- Repository writes happen only as pull requests you review: optimization PRs and heal PRs.
- Runners are single-job, private-network machines destroyed after each job; deleting the workspace removes its data permanently.

This page describes what Latchkey can and cannot access, in plain terms, so your security review has a straight answer. It covers four things: what the GitHub App reads, when Latchkey writes to your repositories, how runner infrastructure is isolated, and how data deletion works.

## What Latchkey reads, and what it never touches

The boundary is deliberate: everything on the left exists to power a specific feature, and nothing else is requested. Run and job metadata is the raw material for the analytics dashboards; workflow YAML is what the AI reads to propose optimizations, and the only kind of file an optimization PR edits; repository metadata drives the repository list in the Monitoring modal; and your GitHub plan feeds the GitHub-side cost model on the [Cost Analysis](/documentation/cost-analysis) page.

## When Latchkey writes to your repositories

Only through pull requests, and only in two situations:

- You click apply on an optimization recommendation: Latchkey opens a PR (branch `latchkey/insight-...`) changing the workflow file.
- Self-healing proposes a durable fix: a heal PR describing root cause and change.

| Write moment | What triggers it | What you see on GitHub |
| --- | --- | --- |
| Optimization PR | You click apply on a recommendation on the Optimization Insights page | A pull request titled "Latchkey insight: <what it does>" on a branch named `latchkey/insight-...` |
| Heal PR | Self-healing diagnoses a root cause that needs a durable fix in the repository | A pull request titled "Latchkey heal: <error summary>" on a `latchkey/heal-...` branch, describing what failed, why, and what the change does |
| Runner group management | Installing the app, so `latchkey-*` jobs can route to managed runners | The app manages its own runner group in your organization; no repository content changes |

Both PR kinds are ordinary pull requests for your team to review, edit, or close. Latchkey never pushes to your branches directly and never merges anything, so if you never merge a Latchkey PR, nothing in your repository changes. Pull requests from forks are never touched. The runner group the app manages is organization CI plumbing, not repository content.

## Runner isolation

Managed runners execute your code, so their isolation model matters more than anything else on this page. Four properties work together:

- **One job per runner.** Every managed runner executes a single job and is destroyed afterward; nothing persists between jobs or between customers. Whatever a job writes, installs, or breaks disappears with the machine.
- **Private networking.** Runners live in private subnets with no public IP and no inbound access: the runner reaches out to do its work, but nothing on the internet can initiate a connection to it.
- **Hardened instance defaults**, including enforced instance-metadata protections and encrypted disks.
- **Registration is just-in-time.** Fresh runners register for exactly one job with single-use credentials, so there are no long-lived runner credentials to steal; a credential is spent once its job completes.

### Self-healing and your secrets

Self-healing diagnosis runs locally on the runner, against the step output your job already prints, so nothing new is exposed: secrets masked by GitHub Actions stay masked, and the runner, including everything the diagnosis saw, is destroyed after the job. In-run fixes only touch the ephemeral runner; durable fixes only ever arrive as pull requests for review, and pull requests from forks are never touched. The full model is on [Self-healing](/documentation/self-healing).

## API keys and the MCP server

If you [connect an AI agent](/documentation/connect-your-ai-agent) over MCP, the API key is the credential to reason about:

- **Read-only by default.** Keys can read CI failure and run data; changing anything in Latchkey or GitHub is off by default, and every write is a separate per-key opt-in at creation.
- **Dispatch is opt-in per key.** A key created with **Allow workflow dispatch** also carries the `mcp:dispatch` scope, letting the agent trigger `workflow_dispatch` runs in your monitored repositories. Keys created without it, including every key created before the option existed, cannot dispatch.
- **Running jobs is opt-in per key.** A key created with **Allow running CLI jobs (includes reading)** carries the `jobs:run` scope, letting its holder run one-off commands on billable Latchkey runners in your workspace. **Allow reading CLI job status and logs** grants `jobs:read` alone.
- **Workspace-scoped.** The workspace is derived from the key itself, so a key can only ever see its own workspace's data.
- **Shown once.** The full key (it starts with `lk_live_`) is displayed only at creation; after that the UI shows a placeholder.
- **Revocable.** Revoke any key from Settings, API Keys: a write-capable key (dispatch or jobs) loses access immediately, a read-only key within about a minute. Revoked keys stay listed for audit.

Anyone holding a key can read your CI failure and run data, including log excerpts from completed jobs; a dispatch-enabled key can additionally re-run any manually dispatchable workflow in a monitored repository, and a jobs-enabled key can run commands on billable runners, spending runner minutes. Treat keys like passwords: store them in your agent configuration, not in a repository, enable writes only where you need them, and rotate any key that may have leaked.

## Data handling

- Data is encrypted in transit (TLS) and at rest.
- Analytics data is scoped to your workspace and isolated per organization: each workspace has its own plan, team, repositories, and data, and membership in one workspace never grants visibility into another.
- Self-healing diagnostics work on step logs within the runner; heal reports shown in your dashboard contain the diagnosis and action taken.

## Deleting your data

- **Disable a repository**: ingestion stops immediately; its data is archived out of your dashboard. Re-enabling later starts a fresh backfill. See [Managing repositories](/documentation/managing-repositories).
- **Cancel your subscription**: access is blocked, but your data is retained so re-subscribing restores it.
- **Delete the workspace** (Settings, Account; owner only): permanently removes repositories, workflow data, and managed runner resources, and cancels billing.
- **Delete your account**: removes your Latchkey account and owned workspaces. Your GitHub repositories and workflows are never affected by any of these.

> ****
> Questions a security review needs answered beyond this page? [Contact support](/support) and we will get you what you need.

### Can Latchkey read my secrets?

No. Latchkey reads workflow runs and jobs, workflow YAML, and specific build manifests such as package.json, go.mod and Dockerfile when diagnosing a failure. It never reads your secrets or environment values, and those are not available to the analysis path at all.

### Does Latchkey write to my repositories?

Only as pull requests you review. Optimization PRs and heal PRs are proposed as normal pull requests and merge only when you merge them. Nothing is pushed to a branch directly.

### What happens to my data if I delete my workspace?

It is removed permanently. Runners are single-job machines on a private network that are destroyed after each job, so nothing persists there between jobs, and deleting the workspace removes the stored analytics with it.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt