SchemAgentic

Privacy Policy

How we collect, use, share and protect your information across the app, the cloud, agents and services.

Last updated: 12 November 2026  ·  Effective: 8 October 2026

This Privacy Policy explains how CryptoBees LLC (“CryptoBees”, “we”, “us”, “our”) collects, uses, discloses and protects information in connection with the SchemAgentic application (the “App”) on all platforms it runs on (Windows, macOS, Linux, iOS, Android and the web), our related websites, our cloud and account backend, and the agent, service and AI features (together, the “Services”). By using the Services you agree to the practices described here and in our Terms & Conditions.

The short version

Contents

  1. Who we are
  2. Information we collect
  3. How we use information
  4. AI features & Anthropic
  5. Agents & what they record
  6. Service credentials & connected accounts
  7. Incoming addresses
  8. Cloud storage & collaboration
  9. MCP server & connected agents
  10. Third-party services we use
  11. How we share information
  12. Cookies & analytics
  13. Data retention
  14. Your rights & choices
  15. International transfers
  16. Security
  17. Children’s privacy
  18. Do Not Track
  19. Data-breach notification
  20. Changes to this policy
  21. Contacting us

1. Who we are

The Services are provided by CryptoBees LLC. For all privacy questions, requests and notices, contact us at cryptobees@gmail.com. For the purposes of the EU/UK GDPR, CryptoBees LLC is the “controller” of the personal data described in this policy, except where we act as a processor of the content you create (your schemas).

2. Information we collect

What we collect depends on how you use the Services. If you never create an account, we collect no account or content data at all — your schemas are files on your device.

a. Account & identity information

If you create an account or sign in, our authentication provider (Google Firebase Authentication) records the identifiers associated with your sign-in method. We support email/password sign-in and federated sign-in with Google, Apple and Microsoft. Depending on the method, this includes: your email address, display name, profile photo URL (if your provider supplies one), the provider’s user identifier, a unique SchemAgentic user ID, and whether your email is verified. We do not receive your password when you use a federated provider.

b. Purchase & subscription information

When you buy a Pro subscription, the purchase is processed by the relevant app store or reseller (see §10). We store the entitlement result linked to your account — which plan you are entitled to, the product (SKU) purchased, a purchase/transaction token used to verify and re-validate the purchase, verification timestamps, and, for web/desktop purchases, a Paddle customer identifier. We do not store your full card number or bank details; those are handled by the payment processor.

c. Content you create

Your schemas, nodes, node text, images and files you attach, and other content you author are “Content”. Content lives on your device by default. If you move a schema to the cloud, its nodes, connections and a snapshot file are stored in our cloud (see §8). You retain ownership of your Content.

d. Agent, service and AI usage data

If you use AI, agents or services, we record per-account usage metering: AI unit totals, compute time, service-call counts and storage bytes, per month, against your account and against each schema, together with your email for account support and abuse prevention. We do not store the text of your prompts or the AI’s responses on our AI-gateway servers — those are streamed to the provider and only counted. Agent runs are an exception and are stored in your schema; see §5.

e. Service configuration & credentials

For each service you connect we store its configuration — a name, which node it belongs to, which operations it may call, spending limits, and whether it is in test or live mode. The credential itself is stored separately and is never readable through the app; see §6.

f. Device, diagnostic & usage data

g. Communications

If you email us for support or opt in to product news, we keep your email address and the content of your message so we can respond and, if applicable, send updates you asked for.

3. How we use information

Where required by law, our legal bases for processing are: performance of our contract with you (providing the Services), your consent (e.g. optional analytics, product emails, and using AI, agents and services), our legitimate interests (security, abuse prevention, aggregate product analytics), and compliance with legal obligations (including trade-sanctions compliance).

4. AI features & Anthropic

SchemAgentic’s AI features — agents, AI-drafted service definitions and AI chat — are powered by Anthropic’s Claude models. AI requests are routed through our secure cloud gateway to Anthropic; the App does not call Anthropic directly.

What is sent to Anthropic

Credentials are never sent. An API key or token belonging to a service is used only in the outgoing request to that service, and is removed from anything that comes back before the result reaches the model.

What we retain

Our gateway does not persist the content of prompts or responses. We retain the usage counts described in §2(d), and operational logs containing metadata but not content. What an agent concluded, however, is written into your schema by design — see §5.

How Anthropic handles your data

