Privacy Policy

Effective date: {{EFFECTIVE_DATE}} Last updated: {{EFFECTIVE_DATE}}

This policy explains what personal data Cronspace collects, why we collect it, who we share it with, and what you can do about it. We have tried to write it in plain language rather than the usual fog.

---

1. Who we are

Cronspace is operated by {{COMPANY_LEGAL_NAME}}, registered under {{COMPANY_ID}}, with its registered office at {{COMPANY_ADDRESS}} ("Cronspace", "we", "us").

For personal data covered by this policy, we act as the data controller, except where Section 6 says otherwise.

Privacy questions and data rights requests: {{PRIVACY_EMAIL}}. Security reports: {{SECURITY_EMAIL}}.

2. Who this policy covers

This policy applies to {{WEBSITE_URL}} and to the Cronspace application.

Two things it does not cover:

• Third-party services you connect. When you connect a Shopify store, a Meta Ads account, a Google Analytics or Search Console property, a database of your own, or an MCP server, that provider's own privacy policy — or, for your own database, your own practices — governs what happens to the data on that side.
• Data you bring in about other people. If you upload a customer list or connect a store containing your customers' data, you are the controller of that data and we process it on your behalf. See Section 6.

3. What we collect

3.1 The waiting list, before you have an account

If you ask to be notified about Cronspace, we store your email address, your name, the roles you selected to describe your work, and the timestamps of your request and your confirmation. We send one confirmation email and record only a hash of the link's token, so a stolen copy of our database cannot be used to confirm somebody else's address.

The legal basis is your consent, given by confirming the email. Being on the list is not an account and never becomes one on its own. To be removed, write to {{PRIVACY_EMAIL}} and we will delete the entry.

3.2 Account information

When you create an account: your email address, a hashed password, your name if you provide one, and the invite code you used. We never store your password in a form we can read.

3.3 Workspace content

Everything you and your agents create in the product:

• Agent configurations — instructions, selected model, enabled tools, approval policy, spending limits.
• Tasks and their schedules.
• Runs and their full transcripts — every step an agent took, the tools it called, the arguments it passed, and what came back.
• Chat threads and messages.
• Files you attach to a conversation, and artifacts your agents produce.
• Approval decisions — what you approved or rejected, and when.
• Memories you approved — guidance shared with the whole workspace, and your own preferences, which only you can see. An agent can suggest one, but nothing is saved until you accept it.
• Skills — the folders of instructions and files you upload, import from a public GitHub repository, or have an agent write for you, with every version and the result of the automatic security check. A personal skill is visible only to you; one published to the workspace is visible to every member.

Chat threads are private to the person who created them. Other members of the workspace do not see them, and neither do admins or the owner. What a thread does to shared resources — database writes, spending, artifacts, dispatched tasks — is recorded in the workspace's shared history with that person's name on it, and every member can see that. The one route into private content is the workspace export, which only an owner can run and which is written to a log every member can read before the export is built. That bundle carries the workspace's chats, its projects, its memories and its skills — including the personal memories and skills that are otherwise visible only to the person who saved them.

Workspace content may contain personal data if you put it there. We do not inspect it beyond what is needed to run the service.

3.4 Connection credentials

When you connect an external service, we store the access token or API key needed to reach it. These are encrypted at rest with AES-256-GCM, held separately from your workspace content, and decrypted only inside the specific operation that needs them. They are never included in an agent's context or written to our logs.

3.5 Data retrieved from your connected services

When an agent uses a connector, it retrieves data from that service and stores it as part of the run transcript so you can audit what happened. Depending on what you connect, this can include sales figures and order aggregates, advertising performance metrics, website and search traffic metrics, rows returned by queries against a database you connected, and whatever the MCP servers you configure return.

The database connector deserves its own warning: unlike the analytics connectors, which return aggregates, a query against your own database returns whatever is in it. If those rows contain personal data, that data is written into the run transcript and retained with it. Choose the credential and the queries accordingly.

3.6 Usage and technical data

• Model usage: per step, the model used and the token counts, so we can calculate cost and enforce your spending limits.
• Operational logs: timestamps, run identifiers, workspace identifiers, error details. We keep these to diagnose failures.
• Standard request data: IP address and browser user-agent, processed by our hosting provider for delivery, security and abuse prevention.

We do not run third-party analytics, advertising trackers or session recording on Cronspace.

3.7 Cookies

We set only what the product needs to work:

• A session cookie that keeps you signed in.
• A short-lived invite cookie that remembers you redeemed a valid code, so the sign-up form appears.

These are strictly necessary cookies. We do not use cookies for advertising or cross-site tracking. If that ever changes, we will ask for your consent first.

4. Why we use your data, and on what legal basis

