Security and GitHub permissions

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

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#

Latchkey reads

Workflow run and job metadata: names, timings, statuses, runner labels
Workflow YAML files under .github/workflows/
Repository metadata (names, visibility, default branch) for enabled repos
Your GitHub account plan, to model GitHub runner costs accurately

Latchkey never reads

Your application source code beyond the workflow files
Secrets and environment variable values
Issues and pull request discussions

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 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/optimize-...) 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 AI: Optimize <workflow> workflow" on a branch named `latchkey/optimize-...`
Heal PR	Self-healing diagnoses a root cause that needs a durable fix in the repository	An ordinary pull request 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.

API keys and the MCP server#

If you connect an AI agent over MCP, the API key is the credential to reason about:

Read-only scope. Keys can read CI failure data; they cannot change anything in Latchkey or GitHub.
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 instantly from Settings, API Keys; revoked keys stay listed for audit.

Anyone holding a key can read your CI failure data, including log excerpts, so treat keys like passwords: store them in your agent configuration, not in a repository, 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.
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.