Anthropic processes the content you send to generate a response. We access Anthropic’s API under commercial terms under which inputs and outputs are not used to train Anthropic’s models. Anthropic may retain data for a limited period for safety and abuse-prevention purposes in accordance with its own policies. Please review Anthropic’s Privacy Policy. You are responsible for the content you choose to submit; avoid sending sensitive personal information you would not want processed by a third-party AI service.

Regional availability

Because our AI provider does not serve certain sanctioned jurisdictions, AI features are unavailable in a small number of countries. To enforce this we determine the country of a request from network/geo signals or, as a fallback, your device’s locale (and, transiently, your IP address as described in §2(f)). If your location is restricted, the request is declined; the canvas continues to work.

5. Agents & what they record

An agent runs on our servers, on a schedule or when asked. For each agent we store what you configured — its name, instructions, settings, schedule, what it is allowed to reach, and its budget — and, for each run, a record of what it did: when it started and ended, why it ran, each step it took (including which service operations it called and whether they succeeded), what it concluded, and what the run cost.

These records live in your schema and are readable by everyone the schema is shared with. Unlike ordinary AI chat, they persist until the schema is taken out of the cloud (see §8) or its owner deletes their account. Deleting an agent stops it, but its run records stay with the schema until then. Values delivered between nodes are also stored on the receiving node, and a record of each delivery, with the value it carried, is kept with the schema (see §13).

When an agent asks a person to approve something, the question and what it says are stored with the schema, along with who answered and when.

6. Service credentials & connected accounts

A service needs a credential to reach the API it connects to. How we handle one:

Connected accounts. Where a service signs in through the provider instead (OAuth), the access and refresh tokens are stored the same way, and are used only while whoever signed in can still edit the schema. We receive only the permissions the provider showed you when you approved the sign-in. Signing the service out, or deleting it, destroys the tokens we hold; you can also withdraw access at the provider.

7. Incoming addresses

You can give a service an address that the outside world can post to. If you do: we store the address identifier and, where you have signature checking on, a signing secret (shown to you once, then stored the same way as any other credential). What arrives is delivered to the node and may start its agents, and a short record of each delivery — its time, its size and its event type, not its full contents — is kept so you can see what has been arriving. Who you give the address to is your decision, and what they send is their data reaching your schema.

8. Cloud storage & collaboration

Cloud storage is part of the paid plan. When a schema is in the cloud, its nodes and connections are held in Google Firestore and a snapshot file in Google Firebase Storage, readable and writable only by the people it is shared with, according to the role each has.

If a subscription ends, the schema is disconnected, not deleted: it stays exactly where it is, everyone who had access can still read it, agents and services stop, and nothing new is written until the owner subscribes again.

Anyone you share a schema with can read its content, its agents' run records and its service configuration — though never a credential. Choose who you share with accordingly.

The people a schema is shared with (members) also see each member’s email address, the name on their account and their role; who changed each part last, as their apps record it; who has the schema open now, when each member was last there and last edited it, and where in the schema they are; the schema’s conversation, with each message’s author and time; and, on plans with Version History, its saved versions with who saved each one and a summary of the changes — versions can show content that people later deleted. A conversation stays until the owner clears it or stops sharing, including the messages of people who left the schema or deleted their account; saved versions follow Version History’s limits (at most 25 recent and 25 major versions; a version kept before a restore is a significant one, which up-to-date apps normally keep for 30 days for the last five restores, within Version History’s storage budget; older app versions may thin it like any other significant version), and count against the owner’s storage, whoever’s app saves them. Versions saved while Sync my maps to the MCP server is on also hold the copy of the schema our server keeps for agents, so that agents can read that version; they are deleted with the version.

Every schema in the cloud is listed in the app's Shared tab: under Shared With Others for its owner, even before it is shared with anyone, and under Shared With Me for the people it is shared with. Its owner takes it out of the cloud there, with Stop sharing this: everyone it was shared with loses access at once, and everything the schema kept in our cloud is deleted — its snapshot, its nodes and connections, its agents with their run records and approvals, its services with their stored credentials and tokens, and its incoming addresses with their signing secrets. Copies already on people's devices stay there. (§13 says what a write under way at that very moment can rarely leave behind.)

9. MCP server & connected agents

