Security & Privacy
Learn what PatchPatrol sends to the configured model provider, where credentials and reports live, and which retention decisions remain with you.
You choose the PatchPatrol runtime and model endpoint. The configured provider receives bounded review context, so its network location and data-handling terms remain part of your deployment decision.
The table below separates responsibility across the PatchPatrol process, the customer-controlled runtime, GitLab, and the configured model provider.
Responsibility and data boundary
| Boundary | PatchPatrol behavior | Customer responsibility |
|---|---|---|
| PatchPatrol process | Selects bounded source context, applies scope limits, redacts secret-like content in extracted diff chunks, stops on high-confidence secret patterns found there, validates provider output, and writes review artifacts. | Choose review limits and verify that the resulting input and output match repository policy. |
| Customer-controlled runtime | Executes the PatchPatrol process and connects it to GitLab and the configured provider endpoint. | Keep any required GitLab and provider credentials in protected CI secret storage; control runner access, network egress, endpoint selection, and workspace cleanup. |
| GitLab | Supplies repository and merge-request context through the configured job; receives artifacts or merge-request feedback only when those delivery paths are enabled. | Control repository access, CI job-log and artifact retention, token scope, and access to the GitLab Review Summary or Inline Findings. |
| Configured model provider | Receives the selected review context when PatchPatrol makes a provider call and returns output that PatchPatrol validates before use. | Provider processing, provider logging, provider residency, and provider retention depend on the selected endpoint; evaluate any proxy or gateway between the runtime and endpoint too. |
Provider and trust boundary
This split matters because a customer-controlled runtime does not by itself make every provider local. Ollama or a self-hosted OpenAI-compatible endpoint can remain inside infrastructure the customer manages. A public or otherwise remote provider endpoint receives the selected context across that network boundary.
Credentials and source context
Which credentials you need depends on what you enable:
- The artifact-first path does not require a GitLab API token. A GitLab credential is needed only for enabled merge-request feedback.
- A provider credential is needed only when the selected endpoint requires one. An Ollama endpoint may not require a credential, and the mock path makes no provider call.
You configure the runner, token scopes, protected variables, and network policy. PatchPatrol uses the credentials supplied to the job; it cannot make those surrounding controls safe for you.
Before a provider call, PatchPatrol applies configured review limits to the selected input. Review input can include a bounded diff and bounded supporting context. The secret scan covers extracted diff chunks, not supporting context. It redacts secret-like content in those chunks and can stop the provider call when it finds high-confidence private-key or credential patterns. PatchPatrol assembles supporting context after this scan.
These controls reduce the chance of exposing sensitive data. They do not replace repository classification, least-privilege credentials, review-scope configuration, or provider due diligence.
Data boundaries and retention ownership
The runtime writes ai-review.json, ai-review.md, and ai-review.html to the
configured output path. Those review artifacts can contain findings, summaries,
metadata, and code-derived evidence, so customers should handle them according
to the source repository's sensitivity.
When repository context is enabled, raw rule instructions are not stored in
normal review artifacts by default. ai-review.json records compact audit
metadata under meta.repository_context, including
persisted_memory.enabled=false. With persisted review memory disabled,
PatchPatrol does not load earlier accepted, dismissed, edited, or resolved
findings into the current review. This says nothing about a model provider's
training or retention policy.
Storage and retention depend on where the customer publishes each output:
- Files left in the CI workspace follow runner cleanup behavior.
- Uploaded CI artifacts and job-log output follow GitLab project policies.
- A GitLab Review Summary and Inline Findings follow merge-request access and retention behavior.
- Provider request handling and model-provider retention follow the configured endpoint, gateway, and provider agreement.
Run Reports and other job artifacts follow the retention and access settings of the GitLab project and runner environment. Provider requests follow the configured endpoint, gateway, and provider agreement. PatchPatrol does not enforce one retention policy across those surfaces. Run Reports do not contain raw prompts or raw provider request payloads.
Report a vulnerability
Email suspected vulnerabilities to contact@patchpatrol.io and follow the
responsible-disclosure guidance in
SECURITY.md.
Include the affected component and version, impact, reproduction details, and only the logs or screenshots needed to investigate after redacting secrets. We do not currently publish an SLA for responses.
Next steps
- Trace selection, provider calls, validation, and output writing in Architecture.
- Review the trust and rollout settings in Policy controls.
- Use the Configuration reference for exact endpoint, secret, scope, and output settings.
- Follow the Admin Quickstart to prepare the GitLab artifact-first workflow.
Visit the PatchPatrol product website
for the short product overview.
Discuss a private GitLab review pilot
to evaluate these boundaries in your environment.