Privacy Notice

1. Who we are and what this covers

Skyflo is operated by Operantix Systems Private Limited (CIN U62010PN2026PTC252795), a company incorporated in India with its registered office at Office No. 01, 1st Floor, Future One, S. No. 245/5/1, D.P. Road, Aundh, Pune, Maharashtra 411007, India (“Skyflo”, “we”, or “us”). Operantix is the controller of personal data used to operate Skyflo accounts, billing, security, support, and its own service records.

When you use managed inference or run a mission in Skyflo Cloud, we process the content of that work to provide the Services you asked for. That content can include personal data that belongs to someone else, such as an organisation’s customers or staff. The person or organisation that sends it decides whether to send it and remains responsible for having a lawful basis to do so. Where we process that personal data on behalf of an organisation, or of an individual using Skyflo for business, our Data Processing Addendum applies automatically as part of the Terms once the customer accepts a Terms version that incorporates it. Existing customers can accept the current Terms in the account console’s Privacy page; earlier Terms acceptances are preserved and do not change automatically. The DPA sets out our processor obligations, lists the subprocessors involved and the status of their terms, and names the providers it does not authorise and how to keep personal data away from them.

Managed content is processed by our model providers, OpenAI and Google. Z.ai, which the Managed content disclosure also names, receives no managed requests while it is disabled (section 5.4). Which provider processes a request depends on the model it is routed to; the Managed content disclosure names each provider and the models it serves. Fly.io runs the machines for Skyflo Cloud (section 9).

This policy covers the surfaces below. They behave differently, so the difference is stated throughout rather than averaged into one paragraph:

• skyflo.ai, the public website. No sign-in. Analytics and download attribution run here only if you accept them.
• app.skyflo.ai, the account console. Sign-in required. No analytics run here.
• Skyflo Desktop, the macOS application where agents actually run, unless you run a mission in Skyflo Cloud.
• Skyflo for iPhone and iPad, a companion app that follows missions running on your Mac or in Skyflo Cloud and runs none itself.
• Skyflo Cloud, where a mission you choose to run there runs on a machine Skyflo operates for that mission instead of on your Mac.

Your use of the Services is also governed by the Terms and Desktop Licence.

2. In short

3. What we collect

3.1 The website, skyflo.ai

• Your choice. Every visitor to skyflo.ai is shown one choice, Privacy choices, with Accept and Decline side by side. Until you accept, Google Analytics does not load and no attribution cookie is set or record kept; if you decline, that stays so. You can change your choice at any time from Privacy choices at the foot of any page (section 8).
• Website analytics. If you accept, skyflo.ai uses Google Analytics 4 to measure how the site is used. It sets cookies and collects a device identifier, your IP address, the pages you view, the referring page, your approximate location derived from IP, and browser and operating-system details. We use it with Google’s advertising features, Google signals and ad personalisation turned off. Google Analytics does not run on the account console.
• Download attribution. If you accept, we set a signed first-party cookie holding a random visitor identifier and where your visit came from: the campaign, source, medium or creator named in the link you arrived by, or “direct” when there was none, with the time, landing page and referring page. Later visits from a tagged link update the most recent touch. Query details unrelated to attribution are removed. From then on we record visits to the website and download pages and when an installer link is selected; your browser holds these records briefly in local storage until they are sent. If you later sign in, we link this record to your account. If you do not accept, none of this is set or recorded.
• Historical beta and waiting-list submissions. Before public Desktop distribution, you may have given us an email address through a beta access or waiting-list form. We stored that address, the page the submission came from, and, on the former high-intent form only, the use case and cloud provider selected. Those forms and their Skyflo API routes are no longer available. The historical rows will be deleted no later than 5 October 2026. You can ask us to delete yours sooner. Section 10 explains this deadline.
• Call bookings. Pages that offer a call with us load Calendly’s scheduler only when you choose to show available times. From then on Calendly receives your IP address and browser details. Whatever you enter into the scheduler, typically your name, email address, and any notes, is collected by Calendly and shared with us so we can hold the meeting.
• Server and delivery logs. Our hosting provider records request metadata such as IP address, user agent, requested path, and timestamp for operational and security purposes, whatever you choose in Privacy choices. A reduced copy is kept in our security-log archive in India for 180 days (sections 9 and 10).

3.2 The account console, app.skyflo.ai

Signing in is handled by Clerk, our authentication provider. You may sign in with Google, with GitHub, or with a one-time code sent to your email address. Skyflo does not offer password sign-in and therefore never holds a password for you.

Depending on the method you choose, Clerk receives and holds your account identifier at that provider, your name, your email address and whether the provider reports it as verified, and your profile picture URL. Section 6 covers Google specifically.

In our own account records we store:

• your Skyflo user identifier and email address;
• your organisation identifier, its name, and your role in it;
• one record per linked device, a Mac or an iPhone or iPad running Skyflo for iPhone and iPad: an identifier, the device name it reports, the platform, the app version, when it was linked and first activated, when it was revoked if it has been, and whether the device reported that its signing key is held in hardware;
• your plan and entitlement snapshot, and the managed capacity used and remaining in the current window;
• the documents you accepted, and the versions of the other published documents that governed a purchase, each recorded as its version, its SHA-256 digest, and the time;
• your managed-content choice and the settings derived from it;
• if you accepted download attribution on skyflo.ai, the immutable first acquisition touch and the most recent valid touch associated with your account, including source, medium, campaign, creator identifier, timestamps, landing URL, and referring page where available; and
• coarse product milestones such as account creation, Desktop first launch and activation, first mission creation, plan approval, first agent execution, an independent review report being attached, and paid conversion. These records contain identifiers and timestamps, not prompts, code, files, terminal output, or review contents.

