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.
What Sherlock can and cannot do
| Capability | Access | Why |
|---|---|---|
| Read repository contents | read | Clone into the sandbox for reproduction and patching |
| Read & comment on issues | read / write | Receive the trigger command, post status updates |
| Create branches & pull requests | write | Deliver the fix for human review |
| Push to default / protected branches | never | PR-only by design |
| Merge pull requests | never | Your reviewers decide what ships |
| Actions, webhooks, deploy keys, settings | no access | Out of scope for the App's permissions |