Shimpilot reads private source code and opens pull requests, so its security properties require access controls and validation gates. We describe the implemented controls and the conditions under which they apply.

Merging is gated by capability rather than by model confidence alone. Manual mode always stops at a validated Draft pull request for a human to review in GitHub. Automatic mode can merge only when the customer plan, reviewed migration rule, source-integrity checks, repository validation, required GitHub checks, and merge protections all pass; ambiguous or unverifiable states fail closed.

Stripe payment and webhook migrations require human review. Automatic mode may prepare their Draft PRs, but Shimpilot does not merge those changes unattended. The Stripe v13 migration guide also describes changed retry and default API-version behavior, which a method rename and typecheck alone cannot verify.

Automatic mode may prepare a human-reviewed Draft PR for simple, literal Supabase createClient option moves. It never auto-merges Supabase changes. Authentication response changes, RLS-sensitive writes, Realtime subscriptions, and ambiguous constructor options remain Manual-only and require application-specific review.

You do not need to begin with a private or production repository. The public Shimpilot sandbox contains inspectable provider fixtures, safe control cases, a scenario matrix, and a GitHub Actions workflow. It contains no production credentials or private code.

You can run the public sandbox scan without signing in or granting repository access. For the full connected workflow, create a disposable copy from the repository template, select only that copy when installing the GitHub App, and review every resulting finding and Draft PR in GitHub.

The public scan reads a public repository and reports findings. It does not generate a PR or demonstrate Automatic merge. Use a disposable copy with Manual mode to inspect a Draft PR. Automatic mode can merge an eligible PR without human approval when its gates pass.

A separate public Supabase fixture shows reviewed Supabase v1→v2 and Anthropic model findings alongside Stripe and OpenAI examples. AWS SDK coverage is JavaScript v2→v3 source migration only; it does not require AWS credentials or modify AWS resources or IAM. It uses placeholder credentials and does not prove universal Supabase compatibility.

Access is granted through a GitHub App installation scoped to the repositories you select — never a personal access token and never account-wide OAuth. The App requests Metadata read-only, Contents read/write for cloning and committing migration branches, Pull requests read/write, Checks and Commit statuses read-only for CI state, Actions read-only for bounded failed-job diagnostics, and Administration read-only so Automatic Mode can inspect branch protection/rules immediately before merge. It does not request Administration write and never edits branch protection.

Every repository operation uses a short-lived installation access token minted for that job. Tokens are not persisted to the database.

User authentication is handled by Supabase Auth over HTTPS, with session cookies managed server-side. Dashboard routes resolve the session on the server before rendering; an unauthenticated request is redirected rather than partially served.

Every organization's data is separated at the query layer. Application queries that read repositories, findings, dependencies, impact analyses, migrations, or migration candidates join through the owning organization and filter on it explicitly on the server. An identifier supplied by a browser is never trusted on its own — a request for a resource belonging to another organization resolves as not found.

Row-level security is additionally enabled on every tenant-owned table, which protects against direct database access using a client-side key. We want to be precise about the layering, though: the application server connects to Postgres with a privileged role, so for application traffic it is the explicit organization scoping described above — not row-level security — that enforces isolation. Both exist; the query layer is the one doing the work in normal operation.

Repositories are cloned shallowly into a temporary working directory for the duration of a single job, and that directory is removed in a finally block — so cleanup runs on failure as well as success. Shimpilot does not maintain a long-term copy of your repository.

Findings retain structured file, line, symbol, rule, and version evidence without a source excerpt. A generated migration diff does contain the source fragments necessary to review that proposed change. Our Privacy Policy describes this precisely rather than claiming zero retention.

Platform credentials are supplied as environment configuration. Slack webhook URLs are stored in the database; newly saved URLs are encrypted using an application-held key and are not returned to the browser after saving. Older URLs must be migrated separately. Credential-pattern checks block recognized embedded credentials, but cannot prove arbitrary source is secret-free. We do not intentionally include credentials in AI prompts.

Before any pull request is opened, a generated patch must pass:

• Syntax validation for the affected source language.
• A type check when repository commands are explicitly enabled in an isolated worker; otherwise reported as not run.
• The repository's own test suite when available and execution is enabled; otherwise reported as not run.
• A rescan confirming the original breaking pattern is actually gone.
• Protected-file rules, so configuration and lockfiles are not silently rewritten.
• Diff-size limits, so an unexpectedly large rewrite is blocked rather than proposed.

A failed required local gate blocks the pull request and records the reason. Skipped repository commands are shown as not run. Automatic merge additionally requires its applicable GitHub CI and repository protection gates.

The validator invokes fixed package-manager commands with argument arrays, but package scripts and dependencies can run arbitrary code when execution is enabled. Keep repository command execution disabled on shared workers; only enable it in a separate disposable, network-restricted environment without platform credentials.

AI is used to draft a migration patch. It does not decide whether a migration is safe, does not run commands, does not create pull requests, and cannot bypass validation. Change detection, impact analysis, and risk scoring are deterministic and contain no model output.

Provider changelogs and documentation are treated as untrusted reference material, not as instructions.

Logs record job identifiers, repository identifiers, timings, and error classifications. They do not record access tokens, API keys, private keys, or file contents. Error messages surfaced to the dashboard are redacted before storage.

Security pages often imply more than a product has actually done. To be direct about ours:

• Shimpilot holds no SOC 2, ISO 27001, or comparable certification.
• We make no HIPAA or PCI compliance claim.
• No third-party penetration test has been performed.
• We do not offer end-to-end encryption, dedicated single-tenant infrastructure, or a zero-data-retention mode.
• We do not offer a contractual uptime commitment.

If any of these matter to your organization, tell us before connecting a repository so we can be clear about whether Shimpilot currently fits.

Report suspected vulnerabilities to support@shimpilot.com. Please include reproduction steps and avoid accessing data belonging to other users while testing. We review incoming reports, but do not currently publish a guaranteed acknowledgement or resolution time.

We do not currently operate a paid bug-bounty programme, and we will say so rather than leave the expectation open.

If an incident affects the confidentiality or integrity of customer data, we will notify affected organizations at the contact address on the account, describe what is known, and follow up once the investigation concludes.