3.3 Payments

Paid subscriptions are sold through Dodo Payments as merchant of record. Card numbers and other payment credentials are entered on Dodo’s hosted checkout and are never sent to or stored by Skyflo. We receive the subscription state we need to run your account: plan, billing interval, status, refund and dispute state, and provider reference identifiers. At checkout you choose a billing country, India or the United States; we keep it with your subscription because it determines the currency and taxes Dodo applies and which plans and plan changes are available to you.

3.4 Skyflo Desktop

Skyflo Desktop runs on your Mac and does the work there. Missions, plans, prompts, repository content, code, files, terminal output, and agent results are held on that machine. What leaves it depends on which of the three modes in section 4 a request runs under, on whether you have paired a phone (section 3.5), and on whether you run a mission in Skyflo Cloud (section 3.6).

When an account is connected, Desktop sends the account service coarse lifecycle milestones needed to understand whether the download journey worked. These include first launch, activation, first mission creation, plan approval, first agent execution, and an independent review report being attached. Each request carries only the event name, a random event identifier, and the time it occurred. It does not carry mission content or a mission identifier.

Crash diagnostics are off until you turn them on in Desktop. When they are on, crash and error reports go to Sentry with personal details and content removed, and you can turn them off at any time.

Optional product usage. Product usage is optional and off by default. Collection is also switched off on our side on the date of this version, and while it is off Skyflo receives no product usage, even from a Mac where sharing is on. When collection is on and you enable it in Desktop, Skyflo receives active days, mission starts and final outcomes, the app version and Mac architecture, random app/event identifiers, and a count of skipped events. It receives no account details, prompts, code, files, terminal output or browsing history. This choice is independent of crash diagnostics and works without sign-in. Live usage records are kept for up to 90 days, and unsent events expire after 30 days. Switching sharing off clears unsent events and requests deletion of received records. If your Mac is offline, deletion is retried when it can connect. A one-way deletion marker is kept indefinitely to prevent restored copies from resending; backup copies expire within 35 days. Network infrastructure processes addresses for delivery and abuse protection. Because these records are not linked to your account, turn sharing off on each Mac to remove them; account deletion cannot identify them. Local and BYOK work is unaffected by this choice or an analytics outage.

3.5 Skyflo for iPhone and iPad

Skyflo for iPhone and iPad follows the missions running on your Mac and in Skyflo Cloud. It runs nothing itself. You pair a phone from Desktop, and answers, guidance and approvals sent from the phone are signed on the phone and checked by your Mac before anything happens.

While a phone is paired, your Mac shares with the account service, and the account service holds for the phone, what the phone needs to show your missions: for every mission, its title, status, repository and branch, and which agents are working; for a mission you open on the phone or one that is waiting for you, its conversation as well: your instructions, the agents’ replies, the steps they took with short summaries of their results, and whatever question or approval is waiting. Each reply is capped, only the recent turns travel, and process output, terminal sessions, browser pages and images never do. With no phone paired, the Mac shares none of it.

When you pair a phone, it creates a signing key that stays on the device, in the Secure Enclave where the hardware has one, and sends us its model name (such as iPhone or iPad, not the name you gave it), the platform, the app version and the public half of that key. It is then listed with your other linked devices.

If you allow notifications, the phone registers an Apple push token and your notification preferences with the account service. When a mission needs you, we ask Apple’s push notification service to deliver a notification; depending on the detail level you choose on the phone, its text can include the mission title and what is waiting. The notification also carries mission, approval or question identifiers and links that open the relevant work. “Title only” removes mission text but retains those identifiers. Apple delivers notifications under its own terms, which prohibit sensitive personal or confidential information belonging to an individual in notification content. Organisations relying on our Data Processing Addendum must keep customer personal data out of Apple notifications. “Title only” removes mission text; if the remaining notification identifiers would disclose that data, turn off every notification category in Skyflo’s Notifications settings on each paired phone and confirm those settings reached Skyflo. Hiding notifications in iOS alone does not stop transmission to Apple. If the settings cannot be confirmed, unpair the phone before using the affected missions. Phone access still works with the notification categories turned off.

Answers, guidance, approvals and new missions you send from the phone are held by the account service until your Mac collects them. After your Mac has applied or refused a request, or it has expired unanswered, we keep it for 7 more days so that a request the phone sends again receives the same answer instead of acting twice, and then delete it. When you open a mission on the phone, the account service notes the time so your Mac knows to share that mission’s conversation; the time is kept with the mission’s copy. On the phone itself, missions you have opened are kept so they can be read offline, and unlinking the phone deletes them together with its key.

The copies held for a phone are deleted 30 days after they last changed and 7 days after a mission is archived. Unpairing a phone, whether from the phone’s own Settings, from your Mac or in the account console, deletes its push registration and anything still waiting for it; removing a Mac deletes what that Mac shared, and deleting your account deletes all of it.

3.6 Skyflo Cloud