The optional MCP server lets you connect external AI agents and clients using personal access tokens, or by signing in with your SchemAgentic account. Sync is opt-in; access tokens are shown once and never stored: we keep only a SHA-256 hash of each and its first 12 characters (so you can tell your tokens apart), with your user ID, email, a label, whether the token may only read your maps, and when it was created and last used. You can make a token that can only read, and revoke any token instantly; a revoked token is deleted from our servers at once. A token only ever reaches the content of the account that created it. Any external agent or client you connect operates under its own provider’s privacy terms.

Connecting by signing in. Once we switch it on, some agents (such as claude.ai, Claude Desktop’s connectors, ChatGPT and Claude Code) connect by sending you to SchemAgentic’s own sign-in page on schemagentic.web.app, where you sign in and choose whether to allow them. If you allow one, we keep a record of that connection: your user ID and email, the app’s name and web address (for example claude.ai, or “an app on this computer”), the access you gave it (read only, or read and change), and when it was connected, last used and last renewed. The tokens the app receives, and the one-time code it exchanges for them, are stored only as SHA-256 hashes. The app never sees your password, and a connected app reaches only the account that allowed it. A connection ends by itself after 30 days without use, or 180 days after you allowed it.

Activity record. Once signing in is switched on, for each request a token or a connected app makes to one of the server’s tools, we record the time, which tool, which token or connected app (its label or name, and the first characters of its identifier), and whether it was done, failed or refused; and when an app was connected or disconnected, and why (for example because you disconnected it or changed your password). We never record what was asked or answered, your map content or map identifiers. Each entry is deleted after 90 days. Only you can see your record, on Manage Account.

Disconnecting. You can see every connected app and token, and disconnect or revoke them, on Manage Account at any time, with or without a subscription, and, from the next SchemAgentic update, in the App’s MCP Server dialog. Disconnecting an app deletes its connection and tokens from our servers at once and stops it; changing your password or signing out of all devices disconnects every app within an hour. What an app already received is handled by its provider under its own terms.

While MCP sync is on, the App publishes a copy of each map you save to our server for the agents you connect (from the next SchemAgentic update, also each map you open): a text outline of its node titles and notes, each cut to 160 characters. From the next SchemAgentic update, the App also publishes a fuller copy of each map it publishes, so agents can read it in more detail: node titles up to 1,000 characters and notes up to 4,000; each node’s colours, shape, bold and italic, and whether it is collapsed; check boxes with their labels and whether they are ticked, the text of other content items, and the size of tables; cross-links with their labels; the map’s theme, scene and background colour; and the web addresses of links, images, video and audio in your nodes, only when they start with http:// or https://. Neither copy ever holds a file path on your device, your attachments, images or files themselves (the small picture of a map described below shows them at low resolution), or a schema’s agents, services, credentials or connections. The update also gives each node a hidden identifier, saved in the map file, so agents can find the same node again. From that update, encrypted maps and maps you keep away from agents (Visible to MCP Agents off) publish neither copy, and whatever removes a map’s outline from our server (for example, in the updated App, turning MCP sync off and choosing Remove, or hiding the map; or deleting your account) removes its fuller copy with it.

What an agent adds through the MCP server (text, web addresses, places, table and chart data) waits in your request queue on our server until your App applies it, and is deleted at your app’s first sync 30 or more days after it finishes. Once applied it is part of your map. When your map shows it, your device fetches it from where it lives: pictures are downloaded, link previews load, videos play from YouTube or Vimeo, and addresses are looked up with OpenStreetMap Nominatim. Those sites see your device's network address. Our MCP server never fetches them.

From the next SchemAgentic update, while MCP sync is on and you are signed in, the App keeps a connection to our server (Google Firebase) to learn that an agent queued a request, so it can apply it to a map you have open or build a new map without a restart; the notice holds only which map has new requests and when, never their content, and is deleted with your account.

Requests that wait for your approval, and messages. From the next SchemAgentic update, once we switch it on, an agent can ask to delete or replace something in a map (for example a branch, a link, a note’s text or the text of a check box), or to take back what one of its earlier requests added, and it can leave you a short message. No node, cross-link, content item, label or line animation is deleted, and no note or item text is replaced, until you approve the request in the App. Such a request waits on our servers until you approve or reject it, or for 14 days if you do neither: it holds the map’s title, what the agent proposes to delete or replace (with the titles of those nodes and of their parent nodes), any replacement text, the agent’s stated reason and the name of the token or connected app that sent it. A message holds its text and title and, if it names them, the map and node it is about; it waits until you read it, or for 30 days. Your answer, the reason you give when you reject a request (if any; the agent can read it) and, when you undo or redo an agent’s change in the App, a mark that it was undone (so the agent knows) are kept with the request. Every request and message is deleted at the first sync of your SchemAgentic app 30 or more days after it ends (approved, rejected, read, withdrawn or lapsed), and always when you delete your account.

