Privacy Policy

Who we are

The intentic platform (intentic.dev and the workspace app at app.intentic.dev) is operated by Artur Kurowski, trading as radarsu, a sole trader established in Poland ("we", "us"). Contact: contact@intentic.dev.

We act in two different roles, and the difference matters. For your account, your billing and the records of which sandboxes exist, we are the data controller and this policy governs. For the contents of a sandbox we host for you, we are a processor acting on your instructions: that relationship is governed by our Data Processing Agreement, which forms part of these documents.

What we collect about you

The platform itself stores your identity, where your sandboxes are, and what you have paid for:

• Account data: your name, email address and avatar, received from Google when you sign in, plus the version of these documents you accepted and when.
• Session data: a session token, and the IP address and browser user agent of each sign-in, kept to keep accounts secure. Expired sessions are deleted automatically.
• Sandbox records: sandbox names, their public addresses, and the connection tokens used to reach them. Tokens are stored encrypted.
• Hosted machine records: for a sandbox we host, the machine and volume identifiers at our infrastructure provider and the region it runs in.
• Teammate emails: addresses you enter when sharing a sandbox, stored so the invitee's account can find it. Invitations never accepted are deleted after 90 days.
• Hosted plan records: your subscription status and billing period from Stripe. Hosted usage: the awake minutes of your hosted sandbox each calendar month, so the free lane's allowance can be enforced; kept 13 months so you can query a limit you were told you hit.
• Trial usage: a per-day count of model messages you used on the free trial, so the daily allowance can be enforced.

What we do not collect

We run no advertising and no ad or cross-site tracking, on the website or in the app, and we sell no data to anyone. The only cookie is the strictly necessary session cookie that keeps you signed in. We do run product analytics, in the workspace app and the desktop app: the next section says exactly what that captures.

The sandbox itself reports nothing to us. A sandbox you run on your own machine sends no usage pings, no active-day signals and no counts: nothing the platform sells is priced on anything a sandbox could report, which is why it can ask for nothing. Your code, your files and your prompts are never sent to us by a sandbox: what the analytics below sees is the workspace interface in your browser, and the next section is explicit about that.

We never receive your payment card details. Stripe collects them directly and we see only a customer reference, the subscription status and the billing period.

Product analytics

The workspace app at app.intentic.dev and the desktop app carry product analytics, run for us by PostHog. We use it to see how the product is used and where people get stuck; it is not used for advertising, not shared, and not sold.

In the browser workspace it records the pages you open, clicks and other interactions with the interface, a handful of milestone events our own code sends (a sandbox connected, a hosted sandbox created, an installer downloaded, a message sent), and a session replay: a reconstruction of the interface as you used it, built from what was on the screen, so in an open workspace that is the files, diffs and conversation you had in front of you. Everything you type into a field is masked out of that recording. Once you are signed in, these events carry your account identifier, email address and name, so what happened can be tied back to the account it happened in.

It keeps an identifier for the browser tab you are working in, in that tab's session storage rather than in a cookie: closing the tab ends it, and it does not identify you when you come back. Requests reach PostHog through app.intentic.dev's own address rather than PostHog's own, which is also why a content blocker does not stop them.

The desktop app reports far less, and by design: named events about installing, updating and setting up a sandbox, each carrying which step, the outcome, how long it took, the app version and the operating system, under an identifier that is random per installation. It sends no folder path, no sandbox name, no setup code, no credential and no line of the output on its screen.

Our legal basis is our legitimate interest in understanding and improving the product (Art. 6(1)(f)), and you can object to it: write to contact@intentic.dev and we will exclude your account and delete what has been recorded about you.

Sandboxes you run yourself

When your sandbox runs on your own machine or your own server, your code, files, credentials and everything your agent produces stay there. The platform stores the address and the token needed to reach it, and nothing of what is inside. Traffic between your browser and your sandbox passes through our tunnel provider to reach you, encrypted end to end.

The browser extension

The intentic browser extension lets a sandbox you have paired work in your own browser. It talks to that sandbox and to nothing else: there is no intentic server in the path, we receive nothing from it, and it contains no analytics, no telemetry and no third-party code.

It stores four things in your browser, and they never leave it except as described below: the address of the sandbox you paired and the token that reaches it, which of your sites you allowed it on and whether each is read-only, whether you have paused it, and a local log of the last 200 actions it took so you can see what it did.

• What it reads: the URL, title and content of pages on the sites you explicitly allow, one site at a time, granted in the extension and revocable in your browser's own settings. Depending on the page, that content can include names and other identifiers, messages, health or financial information, or location. It cannot see the URL or title of any tab on a site you did not allow. Allowed page content is sent to your sandbox, where your agent works on it, and onward to whichever AI model you configured under your agreement with that provider.
• What it records: a local rolling log of the last 200 actions the agent took, including the site element it acted on. Text typed into a page is represented by its length rather than its contents. The log stays in your browser and is shown in the popup.
• What it never reads: the contents of password fields, which it is written not to report back.
• Sign-ins you hand over: the extension can copy one site's session cookies to your own sandbox, so a job can continue after you close the browser. It happens only when you confirm it on the page, only while that switch is on, and the cookies go straight to your sandbox over an encrypted connection. We never receive them, and your agent is never shown them.
• How to stop it: pause it in the extension, revoke a site there or in your browser, revoke the whole pairing from the sandbox's card, or uninstall the extension. Uninstalling removes everything above from your browser.