Skyflo Cloud runs a mission on a machine Skyflo operates for that mission, instead of on your Mac. Nothing goes there unless you choose it for that mission, by starting the mission in Skyflo Cloud or by moving it there from your Mac, and a moved mission comes back when you bring it back. Skyflo Cloud is included with paid plans and is not part of the Free plan. Every model request a mission makes in Skyflo Cloud is a managed request, so it also needs your managed-content choice (section 4.3).

A mission you start in Skyflo Cloud begins from its repositories on GitHub, with the title and instruction you give it. When you move a mission from your Mac, your Mac sends Skyflo a checkpoint of it:

• The mission record: the mission’s whole record on your Mac, including its conversation and instructions, plans, the tool calls its agents made and their output, terminal output, questions and approvals, the files and images the mission stored, the memory it retrieved for that mission, and the label of the model sign-in it used (never the key or token itself). Instructions you gave by voice are part of this record like typed ones. The record travels whether or not you let the agent in Skyflo Cloud continue the conversation (section 4.4);
• Its repositories as they stand: for each repository, a Git bundle of the commit it is on, its staged changes, its uncommitted and untracked files, and every local commit your remote does not already have, so the mission continues where it was without a commit or a push. Where no copy on a remote can be found, the repository’s whole history is included. Other branches, stashes and Git hooks are not carried; and
• The move itself: the mission title, the names of its repositories and branch, and the instruction you give it, if any.

Some files are named in the checkpoint but not carried: files your repository ignores (such as dependency folders and build output), untracked files larger than 25 MB, and the contents of submodules. Untracked files are also screened by their names, and those that look like credentials, such as .env files, private keys, and SSH or cloud configuration, are named but not carried. That screen reads only the names of untracked files. It does not read what files contain, and it does not apply to anything else: files your repository tracks, whether committed or staged, the repository’s history, and the mission’s conversation and tool output all travel as they are, and any of them can contain a secret. Skyflo masks recognised secret patterns in mission history as it is recorded, but that masking does not catch every secret. The checkpoint is built only from the mission record and the repositories: it does not read your Keychain, the model keys or sign-ins you configured, your GitHub or SSH credentials, or your Mac’s environment variables. A checkpoint is compressed and sent over an encrypted connection, and is stored in our account database; we do not add a separate layer of encryption of our own to it.

While the mission runs in Skyflo Cloud, its record, its repositories and everything its agents read, write and produce are held on its machine. The machine publishes the mission’s status and conversation to the account service as it changes, so your Mac and a paired phone can show it and send it instructions, answers and approvals; the machine running the mission checks what you send before anything happens. This copy is of the same kind as the one in section 3.5, but it is kept for every mission in Skyflo Cloud, whether or not a phone is paired. When you bring the mission back, the machine sends your Mac a checkpoint of the same kind, including any memory the mission suggested there, for you to review.

Access inside the machine. A mission in Skyflo Cloud runs with Full access inside its machine, whatever access mode it had on your Mac: its agent runs commands and edits files there without asking you first. The machine is the boundary for that access (sections 4.4 and 11). When the mission comes back, your Mac returns it to the access mode it had when it left.

GitHub. A mission in Skyflo Cloud reaches your repositories only through the Skyflo GitHub App (section 3.7). It can fetch them, push its own branch, and open or update that branch’s pull request. Skyflo refuses any push to a repository’s default branch or to any other branch, any tag, and any deletion, and a mission there cannot merge a pull request. Skyflo also refuses any push from Skyflo Cloud that changes what GitHub Actions runs: files under .github/workflows or .github/actions, or an action.yml or action.yaml at the repository’s root. To make such a change, bring the mission back to your Mac and push it from there. Workflows your repository already has still run on the mission’s branch under your repository’s settings, as they would for a push by anyone with write access; you can exclude branches whose names start with skyflo/ from them. A mission you start in Skyflo Cloud commits its work to its own branch and pushes it after each turn; a mission you move there is not committed or pushed by Skyflo, and its work comes back to your Mac as uncommitted changes. For each run we keep the repositories it uses and its branch, and a record of each push and pull-request action: when it happened, the repository, the branches and commit identifiers involved, and whether it was allowed.

Runs and machine time. For each run we keep when it started and ended, its state, the machine it used, and the spending limit you set for the mission. While the machine is awake we measure how long, and the processor and memory it uses, to charge that time against your plan’s managed allowance, the mission’s spending limit and your organisation’s daily Skyflo Cloud limit. The charges appear in your usage as Skyflo Cloud machine time. Time a machine spends saving a stopped mission, and any time we wake it to retry that, is Skyflo’s own upkeep: we record it and do not charge it.

3.7 Connecting GitHub

On any plan, including Free, you can connect GitHub to Skyflo from your Mac by installing the Skyflo GitHub App on the GitHub account or organisation you choose, for all of its repositories or only those you select. The App asks GitHub for permission to read and write repository contents, pull requests and workflow files, and to read actions, checks, commit statuses and repository metadata. When you install it, GitHub also asks you to authorise Skyflo so we can confirm you have access to that installation; we use that authorisation for the check and do not store it.