Where your files are, and which maps are open. From the next SchemAgentic update, once we switch it on, while Sync my maps to the MCP server is on, the copy of each map our server keeps for AI agents also says where its file is: the drive (This Device, SchemAgentic Cloud or iCloud), the folder path inside that drive and the file name — never the full path on your device; for maps on This Device, also a code that identifies the device (not its name). Agents you connect use it to find, rename, move, copy and organise your maps, and the results of those requests say where the file went. A map’s place is deleted with its copy: when you delete, hide or encrypt the map, turn MCP sync off and remove the copies, or delete your account; the place a finished request reports is deleted with that request (see below), or sooner when you hide the map or remove the copies. While a map is open in the App, the App tells our server so (the map’s id, that device code and a time), so that agents’ file requests wait until you close it: this is deleted when you close the map, or when the App starts again after it was stopped; otherwise it lapses after 2 hours (8 days while the map has unsaved changes) and is deleted within about a day after that. Requests to create, rename, move, copy or recover files and folders, and text an agent asks to turn into a map, wait on our server until your App does them (at most 7 days, 30 for new maps) and are deleted 30 days after they end (it can take up to a day longer), and always when you delete your account. None of this is sent to or stored on our server before we switch it on.

Moving maps to the trash. From the next SchemAgentic update, once we switch it on, an agent can ask you to move a map to the trash. Nothing happens until you approve it in the App, and a map whose agents or services are not all turned off cannot be trashed this way (the App never stops them for it); then the App moves the map’s file to the trash of the device you approved it on, where it can be recovered for 90 days, only on that device. When you approve, we keep the map’s title, that device code and, while file places are shared, where the map was, so that the agent can ask to recover it; that record is deleted 90 days after the map was trashed (it can take up to a day longer), when the map is recovered, when you hide it or remove your copies, or when you delete your account. No agent request deletes a file or a folder for good, and none writes over a file that is there.

Schemas shared with you and version history. From the next SchemAgentic update, once we switch it on, if a member of a shared schema connects an AI agent to SchemAgentic, the agent can read, on that member’s behalf, what that member can see of the schema, once that member’s app has published it for agents (Sync my maps to the MCP server on) — with less about people: the display names and roles of the people in it (never their email addresses; a name that looks like an email address is not shown); whether each has it open now and the days they were last there and last edited it (not where in the schema they are, nor their device); the conversation’s messages, without the words of people who are no longer in the schema; which parts changed recently and who changed each last, as their apps recorded it, with approximate times; and the schema’s saved versions — when each was saved and who saved it, as their apps recorded it — with their summaries and, for versions saved while sync was on, their content, including content people later deleted; and who saved the schema last and when. The run records, services, approvals and ports of its agents are never read by these tools. Members cannot keep themselves out of what co-members’ agents see; the schema’s owner can keep the whole schema away from every member’s agent: turning off Visible to MCP Agents for a schema you share (in the schema’s menu or its Share panel of the desktop and mobile apps — not yet the web app — whether or not your own maps sync to the MCP server) deletes the copies members’ apps published for agents and stops new ones — it does not reach copies members saved as their own files. A schema you hid from your own agents before this change is from then on hidden from your members’ agents too. When someone leaves a schema or deletes their account, agents no longer name them: they show as a former member, without the words of their messages, or as another person. What an agent reads goes to the AI service its user chose, under that service’s terms; we keep no copy of it beyond the activity record above (which tools ran and when, never what they read). An agent can also ask you to restore an earlier version of a schema; nothing changes until you approve it in the App, and the App first keeps the schema as it was as a version (a schema whose agents or services can run is refused).

