Privacy policy
What VESPR stores and shares today, what is only planned, and who else touches your data. If something is not described here as true today, treat it as not built.
On this page
The short version
- No ads, no selling. VESPR shows no advertising and does not sell, rent or trade personal data.
- The marketing site is quiet. It sets no cookies, runs no analytics and loads nothing from other companies.
- A workspace is shared. Files, chat, names and cursors are stored on the server of whoever runs that VESPR, and everyone in a workspace can see all of it.
- Agents send text to a model provider. When you ask an agent for help, the parts of the workspace it needs are sent to the AI model provider the operator configured. Today that is NVIDIA Nemotron models through Nebius Token Factory.
- Accounts, schools and payments are not live. They are described below only so you can see what is coming. See Children and schools.
Who runs the server (the operator)
VESPR is open-source software. Whoever runs a VESPR server is its operator and decides what is kept on it. For the hosted service and the public demo that we run, the operator is [Legal entity name], [Registered address]. Privacy questions go to [Privacy contact email].
If a school, a company or a friend runs their own copy, this page does not describe their server. Ask them.
This website, today
- The pages are static files. There are no cookies, no analytics or advertising scripts, and no fonts or scripts loaded from other sites. Two kinds of page send what you type to the VESPR server: the sign-in, sign-up and account pages (only when accounts are switched on there), and the early-access form on the home page (your email address only).
- Your browser keeps these on your own device: in local storage,
vespr-theme(dark, light or auto); in session storage,vespr-intro(a flag so the opening mark plays once per tab) and, only after you sign in on the account pages,vespr-session(your session token for that tab, removed when you sign out or close the tab). None of it is read by anyone but your own browser, except that the session token is sent to the server with your sign-in requests. - When a sign-in page loads, it asks its own server which sign-in methods are available. That request carries nothing about you. If accounts are not switched on, the page says so and sends nothing.
- Early access. If you enter your address on the home page, we store it with the time you asked and, if you click the link in our note, the time you confirmed. We send one note to confirm it was you, and later one note when the code is public or sign-in opens. We use it for nothing else and share it with no one. Ask us to remove it at [Privacy contact email]. Retention: [how long unconfirmed and confirmed addresses are kept].
- Like every web server, the machine that delivers these pages sees your IP address, browser type and the page you asked for. A static page has no VESPR code that records visits, but the company hosting the files may keep ordinary access logs for [log retention period] ([static hosting provider]).
What exists in a workspace today
A workspace (the code calls it a “room”) is one shared document per team. Everything below lives on the operator’s server.
| Data | What it is | Who can see it |
|---|---|---|
| Files | The text of every shared file, saved as a snapshot and also exported as plain files. If someone commits, a git repository too. | Everyone with access to that workspace. |
| Chat | Messages between people and with agents, approval cards (who approved or denied), and notes about commands the agent ran. Chats with an agent are not private. | Everyone in the workspace. |
| Names, colors, cursors | The name attached to your access, a color, which file you are in and where your cursor is. Live while you are connected, and also written to the session log. | Everyone connected; the log is readable with any valid access token for that server. |
| Authorship | For each piece of text: who wrote it (person or agent), when, and for agent text the model and the request behind it. Used for the hover view, replay and commit messages. | Everyone in the workspace. |
| Session log | Every change to the shared document and every presence change, with a timestamp. It powers replay and the catch-up summary, and it contains everything typed in the workspace. | Anyone with a valid access token for that server. |
| Uploads | Files you upload (documents, spreadsheets, images, audio, video, 3D, PDFs), stored under a random ID. The original file name, size, checksum, who uploaded and when are stored beside it. | Anyone with a valid access token for that server can list and download any workspace’s uploads. |
| Usage counts | How many AI tokens each agent and person used, for the budget meter. | Everyone in the workspace. |
| Access tokens | A list of names and secret tokens that let people and agents connect. | The operator. |
In your browser the VESPR app keeps two small settings: which skill packs you chose (local storage, vespr-focus) and a flag that shortens the opening animation on a repeat visit (session storage, vespr-booted). The VS Code editor inside it keeps its own settings in your browser as well. The app reads your access token from the link you were given and does not save it in your browser’s storage.
Do not paste secrets into a workspace. Anything typed there lands in the shared document, the session log and, if an agent reads it, the model provider’s servers.
What is sent to the AI model provider
When someone asks an agent for help, or uses inline suggestions, VESPR’s agent sends the provider:
- the instructions it was given and the list of files in the workspace;
- the workspace chat history;
- the text of any file the agent reads or edits, and the output of any command it runs;
- text extracted from an attachment you ask it to read;
- for inline suggestions, the text before and after your cursor plus short context from teammates’ recent edits and chat.
Today the provider is Nebius Token Factory, serving NVIDIA Nemotron models. An operator can configure a different one. The provider processes the text and sends an answer back. Its own rules on retention and on whether prompts may be used to train models are in its terms: [link to provider data terms, retention period and training policy; not yet confirmed]. We will not state those rules here until we have confirmed them.
What we do ourselves: VESPR does not use your workspace content to train or fine-tune any model.
Other outside calls, only when used:
- Web search is off. If an operator turns it on, the agent’s search query goes to the search provider.
- GitHub. If someone opens a GitHub repository in a workspace or installs a skill from GitHub, the server downloads it (pinned to a commit). No workspace content is sent to GitHub.
- A teammate’s computer. If a runner is enabled, commands and the files they need are sent to that person’s machine, which they chose to share.
Accounts and sign-in In development
The public demo does not use accounts: people connect with an access token the operator gives them. An accounts system exists in the code but is switched off by default and is not part of the demo. If it is switched on, this is what it stores:
- email address, display name, when the account was made and updated, and whether the email was verified;
- the password only as a salted scrypt hash, never the password itself;
- the sign-in providers you link (Google, Microsoft, GitHub, Clever) and the email each gave us;
- if you turn on two-step sign-in: an authenticator-app secret and ten single-use recovery codes (the codes stored only as hashes), or a phone number for text-message codes sent through Twilio;
- a session: a random token of which only a SHA-256 hash is stored, with your user ID, email and name, valid for 30 days;
- failed sign-in attempts, counted in memory by email and IP address for 15 minutes to slow down guessing.
Verification emails and early-access notes are sent through [email delivery provider]. During sign-in with Google, Microsoft or GitHub, one short-lived cookie (10 minutes) remembers the sign-in step. The authenticator secret and phone number are kept in an account file that only the server can read; they are not separately encrypted. See Security.
Cookies and similar storage
The marketing site sets no cookies. The app uses the two browser settings listed above. Once accounts are switched on, the only cookie is the short sign-in cookie described above. There are no advertising or tracking cookies and no analytics today. If we add analytics, this page changes first.
How we use data
To keep workspaces in sync, save them, replay them and serve git; to run the agents you ask for; to enforce limits and keep the service safe; and to answer you when you write to us. We do not use data for advertising, for profiling, to sell to anyone or to train models.
Who we share data with (subprocessors)
These companies handle data for the service. Items not yet in use are marked.
| Provider | What for | What it receives | Status |
|---|---|---|---|
| Nebius (Token Factory) | AI model processing (NVIDIA Nemotron) | The prompts described under “What is sent to the AI model provider” | In use. Location and terms: [to confirm] |
| Nebius (AI Cloud) | Hosting the public demo server | Everything stored in demo workspaces | In use for the demo. Region: [to confirm] |
| Certificate and name services (Let’s Encrypt, sslip.io) | HTTPS certificate and address lookup for the demo’s temporary web address | The web address and server IP, no workspace content | In use for the demo until it has its own domain |
| [Static hosting provider] | Serving this website | Ordinary web server logs | [not chosen yet] |
| GitHub | Importing a repository or a skill someone asks for | The request for that public content | In use only on request |
| Tavily | Web search for agents | Search queries | Off |
| [Email delivery provider] | Verification emails | Recipient address and message | Planned |
| Twilio | Text-message sign-in codes | Phone number and code | Planned |
| Google, Microsoft, GitHub, Clever | Sign-in | Your sign-in request; they send back a verified email and name | Planned |
We may disclose data when the law requires it. [lawyer to add how we respond to legal requests and whether we tell you]
How long we keep data, and deleting it
| Data | How long | How it is deleted |
|---|---|---|
| Workspace files, chat, uploads, session log, git repository | Until the operator deletes the workspace. There is no automatic deletion today. When a session log passes 40 MB the old one is set aside and a new one starts; the old one is not deleted automatically. | By the operator, by hand. On the public demo the operator can reset all workspaces, which removes uploads too. |
| Account data Planned | Until you delete the account or [inactivity period] | On request; later by a button in the app |
| Sign-in sessions In development | 30 days | On sign-out or expiry |
| Copies at the model provider | [per provider terms] | [per provider terms] |
| Backups | [to confirm whether any exist] | [to confirm] |
Deletion on request. Write to [Privacy contact email] and we will delete what we hold about you within [number of days]. Today there is no self-service delete button, so a person does it. Because workspaces are shared, what you wrote in a shared file is also your teammates’ work. How we handle your name in authorship records after deletion is [not decided yet].
Your choices and rights
You can ask us for a copy of your data, to correct it, to delete it, or to stop using it in a particular way. Depending on where you live, laws such as the EU and UK GDPR or California privacy law give you specific rights. [lawyer to confirm which laws apply, the legal basis for each use, and how fast we must answer] Write to [Privacy contact email].
Children
VESPR is not for children under 13 today (minimum age [to confirm with counsel]). Education features for students are planned, with stricter rules, and are described on Children and schools. If you believe a child under 13 has used a workspace, write to us and we will delete their data.
Where data goes
The demo server and the model provider are located in [countries to confirm]. [lawyer to add transfer safeguards if needed]
How we protect data
See Security for what is implemented and the gaps. The most important one: anyone with a valid access token for a server can read any workspace on it.
Changes and contact
If we change this policy in a way that matters, we will [how we announce changes] before it takes effect. Contact: [Privacy contact email], [Registered address].