Privacy policy

1. Scope

This policy describes personal information processing by the Kun website (www.kun-agent.com), the Kun unified account service (api-kun-server.com), and Kun sign-in features in web applications that integrate these services. The website provides product information, documentation, downloads, and release information; the unified account service provides email-code and Google sign-in, profiles, and application authorization.

Model requests, workspace files, plugins, and other third-party services in the Kun desktop application depend on the features and settings you use. The description of Google sign-in here does not mean that every desktop feature only processes sign-in information. Consult the relevant feature documentation and the privacy policies of your chosen providers.

The Kun mobile app and remote connections section below also covers account, connection, attachment and related local-data processing by the phone control app.

2. Information accessed through Google sign-in

When you choose Google sign-in, Google verifies your identity. Through Google’s basic identity permissions, Kun and its authentication provider Supabase receive your Google account identifier, name, email address and verification status, profile picture URL, and other basic profile information to create or recognize your Kun account.

The current sign-in flow requests basic identity, email, and profile permissions (openid, email, and profile). These permissions do not allow Kun to read your Gmail messages, Google Drive files, calendar, or contacts. Google handles your Google password; it is not submitted to Kun as sign-in form data.

2.1 Email verification code sign-in

When you choose email-code sign-in, the email address you provide is used to deliver a one-time code, verify mailbox ownership, and create or recognize your Kun account. Supabase Auth generates and verifies the code. A sign-in session is established only after successful verification; a business profile is created when the profile endpoint is first accessed.

Cloudflare Email Sending processes the recipient address, message content, and delivery results to deliver authentication codes. These messages are for account authentication, not marketing. A code expires after 10 minutes and cannot be reused after successful verification.

The sign-in page uses Cloudflare Turnstile to reduce automated abuse. Your browser may retain the pending email address and send time in tab-scoped session storage to restore the form and countdown; the code you enter is not written to that storage. Email-code and Google sign-in follow the account storage, data use, application authorization, and sign-out practices described in this policy.

2.2 Connecting Gmail in the desktop application

Connecting Gmail is a separate, optional authorization. Signing in to Kun with Google does not grant email access. Gmail access is established only after you choose Connect in a private Agent or Code conversation and approve Google authorization in your system browser. Group conversations and other conversations do not receive access automatically.

Kun requests gmail.readonly and gmail.send to search and read messages you ask it to process and send email after your approval. Data may include your email address, message identifiers, sender, recipients, subject, date, snippets, and plain-text bodies. This feature does not load remote email images or execute email HTML, and does not request permission to modify, delete, or archive messages. Before sending, Kun displays the complete recipients, subject, and body for you to approve.

Each private conversation starts without permission for model processing of Gmail data. The connection card explains the permission beside its Connect Google account or Use Gmail in this conversation action. Choosing that action explicitly permits the requested headers, addresses, snippets, plain-text bodies and related conversation context to be processed by the conversation's configured models for explanations, summaries and replies. Connecting Google from another conversation does not grant this permission. Kun has no model or provider allowlist; automatic routing, failover and gateways follow your configuration. Changing models requires no API-account review. The card's Manage menu can stop Gmail access for this conversation.

Email data may be sent to the model providers, local models or intermediary services that you configure. Processing locations, caching, retention and training practices depend on their agreements and account settings; Kun does not guarantee that every configuration excludes training or provides zero retention. Review your configured services and routes before use. Revoking conversation permission stops future model processing but cannot recall data already received by a provider. For example, the official DeepSeek API processes data in China and uses disk-based context caching by default; consult its privacy policy and Open Platform terms.

The local Kun runtime sends Gmail API requests and exchanges OAuth tokens directly with Google. Access and refresh tokens are encrypted in local credential storage, using the operating-system keychain when available; otherwise an encrypted local store accessible only to your operating-system user is used. Kunserve, Supabase, and Cloudflare account backends do not store Gmail bodies or tokens; paired-device remote viewing and network transport are described separately below. Kun does not maintain a separate complete mailbox cache.

Before accessing mail, Gmail checks encryption protection on the actual volume containing the app data directory. The current implementation verifies macOS FileVault and volume encryption, and denies mail access when protection cannot be verified. Email content, summaries, generated replies, and related app-managed records may remain in this protected data directory. This is operating-system volume encryption, not separate application encryption for each conversation. Email model requests are excluded from optional HTTP model-debug capture; other local chat or operational records may still contain email data. Protect any copies you manually export or back up elsewhere.

If you choose to enable paired-device remote access, an authenticated paired device can still view canonical chat history and live messages, including Gmail content, summaries, and replies. Data travels through your selected connection, such as a direct link or Cloudflare tunnel; a tunnel transport provider may process it to deliver that connection. This displays the conversation on your paired device; model processing still follows conversation permission and your configured routes. Gmail OAuth access and refresh tokens and local-model credentials are not provided to remote clients. IM bridges do not receive Gmail conversations. Manage remote access using the controls and documentation for your chosen connection and transport service.

