Security at Kubi

Effective 2026-11-15

This page explains how Arthur Katcher, doing business as Kubi protects Kubi and what's on your Screens, where we stand on audits and certifications, and how to report a security problem. Capitalized words, such as Screen and Your Content, mean what our Terms of Service say they mean. "Terms 8.3" points to a section of the Terms, and "Privacy 9.1" to a section of the Privacy Policy.

The short version

• Each Screen is a separate virtual computer with its own disk (Terms 1).
• We don't look inside your Screens without a reason, and we log every time a person does (Terms 8.3).
• Each Screen keeps a 30-day history with the screenshots its calls returned, unless you turn detailed history off, and we never record the live view (Terms 8.4).
• We never train AI on Your Content (Terms 8.2).
• Screens, our main database and our backups run in the EU by default (Privacy 8.1).
• We tell you within 72 hours of a personal data breach that affects your data (DPA).
• We don't have SOC 2 or ISO 27001. Section 2 says what we do have and what's planned.
• Found a vulnerability? Write to security@trykubi.com. We won't take legal action against good-faith research that follows our vulnerability disclosure policy.

1. About this page

1.1 Kubi rents cloud computers, which we call Screens, to developers and their AI agents. The service is provided by Arthur Katcher, doing business as Kubi. Kubi is a small company, so this page lists what we do today, marks what is planned and says plainly what we don't have yet.

1.2 Our binding security commitments are in the Terms (section 4.5) and in our DPA. This page describes how we meet them and links each point to the text behind it. We may change these measures as long as the overall level of protection does not materially decrease (Terms 4.5).

1.3 We review this page at least once a year and whenever something on it changes; the date at the top shows the last change. At least once a year, we also assess the risks to the Service and to our customers' data, such as a host failure, a leaked key, fraud or a flaw in the separation between Screens, check that our measures still fit them, and record what we change.

2. Where we stand

2.1 Our current status:

2.2 Our Data Processing Agreement forms part of the Terms (Terms 8.7) and includes the EU Standard Contractual Clauses and the UK Addendum.

2.3 You enter card details on Stripe's payment page or in Stripe's payment fields, so your full card number stays with Stripe (Privacy 6.2), and Stripe's PCI guide says this setup qualifies for SAQ A. Our CSA STAR answers are a self-assessment against the Cloud Security Alliance's questionnaire, updated every year, not an audit.

2.4 Every week, an automated scanner checks scan scope for known vulnerabilities and weak configuration, and we review the results. A scan finds known problems; it is not a penetration test.

2.5 When a status changes, the table shows it: the date for SAQ A, the registry link for CSA STAR, the date of a penetration test, after which business customers can ask for a summary, and the start of a SOC 2 audit. We don't sign HIPAA business associate agreements.

3. Screens are kept apart

3.1 Each Screen is a separate virtual computer with a Linux desktop and its own disk (Terms 1).

3.2 How we keep Screens apart from each other and from the servers they run on: each Screen runs in its own virtual machine.

3.3 Trying to break out of a Screen or to reach another customer's Screen is against our rules (Terms 6, rule 3). Security researchers can test isolation under section 15.

4. What's on your Screens

4.1 You own Your Content, and we use it only to provide the Service to you (Terms 8.1). We never use it, or anything derived from it, to train AI models, we don't let our subprocessors do so, and we never sell it (Terms 8.2).

4.2 We don't routinely scan inside your Screens (Terms 7.2). A person looks inside a Screen only if you ask us to, to investigate abuse or a security problem, or when the law requires it. We log every such access and tell you about it, except in the cases Terms 8.3 lists.

4.3 The live view and the clicks and keystrokes your Agents and viewers send pass through our servers without being kept. Each screenshot a call returns is saved, encrypted, in the Screen's history for 30 days, unless you turn detailed history off (Terms 8.4, Privacy 5.4).

4.4 A Screen's history records each call made on it, with its parameters, including typed text, and the screenshot it returned. Typed text that matches a secret you saved is blanked, and the history is kept for 30 days (Privacy 5.5, 9.1).

4.5 Live view access. live view access

4.6 Service Data, the usage, performance and security signals we use to run Kubi, doesn't intentionally include the contents of your Screens (Terms 8.8).

4.7 Our own use of AI tools. When we use AI tools in our own work, such as coding assistants, we use business accounts whose terms exclude training on what we send. We don't paste Your Content into them, and they get no access to production systems or your Screens. Privacy 6.7 covers the AI that helps draft support replies.

