Gatekeep Trust Center

The short version

• We do not store your source code. In BYO-LLM and self-host modes, your code never reaches a Gatekeep-controlled server at all.
• Zero telemetry. No analytics, no phone-home, no license check that calls out, no crash reporting to us. This is an architectural invariant in the self-hosted build, verified with an egress-restricted test (details below).
• All inference runs on the LLM endpoint you configure. Point it at your own gateway (local vLLM/Ollama, Azure OpenAI, Bedrock) and code never leaves your trust boundary.
• We are a day-0 startup. We are not SOC 2 certified yet. We will not claim a certification we don't have. See the Certifications roadmap and, more importantly, how self-host makes the question smaller.

Data-handling model

Gatekeep reviews a pull request and turns that review into a blocking merge gate plus an audit record. Here is precisely how your code is handled at each step.

What we process, and where

1. Code is processed in-memory, during a review only. When a PR is opened or updated, Gatekeep fetches the diff (and bounded neighboring lines) via the GitHub API, builds a prompt, and sends it to the LLM endpoint. The diff lives in process memory for the duration of that single review and is then discarded.
2. Zero code storage. Gatekeep does not persist your source code, diffs, or file contents to disk or to any database. The only durable state is the audit log — and the audit log records governance events (findings' severity/rule/location, gate decisions, override justifications), not your source files. See What the audit log contains.
3. All inference goes to the endpoint you configure. Gatekeep speaks the OpenAI Chat Completions contract to a base_url you set. In self-host / BYO-LLM mode that is your gateway (vLLM, Ollama, Azure OpenAI, Bedrock/LiteLLM). If you point it at a LAN endpoint, no code touches the public internet.
4. Only two outbound destinations, ever. The application makes outbound connections to exactly two hosts: (a) your GitHub API base URL, and (b) the LLM base_url you configured. There is no third connection to Gatekeep. This is enforced in code and tested.

The zero-telemetry invariant (and how it's verified)

The self-hosted application ships with no analytics, no usage beacons, no remote license validation, and no crash reporter. We verify this the only way that actually proves it: we run the container behind an egress firewall that permits only your GitHub and your LLM host, then execute the full review → gate → override → audit-export flow. Everything must pass with zero blocked outbound attempts to any Gatekeep-owned domain. This egress-restricted test is part of our release sign-off, not a marketing claim.

You do not have to take our word for it: because you run the container, you can apply the same egress restriction yourself and watch nothing leave.

What the audit log contains

The audit log is append-only and hash-chained (each record's hash chains to the previous record's, so any edit or deletion is detectable). It records, per event:

• pr_reviewed — PR number, head commit SHA, finding severities/rules/locations, whether any were suppressed from the timeline.
• gate_decision — pass/fail, the threshold used, and which findings tripped the gate.
• override_granted / override_denied — actor, timestamp, head SHA, and the full written justification text.

It is exportable as JSONL (GET /audit/export, authenticated) — the artifact you hand your auditor. The log stores review metadata and decisions, not your code.

Audit trail · append-only · hash-chained verify() chain intact

1. pr_reviewed PR #4127 · 2 findings (1 HIGH)

   2026-07-22 14:02:58Z · actor gatekeep · head a1b2c3d4

   sha256 4f2a…9c1 ← prev 0b7e…

2. gate_decision fail · threshold: block on HIGH

   2026-07-22 14:03:11Z · actor gatekeep · merge locked

   sha256 b83c…d40 ← prev 4f2a…9c1

3. override_granted override by @dana

   "Hotfix approved by security — ticket SEC-2231. HIGH finding triaged as false positive; parameterized query already merged in a2f9e10."

   2026-07-22 14:19:44Z · actor dana · justification logged

   sha256 e15d…7a2 ← prev b83c…d40

Deployment options

Pick the deployment that matches your trust requirements. The product is the same; the trust surface shrinks as you move down the list.

• Cloud (managed): fastest to start. You can still use BYO-LLM so inference routes to your own key. If you use our managed LLM pool instead, see the subprocessor list.
• Self-Hosted: a single container (or Helm chart) inside your infrastructure. Zero code storage, zero telemetry, zero outbound except to your LLM gateway. Flat monthly pricing with no enterprise sales cycle — during early access, design partners onboard directly with the founding team.
• Air-Gap: self-host with the LLM endpoint on your LAN. The whole system functions with no public internet egress. This is a supported, documented configuration, not a special edition.

Subprocessors

Honesty note: subprocessors apply to our managed Cloud tier only. If you self-host, Gatekeep uses no subprocessors for your code — your code and audit log never leave your infrastructure, so there is nothing to sub-process.

Cloud tier subprocessors

Notes on honesty and completeness:

• Specific vendor names for hosting, email, and support are being finalized as we stand up the managed tier; this list will name each provider before General Availability, and we will version it here. We would rather show you an honest work-in-progress than a polished list of vendors we haven't signed.
• If you use BYO-LLM on the Cloud tier, no managed LLM provider is a subprocessor — inference goes to your key.
• We will post material subprocessor changes here with reasonable advance notice for Cloud customers.

Security practices

We are early, so we state what we actually do, not aspirations dressed as controls.

Architecture & data minimization

• Code is processed in-memory during a review and not persisted. There is no source-code datastore to breach.
• Least-privilege GitHub App: we request only Pull Requests (read/write), Contents (read), Checks (read/write), Issues (read/write, for the override command), and Metadata (read). We do not request Administration, Workflows, Deployments, Actions, or org-admin. Asking for those would (rightly) fail your security review, and we don't need them.
• Short-lived credentials: the GitHub App mints 1-hour installation tokens per installation; nothing uses a long-lived global credential for your repo data.
• Webhook authenticity: every inbound webhook is HMAC-SHA256 verified (X-Hub-Signature-256) with constant-time comparison, and fails closed on a missing/malformed signature.

Secrets

• Bring-your-own secrets. Your GitHub App private key and LLM key are provided by you via mounted files / environment variables. We never ship, transmit, or store your credentials, and they never appear in config.yaml — only references to env vars / file paths do.

Tamper-evident audit

• The audit log is append-only by design (no update/delete code paths) and hash-chained; a verify() pass recomputes the whole chain and flags any gap, broken link, or edited record.

Fail-safe, not fail-open

• If the reviewer errors or times out, the gate does not silently pass. A review failure yields a failing/neutral check with a clear message — never a false green. For a governance tool, silence must never look like approval.

Supply chain

• We do not execute untrusted third-party CLI wrappers inside the review path. We will publish our dependency list and, as we mature, an SBOM and third-party penetration-test results here. Self-hosting means you control the network boundary and can verify nothing leaves.

Certifications roadmap (honest status)

Current status: Gatekeep is NOT SOC 2 (or ISO 27001, or HIPAA) certified. We are a day-0 company. We will not claim a certification, attestation, or audit report we do not have.

• SOC 2 Type II — planned. We are building toward it. The controls our audit log is designed to evidence (blocking gate, mandatory written override justification, immutable hash-chained trail) are the same controls a SOC 2 program cares about, so the product's output is useful to your audit today even while ours is in progress.
• ISO 27001 / HIPAA alignment — on the roadmap, prioritized by design-partner demand.
• We will publish real dates, scope, and the auditor's name here only once an engagement is signed — not before.

How we answer "what do you store? / SOC 2 docs?" today

Regulated buyers ask this first, and it's the right question. Our honest answer has two parts:

1. Self-host shrinks the trust surface to almost nothing. The reason vendors need a thick SOC 2 report is that your code sits on their servers. In Gatekeep's self-host / BYO-LLM mode, your code never reaches us — there is no Gatekeep-side copy of your source to secure, subpoena, leak, or attest about. The question "what do you store?" has a concrete answer: nothing of yours. That is a stronger guarantee than a certification about someone else's data center.
2. You get the audit evidence regardless of our cert status. The hash-chained, exportable audit log is the artifact your compliance function actually consumes. It exists on day one.

If your procurement process hard-requires a vendor SOC 2 report before purchase, tell us — we'll be transparent about where we are, and self-host may let your security team approve us on architecture (no code egress) rather than paperwork.

Data Processing Agreement (DPA)

A Data Processing Agreement for the Cloud tier is available on request — email us and we'll send the current outline for your legal team to review. In self-host / air-gap mode your code and audit log never leave your infrastructure, so there is no processing by us to cover; the DPA is relevant to managed Cloud customers.

Vulnerability disclosure

We build a security tool. We expect to be held to a security tool's standard. If you find a vulnerability in Gatekeep, we want to hear about it, and we will not lawyer you for reporting it in good faith. This is a summary of our full Vulnerability Disclosure Policy.

Security contact

Our /.well-known/security.txt is published. Report vulnerabilities to security@gatekeephq.pro. Honest status notes: mailbox forwarding is being finalized during early access — if a report bounces, reach the founder directly via the details in our outbound correspondence, and tell us so we fix it. A PGP key for encrypted reports is not published yet. Roadmap

Scope

In scope: the Gatekeep application/container (the self-hostable service); the Gatekeep Cloud (managed) service and its public endpoints, once live; our public website and marketing pages; and the GitHub App integration surface (webhook handling, signature verification, token flow, Checks API usage).

Out of scope: your LLM endpoint, your GitHub instance, and your infrastructure (in self-host/BYO-LLM mode these are yours, not ours); findings that require a compromised host, physical access, or a malicious insider who already controls the container; social engineering, physical attacks, and denial-of-service / volumetric testing; missing security headers or best-practice "nice-to-haves" with no demonstrable exploit; and third-party dependencies without a working exploit path through Gatekeep.

Safe harbor

If you make a good-faith effort to comply with this policy while researching and reporting a vulnerability, we will consider your research authorized and lawful, we will not pursue or support legal action against you for it, we will work with you to resolve the issue quickly, and we will not report you to law enforcement for accidental, good-faith violations. Good faith means you test only against your own instance or a dedicated test account, minimize harm, stop at proof-of-concept, keep it confidential until we've had a chance to remediate, and file one issue per report with clear reproduction steps.

Our response SLAs

Severity is assessed using CVSS as a guide plus real-world exploitability in Gatekeep's context.

Recognition

We maintain a security acknowledgements list and will credit reporters who want it (opt-in). We do not currently run a paid bug-bounty program, and we will not imply one exists. If that changes, it will be announced here. For now, we offer credit, a fast and respectful response, and our genuine thanks — a governance tool lives or dies on being trustworthy, and you're helping us earn that.

---

Questions

Security or trust questions: see the vulnerability disclosure section above for the security contact, and our DPA (available on request) for data-processing terms (Cloud tier). For anything else, contact the founder directly — at this stage you get a person, not a ticket queue.