Rich content, pictures and exports. From the next SchemAgentic update, once we switch it on, the copy of each map our server keeps for AI agents (see above) can also hold, for the maps you sync, the contents of tables (titles, headers and cells), lists (titles and items), the type and title of charts, the titles and times of calendar cards, which of your maps a map links to, and the pixel size and type of pictures and videos, and the type of sounds and attachments (never their names or the files, and nothing about places on a map: no address, place name or coordinates); never a schema’s agents’ run records, services, approvals or ports. Once we switch it on too, it can also hold a small picture of each map, at most 256 pixels on its longer side and 48 KiB, kept without the image file’s metadata, as the map looked when you last closed it or saved it from its menu: it shows the map’s pictures, place cards and link cards at low resolution, including a card that opens a map you hid from agents, and the agents standing on its nodes with their status, as drawn; when you change the map, the picture is left out and the one we keep is deleted, until you close the map again. An agent you connect reads these through the MCP tools, and the picture goes to the AI service its user chose. These live inside that copy and are deleted with it: when you hide the map from agents (Visible to MCP Agents off), when the App removes the copy (as described above), when you turn MCP sync off and choose Remove (Keep leaves them; MCP sync is set on each device, so turn it off on every device where it is on), when the owner of a shared schema hides it from members’ agents, or when you delete your account. If we switch either of them off again, new copies are kept without them, and we delete what was already stored by a clean-up we run over the stored copies; until it has run, earlier copies keep them. A version of a map saved in Version History while this was on keeps the rich content (never the picture) with that version, so that agents can read the version, and it is deleted with the version. An agent can also ask the App to save an export of a map (Word, SVG or text) as a new file in the App’s exports folder on your Windows or Linux computer, iPhone or iPad (Documents/SchemAgentic Exports; on iPhone and iPad, SchemAgentic/Exports in the Files app) — never over a file you have, and never on a cloud drive or on our servers; it stays there until you delete it (on iPhone and iPad also when you delete the App) — and to publish, one at a time, the copies agents read of maps you have not opened since you turned MCP sync on (the App first asks our server which of them already have a copy, sending only their ids, which we do not keep); maps you hid from agents on that device, encrypted maps and maps that already have a copy are skipped, and the MCP Server dialog shows when it last did so. A map you hid on another device while MCP was not available there (signed out, without the plan, or in the web app) is not known to that device, just as when you open the map there. An export is made by the App on your device and saved there: its content never passes through our server, and neither do your pictures, sounds, attachments or map files. What waits on our server is the request — the format and options, and the drive, folder and file name the agent asked for; then its size, or for copies how many maps were published and skipped (and, while file places are shared, where the export went) — at most 7 days, and is deleted 30 days after it ends (it can take up to a day longer), and always when you delete your account. We also keep two counters of how many exports and copy requests agents asked for today, which keep the daily limits; they are overwritten each day and deleted with your account.

Maps shown inside a chat app. Once we switch it on, when you ask a connected chat app that can show interactive views (such as Claude) to show one of your maps, our server sends that map’s synced copy to the app: its title, id and when it was last published, how many topics it has and how they nest, its topic titles (up to 120 characters each) and the start of each topic’s note (up to 200 characters), whether a topic is folded or holds other content, for up to 2,000 topics, and, once map links are switched on, the map’s link — nothing else of it: no pictures, files, places or styles, and none of the links in it. The app draws it in a sandboxed frame inside the chat. The page in that frame comes from our server and holds none of your data; it loads nothing from anywhere else, calls no tool, stores nothing and cannot change your map, and no AI model is used on our side. Like any answer an agent receives, what it shows stays in that chat under the chat app’s own terms. The ready-made prompts the server offers (such as “Summarize a map”) are fixed text: we read and store nothing for them, and call no model.

Compatibility counts. To keep the MCP server working with each chat app, once we switch it on, each of our server’s instances counts, per hour, which protocol versions are used, which well-known apps connect (by fixed names, for example “claude-code”; any other name is counted only as “other”), which capabilities they announce, which kinds of request they make and which tools are called, whether a token or a signed-in app sent each request, and how many requests our limits refused or could not check. These are counts only — never who, from where, or what: no account, email address, token, network address, map, title or anything you or an agent wrote. Counts below 3 are merged into “other”, and each instance writes at most one line of counts for each hour to our server logs (or one more for every 100,000 requests, should an instance ever serve that many in an hour), which keep them for 30 days. Nothing of it is stored with your account.

Call limits. To keep the service fair, once we switch it on, our server counts how many requests each account’s agents make, in the memory of each server instance (until the instance stops). Where a plan has a daily limit, that day’s count is also stored on our server, as one record holding only the day, the number of requests and when it expires; it is deleted automatically about two days after that day (it can take up to a day longer), and when you delete your account. If our server cannot check that count, the request is refused, never run.

