Privacy Policy
Bitting UAB
1. Who we are and what this policy covers
Bitting UAB (“Bitting”, “we”, “us”) runs a service that keeps a register of an organization's keys and certificates, works out which of its services hold each key, and runs key rotations that the organization's named people approve. To do that, software the customer installs in its own network reads the customer's repositories, CI logs, chat, tickets and infrastructure, masks every secret value and anything shaped like a card number, and sends the masked text to our models in Stockholm. This policy explains what personal data we handle when we do that, and why.
Registered at Lvivo g. 25, LT-09320 Vilnius, Lithuania.
We handle personal data in two different situations, and different rules apply to each:
| Whose data | Our role | What applies | |
|---|---|---|---|
| Part A | People who visit this website, ask about the service or write to us | Controller: we decide why and how the data is used | This policy |
| Part B | Our customers' staff who hold accounts, approve rotations, own services or answer the model's questions; and people who appear in what the service reads, such as commit authors, chat message senders and ticket writers | Set out in B.1, because it depends on the data | This policy and the data processing agreement we sign with each customer |
If the data processing agreement (“DPA”) and this policy ever disagree about Part B, the DPA wins.
2. Part A: this website and our contact with you
This part covers the personal data we collect for our own purposes: running this website, answering requests, and staying in touch with people who are or might become customers.
A.1 What we collect
What you give us. When you send the form on this site, we collect what you type into it, such as your name, email address, phone number or company, and the fact that you agreed to be contacted. If you email or talk to us, we keep that correspondence and any contact details in it.
What is collected automatically. Our web server records the IP address a request came from, the browser used, the pages requested, the page you came from and the time. These logs exist to keep the site running and secure.
We don’t ask for sensitive data (the “special categories” in Article 9 GDPR) through this website, so please don’t send any through the form.
A.2 Why we use it, and what allows us to
| Why | What | Legal basis (GDPR Art. 6) |
|---|---|---|
| Answering your request and working out whether the service fits | What you sent in the form, our correspondence | Art. 6(1)(b): steps you asked for before a contract |
| Looking after customers, billing and support | Contact details, correspondence | Art. 6(1)(b): carrying out a contract |
| Keeping the site running, secure and free of abuse | Server logs | Art. 6(1)(f): our legitimate interest in running a secure service |
| Contacting you about the service | Email address, company | Art. 6(1)(f): our legitimate interest in business-to-business marketing. You can object at any time |
| Meeting tax, accounting and legal duties | Billing and contract records | Art. 6(1)(c): a legal obligation |
Where we rely on legitimate interest, we have weighed that interest against your rights, and you can ask to see the assessment.
A.3 How long we keep it
- Requests from people who don’t become customers: 12 months from our last contact, then deleted.
- Customer contact and contract records: for the length of the agreement plus ten years, the period Article 78 of Lithuania's Law on Value Added Tax sets for keeping invoices.
- Server logs: 30 days.
- A record that you objected or opted out: kept indefinitely, so we can keep respecting it.
A.4 Your rights
If you are in the EEA or the UK, you can ask to see your data, correct it, have it deleted, limit or object to how we use it, get a copy you can take elsewhere, and withdraw consent where we rely on it. Write to [email protected] and we will answer within one month.
You can also complain to a data protection authority. If you are in the EEA, that can be the authority where you live or work.
3. Part B: data inside the service
This part covers the data that passes through the service: the masked text the Bitting agent sends us from a customer's repositories, CI logs, chat, tickets and infrastructure, the register and holder maps built from it, and the approvals and evidence log of every rotation.
B.1 What we handle, and in what role
For what the service reads from a customer's systems, and for the register, holder maps and evidence log built from it, we act as a processor under the data processing agreement: the customer decides which repositories, logs, channels and clusters are connected and what is done with the result. For account details and approval records we act as a controller. The service handles the following:
- Masked source text. Lines of code and commit details (author name, email address and time), CI log lines, chat messages, tickets and wiki pages from the repositories, pipelines, channels and spaces the customer connects. The Bitting agent reads them inside the customer's network and, before any line leaves it, replaces every secret value with a label and a keyed fingerprint and deletes anything shaped like a card number. Names and email addresses of commit authors and message senders stay in the text and are personal data.
- Infrastructure descriptions. Kubernetes manifests, Helm values, infrastructure state, pipeline definitions, the names of secrets, variables and vault paths, the names of services and their owners from files such as CODEOWNERS, masked in the same way.
- Approvals, questions and the evidence log. The names, work email addresses and passkey public keys of approvers, account holders and service owners; the questions the model asked and the answers people gave; who prepared, approved, signed and ran each rotation and when; and every step the agent took.
- Coding-agent requests. For each request a coding agent sends through the boundary: the time, the agent and its pass, the API, method and path, whether a key was attached, whose approval the pass ran under and the outcome. Bodies of requests to test APIs are kept; bodies of requests to live APIs are never kept, only their size and a fingerprint.
We never receive a key's value in clear. The agent handles values inside the customer's network, and each key version Bitting rotates is stored with us only as ciphertext under a wrapping key that is generated in the customer's network and kept there, so nobody at Bitting can open it.
We do not process card data. The agent deletes anything shaped like a card number before a line leaves the customer's network, and the boundary keeps no body of any request to a live payment API.
Raw source text, key values and the wrapping key never reach us. If the customer switches the agent off, nothing more is read.
B.2 What we do with it
Reading and masking. The Bitting agent runs on the customer's own machines, reads only what the customer connected, and dials out to us; it accepts no inbound connection. A small classifier inside it marks candidate credentials on the customer's machines, and the agent masks values before anything is sent.
Mapping holders and preparing rotations. Our models read the masked text on cloud GPU capacity we control in Stockholm, link each key to the services that hold it, write what stops if it changes, and prepare a rotation plan from a fixed set of steps. Where a model is unsure, it asks the owner of the service a question and waits for a person's answer.
Running approved rotations. A rotation runs only after the customer's named approvers sign its plan with a passkey. The agent then carries out exactly the approved steps in the customer's systems, and reads each destination before and after it writes.
The register and evidence log. The register, holder maps, approvals and every step are written to an append-only, hash-chained log on cloud infrastructure in Stockholm, with clocks synchronized to a documented time source, and can be streamed to the customer's own security log tools.
No onward sale. We do not sell, rent or share anything the service reads or builds. The subprocessors that host the service on cloud infrastructure in Stockholm, send our email and take payment all process data inside the EU and are named on our subprocessor list.
B.3 AI models: where they run and what they learn from
Where models run. Bitting's models run on cloud GPU capacity we control in Stockholm, Sweden, beside the register and evidence log on cloud infrastructure in Stockholm. One small classifier, which tells credentials from other strings, runs inside the customer's network in the Bitting agent, on the customer's own machines. The models in Stockholm receive masked text only: where a key was found, its kind and issuer, the names of secrets, variables and services, and manifests, infrastructure state and pipeline definitions with every secret value replaced by a label and anything shaped like a card number deleted. No key value and no card data is ever sent to them, and nothing is sent to a third-party model provider, which is why none is on our subprocessor list.
Training. We do not train on customer data unless a customer opts in. Our models are fine-tuned on infrastructure code we generate with planted keys whose holders we know, and on public infrastructure code published under permissive licenses. A customer may opt in, in its order form, to share corrections: when its platform lead corrects a holder link the model proposed, we keep a pair, the masked context and the corrected link, with service and repository names replaced by their kind and no key value. Pairs from customers who opted in are pooled to fine-tune our holder model on GPUs in Stockholm. The classifier in the agent is trained only on generated and public data.
Where a person decides. Everything the model produces is a proposal. When the model is less than nine in ten sure it has found every service that holds a key, it prepares no rotation: it names the links it could not settle, asks the owner of each service and waits. A rotation runs only after a person the customer names approves it with a passkey, a key the customer marks critical needs a second signature, and nothing is ever approved on a timeout. The model never switches an old key off while a service it found still uses it, and a coding agent's pass, which the model proposes, runs only once a person approves it. The service makes no automated decision with legal or similarly significant effect on any person.
B.4 Where the data is kept
Masked source text, holder maps, the register, approvals, the evidence log, the ciphertext of rotated key versions, and the backups of all of them are stored and processed on cloud infrastructure in Stockholm, Sweden. None of it is stored or processed outside the EU, and no subprocessor outside the EU receives any of it.
Key values, the raw text the agent reads and the wrapping key stay in the customer's own network, on machines the customer runs. Payment details are held by our payment provider and never reach our systems.
The suppliers that handle data in the service are named on our subprocessor list, which comes with the data processing agreement and which we send to anyone who asks: write to [email protected].
B.5 How long we keep it, and what deleting can’t remove
The register, approval records and evidence log are kept for the period the customer sets, five years unless it sets another, up to ten. When a contract ends we send a full export and delete them within 30 days, unless the customer asks us in writing to keep them until its own period ends.
Masked source text is kept for 90 days after the read that used it and then deleted; what the register needs from it is in the register.
Bodies of coding-agent requests to test APIs are kept for 30 days. The rest of the boundary log is kept with the evidence log.
Where a customer has opted in, a correction to a holder link is kept as a pair, the masked context and the corrected link with service and repository names replaced by their kind, for as long as the models trained on it are in use. A customer that withdraws consent has its pairs deleted before the next training run.
Account-holder details are kept for the life of the account and 24 months after it closes. Invoices and the accounting records behind them are kept for ten years, the period Article 78 of Lithuania's Law on Value Added Tax sets for invoices.
B.6 Requests from people whose data is in the service
If your personal data is in what Bitting reads for a customer, for example as the author of a commit or the sender of a chat message, the customer chose what to connect and holds the source; write to that company. If you write to us instead, we pass your request on to the customer within five business days. If you hold an account with us or approve rotations, write to us directly about your account details and approval records.
For everyone
4. Moving data between countries
Bitting UAB is a company in Lithuania, inside the EEA. Section B.4 says where the data in the service is kept. If any personal data we control ever has to leave the EEA, for example because a supplier named on our subprocessor list handles it elsewhere, it is protected by the European Commission’s Standard Contractual Clauses or another safeguard the GDPR accepts. You can ask us for a copy.
5. Security
We protect data in line with the risk. That includes encryption in transit and at rest, access limited to the people and systems that need it, each customer’s data kept separate from every other’s, and a log of every access to production systems.
If a personal data breach affects you, we tell you without undue delay, and at the latest within 36 hours of finding out, with the information you need to meet your own reporting duties.
6. Children
The service is sold to businesses and is not meant for children. We don’t knowingly collect personal data from anyone under 16.
7. Changes to this policy
We may update this policy. If a change matters, we email customers at least 30 days before it takes effect. The version number and date at the top of this page change every time.
8. Contact
Privacy questions and anything else: [email protected]
By post: Bitting UAB, Lvivo g. 25, LT-09320 Vilnius, Lithuania