Privacy Policy

Last updated: 1 July 2026

1. Introduction

PRGuard is a product of Unifi Software Development Ltd ("the Company," "we," "us," "our"), a company registered in England and Wales (company number 11054002), trading at unifidev.com. We operate the PRGuard Code Governance platform at prguard.dev. This Privacy Policy explains what data we collect, why we collect it, how we process it, and how long we retain it.

We are committed to data minimisation. We collect only what is necessary to deliver the Service and maintain an auditable compliance trail. We do not sell your data. We do not use your code or governance rules to train machine learning models.

2. Data We Collect

2.1 Account Data

You can create an account in one of two ways, and what we collect depends on which you choose.

Registering directly — we collect:

• Your name
• Email address
• A securely hashed password

Signing in with GitHub (OAuth) — we collect:

• GitHub username and user ID
• Email address (from GitHub, used for account notifications and billing communications)
• GitHub OAuth access token (used to interact with the GitHub API on your behalf)

A directly-registered account may link a GitHub identity later, in which case we collect the GitHub data above at that point. Whichever route you use, two-factor authentication (TOTP) secrets are stored securely and used solely for login verification.

If you generate a personal API key for the prguard CLI or the HTTP API, we store only a one-way (SHA-256) hash of it — alongside a short, non-secret prefix so you can recognise the key — never the full key itself. The full key is shown to you once at creation; afterwards we can show you the prefix but cannot recover or display the key in full.

2.2 Organisation Data

When you create or join an organisation, we store the organisation name, associated billing plan, and membership roster (linking users to organisations with role designations).

2.3 Repository Metadata

For each connected repository, we store:

• Repository name and GitHub URL
• GitHub App installation ID
• Webhook secret (encrypted)
• An auto-generated repository-scoped API key (stored only as a one-way hash, never in plaintext)
• Configuration preferences (audit triggers, review mode, file skip patterns)

We do not clone, download, or store your repository source code.

2.4 Pull Request & Commit Data (Transient)

When a webhook is triggered, PRGuard fetches the PR diff or commit patch directly from the GitHub API. This data is:

• Processed in memory for the duration of the audit (typically seconds).
• Not written to disk or persisted in any database.
• Discarded immediately after the audit completes or fails.

We store only metadata about the audit: the PR number, title, author, commit SHA, file count, whether the diff was truncated, and the resulting verdict and findings. The raw diff content is never stored.

2.5 Context Files

Context Files — the Markdown governance rules you author in Context Studio — are stored in our database for the lifetime of the associated organisation or repository. These files are your intellectual property and are used solely to construct audit prompts. See our Terms of Service for details on the processing licence.

2.6 Billing & Payment Data

Payment processing is handled entirely by Stripe. We do not receive, process, or store credit card numbers, bank account details, or other payment instrument data. We store:

• Stripe customer, subscription, and session identifiers
• Payment amounts, statuses, and timestamps
• Credit balance and transaction history (an append-only ledger)

2.7 Audit Logs

Each completed audit produces an Audit Log record containing: verdict (Pass/Fail/Warning), quality score, structured findings (severity, file, line, category, message, and any suggested fix or remediation instructions, which may include short code excerpts), LLM provider used, processing duration, and whether the result was posted to GitHub. These records form the compliance audit trail.

2.8 LLM Usage Records

For billing accuracy and cost transparency, we record: the LLM provider and model used, input and output token counts, the raw provider cost, and the marked-up charge applied to your credit balance.

2.9 Session & Device Data

So you can review and sign out of where your account is logged in, we record limited information about each active login session:

• IP address of the session
• Browser user-agent string (from which we derive a readable browser and operating system label, e.g. “Chrome on macOS”)
• Timestamps for when the session began and was last active

This data is used solely for account security — to show you your active sessions in Account Settings and let you revoke any of them — and is never used for tracking, advertising, or profiling. The record is automatically deleted when you sign out of that session or when the session expires.

3. How We Use Your Data

We use the data described above to:

• Deliver the Service — fetch diffs, construct prompts from your Context Files, invoke LLM providers, and post results to GitHub.
• Bill accurately — track credit consumption, process payments via Stripe, and maintain an immutable financial ledger.
• Maintain the audit trail — provide your organisation with a searchable history of every governance decision for compliance and internal audit purposes.
• Communicate with you — send transactional emails (payment confirmations, payment failures, email verification) and, where permitted, product updates.
• Secure the platform — detect prompt injection attempts, validate webhook signatures, enforce rate limits, sanitise error messages, and let you review and revoke your own active login sessions.

We do not use your data for advertising, user profiling, or behavioural analytics.

4. Third-Party Data Processing

4.1 LLM Providers

To perform code audits and to generate automated fixes, PRGuard sends data to third-party LLM providers. Depending on the model your organisation selects, this is one of:

• Google (Gemini)
• Anthropic (Claude)

These are the only LLM providers we currently send data to. We will update this policy before enabling any additional provider. To keep audits running reliably, a given request may be routed to either of these providers: if one is temporarily unavailable, we may automatically send the request to the other to complete your audit. The data sent is the same in either case (see below), and both providers are governed by the API terms described in §4.2.

What is sent: The PR diff or commit patch (your code changes, including the changed file paths, which may be truncated for very large change sets), your Context Files (governance rules), the repository name, and the pull request number. When Deep Context Retrieval is enabled, we also fetch the external files your context rules reference and send their contents — and the compact summaries ("skeletons") we generate from them — to the provider as part of the audit. Other PR metadata we store for the audit trail — such as the PR title, author, and commit SHA — is not included in the prompt sent to the provider.

Automated fixes: When you request an automated fix for a finding, PRGuard fetches the current, complete contents of the file being fixed from the GitHub API and sends that full file — together with the fix instruction, your Context Files, and the file path — to the LLM provider so it can produce a corrected version. Unlike an audit, which sends only the diff, generating a fix necessarily involves sending the whole file being changed. Only files you have explicitly asked to fix are sent this way; no other files in your repository are included. The corrected file is written back to GitHub as a pull request or commit for your review; we do not store the full corrected file (see §7).

What is not sent: Your billing data, account credentials, or data from other organisations. Each audit is scoped to a single organisation.

4.2 Data Processing Agreements

We send this data to providers through their API or business channels, under the API terms in force at the time of each request. The major providers' current published API terms exclude data submitted through these channels from being used to train their models, and we choose these channels deliberately for that reason. However, third-party terms are outside our control and may change. Providers may also temporarily retain data for abuse-monitoring and safety purposes in accordance with their own published retention policies. We encourage you to review the data-processing and retention policies of any provider your organisation enables.

Audits are run using PRGuard's own provider API keys under the agreements described above; a Bring Your Own Key (BYOK) option is not currently offered. If we introduce BYOK in future — where requests would be sent under your own API agreement with the provider, governed by their terms — we will update this policy first.

4.3 Stripe

Stripe processes all payments and stores payment instrument data. Stripe's privacy policy applies to payment data: stripe.com/privacy.

4.4 GitHub

PRGuard communicates with GitHub to fetch diffs and post review comments. This is governed by your existing GitHub terms and the GitHub App permissions you granted during installation.

4.5 Infrastructure

The Service is hosted on cloud infrastructure. Application data is encrypted at rest and in transit (TLS 1.2+). We do not share application data with our infrastructure provider beyond what is necessary to operate the servers.

5. Data Retention

6. Data Minimisation

We apply data minimisation throughout the platform:

• The full source and complete diff are never stored. PR diffs are fetched from GitHub, processed in memory, and discarded after the audit. Only structured metadata and findings are persisted.
• Error messages are sanitised. API keys, GitHub tokens, file paths, URLs, and credentials are automatically redacted before storage.
• Encryption keys are isolated. LLM provider API keys are encrypted at rest using Fernet symmetric encryption with a dedicated field encryption key.
• Audit logs store findings, not your full source files. Findings reference file paths and line numbers, and may include short code excerpts — such as a suggested fix patch (capped at ~40 lines) or a specific symbol named in remediation instructions — but never the full file or the complete diff.