Word search for agents. To let a connected agent find your schemas by their words, once we switch it on, SchemAgentic keeps, with each schema’s synced copy, a list of the words in it — in a simplified form that ignores capitals, accents and word endings, with pairs of characters for Chinese and Japanese text, made from the schema’s title, its topics’ titles and notes, text items, check boxes, link cards’ labels and the captions of pictures and media, list titles and items, and table titles, headers and cells (never web addresses or file names), together with the at most two languages it is written in. It is made from the copy itself, is not shown to anyone as such, and is deleted with the copy: when you hide the schema from agents, when the copies are removed, when the owner of a shared schema hides it, or when you delete your account. No AI model reads or processes it, and what an agent searches for is not stored. If we switch word search off again, new copies are kept without a word list, and a clean-up we run deletes the lists already stored.

What is inside notes. Once we switch it on, a synced copy also lists what sits inside a topic’s notes and text items — their text, check boxes, links and the web addresses of pictures and media with their captions, tables, lists, charts, calendar cards’ titles and times, which of your schemas a note links to, and the kind and size of pictures and files (never their file names or where a place is) — for your agents to read; it is deleted with the copy. A version of a schema saved in Version History while this is on keeps them with that version, so agents can read the version, and they are deleted with the version. If we switch it off again, new copies are kept without them, and a clean-up we run deletes what was already stored in the copies (a version keeps its own until it is deleted).

Your saved scenes. Once we switch it on, when an agent asks, SchemAgentic tells it the names of the canvas scenes you saved, when each was saved and how it was made (with AI, from a schema or imported), so it can use one; they are read from your account when the agent asks and are not stored by the MCP server (the agent’s own provider receives them, as with anything an agent reads).

Review mode and agent activity. From the next SchemAgentic update, once we switch them on: if you turn on review, changes agents ask for to schemas you already have wait in Agent Requests until you approve them in the app (new schemas and file requests are not held); the switch is kept with your account until you change it or delete your account. The Agent Activity list in the app reads the requests our server already keeps and stores nothing new. The records the app keeps to undo file changes (at most 7 days), to tell you that changes may be waiting for a closed schema (at most 30 days) and to count its tries to draw an agent’s drawing (at most 30 days), and, for each account, whether this device saw review on (cleared after 30 days of answers that review is off) and which requests you undid from Agent Activity (at most 50, for 7 days), stay on your device and never leave it.

Drawings and scenes agents write. Once we switch them on, a drawing (SVG text, checked and cleaned by our server) or a scene an agent writes waits in its request until your app applies it, as any request does; it then becomes part of your schema — a drawing as a picture with its checked SVG beside it, a scene as SchemAgentic’s checked version. A third daily counter, of how many drawings agents asked for today, keeps the daily limit of drawings; it is overwritten each day and deleted with your account.

10. Third-party services we use

We use the following processors and service providers to run the Services. Each receives only the data needed for its function. YouTube (Google) is the exception: it is not our processor, and it collects and uses data under its own policies, as described in “YouTube videos” below.

ProviderPurposeData involved
Google Firebase (Authentication, Firestore, Storage, Cloud Functions)Accounts, cloud schemas, backendAccount identifiers, entitlements, schema content, run records, usage
Google Secret ManagerStoring service credentials and tokensAPI keys and OAuth tokens you provide
Google Analytics for Firebase (GA4)Aggregate usage analyticsApp/device usage events, approximate region, instance identifier
AnthropicAgents, AI drafting and AI chatInstructions, node text, service descriptions (see §4)
Apple App StorePurchases on iOS & macOSPurchase/transaction identifiers
Google PlayPurchases on AndroidPurchase tokens/product identifiers
PaddleMerchant of Record for Windows, Linux & web purchasesBuyer email, account ID, customer/subscription IDs
Services you connect (e.g. Stripe, Slack, GitHub, Google, Notion, Airtable, Twilio, Resend, or any API you add)Whatever you configured them to doExactly what your operations send, at the times your agents call them
YouTube API Services (Google)Playing YouTube videos in your schemasWhen a video is played: your network address and browser or web-view details, the video, and the app's identifier, sent directly to YouTube from your device (see “YouTube videos” below)

We do not control, and are not responsible for, the privacy practices of third-party services you choose to connect. Please review their policies before sending them anything.

YouTube videos

SchemAgentic uses YouTube API Services: a YouTube video in a schema plays in YouTube's own embedded player. By using the Services you agree to be bound by the YouTube Terms of Service. The Google Privacy Policy describes how Google handles information about you; it governs what YouTube collects.

