Security
Poliogo analyses your repository in memory and keeps the list of services it detected. The files the scanner reads are never stored; the one thing kept from your repository is the original of a file Poliogo edited when it installed your pages, so deleting the project can restore it. Every connection runs over TLS 1.3.
0
Source files kept after a scan. Files are read in memory and dropped.
TLS 1.3
On every connection, with HSTS set for a year on every response.
5
Sub-processors, each named below with its purpose and region.
72h
Maximum time to notify a supervisory authority of a qualifying breach.
Six controls. Each is a property of how the product is built, not a statement about intent.
The App that signs you in and scans your code holds three permissions — contents, metadata and emails — and every one of them is read. You choose which repositories it can see, and revoking it is one click in your Git provider's settings.
Manifests and source are read into memory, matched against the endpoint library, and dropped when the request ends. What is kept from your repository is one thing: when Poliogo edits a file of yours to install your pages — a layout, a footer, an existing legal page — the original is saved (up to 100 KB per file) so deleting the project can put it back, and the removal pull request shows exactly that.
Every connection is served over TLS 1.3, with HSTS set for a year on every response. Data at rest is encrypted by our infrastructure providers. Provider tokens ride in HttpOnly cookies that page scripts cannot read, and a pasted Cloudflare token is encrypted before it is stored there; the GitHub token Firebase hands your browser at sign-in stays in that tab's session storage and is mirrored to the same cookie for installs.
Drift updates land on a branch Poliogo creates and opens a PR from. Changes reach your default branch only through a pull request you approve — a merge is always your click, whether you press it on your Git host or on the Updates page.
Each one is named on the security page with its purpose, the data it touches and the region it runs in — the infrastructure, sign-in, analytics and billing providers, and the three AI providers that draft optional clauses from notes you type. Our Data Processing Addendum covers them, takes effect with the Terms, and needs no signature to apply.
Every change, approval and publication is recorded with who did it and when. Records are appended rather than edited in place, and the whole history downloads from Version History in your dashboard.
Access is granted per connection, and read-only except where opening a review request requires creating a branch. The right-hand column is the part worth reading: it is what the connection cannot reach even if we wanted it to.
| Connection | What Poliogo reads | What it never reads |
|---|---|---|
| Git — GitHub, GitLab, Bitbucket | Dependency manifests, source text and .env.example, in the repositories you select. | Repositories you did not select, and the value of any secret. |
| Hosting — Vercel, Netlify, Railway, Cloudflare Pages | Project names, the production URL, and environment variable names. | Environment variable values. They are never requested and never stored. |
| MCP server — Cursor, Claude Code, Windsurf | Your workspace, locally, on your own machine. | Your code never leaves the machine. Only the detected-service list is sent. |
One clarification, because it is the question a reviewer always asks: which of these can write, and what stops it writing anywhere else.
poliogo/compliance-* branch and opening a pull request from it.api scope. It is broader than we would choose — GitLab has no narrower grant that both lists your projects and opens a merge request — so what constrains it is the code rather than the scope: every write is refused before it leaves us unless it targets a poliogo/* branch.On every one of them, changes reach your default branch only through a pull request you approve. That is not a policy — it is a check in front of every write we make: a branch outside our own namespace is refused before any request reaches your host, and the merge is always your click, on your Git host or on the Updates page.
The whole lifecycle, end to end. It is short on purpose — the less a system retains, the less there is to reason about when someone asks what you hold.
01
The GitHub App is installed against the repositories you pick, and holds contents, metadata and emails — all read. Revoking it is one click in your GitHub settings, and it takes effect immediately.
02
Manifests and source text are streamed through the scanner at the edge and matched against the vendor endpoint library. There is no disk in that path to write them to.
03
The fingerprint: a list of the services we detected, such as “Stripe”, “Supabase”, “OpenAI”. It is what your documents are assembled from, and it is all a scan leaves behind.
04
Scanned file contents are discarded when the request ends. The one exception is deliberate: when Poliogo edits a file of yours to install your pages — a root layout, a footer, an existing legal page or banner — it keeps the original (up to 100 KB per file, 256 KB per project) so deleting the project can restore it, and the removal pull request shows exactly that. While an update waits for your approval, the edited version of those files is held with it; nothing else from your repository is stored.
Infrastructure security is half the question. The other half is whether the documents Poliogo produces can be traced back to something, and by whom they were written.
Every clause in a generated document is drawn from a maintained set built from published regulatory text and mapped to a service found in your stack. The one exception is the clauses drafted from operational notes you type yourself: those are written by a third-party AI model, shown to you before they are added, and stored as your own text. Everything else is fixed wording, which is what makes it reviewable at all.
Which services your code talks to is decided by pattern matching, not by a model, and the plain-English explanation beside each clause is fixed text written in advance. A model is reached in one place: drafting extra clauses from operational notes you type. Those land in the custom-clause slots, so no statutory section can be rewritten or removed by a model — but the drafting itself is steered by the prompt and checked by a schema on the way back, which is why you review the result before it is added.
Each change, approval and publication is logged with who did it and when, and the whole history can be downloaded from Version History in your dashboard. Records are appended, not edited in place.
The complete list, and we would rather it stayed short. Each is bound by a written contract limiting it to our instructions. Our Data Processing Addendum takes effect with the Terms and needs no signature to apply. We give 30 days’ notice before adding or replacing one. On September 11, 2026 the optional clause-drafting step moved to Cloudflare, which already ran our infrastructure, with Groq as its fallback; Google’s Gemini API and OpenRouter served it until that date and now receive nothing. Both remaining providers are barred by their written terms from training a model on what we send.
| Sub-processor | What it does for us | Where it runs |
|---|---|---|
| Cloudflare, Inc. | CDN, DNS, security filtering and edge compute — the platform the product runs on — and the AI model that drafts optional clause suggestions from the notes you type. Its terms bar training a model on them. | Edge locations worldwide |
| Google LLC (Firebase) | Sign-in, application data storage and push messaging. | United States |
| PostHog, Inc. | Product analytics on our public marketing pages only — never inside the signed-in product, and never on a customer's Trust Center. | European Union |
| PayPal (Europe) S.à r.l. et Cie, S.C.A. | Subscription billing and payment processing. | European Union and United States |
| Groq, Inc. | Drafts the same optional clause suggestions when Cloudflare is unavailable. Its Services Agreement bars training or fine-tuning on what we send. | United States |
Where personal data leaves the EEA, the UK or Switzerland we rely on the European Commission’s Standard Contractual Clauses, the UK International Data Transfer Addendum, or the provider’s certification under the EU–US Data Privacy Framework, and we assess the destination country’s laws first. The full detail, including retention periods and the cookie table, is in our Privacy Policy.
If you have found a security issue in Poliogo, we want to hear about it before anyone else does. There is no dedicated security@ alias yet, so until there is, both routes below reach us and both are monitored by the same people. Put Security at the start of the subject line or the message — reports carrying it are triaged ahead of ordinary support.
Preferred. Use it if your report includes attachments, logs, or a proof of concept.
Contact form
Use it if you would rather not send mail from your own address. Leave a reply address if you want to be credited.
We acknowledge a report within one business day and will tell you what we found and when it is fixed. Please give us a reasonable window to ship a fix before publishing, and test only against your own account — never against another customer’s data. We will not pursue a researcher who reports in good faith and stays within that.
Send us the questionnaire. We answer vendor assessments, countersign the DPA where your process needs a signed copy, and will walk a reviewer through anything on this page.
Found a vulnerability? Report it through the same route and mark it Security — we triage those first and will acknowledge you within one business day.