5. Encryption and keys

5.1 Connections to the dashboard, the API, the MCP server and the live view are encrypted with TLS, version minimum TLS version or newer, and we reach our own systems only over encrypted connections (Privacy 8.3). At rest: Screen disks, recovery copies, database backups, saved screenshots and disk exports are encrypted at rest (Privacy 10).

5.2 We store your API keys only as hashes, so a copy of our database would not reveal them (Privacy 3.1). The logins and keys you give your Agents are Your Content and stay on your Screens (Privacy 5.1).

5.3 Encryption keys and our own secrets. The keys that encrypt stored data are kept apart from the data they protect: rebuilt at each boot by Clevis with Kubi's own Tang key servers, which never hold the key, with an offline passphrase as the fallback, so no key is stored with the disk it unlocks. Our own credentials for running Kubi, such as server, database, Stripe and email keys, are kept in an encrypted secrets store, never in source code. Only people with production access can reach them, with two-factor sign-in (DPA, Annex II). We replace a key as soon as we learn it may have leaked.

6. Where your data lives

6.1 Screens, our main database and our backups run in the EU by default, in France and Germany. We don't move Your Content to another country without telling you first, unless an emergency or the law requires it (Terms 4.1, Privacy 8.1).

6.2 Some data is handled outside the EU:

6.3 Kubi is run from Serbia, and the seller is not established in the EU. Where the law requires a safeguard for a transfer, we use transfer mechanism, such as the EU Standard Contractual Clauses with the UK Addendum or IDTA (Privacy 8.2, 8.3).

6.4 Our servers run in data centers operated by Ikoula and Hetzner, and our backups are stored with Scaleway; they handle physical security, power and cooling. host certifications. Those certificates cover their data centers, not Kubi itself.

6.5 We disclose data to authorities only when the law requires it and after a reasonable check that the request is valid, and we tell you, except in the cases Terms 7.5 lists. Our data export and switching page, trykubi.com/legal/data-export, explains which countries' laws apply to our infrastructure and how we handle government requests (Terms 12.5).

7. Who can access our systems

7.1 people with production access can access Kubi's production systems. That access requires admin access method. Every administrative access is logged, including every time a person opens a Screen, and we keep this admin log for 1 year (Privacy 8.3, 9.1).

7.2 Anyone who joins Kubi gets only the access their work needs, and we remove it on the day they leave. Before anyone new gets production access, they sign a confidentiality agreement at least as strict as our Terms (Terms 9) and are briefed on our security rules and incident plan. At least every 3 months, we review who and what can reach production, including people, admin keys and service accounts, and remove what is no longer needed (DPA, Annex II).

7.3 Our work computers use full-disk encryption and a screen lock and get software updates promptly. We copy Your Content to them only when a case needs it, and delete it afterwards (DPA, Annex II).

7.4 We will never ask you for your API keys or for the passwords on your Screens. If someone claiming to be Kubi does, please tell us at security@trykubi.com.

8. Accounts and sign-in

8.1 You sign in to Kubi with GitHub or Google, so we never see or store a password for Kubi (Privacy 6.2). Turn on two-factor sign-in for that account. If you lose access to it, we help you move your Account to another sign-in (Terms 3.3).

8.2 Dashboard sign-in sessions end 7 days after last use, and we keep sign-in records for 90 days to spot account takeovers and leaked keys (Privacy 9.1). New Accounts start with lower limits, and we may ask you to verify your identity or payment method (Terms 3.4).

8.3 Account owners manage their Team Members (Terms 3.3). If an API key leaks or someone gets into your Account without permission, revoke the key in the dashboard and tell us at security@trykubi.com right away (Terms 3.3).

8.4 Single sign-on through your company's identity provider (SAML) isn't available yet. Each Team Member signs in with their own GitHub or Google account. If they use your company's Google Workspace accounts, your company's rules for those accounts, such as required two-factor sign-in, apply to their Kubi sign-in too.

9. Network and abuse controls

9.1 Where Screens can connect. Screens can reach the internet, so your Agents can use the websites they need, but outgoing email ports are closed by default (Terms 6). You can't yet limit which sites a Screen connects to. If you need that, run your own proxy or firewall inside the Screen. An Agent that reads a page with hidden instructions could try to send your data elsewhere (Terms 5.3), so give it only the logins and data a task needs (section 14.2).