Once GitHub is connected, Skyflo Desktop can clone, fetch and push your repositories for missions on your Mac through the connection. For each operation the account service asks GitHub for a short-lived token, valid for at most an hour and limited to one repository and to reading or writing its contents, and hands it to your linked Mac. The Skyflo service on your Mac holds that token in memory only, uses it for that repository, and never writes it to disk or passes it to the tools a mission runs. For a mission on your Mac, the code itself travels between your Mac and GitHub; the account service lists the repositories the connection covers when you pick one, but does not store that code. A mission in Skyflo Cloud uses the same App to fetch its repositories, push its own branch, and open or update that branch’s pull request, within the limits in section 3.6. A push from a mission on your Mac through the connection can change your GitHub Actions workflows, and GitHub can run them under your repository’s settings. A push from Skyflo Cloud cannot (section 3.6).

We keep the installation’s identifier, the GitHub account name and type it belongs to, whether it covers all or selected repositories, the permissions granted, who connected it, and whether it has been suspended or removed, and a record of each attempt to connect: who started it, when, and how it ended.

3.8 Messages between missions

An agent working on one mission can send a message to another mission. On your Mac, a mission can see and message only other missions in the same workspace, and a message never reaches a mission in another workspace. A mission can message a mission in Skyflo Cloud only while it runs with Full access on your Mac, and only a mission of your own account: a message never reaches another user or organisation. A mission in Skyflo Cloud cannot send messages. A mission cannot message one that has more access than it has.

Only the text of a message crosses, up to 8,000 characters, with the name of the mission that sent it. No files, results, tools or model choice travel with it. The receiving mission handles the message as its own next step: its own approvals and access mode, its own managed-content choice, and its own provider and model apply, and the model use it causes is charged to the receiving mission, as its own managed usage or its own Skyflo Cloud spending. A message to a mission in Skyflo Cloud is held by the account service like any other instruction sent to that mission (section 10).

4. Where your work goes: the three modes, and Skyflo Cloud

This is the part of Skyflo that is most often assumed rather than read, so it is stated as a table and then explained.

4.1 Local execution

The mission record, the repositories agents touch, the files they read and write, and the output they produce are held on your machine. Where a mission does not call a remote model, does not run in Skyflo Cloud, and no phone is paired, no mission content leaves your Mac because of Skyflo. A paired phone receives the copy described in section 3.5. The account console manages your account, not your work.

4.2 Bring your own key

When you supply your own API key for a model provider, Skyflo Desktop calls that provider directly from your Mac. Your key is stored in your operating system’s keychain on that machine and is not transmitted to Skyflo’s servers. The content of that request goes from your Mac to that provider under that provider’s terms, privacy policy, and data-retention settings. Skyflo is not in the path and does not see it.

These providers are deliberately not listed as our processors in section 9. The transmission is made by your machine at your instruction, using an account you hold, and the provider is your counterparty rather than ours.

4.3 Skyflo managed inference

Managed inference is the mode where Skyflo is in the path. It is off by default, it requires you to read the managed content disclosure and record an affirmative choice in the console, and it can be switched off again at any time. Section 5 sets out exactly what is transmitted and what we keep.

Switching it off takes effect on the next request. Anything already sent has already been sent, and section 10 covers how long it and its records persist.

This table describes the model-request path. Local tools, browsers and connected systems can also send content to services you authorise, separately from model processing. Their own terms and data practices apply.

4.4 Skyflo Cloud

Skyflo Cloud is not a fourth way to call a model. It is a different place for a mission to run, chosen one mission at a time. While a mission is there, Skyflo holds its content: its checkpoint in our account database, the mission itself on a machine Fly.io runs for us, and the copy that lets your Mac and phone follow it (section 3.6).

Each mission runs on its own machine, created for its run. Codex and Skyflo’s own agent can run there; other agents stay on your Mac. Every model request the mission makes there goes through our model gateway as a managed request (section 5), even if the mission used your own key or subscription on your Mac, because no model provider key, yours or ours, is placed on the machine. A mission that uses Codex sends its requests to OpenAI, and one that uses Skyflo’s own agent is routed like any other managed request.

When you move a mission, you choose whether its agent in Skyflo Cloud continues the conversation so far. That choice does not decide what is uploaded: the whole mission record, including the conversation, travels and is stored with the checkpoint either way (section 3.6). It decides only whether the agent reads it. If you let the agent continue, its earlier turns are sent to that agent’s model provider as continuation context; if not, the agent starts fresh from your next message.

The machine can reach only the account service, our model gateway, and public package registries (npm and Yarn, PyPI, crates.io, the Go module proxy, RubyGems, Maven Central and Gradle), so a mission can install its project’s dependencies and run its tests. Those registries receive the machine’s requests under their own terms. Everything else is refused, GitHub included: your repositories are reached only through the Skyflo GitHub App (section 3.7). You must not use a machine in Skyflo Cloud for anything the Terms forbid there, such as mining cryptocurrency or testing the security of other systems.

A mission stays on its machine until its run ends. While it is idle, its machine sleeps and keeps its disk; after 7 days without activity the mission is stopped and its work saved. Once a mission’s work has been saved in Skyflo Cloud or brought back to your Mac, or if its run ends before any work was done, we destroy the machine it ran on and that machine’s disk, and if destroying it does not succeed at first, we keep retrying automatically until it does. We do not destroy a machine that holds work we have not yet saved, with two exceptions: if you end a mission’s run yourself, or delete your account, its machine is destroyed at once, and work since it was last saved is not kept. Section 10 sets out what happens to each part of a mission’s data in each case.

