Shimpilot reads private source code and opens pull requests, so its security properties are structural rather than procedural: the system is designed so that unsafe actions are not available, not merely discouraged.

The clearest example is merging. Shimpilot has no auto-merge code path at all — not a disabled flag or an admin setting, but no implementation. Every migration policy, however permissive, terminates at an open draft pull request.

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 read access to repository contents and metadata, and write access limited to creating branches and pull requests.

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.

Small code fragments are retained deliberately: the excerpt shown alongside a finding, and the generated diff attached to a migration. Our Privacy Policy describes this precisely rather than claiming zero retention.

Credentials are supplied as environment configuration and are never stored in the database, embedded in the client bundle, written to pull requests, or included in AI prompts. Startup validation checks that required variables are present by name, and is written so that a variable's value is never printed, even in a failure message.

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

• AST validation — the result must parse as valid TypeScript.
• A type check.
• The repository's own test suite, where one is available.
• 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 failure at any gate blocks the pull request and records the reason. Validation failure never results in a migration marked successful.

Shell commands executed during validation are a fixed set invoked with argument arrays, not strings interpolated into a shell — an AI model cannot introduce a command.

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 privacy@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.