Where we rely on legitimate interests, we have weighed them against your rights. You can object — see Section 11.

5. AI models and your content

To answer you, an agent sends the relevant part of your workspace content — your messages, the run's context, attached files, tool results — to a model provider. We route these requests through the Vercel AI Gateway to the provider of the model that answers — the one you selected, or, in Auto, the one Cronspace chose for that message.

The model you pick decides which company receives your content. The models on offer today come from Anthropic, OpenAI, Google, xAI, DeepSeek, MiniMax and Alibaba; image generation uses models from OpenAI, ByteDance, Recraft and xAI. The provider is part of the model's name and is shown in the agent's settings before you select it.

Auto. A chat can be set to Auto instead of a model, and new chats start that way unless your workspace says otherwise. In Auto, Cronspace picks the model for each message from a short fixed list — today Alibaba's Qwen for simple messages and Anthropic's Claude (Haiku, Sonnet and Opus) for the rest — so in Auto your content can go to any provider on that list, including one whose processing region is not published (section 8). To decide the provider yourself, pick a model instead of Auto, in the chat or as your workspace's default for new chats. Scheduled tasks never use Auto.

To choose, Cronspace has a small classification model from TypeSafe AI, reached through the Gateway, judge what kind of request each message is. It does not write replies. It reads only what you wrote in the message being answered (shortened when it is very long), the end of the previous reply, the names of tools used recently, and the kinds of file attached — never tool results, attached documents, memories or your workspace instructions. TypeSafe AI does not train on customer requests, and this request carries the same restriction as every other. What is decided, and why, is kept as a record of the turn, without the text of your message.

Several of these models are open-weight and are served by inference providers rather than by the company that trained them, so the model's origin is not the same thing as the place your request is processed. Section 8 lists the processing region the Gateway publishes for each one, and says plainly where none is published.

Three commitments:

• We do not use your content to train models, ours or anyone else's.
• We do not sell your data, and we do not share it for advertising.
• Every model request is routed only to providers contractually barred from training on it. Several of the models we offer are served by a pool of inference providers rather than by one company, and not every provider in every pool gives that guarantee — so we set the restriction on the request itself, and a provider that does not qualify is never eligible to serve it. This applies to chats, scheduled runs and image generation alike.

Memory search. Your agents can use the memories you approved (section 3.3). To find the few that matter for what you are doing, we turn text into numeric vectors with an embedding model from OpenAI, again through the Gateway. What leaves for this is:

• the title and body of a memory, when it is saved, edited, or suggested by an agent — the suggestion is checked against what you already remember, so you are not asked to save the same thing twice;
• the text that opens the turn — your message, or a scheduled task's title and goal — but only in a workspace that already holds more than a dozen of your own memories. Below that, everything you remember fits in the request anyway and nothing is sent.

Attachments are named, never sent. This happens whichever chat model you selected, and it carries a stronger guarantee than the rest: these requests are routed under zero data retention, so the provider computes the vector and keeps nothing. As everywhere else, none of it is used to train models.

Skills. When you add a skill, an automatic reviewer reads it to look for instructions that would harm you. Today that review is done by an Anthropic model, reached through the Gateway under the same restriction as every other request: it is routed only to providers barred from training on it. When an agent loads a skill, the skill's instructions go to the model that is answering — one you selected, or in Auto one on the Auto list — like any other part of your message, and the files it reads or the scripts it runs stay in that conversation's sandbox. We keep the result of each review — its verdict, summary, findings, cost and the model's answer — with the skill, for as long as the skill exists.

One limit you should know about:

• Model output can be wrong. Nothing an agent tells you should be treated as verified, and it is not professional advice. See the Terms of Service.

6. When you are the controller and we are the processor

If you use Cronspace to process personal data about other people — your customers, your leads, your employees — then for that data you are the controller and we are the processor. We process it only on your documented instructions, which in practice means: the agents you configure, the tasks you schedule, and the connectors you authorize.

This matters most for connected commerce and advertising accounts, where the data we retrieve on your instruction can describe your customers.

If you need a Data Processing Agreement, contact {{PRIVACY_EMAIL}}.

7. Data from connected services

Shopify. If you connect a store, agents query it for sales analytics. We handle any protected customer data in line with Shopify's requirements: we retrieve only what is needed to answer your question, we do not use it for any purpose other than serving your request, and we do not sell or share it.

Meta. If you connect advertising accounts, agents retrieve performance metrics for the accounts you select. We use Meta data only to answer your questions inside Cronspace, never to build advertising profiles or to enrich any other dataset. Disconnecting your account, from either side, triggers deletion of the data we hold from it.