9.2 Automated signals about network and resource use, such as a sudden burst of outgoing connections, can slow down or pause a Screen to stop harm. Where practicable, a person reviews the case before we suspend or close an Account (Terms 7.2). Our network log records IP address, port, time and Screen, never contents, so we can trace abuse reports, and we keep it for 90 days (Privacy 9.1).

9.3 Anyone can report abuse to abuse@trykubi.com, and when we act against an Account, we explain why and how to appeal (Terms 7.1 to 7.4). Kubi isn't available to anyone on a US, EU, UK or UN sanctions list or in a country under comprehensive sanctions (Terms 2.4), and Stripe runs fraud and identity checks for us (Privacy 6.2).

9.4 Protecting our servers. Screens can't reach other customers' Screens or our management systems (DPA, Annex II). Our servers accept only the connections the Service needs and block everything else. The host's DDoS protection sits in front of our public endpoints. We review our firewall rules at least once a year and whenever the setup changes.

10. Backups, deletion and leaving

10.1 We don't back up your Screens for you: our recovery copies are for our own failures, so keep your own copies of anything important (Terms 8.5). For our own disaster recovery, we keep encrypted copies of Screen disks for 7 days and database backups for 14 days. They are not a backup service for you (Privacy 5.6, 9.1).

10.2 When you delete a Screen, you can restore it from the dashboard for 7 days; then we erase its disk, history and saved screenshots (Privacy 9.2). You can export Your Content at any time, free of charge, and our export page, trykubi.com/legal/data-export, lists the methods, formats and known limits (Terms 12.1, 12.5). When your Account ends, you have the Retrieval Period to download your data, then we erase it, and we never restore a deleted Account or Screen from our backups (Terms 12.4, Privacy 9.3).

10.3 Restoring after a disaster. We test restoring a database backup at least once a year (DPA, Annex II). We have no formal recovery time or recovery point targets yet. If our database had to be restored, changes made since the last backup could be lost, and Screens can be restored only from recovery copies, which are best effort.

11. How we build and run Kubi

11.1 How code reaches production. Our code and server configuration live in version control (DPA, Annex II). Before a change reaches production, these automated checks run: tests, a scan of our dependencies for known vulnerabilities and a scan for secrets committed by mistake. We deploy only from version control, never from a laptop, and try changes outside production first. Kubi has one engineer today, so these automated checks stand in for a second reviewer. We never copy Your Content into test systems.

11.2 We follow security advisories for the software Kubi runs on and aim to patch critical vulnerabilities in our infrastructure promptly, starting with anything that could let one Screen reach another or reach our servers. How Screen images are kept up to date: screen image updates. The software you install inside a Screen is yours to keep updated (Terms 4.5).

11.3 Our systems send metrics and ops logs, which contain no Screen contents or keys, to Grafana Labs, which alerts us when something breaks (Privacy 9.1).

11.4 We don't promise a particular uptime (Terms 4.4). Our status page, status.trykubi.com, shows outages, and we announce planned maintenance in advance when we can. If a fault in our systems makes a Screen unavailable for more than 4 hours in a row, we credit that time if you ask within 30 days (Terms 10.8).

11.5 Our SDK. Its source is public at SDK repository URL. We publish each release from that repository with an automated workflow that adds build provenance on npm, so you can check that a package was built from our public source. Publishing uses short-lived tokens, not stored passwords. A bot proposes dependency updates, and we can send you a software bill of materials (SBOM) for a release on request. Security fixes go into the latest release, and we publish an advisory for each one (vulnerability policy 6.4). The same applies to our CLI once it is released.

11.6 If we can't be reached. If we can't be reached during an incident, our automated limits keep working and can slow down or pause a Screen that harms others (Terms 7.2). A named backup person, with their own logged admin account, can also pause Screens and post on the status page. If we ever stop offering Kubi, Terms 11.3 and 12 give you notice, a refund of prepaid Fees for the time you won't use, and the export tools and Retrieval Period.

12. Subprocessors and vendors

12.1 The Trust Center lists every subprocessor, what it does and where it processes data. We announce new ones there at least 30 days before they start, except in urgent cases (Privacy 6.1), and business customers can object as the DPA describes. Before we add a vendor that would handle customer data, we review its security documents, its data processing terms and where it processes data.

