PatchFlowDocs
Operations

Security model

Understand credentials, code execution, trust boundaries, and the merge boundary.

Open Markdown ↗

Credentials

  • Hosted pilot: PatchFlow supplies the migration-provider credential. You never paste it into the workspace.
  • CLI evaluation: CURSOR_API_KEY starts and resumes cloud agents on the machine running PatchFlow.
  • GitHub App installation tokens read Checks and Contents and write Pull requests, labels, and comments only on repositories you select.
  • Private clone credentials are temporary and never enter clone URLs. Tokens are not included in migration prompts.

Two independent GitHub grants

PatchFlow's GitHub App is installed by you and scoped to the repositories you select. Every operation is checked against that selection, and a repository outside it is refused before an agent is started.

The coding agent uses a separate GitHub integration to clone, commit, and open the pull request. Installing PatchFlow's App does not grant that agent anything, and revoking PatchFlow does not revoke the agent's access.

Important

This is the boundary most worth understanding: PatchFlow's scoping constrains PatchFlow, not the agent provider. Grant agent GitHub access deliberately and review it separately.

The local gate runs agent-authored code

When you use the local CLI test gate, PatchFlow clones a branch an agent wrote and runs setupCommand and testCommand on that machine. Those commands receive a stripped environment: PATH, HOME, locale, temporary directories, and CI=1. Provider keys and cloud credentials are not visible to them.

Use testEnvPassthrough to name any additional variable a repository genuinely needs, such as a private registry token. Each name you add is deliberately reachable by the code under test.

Important

A stripped environment is not a sandbox. Prefer customer-owned GitHub Checks for production trust. Treat patchflow.config.json as code: setupCommand and testCommand are shell commands.

Managed execution boundary

For production use, customer-owned GitHub Checks are the supported execution boundary: your tests run in infrastructure and with secrets you control.

PatchFlow does not currently offer a generally available hosted sandbox for running customer test code. Until that exists, required Checks on your repository remain the fail-closed gate.

Registry metadata boundary

PatchFlow discovers newer npm versions only for dependencies whose repository evidence routes them to the public npm registry. It uses package-lock resolved URLs and committed .npmrc registry mappings; unscoped packages without an override follow npm's public default. Scoped packages without registry evidence remain private or unknown and are not sent to the public registry.

For an eligible dependency, PatchFlow sends only its package name to registry.npmjs.org and reads the latest stable dist-tag. It does not send the repository name, source code, manifest, lockfile, GitHub identity, or credentials. The workspace shows registry provenance with the proposed upgrade.

PatchFlow does not currently accept private registry credentials. Private and ambiguous dependencies fail closed until a customer-owned registry access path is available; PatchFlow never falls back from a private registry to public npm.

Human merge boundary

PatchFlow opens draft PRs and never merges. Repository branch protection and required human approval remain the final authority.

Output handling

Gate output is truncated before storage, PR comments, and agent retry prompts. Avoid tests that print credentials; PatchFlow cannot reliably redact arbitrary application output.

NextCurrent limits