5. Managed inference in detail

5.1 What is transmitted

When a managed request runs, the request your agent has assembled travels from your Mac, or from the machine running a mission in Skyflo Cloud, to Skyflo’s model gateway and is sent by us to our model provider. Depending on what the mission is doing, that request may contain:

• Your prompts and the agent’s instructions, including the system and harness instructions Skyflo supplies;
• Continuation context, which is the earlier turns of the same mission replayed in full: previous messages, the tool calls the model made, the results those tools returned, and the model’s own encrypted reasoning from earlier turns;
• Code and repository content that a tool read on your machine and returned into the conversation, including file contents, diffs, paths, and command output;
• File and tool context more generally, including terminal output, logs, and the output of connected systems, wherever a tool has placed it in the conversation;
• The schemas of the local tools the agent may call, so the model knows what is available; and
• The model’s generated response, which returns along the same path.
• Images or screenshots included in a managed request, which can contain personal or confidential information as well as visible text.

Skyflo masks recognised secrets in supported text fields, including prompts, instructions, tool context, and replayed messages, before token counting and managed transmission. It refuses unsupported or unsafe request forms. These controls do not detect every secret or personal detail, and do not inspect text inside images or decrypt prior model reasoning. Do not submit content you are not authorised to send. The pseudonymous identifiers described below do not anonymise the content of your request.

5.2 Counting and repeated transmission

Before a managed mission request is admitted, its content is sent through our gateway to the provider of the model being considered for input-token counting. OpenAI and Google count with their own endpoints. Z.ai is currently disabled for both inference and token counting. An admitted request sends the applicable content again to that provider for inference. Counting itself sends content even if inference is later refused. When routing considers models from more than one provider, more than one provider can receive the content for counting before one of them performs the inference. Refreshing a quote can require further counts, so two transmissions are not a maximum. Token-count traffic is paid by Skyflo and does not reduce customer managed allowance.

5.3 What we keep about a managed request

We keep the operational records listed below to authorise, meter, reconcile, secure, and evidence managed requests. Our managed path handles content transiently and does not persist prompts, code, file content, tool output, reasoning, or responses in our account database, operational logs, or diagnostics. This does not cover content you separately send to support. The retained metadata is associated with your account and is not anonymous. This describes the managed path only; a mission you run in Skyflo Cloud is held as section 3.6 describes.

• your organisation, user, and device identifiers;
• identifiers for the mission, thread, turn, routing decision, attempt, and reservation the request belonged to;
• which model reference and provider model ran it, and which price and policy revisions applied;
• Content digests used to compare the integrity of the request body, input, and tool schemas. These are not readable copies of content and should not be treated as proof of anonymisation.
• the size of the request in bytes, the token counts the provider reported for input, cached input, cache writes, output, and reasoning, and the number of bytes of output delivered;
• the capacity reserved and the cost settled, and the signed receipt digest that evidences it;
• the provider’s response and request identifiers, and the service tier it reported;
• timing and delivery state: when the request was reserved, claimed, dispatched, and resolved, whether it completed, failed, was cancelled, or ended indeterminate, and a short machine-readable reason where it did not complete;
• rate-limit figures the provider reported to us, which we use to decide what we can admit next;
• security and error information, such as refused authorisations and failed integrity checks; and
• the provider and model that processed each request, so that a rights request or billing question can be traced to the right processor.

5.4 Our model providers, and what we can and cannot tell you about them

The providers we currently engage and pay for managed inference are OpenAI and Google. Z.ai is disabled for managed requests and token counting; the records and provider statements about its earlier use remain below. Each managed model belongs to exactly one provider, the model picker names the provider beside each model, and a model you pin goes only to its provider; when you leave routing to Skyflo, successive requests in one mission can reach different providers. Voice Mode uses OpenAI only (section 5.6). In Skyflo Cloud, a mission that uses Codex reaches OpenAI only. Which models are offered can change, and a provider none of whose models is offered receives no managed request, including for token counting. The Managed content disclosure describes each provider's processing, the storage and retention statements each has published, pseudonymous routing identifiers, and the restrictions on provider-hosted tools and stored objects. Those details also apply to the managed processing described in this Notice. Please read that disclosure before enabling the feature; the console presents the precise version and records your affirmative choice.

Our choice to disable retrievable response storage at OpenAI, the stateless calls we make to Google, and Z.ai's statement that it does not store API content do not mean that a provider retains nothing; section 10 lists what each says it keeps. We do not claim Zero Data Retention, anonymous request content, physical isolation of each customer's cache, or a guarantee that content never leaves your country. How a new version of the managed content disclosure affects your managed-content choice is set out in that disclosure. Using any of these providers with your own key remains your separate provider relationship.

5.5 Mission titles

Mission titles are generated on your Mac. Enabling managed content does not enable a separate title-processing feature. A managed-title feature, if we offer one, will have its own control and applicable disclosure before it sends content.

5.6 Voice Mode