Google. If you connect Google Analytics or Search Console, agents retrieve traffic and search metrics for the properties you select. We store the refresh token needed to keep the connection alive, encrypted as described above, and we use Google data only to answer your questions inside Cronspace. Disconnecting revokes the token.

Databases you connect. A Postgres or MySQL database you connect is your system, and its contents are yours. We store the connection credential encrypted, we execute the queries your agents run under the permissions you granted, and we write the results into your run transcripts. We do not copy your database, index it, or use its contents for anything other than the run that asked for them. Grant the narrowest credential that does the job: what an agent can read, it can put in a transcript.

MCP servers you configure. These are your own integrations. What they return is governed by whatever those systems are. We store the results in your run transcripts, and we cannot vouch for the privacy practices of a server you point us at.

You can disconnect any service at any time from your workspace settings. Disconnecting revokes and deletes the stored credential.

8. Who we share data with

We do not sell personal data. We share it only with the providers that make the service run:

A model provider receives your content only when a message is answered by one of its models: one you selected, or, in Auto, one on the Auto list (section 5). TypeSafe AI receives the excerpt described in section 5 only for messages in a chat set to Auto. Rows below the Gateway are therefore conditional on your own choice — pick a model, and Auto's providers never see your content. The one exception is memory search, which always uses an OpenAI embedding model whatever chat model you picked — section 5 says exactly what it sends and when.

"Processing region" is what the AI Gateway publishes for that model's eligible inference providers. "Not published" means we cannot state a region, not that the data leaves the EEA or the United States — several of these models are open-weight and served by providers in various countries. If a guaranteed region matters to you, the Claude and Gemini models are the ones that publish one.

Each is bound by a data processing agreement limiting them to processing on our instructions.

We may also disclose data when the law requires it — a valid court order or a binding request from a competent authority — and, if we are ever part of a merger or acquisition, to the acquiring party, who would remain bound by this policy or give you notice before changing it. We will tell you about a legally compelled disclosure unless we are prohibited from doing so.

9. International transfers

Some of the providers above process data in the United States. Where we transfer personal data outside the European Economic Area, we rely on the European Commission's Standard Contractual Clauses, or on an adequacy decision where one covers the provider. You can request a copy of the safeguards at {{PRIVACY_EMAIL}}.

For model requests, the destination follows the model that answers — the one you select, or in Auto one from the Auto list. The Gateway publishes an EU-or-US processing region for some models and none for others, as set out in Section 8. Where no region is published we cannot promise one, and you should assume the request may be processed outside the EEA under the Standard Contractual Clauses our provider agreements rely on. If a guaranteed region matters for your data, restrict your agents to models that publish one and choose a model rather than Auto; the choice is yours and it is made per agent.

10. How long we keep things

When you delete something in the product, it goes from the live system straight away and ages out of backups on the schedule above.

11. Your rights

Under the GDPR and comparable laws, you can ask us to:

• Access the personal data we hold about you, and get a copy.
• Correct anything inaccurate.
• Delete your data ("right to be forgotten").
• Restrict or object to processing based on legitimate interests, including profiling.
• Port your data to another provider in a machine-readable format.
• Withdraw consent, where we relied on it, without affecting what came before.

Write to {{PRIVACY_EMAIL}}. We will respond within one month; if a request is complex we may extend by two further months and will tell you why. We may need to verify your identity first.

You also have the right to complain to a supervisory authority. In Spain that is the Agencia Española de Protección de Datos (aepd.es); elsewhere in the EEA, the authority where you live or work.

12. Security

What we do:

• Encryption in transit (TLS) and at rest.
• Connection credentials encrypted with a separate key and decrypted only inside the operation that uses them.
• API keys stored as hashes, never in plain text.
• Access to production data limited to personnel who need it.
• Workspace isolation enforced in the application layer, so one workspace cannot read another's data.
• Agent actions gated by approval policies, with a full step-by-step record of every run.

Files you attach and artifacts your agents produce are stored in a private store. They are only served to signed-in members of the workspace that owns them; there are no public links to them.

No system is perfectly secure. If we suffer a breach affecting your personal data, we will notify the relevant supervisory authority within 72 hours where required, and tell you directly when the law requires it.

13. Children

Cronspace is not for anyone under 16. We do not knowingly collect data from children. If you believe a child has given us personal data, write to {{PRIVACY_EMAIL}} and we will delete it.

14. Changes to this policy

We will post any change here and update the date at the top. If a change materially affects your rights, we will tell you by email or in the product at least 14 days before it takes effect.

15. Contact

{{COMPANY_LEGAL_NAME}} {{COMPANY_ADDRESS}} Privacy: {{PRIVACY_EMAIL}} · Security: {{SECURITY_EMAIL}} · General: {{CONTACT_EMAIL}}