Sandboxes we host for you

If you take the free hosted sandbox, we create a virtual machine and a disk for it at Fly.io and we pay for them. Everything you then put in that workspace: repositories, files, environment variables, credentials you choose to store there, and everything the agent writes, sits on that disk, which is infrastructure we arranged rather than infrastructure you own. This is the one part of the service where your working content is in our sphere, and it is why the Data Processing Agreement exists.

We do not read it, and the product gives us no way to: the command path runs from your browser to the sandbox's own daemon, and the platform holds power over the machine (create it, stop it, start it, destroy it) rather than a path into it. We will not build ourselves such a path to satisfy an abuse complaint, a complaint is answered by stopping or destroying the machine. The one thing that can show your workspace's content is the session replay described under Product analytics, and it records the interface in your own browser rather than anything on the machine.

Two honest limits on that. Fly.io, as the operator of the physical infrastructure, necessarily has the access any infrastructure provider has to the memory and disks of the machines it runs; our agreement with them restricts what they may do with it. And a sandbox reachable from the internet is reachable by whatever you expose from it: what you publish from your workspace is published by you.

Where a hosted sandbox lives

If you provision a hosted sandbox from the European Economic Area, the United Kingdom or Switzerland, the machine and its disk are created in the European Union (Stockholm) and your workspace content stays there. Everyone else's is created in the United States (Ashburn, Virginia). The region is decided when the machine is created, from the country of that request, and it is recorded on the machine; the country itself is not stored.

AI models and your prompts

With your own subscription or API key, your prompts, workspace files and command output go from your sandbox directly to your model provider (Anthropic, or whichever you configure) under your agreement with them. That traffic does not pass through the platform, and we neither see nor store it.

The free model trial is the exception, and it is worth understanding before you use it. It exists so you can chat before you own any AI subscription, and it works by serving your messages with our own Google Gemini keys, so for as long as you are on the trial, your prompts and the context sent with them pass through the platform on their way to Google. We do not store their content; we store only the daily count. Once you configure your own key, that stops. Do not put anything in a trial conversation that you would not want processed this way.

Who else processes your data

We use a small number of providers to run the service, listed with what each one does, where it processes data and under what safeguard, on our sub-processors page. We keep that page current and announce changes there before they take effect.

Your own model provider is not among them: you contract with them directly, and they process your data under your agreement, not ours.

Legal bases

Under the GDPR we rely on:

• Performance of our contract with you (Art. 6(1)(b)) for account data, sandbox records, hosted machines, hosted usage and the hosted plan.
• Our legitimate interest (Art. 6(1)(f)) in keeping accounts and infrastructure secure, for session and sign-in security data and for acting on abuse reports.
• Our legitimate interest (Art. 6(1)(f)) in understanding and improving the product, for the analytics above. You can object to that one, and the section says how.
• Compliance with a legal obligation (Art. 6(1)(c)) for tax and accounting records of payments.

International transfers

Some of our providers are established in the United States. Where personal data reaches them, transfers are covered by the EU–US Data Privacy Framework where the provider is certified, and otherwise by the European Commission's Standard Contractual Clauses under that provider's data processing agreement. The sub-processors page states which applies to each.

For hosted sandbox content specifically, the region rule above is what limits the transfer: European users' workspace content is not transferred out of the EU by us at all.

How long we keep things

A daily sweep enforces these windows automatically:

• Sessions and sign-in verifications: deleted when they expire.
• Unaccepted sandbox invitations: deleted after 90 days.
• Hosted usage records: 13 months.
• Analytics events and session replays: held by PostHog under the retention of our plan with them, and nowhere else. Ask and we delete yours before that.
• Account, sandbox and hosted plan records: until you delete your account.
• Payment records: as long as tax law requires us to keep them, currently five years from the end of the accounting year in Poland.
• A hosted sandbox's disk: destroyed with the machine, immediately, when you delete the sandbox or your account, and, for a machine whose owner is not on the hosted plan, when it has gone unopened for the period published in the app, which we warn you about by email first. Our infrastructure provider's automatic daily snapshots of that disk are not destroyed with it, they expire on their own retention schedule, currently five days, so erasure completes within that window rather than instantly. We hold no other copy.

Your rights

You can access, correct, export and erase your data at any time: Settings offers self-service export and account deletion, and deletion takes effect immediately. You also have the rights to restriction, objection and portability under the GDPR.

You can complain to the Polish supervisory authority (UODO, uodo.gov.pl) or to the authority where you live. For anything else, write to contact@intentic.dev and we will answer within 30 days.

Security incidents

If a breach affects your personal data, we will notify the supervisory authority within 72 hours where the GDPR requires it, and tell you directly and without undue delay where the breach is likely to result in a high risk to you.

Changes

We will update this policy as the service changes and move the effective date above. Material changes are announced in the app before they take effect, and re-accepted at sign-in.