Disconnecting Gmail deletes local connection credentials and all conversation Gmail grants, but does not automatically delete existing chats or debug records; use the app’s history and debug-data controls to delete them. To prevent old email records being sent to unapproved models, the app retains a local sensitive-data classification containing conversation identifiers only. You can separately revoke Google access; Google revocation may affect other Kun OAuth clients in the same project, including Google sign-in.

Kun uses Google user data only for Gmail features that you explicitly request, does not sell it, and does not use it for advertising or general-purpose model training. Kun’s use of information received from Google APIs, and transfers to other applications, adhere to the Google API Services User Data Policy, including its Limited Use requirements. Email you approve for sending is delivered to your recipients and email service providers in the usual mail-delivery process. Human access to Google user data requires your explicit consent or is limited to policy-permitted exceptions such as security investigations, legal obligations, or permitted internal operations.

2.3 Google API Limited Use and user-configured models

Kun'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. The use of raw or derived user data received from Workspace APIs will adhere to the Google User Data Policy, including the Limited Use requirements.

Kun does not use Google user data to develop, improve or train generalized AI/ML models, and does not sell it or transfer it for that purpose.

Kun runs on your computer and provides no AI model. Gmail data is requested only when you ask Kun to find, read or send an email, and is given to the model you have configured. We recommend a local model (for example through Ollama), in which case the data is processed on your device and not shared with us or any model provider. If you configure a remote model service, the requested email content is sent to that service under your own account and its terms; we recommend choosing a service whose terms exclude training on your data. The Gmail connection card shows which model will receive the data.

Gmail credentials are encrypted on your device and never given to models. You can disconnect and revoke Kun's access at any time. Sending an email always requires your explicit approval of the recipients, subject and full body.

2.4 Kun mobile app and remote connections

The Kun mobile app controls Kun on your computer. The computer runs tasks and retains conversations, execution records and long-term attachments as the source of truth. The phone can read, cache and send inputs within its authorization. Disconnecting the phone or moving it to the background does not automatically stop tasks already running on the computer.

On iOS, sign-in credentials are stored in Keychain. The phone separates cached history, cursors, drafts and unresolved requests by account and computer. The default history-cache limit is 100 MiB and the media-cache limit is 200 MiB, with cleanup based on recent use. Drafts and unresolved requests are retained separately from ordinary cache eviction. Signing out and removing an account on the phone clears its local credentials and cache; this does not automatically delete computer history or the server-side account.

Remote control uses an HTTPS/WSS relay hosted by Cloudflare. The relay checks identity, authorization and routing. It does not persist chat bodies or business frames or create a cloud conversation history. Supabase stores account identity and the metadata needed for devices, device grants, short-lived pairing and connection tickets, temporary transfers and authorization audits without conversation bodies. Network services still process technical information needed for the connection. Not keeping a cloud history copy does not mean that traffic avoids cloud services.

Attachments you choose to transfer temporarily pass through private Cloudflare R2 storage, with a limit of 25 MiB per file. Transfer access expires after one hour. Receipt confirmation or cancellation requests object deletion; scheduled cleanup and bucket lifecycle rules handle remaining objects. Access expiry and physical deletion are separate operations, so a file is not guaranteed to disappear at the exact instant of expiry, confirmation or cancellation. Long-term attachment references remain on the computer, and viewing a file again may require another temporary transfer.

The relay and attachment transport use TLS but do not yet provide end-to-end encryption. Transport services such as Cloudflare may process content to deliver the relay and temporary storage. This is not a connection that only your phone and computer can decrypt.

Before sending messages or attachments to the computer or continuing model execution, the mobile app asks for explicit data-transfer consent. Your computer passes messages, attachments and related conversation context to the model, provider or gateway you configure, such as OpenAI, Anthropic, DeepSeek, a custom service or a local model. Processing locations, retention and training practices depend on the actual configuration and service terms. Check the conversation model and desktop configuration. You can withdraw consent for that account and computer in Privacy and security. Withdrawal prevents subsequent transfers without consent, but cannot recall data already provided to a service or automatically stop tasks already started. This consent does not replace tool approvals or the separate Gmail conversation permission described above.

iOS voice input defaults to on-device recognition. If the device or language is unsupported, the app reports that limitation rather than silently switching online. Audio may be processed by Apple's speech service only when you explicitly enable Allow Apple online recognition for that recording. Recording uses memory buffers: Kun does not save raw recording files or upload raw audio to Kun cloud services. You can edit the transcript; confirming it or entering the background appends it to a local draft without automatically sending it to the computer or a model. Apple's own information applies to processing by the system speech service.

Signing out on the phone, revoking computer access, withdrawing AI data-transfer consent and deleting a Kun account are different operations. The new in-app self-service account-deletion entry has been deployed on the server but remains disabled pending verification with disposable test accounts. For now, use the contact email on this page to request access, correction or deletion of account information. These instructions will be updated for the functionality actually available at release.