12.2 Our subprocessors are bound by contract, and we remain responsible for their work (DPA 2.3). The AI models, websites and services your Agents use are your choice, not our subprocessors (Privacy 6.6).

13. Incidents

13.1 If we confirm a security breach that affects Your Content, we notify you without undue delay and share what we learn as our investigation progresses (Terms 4.5, Privacy 10). The DPA sets the deadline and what the notice contains: no later than 72 hours after we become aware of a personal data breach that affects your data.

13.2 For data we control ourselves, such as Account and billing data, we also notify the data protection authority and the people affected where the law requires it. For data on your Screens, you notify your own authority and the people affected, and we help you do it (DPA 2.2). A breach caused by what you run or share inside your Screens is yours to handle, but we tell you if we learn of one.

13.3 After an incident, we aim to tell affected customers what happened, what data was involved, what we did and what we changed to prevent it happening again.

13.4 At least once a year, we rehearse our incident plan on a made-up incident and fix what the rehearsal shows.

13.5 If a widely reported vulnerability could affect the separation between Screens or our servers, we post an advisory in the Trust Center saying whether you are affected and whether you need to do anything. When you need to act, Account owners also get an email.

14. Your part

Security is shared. We secure the servers, the network and the separation between Screens. You are responsible for what runs inside your Screens (Terms 4.5). In practice:

14.1 Keep your API keys secret. Use a separate key for each Agent or environment, so you can revoke one without stopping the others, and revoke keys you no longer use.

14.2 Give your Agents only the logins and keys a task needs, since they can read web pages with hidden instructions (Terms 5.3), and keep payments, purchases and other actions with legal or financial effect under human review (Terms 5.4).

14.3 Save the passwords and keys your Agents type as secrets, so history blanks them, and turn detailed history off for Screens that handle sensitive data (Terms 8.4).

14.4 Keep copies of anything important outside Kubi (Terms 8.5).

14.5 Treat live view links as secrets, and share access to your Account only with people you trust.

14.6 Keep the software you install on your Screens up to date, and tell us at security@trykubi.com if you suspect a Screen has been compromised.

15. Reporting a vulnerability

15.1 To report a security problem, email security@trykubi.com. Our vulnerability disclosure policy at trykubi.com/legal/vulnerability-policy explains what you may test, how we respond and the safe harbor we give to good-faith research, and it is the binding text. Our contact details are also in trykubi.com/.well-known/security.txt.

16. Documents you can get

16.1 What is available and how:

16.2 We answer security questionnaires from business customers by email at security@trykubi.com. We start from our CSA STAR answers, so a standard questionnaire, such as the CSA CAIQ, is quicker for both sides than a custom one.

17. Frequently asked questions

17.1 Is Kubi SOC 2 compliant? No. We haven't started a SOC 2 audit, and we will start one when a customer needs the report. Until then, this page, our DPA and our CSA STAR answers show what we do.

17.2 Do my Screens share anything with other customers? Each Screen is a separate virtual computer with its own disk, but Screens from different customers can run on the same physical server. Section 3 explains how we keep them apart.

17.3 Can Kubi see my Screens, passwords or prompts? A person looks inside a Screen only in the cases in section 4.2, and we log every such access. The live view is never stored, screenshots are kept only in your Screens' 30-day history, and passwords your Agents type are blanked there once you save them as secrets. Your Agents use the model provider you choose, under your own account, so your prompts go to that provider, not to us (Privacy 6.6).

17.4 Do you train AI on my data? No (section 4.1). We use AI provider to help draft support replies, and it never receives the contents of your Screens (Privacy 6.7).

17.5 Do you offer zero data retention? A Screen keeps its disk, because that is what a Screen is for, and you delete it when you want. Beyond that we keep little: we never store the live view, history with its screenshots is kept for 30 days and can be switched off, ops logs for 14 days, and the network log, which records no contents, for 90 days (Privacy 9.1). Ask security@trykubi.com if you need a shorter period for something.

18. Contact

Arthur Katcher, doing business as Kubi, postal address

• Security issues, leaked keys and security questions: security@trykubi.com
• Abuse reports: abuse@trykubi.com
• Privacy questions and requests: privacy@trykubi.com
• Legal notices and requests from authorities: legal@trykubi.com
• Help and billing: support@trykubi.com
• EU representative: EU representative name, address, email and phone
• UK representative: UK representative name, address and email

A person reads every message sent to these addresses.