PatchPatrol Docs

Security & Privacy

Public trust posture, retention responsibilities, and vulnerability reporting for PatchPatrol.

Security and Privacy

This page describes what PatchPatrol currently guarantees in the public documentation surface and what customers must continue to enforce in their own environments.

This is the public operational posture today, not future roadmap commitments.

Provider and trust boundary

PatchPatrol runs on your CI/runtime infrastructure with selected provider endpoints:

  • AI_REVIEW_PROVIDER=openai uses a configured OpenAI-compatible base URL.
  • AI_REVIEW_PROVIDER=ollama uses OLLAMA_HOST.
  • AI_REVIEW_PROVIDER=mock skips provider calls for docs and dry planning.

The public posture favors customer-controlled model endpoints first, while still supporting public-hosted endpoints for quick evaluation.

Before provider review starts, PatchPatrol performs trust checks:

  • provider allowlist validation,
  • secret-like content redaction.

If redaction detects high-confidence private-key/credential patterns, trust checks can fail and provider execution stops.

For non-mock providers, an empty AI_REVIEW_PROVIDER_ALLOWLIST_BASE_URLS is treated as a trust-gate failure. In that default state, runs stop before any provider call and return exit 11. When using openai, operators should also set OPENAI_BASE_URL explicitly if they rely on a non-default endpoint.

Data boundaries and retention ownership

PatchPatrol does not claim an external vendor-hosted retention or lifecycle layer for artifacts.

  • Artifact files remain in the configured output path (AI_REVIEW_OUTPUT_DIR, default .ai-review) unless your CI publishes them.
  • CI logs, Merge Request comments, and any local backups follow your pipeline and repository retention settings.
  • No component in this public surface currently enforces a central retention policy for artifacts.

The product expects operators to define and enforce retention in CI job settings and repository governance.

For concrete policy guidance, see:

Secret handling and logging posture

PatchPatrol avoids shipping raw secrets into logs as part of the standard flow.

  • Secret-like patterns in review input are redacted before provider context handling.
  • Logs focus on structured run signals and metadata.
  • Operators should still treat OPENAI_API_KEY, GitLab tokens, and CI variables as secrets managed by their own secret infrastructure.

Security posture and reporting

Security reporting for the project remains:

  • Route: contact@patchpatrol.io
  • Process: follow disclosure expectations in SECURITY.md.

Current posture notes:

  • No formal SLA for response in this pilot phase.
  • Reported findings are triaged and coordinated through the contact route above.
  • Trust signals in artifacts are best treated as part of your rollout controls and validation process, not as a replacement for private review policy.

What this is and is not

  • It is a statement of shipped runtime behavior and policy docs.
  • It is not a claim of enterprise-grade guarantees, hosted compliance attestations, or additional support promises beyond the public support policy.

If you are mapping rollout risk, use this together with:

On this page