Voice Mode is managed processing with OpenAI. Your microphone audio goes from your Mac directly to OpenAI; Skyflo’s gateway opens each session but is not in the audio path, and Skyflo never receives or stores your audio. When a session opens, including when a call reconnects or changes voice, your Mac sends through Skyflo’s gateway to OpenAI a bounded record of the current mission’s conversation, one short line about what is open on screen, and up to 12 recent lines of the call’s transcript, each at most 1,000 characters, all masked for recognised secrets first. The gateway relays them without storing them. A spoken instruction that Skyflo acts on is saved to its mission like a typed one and is ordinary mission content from then on: it travels with the mission to Skyflo Cloud (section 3.6), and a spoken instruction to a mission already in Skyflo Cloud is held by the account service like any other instruction sent there (section 10). The Managed content disclosure describes Voice Mode in full.

6. Google user data

This section describes exactly what Skyflo does with data received from Google when you choose Sign in with Google. Google Sign-In is optional; GitHub and a one-time email code are the alternatives, and the account works identically either way.

6.1 What we access

Skyflo requests only the basic OpenID Connect scopes: openid, email, and profile. Through them we receive your Google account identifier, your email address and whether Google reports it as verified, your name, and your profile picture URL.

We do not request, and therefore cannot access, any Google API scope beyond those. Skyflo does not read, write, or store your Gmail messages, Google Drive files, Google Calendar events, Google Contacts, Google Photos, or any other Google service data.

6.2 How we use it

Google user data is used only to create and authenticate your Skyflo account, to identify you inside the account console, to address service and transactional email to you, to attribute your organisation membership and device approvals, and to detect and prevent abuse of the sign-in flow. It is not used for advertising, for profiling, or for building a marketing audience.

Skyflo does not use Google user data to develop, improve, or train generalised AI or machine-learning models. Google user data is not sent to our model providers: the identifiers we transmit in managed mode are keyed hashes, as described in section 5.4.

6.3 How we store it

Your Google identity record is held by Clerk, our authentication processor, in its systems. Our own account database stores your Skyflo user identifier and your email address, and links them to your organisation, devices, plan, and acceptances. We hold this for as long as your account exists, and then as described in section 10.

6.4 How we share it

We do not sell Google user data, and we do not transfer it to third parties for advertising or for any purpose unrelated to running Skyflo. It is disclosed only to the processors listed in section 9 that are necessary to operate the account, and only where the law requires disclosure or where you have directed us to share it.

Skyflo’s use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

6.5 How to withdraw it

You can disconnect Skyflo from your Google Account at any time at myaccount.google.com/permissions. Doing so stops future Google sign-ins; it does not by itself delete your Skyflo account. To have the account and its data deleted, write to contact (at) skyflo.ai as described in section 13.

6.6 A separate matter: Google Analytics

Google Analytics on the skyflo.ai website is unrelated to Google Sign-In. It measures website traffic, it runs only on the marketing host and only if you accept it, and it involves no access to your Google Account. See sections 3.1 and 8.

7. Why we process it, and on what basis

Under India’s Digital Personal Data Protection Act, we process account, billing, device, support and service data because you provided it to use Skyflo for the purposes described here, and we rely on your consent for managed inference, product usage, website analytics and download attribution. You can withdraw any consent in the same place you gave it: the account console for managed content, Desktop settings for product usage, and Privacy choices on skyflo.ai for analytics and attribution.

Where we rely on consent you can withdraw it at any time, and withdrawing it does not affect processing that already happened. Withdrawing the managed-content choice stops future managed requests; it does not recall requests already sent.

The managed-content control is an additional authorisation to transmit content. It is not consent on behalf of every person mentioned in a mission, nor a substitute for the lawful basis or international-transfer safeguards required for that data.

8. Cookies and similar technologies

• Strictly necessary. On app.skyflo.ai, Clerk sets session cookies. Without them you cannot stay signed in. Cloudflare Turnstile may also run during sign-in as a bot challenge.
• Your choice. Google Analytics and download attribution run on skyflo.ai only if you accept them. Choose Privacy choices at the foot of any page to change your mind. Declining or withdrawing stops both at once, deletes their cookies from your browser, and clears anything waiting to be sent. Records we received before you withdrew are kept only for the periods in section 10, and you can ask us to delete them.
• Remembering your choice. We store your choice in a first-party cookie for 12 months so we do not ask on every visit. It contains no identifier and is necessary for the choice to work.
• First-party download attribution. Only after you accept, a signed, HTTP-only cookie on skyflo.ai stores a random visitor identifier plus first-touch and last-touch acquisition details for up to 180 days. It is available across skyflo.ai and app.skyflo.ai so attribution can survive sign-in redirects. It does not contain an email address, account identifier, prompt, code, or file content. If you sign in, the server links the attribution record to your account. Your browser also holds attribution events in local storage for up to 7 days until they are sent.
• Account hint. When you sign in to app.skyflo.ai, the console sets a first-party cookie, readable across skyflo.ai and app.skyflo.ai, holding four facts: your plan tier, whether a Mac is linked, which plan an upgrade would move you to, and whether billing needs your attention. It contains no identifier, email address or content, is never used to authorise anything, lasts up to 30 days, and is removed when you sign out. The website uses it only to show you the right link, such as Dashboard instead of Log in.
• Analytics. Only after you accept, Google Analytics sets cookies on skyflo.ai that identify a returning browser and record which pages were viewed. The account console loads no analytics.
• Third-party embeds. The pages that offer a call with us load Calendly’s scheduler only when you choose to show available times. From then on Calendly may set its own cookies and receives your IP address, browser details and whatever you enter into the scheduler.

