Security

Designed so the blast radius is a branch

Sherlock's autonomy is bounded on every axis: where code runs, what it can touch, who can trigger it, and what it can produce.

Sandboxed execution

Every investigation clones your repository into an isolated, ephemeral container. Your app runs there — never on your infrastructure, never alongside another tenant's code. Workspaces are destroyed when the run completes.

GitHub App permissions

Sherlock installs as a GitHub App scoped to the repositories you select. Access uses short-lived installation tokens — no personal access tokens, no OAuth scope creep, revocable in one click from GitHub settings.

PR-only output

The only write Sherlock performs is opening a branch and a pull request. It cannot push to protected branches, cannot merge, cannot tag releases, and cannot touch CI/CD or deployment settings.

Human review, always

Every change waits for your team's review like any other PR. Branch protection rules, required reviews, and CODEOWNERS all apply — Sherlock works inside your process, not around it.

§ Authorization gates

Investigations only start from an exact /sherlock investigate command by a non-bot user whose write access is verified against the GitHub API at trigger time — payload data is never trusted.

Rate limits & audit

Per-installation rate limits cap concurrent and daily runs. Every investigation produces a complete log of what ran, what was read, and what changed — attached to the PR.

The permission surface

What Sherlock can and cannot do

CapabilityAccessWhy
Read repository contentsreadClone into the sandbox for reproduction and patching
Read & comment on issuesread / writeReceive the trigger command, post status updates
Create branches & pull requestswriteDeliver the fix for human review
Push to default / protected branchesneverPR-only by design
Merge pull requestsneverYour reviewers decide what ships
Actions, webhooks, deploy keys, settingsno accessOut of scope for the App's permissions