Security and data handling

This page describes the hosted BNLGit service during the public beta. It is written to be checkable rather than reassuring.

What we store

• Your repositories — source and .llm mirrors, as ordinary Git repositories on our infrastructure.
• Summary metadata — the provenance, freshness state, line spans, token counts and cost of each generated summary.
• Your BYOK connection secrets — encrypted, as described below.
• Account and billing records — email address, forge username, subscription state. Card details are held by Stripe, never by us.

What leaves the service

Two categories, both of which you control.

To your LLM provider. When you generate a summary, run a bake-off, or run a cleanup analysis, the relevant file contents are sent to the provider you configured, using the key you supplied. Nothing is sent to any provider you have not connected. If you connect no LLM connection, no file content leaves the service at all.

To no one else. We do not send your code to a model of ours, we do not train on it, and we do not share it with third parties.

How your provider keys are protected

Connection secrets are encrypted at rest with AES-256 under a dedicated BYOK_SECRET_KEY, deliberately separate from the instance's general-purpose secret key so the two do not share a blast radius. If that key is not configured, the service refuses to read or write connection secrets rather than falling back to another key.

Plaintext secrets are never returned by any API — only a masked hint — and credential references are visible only to repository admins and site admins.

Full detail: BYOK connections and security.

Outbound request restrictions

Requests BNLGit makes to a connection endpoint are blocked from reaching loopback addresses, private IP ranges, link-local addresses and cloud metadata endpoints, regardless of what URL the connection specifies. This is not tenant-configurable, which is the point of it on a shared service.

Access control

Every read is authorised per request against Gitea's own permission model. The BNLGit additions — search, MCP, the cleaner — do not introduce a parallel permission system and do not widen what a token can reach; they are different ways of asking the same question of the same model.

• Repo-scoped MCP requires code-read access on that repository.
• Fleet search and fleet MCP are scoped to what their caller can already see.
• Private repositories are excluded from a caller's results the same way they are excluded from the web UI.

What the shared beta does not isolate

Being straight about this matters more than sounding secure.

The public beta runs on a shared instance. That means:

• Your repositories are logically isolated by the permission model, but not physically isolated on separate hardware or in a separate database from other beta customers.
• Instance-level settings — including whether reranking is on, and the spend ceilings — are set by us as operator, not per tenant.
• Capacity is shared. A busy period affects everyone's response times.

If you need physical isolation, a dedicated instance is the answer rather than the shared beta. Mail hello@bnlgit.com.

Query embeddings

Where vector retrieval is enabled, search queries are embedded using our server-side key, never yours. Your key is spent only when indexing your own repository. This exists so that one reader cannot fan embedding spend across every tenant whose repositories they can see.

Your data on the way out

Everything of substance is a Git repository, including the summaries. git clone is a complete export — there is no proprietary format to escape from and no export request to file.

After cancellation your data is retained for 30 days, then removed. Deletion is confirmed by a person before it runs rather than fired by a timer.

Reporting a vulnerability

Mail hello@bnlgit.com with "security" in the subject. Please give us a reasonable window to fix an issue before disclosing it. We will tell you when it is fixed, and we will credit you if you would like to be credited.

What we do not claim

• We are not certified against SOC 2, ISO 27001 or any equivalent standard, and we do not imply otherwise.
• We publish no uptime SLA for the beta. It is a beta on shared infrastructure, and pretending otherwise would be the wrong way to start.
• We have not had an independent third-party penetration test of the BNLGit additions.

If any of those is a blocker for your organisation, it is better that you know now than after you have paid.