You can block or delete cookies in your browser settings. Deleting the first-party attribution cookie stops that browser from carrying the existing attribution into a later sign-in, but does not delete attribution already linked to an account. To opt out of Google Analytics across sites, install the Google Analytics Opt-out Browser Add-on. Blocking analytics cookies does not affect the account console or Skyflo Desktop.

9. Who we share it with

We use the following processors and service providers. Each receives only what it needs for its stated function.

Dodo Payments is listed separately because its role is different. It is the merchant of record for paid subscriptions, which means it sells the transaction in its own name and acts as an independent controller of the payment data you give it, rather than as our processor. It receives the payment details you enter with it and your billing contact data; it gives us the subscription state we need to run your account.

Model providers you configure yourself are also not in that table, for the reason given in section 4.2: that transmission is made by your machine at your instruction, and the provider is your counterparty rather than our processor. OpenAI, Google and Z.ai appear above only in their capacity as providers we engage and pay for managed inference.

GitHub appears in that table only for running our backup job. You install the Skyflo GitHub App on your own GitHub account or organisation and choose its repositories, and GitHub holds those repositories under your own agreement with it. Your Mac, and a mission in Skyflo Cloud, fetch from and push to them through the App at your instruction, as section 3.7 describes, and GitHub processes that activity under its own terms.

We may also disclose personal data where the law requires it, to establish or defend legal claims, or as part of a merger, acquisition, or sale of assets, in which case we will tell you before your data becomes subject to a different policy.

We do not sell personal data, and we do not share it for cross-context behavioural advertising.

10. How long we keep it

This section is the one statement of how long Skyflo keeps each kind of record, and the Terms and the Managed content disclosure refer to it. Your Mac keeps its own local mission history, which is yours to delete. Deleting your account does not erase a copy that a backup or a provider still holds, for the periods stated below.

10.1 Records Skyflo keeps

10.2 A mission in Skyflo Cloud, event by event

One rule runs through this table: we destroy a mission’s machine and its disk only once the mission’s work is saved, or if its run ended before any work was done, and if a destroy does not succeed at first we keep retrying until it does. The exceptions are a run you end yourself and deleting your account.

10.3 What our providers keep

These are the providers’ own published positions, which we do not control. Turning managed content off or deleting your Skyflo account does not erase a copy a provider keeps under them. We handle valid rights requests and seek the provider’s assistance where it is required.

• OpenAI keeps abuse-monitoring logs of API requests, which can include content, for up to 30 days by default, and longer where the law requires it or to protect its services or others from harm. Its prompt cache is kept for at most 24 hours, and flagged images may be kept for review.
• Google logs prompts and responses to the paid Gemini API for 55 days, solely to detect and prevent policy violations, keep its services secure, and make disclosures the law requires, and can cache repeated content briefly.
• Z.ai states that it does not store API content. It can cache part of a recent request to serve a repeated one, and does not state for how long.
• Fly.io must delete our data once we stop using its services, within the period its data processing agreement sets, which is no more than 90 days. It does not state how long it keeps data from a machine after we destroy it while we still use its services.

The Managed content disclosure describes each model provider’s processing in full.

11. Security

Both hosts are served over HTTPS with HSTS and a per-host Content-Security-Policy, so the marketing surface and the authenticated console are not treated as one trust boundary. The account API is called from our servers using your verified session; the browser does not hold an account-API credential. The console is excluded from search indexing.

Because password sign-in is not offered, there is no Skyflo password to leak. Where your Mac, iPhone or iPad supports it, the key that identifies the device is generated in the Secure Enclave; the console shows you which of your devices reported a hardware-backed key, and you can revoke any device at any time.

For managed inference specifically: the credential that pays our model provider exists only in the gateway service and nowhere else, every managed request is individually authorised and bound to the device that asked for it, and our logs and error reports are written to exclude prompts, code, tool output, shell output, environment values, credentials, and provider payloads.

For Skyflo Cloud: each run gets its own virtual machine, created for that run and destroyed when the run ends (section 10.2), and the virtual machine is the boundary between one mission and every other customer’s missions. All of these machines run under one Skyflo account at Fly.io. Inside the machine the mission runs with Full access (section 3.6), so any program it runs, including a dependency’s install script, can read what the machine holds and use the machine’s own access. That access is deliberately narrow. The machine holds no account-wide model provider key, no GitHub App private key and no GitHub token, no credential that can manage Fly.io machines, and no database credential. It holds only credentials for its own run: a device key that identifies it as that mission’s runner, a device token that lasts 10 minutes, and model-gateway grants that last at most 15 minutes and are bound to that runner, run, mission and handover. They stop working when the mission moves on. With them, code in the machine can make managed model requests and Git requests for that one run, charged to that mission and within its spending limit. Its network access is limited to the destinations in section 4.4. Git goes through a Skyflo service outside the machine, which uses a GitHub token limited to one repository and one kind of operation at a time, and allows pushes only to the mission’s own branch, never a push that changes the repository’s GitHub Actions workflows or actions (section 3.6).

The contents of a mission’s checkpoints are available only to the person the mission belongs to, through their own linked devices and the Skyflo Cloud machines running that mission for them; other members of the same organisation cannot read them. Within Skyflo, access to the account database that holds them is limited to the people who operate the service, for operating, securing and supporting it.