11. How we share information

We do not sell your personal information and we do not share it for cross-context behavioral advertising. We disclose information only:

12. Cookies & analytics

Our websites use a minimal set of cookies and similar technologies necessary to run the site and remember your choices. In-app analytics are provided by GA4 as described in §2(f). Apart from the YouTube player described in §10, we do not serve third-party advertising in the App. If that ever changes, we will update this policy first. YouTube's embedded player may place cookies in the web view or browser that plays a YouTube video (see §10).

13. Data retention

14. Your rights & choices

Depending on where you live (including under the EU/UK GDPR and the California Consumer Privacy Act, as amended), you may have the right to access, correct, delete, or export your personal data, to object to or restrict certain processing, to withdraw consent, and not to be discriminated against for exercising these rights. Because we do not sell or “share” personal information as those terms are defined, there is no sale to opt out of.

You can exercise many choices directly in the app:

Deleting your account. You can have your account and its associated data deleted permanently: email cryptobees@gmail.com from your account email and ask us to delete it. If you signed in with Apple and chose to hide your email, write from any address and tell us your account’s address as Manage Account shows it (it ends in @privaterelay.appleid.com): we check through that address that the request is yours. To protect you against accidental or unauthorized deletion, we first make sure the request comes from you, and then turn on account deletion for your account. You then delete it yourself, from Manage Account on this site, or from within the app: open Account, choose Manage Account, then Delete Account. Your account’s email address must be verified, and we re-verify your identity and then ask you to confirm once more — on this site, by typing your exact account email. When you confirm, we delete your account and the personal data associated with it — including your profile, entitlement and usage records, cloud schemas and their snapshots, agent run records, service configurations and their stored credentials and tokens, MCP tokens, connected apps, the MCP activity record and requests and messages from MCP agents, where your map files are and which maps you have open, file requests from MCP agents and the records of maps moved to the trash — and sign you out (§13 says what happens to a credential you set in a schema someone else owns). Some records may be retained where we are required to keep them by law or to resolve disputes or prevent fraud; and while we cancel a subscription billed through our web checkout, we cannot cancel one billed by Apple or Google Play — only they can, so cancel that separately in the App Store or Google Play before deleting, or you will keep being charged. To exercise any other right, contact us at the same address; we will respond within the timeframe required by applicable law. You may also lodge a complaint with your local data-protection authority.

15. International data transfers

We and our processors operate in the United States and other countries. Where we transfer personal data across borders, including from the EEA, UK or Switzerland, we rely on appropriate safeguards such as the European Commission’s Standard Contractual Clauses or equivalent mechanisms offered by our processors.

16. Security

We take reasonable and appropriate technical and organizational measures to protect your information, including: storing service credentials and OAuth tokens in a dedicated secrets manager with no read path back to any client; removing credentials from responses before they are recorded; requiring a person to approve any action that spends money, messages someone outside a schema, or deletes data; refusing outbound calls to private network addresses, checked again on every redirect; verifying incoming webhook signatures with a constant-time comparison; per-user and per-role access rules on cloud data and storage; hashing MCP access tokens and the tokens of apps connected by signing in; and transport encryption throughout. No method of transmission or storage is completely secure, and we cannot guarantee absolute security. You are responsible for keeping your account credentials and any API or access tokens confidential.

17. Children’s privacy

The Services are not directed to children under 13, and we do not knowingly collect personal information from children under 13. Some features (such as AI and purchases) may have a higher minimum age under the applicable app store’s or provider’s terms. If you believe a child has provided us personal information, contact us and we will delete it. This is consistent with the U.S. Children’s Online Privacy Protection Act (COPPA).

18. Do Not Track

Some browsers offer a “Do Not Track” signal. There is no common industry standard for how to respond to it, and our websites do not currently respond to DNT signals. We limit tracking as described in this policy regardless.

19. Data-breach notification

If a data breach affecting your personal information occurs, we will notify affected users and any relevant authorities without undue delay and as required by applicable law, describing the nature of the incident and the steps we are taking.

20. Changes to this policy

We may update this Privacy Policy from time to time to reflect changes to the Services, our practices, or legal requirements. When we make material changes we will update the “Last updated” date above and, where appropriate, provide additional notice. Please review this page periodically.

21. Contacting us

For any privacy question, request or notice:
cryptobees@gmail.com
CryptoBees LLC