The following describes the new account-deletion flow for enablement after the verification noted above. It deletes your Kun cloud account information, revokes device and sharing access and cleans up related temporary attachments. It does not remotely erase computer history, already-published messages, other people's local copies or someone else's shared task. Deleting a guest account revokes its membership; deleting an owner account closes its shared tasks.

For accounts using Sign in with Apple, deletion progress distinguishes not applicable, revoked, pending and manual action required. Normally, the server uses encrypted Apple credentials to request revocation. Temporary failures are retried within a fixed 24-hour window starting when email-code verification succeeds and deletion is durably accepted. Retries or late sign-ins do not extend this window. Deletion of the Kun account and your information continues rather than waiting indefinitely for Apple. Missing or undecryptable credentials, or the end of the window, result in manual action required, not a claim of successful revocation. After the window, encrypted tokens are no longer read for revocation and maintenance removes them; physical erasure is not guaranteed at the exact deadline.

After account deletion, related temporary-file cleanup and Apple revocation or manual-action handling have all reached a terminal state, the server retains the status proof for a further 24 hours so a signed-out device can check with its original status credential. Unresolved work is not marked complete merely because a proof-retention period elapsed. The phone may retain an unread Apple manual-action notice until you explicitly acknowledge reading it. Manual action means stopping Kun's authorization in Apple's Sign in with Apple settings, not signing out of or deleting your entire Apple Account.

To prevent continued access or repeated actions after deletion, minimal security audits, deletion fences and reconciliation records without conversation bodies may remain. This flow does not promise to erase every security log retained by a processor under applicable law or its published policy. Accepted sharing-management receipts belonging to other accounts may retain your opaque account or member identifier for the existing seven-day reconciliation period. The flow does not rewrite another person's idempotency proofs, shared content or business records. Publication provenance and operational audit records in the separate operator directory are also outside ordinary user-content deletion.

3. How information is used

Account information is used to sign you in, identify the current user, display your name, email, and avatar, and establish sessions in applications you authorize. Changes you make in the website’s personal center, such as your display name, are saved to your Kun profile.

When an independent application requests Kun sign-in, the consent page identifies the application and requested permissions. If you approve, the application receives the corresponding identity information and its own sign-in tokens. Applications using the Kun sign-in component manage sessions separately from the account center; signing out of an application does not also sign you out of the account center.

4. How information is stored

Supabase Auth manages account identities, authentication sessions, and authorization records. Kun’s Supabase database stores profile information such as an account ID, display name, avatar URL, and creation and update timestamps. The server reads and updates profiles using verified user identities.

Web applications using the Kun sign-in component, including versions of the official website with sign-in enabled, use browser sessionStorage for their application access token, refresh token, and sign-in validation state. The unified account center stores a separate session in browser storage on its own domain to maintain sign-in and refresh tokens. The website also uses localStorage for your language preference and sessionStorage to cache the public GitHub star count.

Clearing browser storage may sign you out or reset preferences, but does not automatically delete your server-side account, profile, or existing operational records.

5. Downloads, updates, and operational data

Cloudflare serves the website and account service. Hosting and authentication services process operational data such as IP addresses and browser request information when handling requests. Service logs support operations and troubleshooting.

The website also enables Cloudflare Web Analytics, which collects page views, referring sites, device and browser types, country, and page-load and performance metrics in the browser to understand visits and improve website performance.

When the website accesses the release-update endpoint, downloads an installer, or accesses the model-catalog endpoint, the existing analytics implementation writes an event date, hashes of the IP address and User-Agent, and Cloudflare-provided country, region, city, timezone, and data-center information to Supabase. Depending on the endpoint, records also include request paths, release versions or channels, installer names and formats, download ranges, response statuses, and error categories. Hashing does not make this information fully anonymous.

These records support download and update statistics and analysis of endpoint operation. The public statistics endpoint provides aggregate counts. To retrieve the GitHub star count or load avatars hosted by Google or other providers, your browser sends requests to those services, which receive normal network request information.

6. Information provided to services and applications

Google provides identity verification. Supabase provides authentication, application authorization, profile storage, and analytics storage. Cloudflare provides hosting and network services for the website, account endpoints, and downloads. These providers process information needed for their respective functions and have their own privacy policies.

Independent applications you authorize can receive the identity information requested for their sign-in features and approved by you. Whether an application deletes previously received information after you revoke access depends on its policy. Review the privacy information of third-party sites you visit through links on this website.

7. Your choices and account information

You can browse public product information and documentation without signing in. When using a web application with the Kun sign-in component, you can sign out of that application. You can also change your display name in the website’s personal center and revoke Kun’s access in your Google Account third-party connections settings. To revoke an authorized application’s access, contact us at the email address on this page.

Signing out or revoking authorization does not automatically delete stored account information. There is currently no automatic account-deletion function on this page. To request access, correction, or deletion, use the contact email provided on this page.

8. Changes to this policy

This page will be updated as sign-in and website features change, with a revised update date. Review the relevant information before using new account features or granting additional permissions.

Contact us

For privacy questions or requests to access, correct, or delete account information, contact the email address below. Do not include passwords, access tokens, or other secrets in your message.