7. Data Security

We implement the following security measures:

• Encryption in transit: All connections use TLS 1.2 or higher.
• Encryption at rest: Sensitive application fields — LLM provider API keys and per-repository webhook secrets — are encrypted at field level using Fernet symmetric encryption. Two-factor (TOTP) secrets are held by our authentication subsystem and protected by encryption of the underlying datastore at rest.
• Webhook verification: All GitHub webhooks are verified using HMAC-SHA256 signatures with per-repository secrets.
• Deduplication: A 24-hour deduplication window, backed by our database cache, prevents processing the same webhook event twice.
• Two-factor authentication: User accounts are secured with TOTP-based two-factor authentication, which must be enrolled within a short grace period after first sign-in.
• Session visibility & revocation: You can review every active login session (device, browser, IP, and last activity) from Account Settings and sign out any of them — or all other sessions at once — if you suspect unauthorised access.
• Prompt injection defence: Untrusted content (PR diffs, Context Files) is fence-sanitised before prompt construction, and an automated pre-screening stage detects injection patterns.
• Immutable financial records: Credit transactions and billing records cannot be modified after creation.

8. Your Rights

Depending on your jurisdiction, you may have the right to:

• Access the personal data we hold about you.
• Rectify inaccurate personal data.
• Erase your personal data (subject to our obligation to retain financial and audit records for legal and compliance purposes).
• Restrict or object to certain processing activities.
• Data portability — receive your data in a structured, machine-readable format.

To exercise any of these rights, contact us at privacy@prguard.dev. We will respond within 30 days.

Note: Audit Logs, Credit Transactions, and Payment Records may be retained after account or organisation deletion where required for compliance, financial record-keeping, or legal obligations.

9. Cookies & Tracking

A cookie is a small text file stored on your device. We group cookies into the categories below. Under the UK Privacy and Electronic Communications Regulations (PECR) and the UK GDPR, strictly necessary cookies do not require your consent; all other categories are only set if and when you opt in.

Strictly necessary — required for the service to function, including sign-in sessions (sessionid), cross-site request forgery protection (csrftoken), and storing your cookie preferences (prg_cookie_consent). These are always active and cannot be switched off.

Analytics — optional. With your consent we may use Google Analytics (provided by Google) to understand how the product is used so we can improve it. Google Analytics sets cookies (for example _ga and _ga_*) and processes usage data with your IP address truncated (anonymised). These cookies are only set after you opt in and are never loaded if you reject them. As Google processes this data on servers that may be outside the UK/EEA, see “International Data Transfers” below.

Marketing — optional. If enabled, they help us measure campaigns and show relevant messaging. We do not currently load any marketing cookies; this category is reserved for future use and will only ever activate with your consent.

When you first visit, a consent banner lets you accept all cookies, reject all optional cookies, or choose individual categories. Rejecting is as easy as accepting. We keep a record of your choice for accountability. You can change or withdraw your consent at any time using the button below or the “Cookie settings” link in the site footer; we will ask again periodically and whenever this policy materially changes.

Cookie settings

10. International Data Transfers

Your data may be processed in jurisdictions outside your own, including where our infrastructure provider and LLM providers operate. Where data is transferred outside the UK or EEA, we rely on standard contractual clauses, adequacy decisions, or equivalent safeguards as required by applicable data protection law.

11. Children's Privacy

PRGuard is not directed at individuals under the age of 18. We do not knowingly collect personal data from children. If we become aware that we have collected data from a child, we will delete it promptly.

12. Changes to This Policy

We may update this Privacy Policy from time to time. Material changes will be communicated via email to the organisation Owner's registered address at least 30 days before they take effect. The "Last updated" date at the top of this page will always reflect the most recent revision.

13. Contact

For privacy-related enquiries, contact us at:

• Email: privacy@prguard.dev
• General enquiries: hello@prguard.dev