What a mission holds can itself contain secrets: files your repository tracks, its history, and its conversation and tool output travel with it and are held on its machine and in its checkpoint (section 3.6). Skyflo Cloud protects the machine’s own access; it does not make a secret you committed safe to move.

On your Mac, a GitHub token from the Skyflo GitHub App is held in memory only, for one repository, for at most an hour.

No system is perfectly secure, and no control here is a guarantee. If a breach affects your personal data we will notify you and the relevant authority where the law requires it. Not every provider has committed to tell us of a breach in its own systems; the Managed content disclosure says which.

12. International transfers

Operantix is established in India. Its security-log archive is stored in Mumbai, India (section 9). Its account service, including the copies held for a paired phone and the checkpoints and records of Skyflo Cloud, and its managed gateway are hosted in the United States. Fly.io runs the machines for Skyflo Cloud; we do not choose a region for them, so a mission there can run in any country where Fly.io operates. OpenAI and its service providers may process data in other countries; Google may store or cache data transiently in any country in which it or its agents maintain facilities; Z.ai generally processes in Singapore. Neither managed processing nor Skyflo Cloud has an India-only or customer-selected regional guarantee.

For a transfer subject to UK, EEA, or other transfer restrictions, the appropriate safeguards must be in place before the affected data is transferred. Where applicable, these include the EU Standard Contractual Clauses and the UK Addendum, or another permitted mechanism, covering the relevant transfer and onward processing. For personal data we process on an organisation’s behalf, our Data Processing Addendum incorporates the EU Standard Contractual Clauses, the UK Addendum and the Swiss adjustments. You may request information and a copy of the applicable safeguards from contact@skyflo.ai, with confidential details protected where appropriate. Enabling managed content is not a waiver of transfer protections.

13. Your rights and choices

Subject to the law that applies to you, including the UK and EU GDPR, India’s Digital Personal Data Protection Act 2023, and the California Consumer Privacy Act, you may ask us to:

• confirm what personal data we hold about you and give you a copy;
• correct data that is wrong or incomplete;
• delete your account and the data attached to it, subject to the bounded retention periods in section 10;
• export your data in a portable form, including the copies held for a paired phone;
• restrict or object to a particular use, including any use we base on legitimate interests;
• withdraw a consent you previously gave, such as the managed-content choice, website analytics and attribution (through Privacy choices on skyflo.ai), or a historical beta or waiting-list signup.

We do not hold a stored conversation from the managed transmission path to export or erase. We can address the operational records we retain, tell you which provider processed a given request, and will coordinate required assistance from that provider for a valid rights request. We will explain what action was taken, any lawful retention exception, and any applicable review or complaint route.

An export of your data includes what Skyflo keeps for Skyflo Cloud and GitHub: each mission’s placement and runs, with their title and first instruction; machine-time measurements and charges; the GitHub connections you made and the repository writes your missions made; and a record of every checkpoint. It lists checkpoint contents by size and digest rather than including them. Bringing a mission back from Skyflo Cloud returns its complete record to your Mac.

Write to contact (at) skyflo.ai from the email address on your account. We confirm your identity before acting on an access or deletion request, because an unverified deletion is somebody else’s account being destroyed. We answer within the period the applicable law sets, and within 30 days where no period is set.

If Indian law applies to you, you may also nominate another person to exercise these rights if you die or become unable to act; write to us with their name and contact details.

If you are in the United Kingdom or the European Economic Area you may also complain to your local supervisory authority. In India, you may contact our Grievance Officer, and if you are not satisfied with our answer, you may complain to the Data Protection Board of India through its online complaint process once the relevant provisions are in force, and use the other statutory complaint and appeal routes available under the law then in force. References to the Digital Personal Data Protection Act do not represent that every provision or Board remedy has commenced.

14. Children

Skyflo is not directed at children, and is not offered to anyone under 18. You must be at least 18 years old, or the age of legal majority where you live if that is higher, to use the Services. We do not knowingly collect personal data from children, and we will delete it if we learn we have.

15. Changes to this policy

We will not edit this published version in place. If we change this policy we will publish a new version at a new dated URL, and skyflo.ai/legal/privacy will serve that newer version from the moment it goes live. Where a change materially affects how we handle data you have already given us, we will give notice and, where the law requires it, ask for consent.

This Privacy Notice is not something you accept; it describes how we handle personal data. How a new version of the Managed content disclosure affects your managed-content choice is set out in section 1 of that disclosure.

16. Contact

Privacy questions, rights requests, and complaints go to contact (at) skyflo.ai, or by post to the registered office below. Please include enough information for us to identify your account and respond.

Operantix Systems Private Limited
Office No. 01, 1st Floor, Future One,
S. No. 245/5/1, D.P. Road, Aundh,
Pune, Maharashtra 411007, India
CIN: U62010PN2026PTC252795

Grievance Officer. Karan Jagtiani is our Grievance Officer and privacy contact, reachable at contact (at) skyflo.ai or by post at the address above. If you are not satisfied with how we have handled your personal data, write to him directly. We acknowledge consumer complaints within 48 hours and redress them within one calendar month. Privacy rights requests are handled within the period required by applicable law, with any permitted extension explained.

Customer care and grievance telephone: +91 7020882073