Privacy policy
ToolsEnabled Privacy Policy
Version 0.9.1-security · Effective 6 September 2026 · Last updated 24 September 2026.
Version 0.9.1-security — updated 6 September 2026, effective on the date shown on the published page.
This is a beta. The hosted service described here is new. §6A says plainly what that means for your account.
This policy describes what the software does on your machine and what our hosted service holds about you if you create an account. This update adds the passkey and session security records described in §6A, explains their purpose and recovery limits, and corrects earlier absolute claims about remote-access encryption.
This policy describes what happens to your data when you use ToolsEnabled — the local AI agent runtime, its optional hosted relay, and related desktop tooling described in docs/. It does not cover other, separately named products (for example, the "AI Calendar" Chrome extension), which have their own privacy policies. It also does not cover the internal tooling this company's own engineers and agents use to build ToolsEnabled — only the product a customer installs and runs.
The hosted account security changes in this update were checked against the account service source. Other sections retain earlier descriptions and the open questions they identify; this update is not a new verification of the entire product or its providers. Data-handling descriptions need review whenever a release changes how data moves.
Who "we" are. Throughout this policy, "we," "us," and "the Company" mean ToolsEnabled, Inc., a Delaware corporation (Delaware file number 10741110), which provides ToolsEnabled and is the controller of the data described here, reachable at the addresses in §11.
1. The short version
ToolsEnabled is built to run on your own computer and keep your data there by default. As of today:
- The local app account and the hosted website account are different. The local account described in §3 identifies who asked the assistant to act and is stored on your computer. A website account used for FRA remote access is held by our hosted service and has the account, recovery and security records described in §6A.
- We do not run any analytics, telemetry, or crash-reporting service. There is no Sentry, PostHog, Mixpanel, Segment, or similar SDK anywhere in the product, and no code that phones home usage statistics. (Re-verified by direct source search on 2026-08-12; the product has exactly one runtime dependency, Playwright. See §4.)
- The audit log the product keeps of its own actions stays on your machine. It is not uploaded anywhere by us. (See §3.)
- The product keeps three other stores of your data on your own disk, and an older version of this policy failed to mention any of them: an encrypted credential vault that can hold API keys, sign-in tokens, passwords and — if you choose to save one — a full payment card number (§2A); a browser profile, which is a real Chrome profile holding cookies, history and saved logins for the sites your agent visits (§2B); and a spend ledger recording amounts and purposes of purchases (§2C). All three stay on your machine. None is uploaded by us.
- FRA uses our hosted account and connection services. If you create a hosted account, we keep your email, password verifier or Google sign-in identifier, enrolled-computer records, document acceptance and the session security information described in §6A. If you enable passkey protection, we also keep the public passkey credentials and security settings described there. Your account page lets you manage passkeys and delete the account.
- What does leave your machine is what you'd expect from an AI agent tool: prompts and file content go to the AI provider (Anthropic, OpenAI, Google, or a model you run yourself) that you configured, using your account. Full detail in §2.
The local software and the hosted service have different data flows. This policy must be updated when those flows change, including when new account security records are introduced.
2. What leaves your machine, and to whom
ToolsEnabled's core job is running AI agents, which means sending your prompts, instructions, and (when you give an agent file access) file contents to an AI model. That is inherent to the product working at all, not a hidden data flow. Today there are three distinct paths, verified directly against the code:
2.a Provider CLIs you already have installed (Claude Code, Codex, Gemini CLI)
For most agent work, ToolsEnabled does not talk to Anthropic, OpenAI, or Google itself. It launches the CLI tool you already have installed (claude, codex, gemini) as a subprocess and lets that tool communicate with its provider, using your login — a subscription sign-in or an API key you provide, not a key we hold. The code that launches these subprocesses (src/) actively strips ambient provider API-key environment variables before handing control to the CLI, specifically so the CLI is forced to use your own account rather than some other key. We do not see or store the content of these conversations; it passes from your machine to the provider you chose, under the account you chose, under that provider's own privacy terms — not ours.
2.b A local model on your own network (Ollama)
One code path (src/) talks to a local Ollama instance for certain "quick" completions. Today it is configured to a private LAN address belonging to the owner's own second machine, not a public service — this is infrastructure-specific to how this instance is currently deployed, not a general product behavior, and will need to be re-pointed at each customer's own local Ollama installation (or removed) before this is a general product feature. Open question, not resolved here: how this path is configured for a customer install, since the current wiring is owner-specific.
2.c Google Vertex AI, using an account we operate
A smaller set of backend features (advisory/report generation — src/ and its sibling files) make direct HTTPS calls to Google's Vertex AI API. Unlike §2.a, these calls use our own operator Google Cloud account and credentials, not an account you configure. Prompt text is sent to Google under our account and is subject to Google's Vertex AI terms and data-handling policies as the operator's customer.
Open question, flagged rather than guessed at: it is not fully clear from the code alone whether this path ever carries a paying customer's prompts (as opposed to being purely an internal/operator-facing report generator). Before this policy is finalized, someone who knows the product roadmap needs to confirm: does any customer-facing feature route through this operator-owned Vertex path? If yes, this section needs to say plainly "this feature sends your prompt through our Google Cloud account," which is a meaningfully different privacy fact than "your prompt goes to the account you configured" (§2.a).
A content filter (containsSensitiveMaterial) runs before certain requests in paths 2.b and 2.c to block prompts that look like they contain credentials or session tokens — a safety net, not a guarantee that no sensitive content is ever sent.
2.d What we did not find
We did not find any code path where ToolsEnabled itself relays your prompts, file contents, or conversation history to a server operated by us for any purpose other than what's described in §2.c. There is no general-purpose "send usage data to ToolsEnabled" call anywhere in the product.
2A. The credential vault — including, if you save one, your card number
New in the 2026-08-12 revision. This section did not exist before, and the product has had a vault the whole time.
ToolsEnabled stores the credentials it needs in an encrypted file on your own computer.
Where it is. vault/secrets.json inside the product's data folder. On a normal install that is %APPDATA%\.
How it is protected. With Windows' own Data Protection API (DPAPI), tied to your Windows sign-in. There is no separate password and no key file of our own: Windows holds the key material, and a copy of the file taken to another machine or opened under another Windows account cannot be decrypted. The folder's permissions are set explicitly so that only your Windows account, SYSTEM, and Administrators can open it. (An earlier version inherited permissions that made the vault readable by any account on the machine; that was found and fixed. We are telling you because it happened.)
What can go in it. Whatever you connect: AI-provider API keys, Google and Chrome Web Store OAuth tokens, Telegram bot tokens, a GitHub token, search-service keys, hosting-provider tokens, payment-provider API keys, and — for a couple of sites — an actual website password you asked it to keep.
Two entries need saying out loud, because most people would not guess a developer tool holds them:
- A full payment card. If you use the feature that saves a card, what is written to the vault is the cardholder name, the card number and expiry date, plus a billing postal code. The card's security code (CVC/CVV) is never stored — the saved card record has no field for it. Nothing in ToolsEnabled reads a stored card yet; storing one does not by itself enable any purchase. When a purchase flow exists, it will ask for the security code at that moment and discard it. This is a hard rule of the payment-card industry standard, not a preference: the security code is the one card element that may never be persisted, anywhere, by anyone. This is not a token, not the last four digits — it is the card. It never leaves your machine: it is written by a local dialog, it is on a deny-list that stops any agent, log, report, or tool response from ever reading it back, and no code in the product currently uses it for anything. The part that would spend it has not been built. You should still know it is there.
- A legal name. If you use the identity feature, your given and family name are stored in the same vault under the same deny-list.
Does it leave your machine? The file does not. There is no backup, sync, or export of it, by us or by anything in the product. But the credentials inside it are used for their purpose — an API key in the vault is what gets attached to a request to that provider, which is the entire point of saving it. So the effect of a key leaves your machine whenever you use the thing it unlocks.
Every read is logged. Each time a secret is fetched, listed, or checked for existence, a line is appended to secrets.json.access.log recording which key and what action — never the value.
What you can delete. Secrets can be deleted one key at a time. There is no "empty the vault" command, and no export. See §8, which is honest about this rather than promising otherwise.
2B. The browser profile — cookies, history, and saved logins, on your disk
New in the 2026-08-12 revision.
When ToolsEnabled drives a browser for you, it does not use your everyday Chrome. It launches Chrome against a separate profile of its own, and that profile is a real, ordinary Chrome profile directory that persists between runs.
Where it is. profiles/chrome in the product's data folder — on a normal install, %APPDATA%\.
What accumulates in it. Exactly what accumulates in any Chrome profile, for whatever sites your agent visits: cookies and logged-in sessions (Default\Network\Cookies), browsing history (Default\History), any passwords Chrome saves (Default\Login Data), site data, cache, favicons, and extension state. If your agent signs in to a website on your behalf, the session that keeps it signed in lives here.
It is kept apart from your own Chrome, deliberately. The product will only attach to a browser it launched itself and can prove it owns; it never adopts or reads the Chrome you use personally, and its cleanup tooling names your real Chrome profile as a path it must never touch.
What reaches the AI model. Page text, screenshots and page structure the agent asks for do go to the AI provider — that is how browser automation works. Before any of that is handed over, cookie values, Authorization headers, bearer tokens and credential-shaped URL parameters are stripped out. That filter protects what is returned to the model. It does not change what Chrome writes to the profile on your disk, which is everything listed above.
Nothing from this profile is transmitted to us.
What you can delete. The whole folder, by hand. There is no in-product "reset browser profile" command. Deleting the folder signs the agent out of everything and is safe to do.
2C. Virtual payment cards and the spend ledger
New in the 2026-08-12 revision.
ToolsEnabled can issue virtual payment cards with spending limits through Stripe Issuing, so an agent can be given a card that physically cannot spend more than a set amount per day.
What is sent to Stripe when a card is created: a cardholder name, and optionally an email address, a phone number, and a full billing address; then the card's currency, its daily spending limit, and any merchant-country or category restrictions. Stripe is the card issuer and this information is handled under Stripe's terms, not ours.
What is stored on your machine. Only the trimmed result: the card's Stripe id, cardholder id, type, status, currency, the last four digits, the expiry month and year, and the spending controls. The full card number and CVC are never returned to the product and are never stored — Stripe does not hand them over and there is no code anywhere that asks for them.
Do not confuse this with §2A. They are different features: the virtual-card feature never stores a card number; the vault's "saved card" feature stores a whole one.
The spend ledger. Spending is recorded in a local database, state/. Each row holds a date, a timestamp, an amount, a purpose, a provider name, and a reference — no card number, no cardholder name, no address. It stays on your machine.
3. The audit log
ToolsEnabled keeps a local, tamper-evident log of the actions its agents take (which tool was called, when, with what high-level parameters) so you can review what an agent did. This log:
- Is stored in a local SQLite database on your own machine (
state/audit.sqlite3), hash-chained and signed with a key held in your machine's local secret store. We verified directly that the code writing and reading this log (src/lib/audit-store.js,src/lib/audit.js) makes no network calls of any kind. - Is not uploaded to us, or to anyone. There is no off-machine audit custody service. If one is ever built it will be opt-in, and this policy will be updated first to describe exactly what leaves your machine and where it goes.
- Is honestly not a tamper-proof vault against every threat. Our own engineering documentation states plainly: it is "local tamper evidence, not remote WORM storage" — someone with the same level of access as you have on your own machine could, in principle, alter both the log and the key that signs it. We are repeating that limitation here rather than letting a security document say it while a privacy document stays silent.
- Cannot have single entries removed, and you should know that before you ask. Every entry is hashed together with the one before it and signed, so the log is append-only by construction. There is no "delete this event" command and there could not be one that worked: removing a row would break the chain and the next verification would report it. The only way to erase something from the audit log is to delete the whole log file, which is yours to do and which we tell you how to do in §8. This is a deliberate design trade: the log is only worth having because it cannot be quietly edited, and that property and selective deletion cannot both be true.
4. Telemetry, analytics, and crash reports
We do not currently collect any of these. Specifically, verified by direct source-code search across the entire product:
- No analytics or telemetry SDK (Sentry, PostHog, Mixpanel, Segment, or similar) exists anywhere in the codebase.
- No code sends usage statistics, feature-usage counts, or behavioral data to any server we operate.
- No automatic crash-reporting exists. If the desktop application crashes, the planned failure-handling design (
docs/) copies a diagnostic bundle to your clipboard for you to send to whoever is helping you — this is a manual, user-initiated action, not automatic transmission to us.design/ INSTALLER- EXPERIENCE. md
Open question: the launch gate this product is being built toward (docs/) explicitly lists "consented metrics wired" as a requirement before general release. That means opt-in usage metrics are planned but not yet built. When they are built, this section must be rewritten before that feature ships to describe exactly what is collected, that it is opt-in, how to turn it off, and how long it is retained. Nothing in this policy should be read as pre-approving that future feature's design — it doesn't exist yet.
We also could not confirm from this source tree whether the packaged desktop application (built from a separate installer checkout, not the engine repository this policy was verified against) adds any Electron-level crash reporting. This is flagged as an open item to verify against that other checkout before publication, not asserted either way.
5. Licensing data
Corrected 2026-08-12. The previous version of this section said no tier was technically enforced. That is no longer true, and the way it became true matters for your privacy, so it is spelled out.
A licence is a signed key that is checked offline, by Ed25519 signature against a local revocation list, with no network call to verify it. That part is unchanged.
What changed is where the check now happens. There are two places, and both of them are on machines we operate, never on yours:
- Admission to the relay we host. When your machine asks our relay to connect it to your other machine, our relay checks the licence before accepting.
- Admission to your account area on our website. Same idea, on our web server.
Nothing on your computer checks a licence. An installation with no licence does not merely skip the check — it never loads the code that would perform one. That is enforced by a test that fails the build if any part of the product outside a short, named list tries to check a licence on its own.
Practically: an unlicensed ToolsEnabled is the complete product, permanently, and there is no licensing data on your machine at all unless you bought something.
Payment details. Nothing is sold at launch, so there is no payment relationship and no payment record. If we ever charge for the hosted service, a payment provider — not us — will collect the card, we will never see or store the number, and this section and §6A will be rewritten before the first charge.
6. Our hosted service — free at launch, and running
We operate a service that connects your computers to each other over the internet without you running a server, and gives you an account area on our website. At launch it is free. The allowance is 2 connected computers and 1 active web session per account, counted only on our side (Terms of Use §1a). Everything else — the local runtime, direct connections on your own network, a relay you run yourself, the audit log, the kill switch, the approvals — is free, permanent, never licence-checked, and never touches our infrastructure.
Remote-access encryption and its limits. FRA encrypts session content between the connected endpoints; the relay is designed to forward encrypted frames rather than interpret that content. Our hosted service still handles account information, peer introductions and connection metadata (§6A), and supplies the website code used by a browser endpoint. Encryption does not remove the need to trust the account service, that website code, and the computers or browsers allowed to join a session. Compromise of an endpoint or the introduction of an unauthorized peer can expose data. We do not claim that peer-to-peer transport makes customer content inaccessible under every server or endpoint compromise.
Where it runs. Your account record lives on a server we rent from Exoscale (Akenes SA, a Swiss company) in its Frankfurt, Germany region — inside the EU. We chose the EU deliberately: it means European data-protection law applies to your record directly, rather than by an arrangement between countries. Exoscale keeps its own operational audit logs of our administrative actions under its standard retention. Backups are encrypted on our server before they leave it and are held by a different provider than the one running the service. We keep backups and server request logs no longer than we need them, and our request logs never contain your session token or your cookies.
The relay we operate runs on that same server. It forwards encrypted session traffic and uses account authorization information to decide which connections are allowed. The limits described above still apply.
There is no support commitment on the free product; see the Terms of Use §5.
6A. What we keep about you if you create an account
This section describes records held by our hosted account and connection services. These records are separate from the data stored by the local software on your own computer.
Account and connection records. We keep:
- Your email address and sign-in credentials: a salted scrypt password verifier if you set a password, and the Google account identifier if you use Google sign-in. We do not store your account password in readable form. Google sign-in does not give this service access to your contacts or mail.
- Session security records: hashes of browser session tokens, creation, last-activity and expiry times, the account security version and idle-time setting, and whether a session has completed the passkey check required for remote access. A verified session also records the passkey used and the verification time. Temporary links between old and replacement session-token hashes let a logout also close a replacement session. We store token hashes rather than the browser's bearer tokens in these records.
- Enrolled-computer and connection records: computer identifiers, the names you choose, public device keys and certificate fingerprints, device-token hashes, enrollment and removal times, whether the device collected its credential, and the pairs and browser public-key introductions used to connect devices. The service can also keep the latest reported connection-attempt time and named outcome for a computer, and monthly totals of bytes carried by the relay. These records describe account access and connection operation, rather than the content of the encrypted frames.
- Document acceptance: the document, version, hash of its text and acceptance time, including the records displayed in your account area.
- Account state: creation and disabled status, passkey-protection settings, and the security version used to invalidate older credentials and sessions.
Passkeys are optional to enroll and change how a protected account is recovered. When you choose to enable passkey protection, we keep each passkey's credential identifier and public verification key, its name, creation and most recent use times, signature counter, supported connection methods, and the authenticator's indications of backup eligibility and current backup state. We also keep a random account identifier used for passkey operations; it is not your email address. The passkey's public key lets the account service check a signed response to a fresh challenge. Counters, account security versions and challenge/session checks help prevent reuse of old authorization.
Our server does not receive your passkey's private key, fingerprint, face scan or authenticator PIN. Your device or passkey provider handles how you unlock and store a passkey. A provider may synchronize passkeys between your devices under its own security and privacy terms. The backup indications we receive describe the authenticator's reported state; they do not give us access to its backup or private key.
Choose computer and passkey names with the understanding that we store them: a label containing your name, employer or other personal information becomes part of your account record. Passkey metadata is used to authenticate you, protect remote access and let you manage your credentials; it is not added to provide advertising or general browsing analytics.
What protection means for recovery. Enrolling your first passkey requires your explicit consent. Once protection is enabled, signing in through your password or Google account alone gives a restricted account session until a passkey is verified; it does not authorize remote access to your computers. Password and emailed-code recovery do not remove passkeys or turn off that protection. You can register more than one passkey. Removing one requires verification with another registered passkey, and the final passkey cannot be removed through that control. Keep a second usable passkey: if you lose every registered passkey, password or mailbox access alone cannot restore protected remote access. This release does not provide recovery codes that bypass the passkey requirement.
Purpose and retention. These records let us operate sign-in, account security, device authorization, connection diagnostics and the account controls you request. Account settings remain while the account exists. A passkey record remains until you remove that credential or delete the account. Browser session records expire or are revoked; expired records are cleared during session cleanup. A passkey's most recent use time remains in its separate credential record until that credential is removed. The links used to carry logout across session rotation are short-lived and cannot be used to sign in.
Deletion. You can delete your account from the account page after the required security check. That removes its active account, acceptance, session, passkey and connected-computer records. For a protected account, deletion requires a passkey check. If you cannot access the account, contact legal@toolsenabled.ai for a data-deletion request; contacting us is not a way to bypass passkey protection and regain remote access. Deleted credentials must not regain authority through a backup restore. Any retained backup copies and operational logs are subject to the retention practices described in §6; this security update does not independently verify provider retention or backup deletion schedules.
Security mail. We send security codes to your account address when requested for supported account actions: adding a computer, creating a friend access code, setting or resetting a password, first-passkey enrollment, and the email-check paths for account deletion or a longer browser idle setting. Which check is required depends on your account's security state; protected actions require a passkey. There is no marketing mail or signup-confirmation requirement added by passkeys. The mail is carried by Porkbun, which also hosts the contact mailboxes in §11, so the mail provider processes the recipient address, message and anything you send to those mailboxes.
Hosting providers and content. The hosted records are stored on infrastructure we operate through hosting providers (§6), and any backup service used for those records also processes its stored copies. Encryption and access restrictions are safeguards, not a claim that an infrastructure provider could never access data. The account database does not store the contents of encrypted FRA session frames. The trust and compromise limits in §6 apply to the remote service as a whole.
This remains a beta service. The terms describe possible service or account interruptions. Passkey protection is not a promise of uninterrupted availability, nor a claim that the entire service has been certified secure. A password reset preserves protected-account settings rather than silently weakening them.
7. Children's privacy
ToolsEnabled is not directed at children. The local software collects nothing and sends nothing, so there is nothing it could knowingly collect from a child. The hosted account is different: it collects an email address, so we set an age floor. You must be at least 16 to create an account, and we do not knowingly keep an account for anyone younger. If you believe a child has created one, tell us at the address in §11 and we will delete it.
8. Your data: what you can actually do, and what we cannot do yet
If you have a hosted account (§6A), you can also delete it, and that deletion is real and end to end (§6A). Everything else in this section is about the data on your own machine, which you control completely without asking us anything.
Rewritten 2026-08-12. The previous version said data rights were "trivially satisfied" because everything is local. That was too comfortable an answer, and parts of it were wrong. Here is the checked one.
8.1 Where your data is, so you can go and look at it
On a normal install, everything the product writes about you is under one folder:
%APPDATA%\ToolsEnabled\Inside it, the things worth knowing by name:
| What | Where |
|---|---|
| The signed audit log (§3) | capability\ |
| General state and the spend ledger (§2C) | capability\ |
| The encrypted credential vault (§2A) | capability\ |
| Who read which secret, and when (§2A) | capability\ |
| The browser profile: cookies, history, logins (§2B) | capability\ |
| Screenshots the product took | capability\captures\ |
| Plain-text action logs | capability\logs\ |
| Your local account and app settings | directly under %APPDATA%\ToolsEnabled\ |
In a developer checkout the same folders sit inside the checkout instead.
8.2 What you can do today — these work
- Delete everything. Delete
%APPDATA%\ToolsEnabled. That removes the vault, the audit log, the state database, the browser profile, the screenshots, the logs, and your local account. Nothing is held anywhere else on your machine, and — unless you created a hosted account — nothing is held by us at all. If you did, §6A's delete button removes that too. - Delete the browser profile only. Delete
capability\. This signs the agent out of every site.profiles\ chrome - Delete one saved credential. The vault supports deleting a single key.
- Read your own audit log. The product can show you recent entries and verify that the log has not been altered.
- Choose what happens to your data when you uninstall. The installer is designed to ask, and to keep your data rather than destroy it if it cannot ask. Before this policy is published, someone must confirm that the shipped installer actually contains this behaviour — the code for it was read in a separate desktop-shell checkout, not in the engine this policy was verified against. Until that is confirmed, do not rely on this bullet.
8.3 What is not built — stated plainly, because promising it would be a lie
None of the following exists in the product today. They are not hidden behind a support request; there is no code that does them.
- There is no data export. No command, button, or tool produces a portable file containing your data. You can view the most recent audit entries, capped, on screen. That is not portability.
- Your hosted account, if you have one, has a delete button on your account page. It shows you the record — your address, your machines, what you agreed to and its fingerprint — before it destroys it, and deletion is end to end (§6A). Your local account is deleted by deleting files (above), because it was never anywhere but on your machine.
- You cannot delete one entry from the audit log. See §3: the log is hash-chained, so selective deletion is not possible without detection. The whole file, or nothing.
One contradiction we are pointing at ourselves. The product's own code lists "reading, exporting, or deleting your own data" among the things a licence must never be allowed to gate. That is a good commitment and we stand by it — but export does not exist yet, so today it is a promise that it will never cost anything, not a promise that it works. Both halves are true and you should have both.
8.4 What we will do until the software catches up
Until export and deletion are built, a request is handled by a person. Send it to legal@toolsenabled.ai (§11), and we will say what we hold, and we will delete what we can. We are not stating a response-time commitment here because we have not agreed one, and an invented number would be worse than none.
8.5 Legal rights are not being claimed here
We are not making a GDPR, UK GDPR, CCPA, or any other compliance claim. Those regimes impose specific duties — response deadlines, a defined request process, a lawful basis, and in some cases a named representative — and whether they apply to this product, and where, is a question for a lawyer, not for this document. It is on the approval queue and has not been answered. Nothing in this section should be read as satisfying any of them.
Note also that this policy describes ToolsEnabled as provided by ToolsEnabled, Inc., a Delaware corporation (see the top of this document).
9. Security
See SECURITY.md for how to report a vulnerability and for the current, honest state of independent security review (there has not been one yet).
10. Changes to this policy
We will post updates here with a new "Last updated" date. Material changes — anything that changes what leaves your machine or who can see it — will be called out explicitly, not buried in a version bump.
11. Contact
Privacy questions, data requests, and legal notices: legal@toolsenabled.ai Help and abuse reports about the hosted service: support@toolsenabled.ai Postal: ToolsEnabled, Inc., c/o Harvard Business Services, Inc. (our registered agent), 16192 Coastal Highway, Lewes, DE 19958.
Open questions this policy could not resolve from code alone
Collected here so they are not lost inside the sections above:
- Whether the Vertex AI advisory path (§2.c) ever carries customer prompts or is purely an internal/operator tool.
- How the local-Ollama path (§2.b) is meant to be configured for a customer's own machine, versus its current owner-specific wiring.
- Whether the packaged Electron desktop shell (built from a separate installer checkout not covered by this verification pass) adds any crash reporting or telemetry not present in the engine repository checked here. The same uncertainty now also covers the uninstall-time data choice in §8.2 — that behaviour was read in the desktop-shell checkout and has not been confirmed present in a shipped installer.
- What the actual "AI Calendar" Chrome extension collects from a user's browser — out of scope for this policy, but it needs its own accurate policy before it ships, and its source was not found in this tree to verify.
- New, 2026-08-12. Whether any legal regime (GDPR, UK GDPR, CCPA, or another) applies to this product, and therefore what §8 is legally required to contain. This is a lawyer's question and no part of this document assumes an answer; the question stands for the free hosted account and is docketed beside TE-L-0008 as the "global free-account privacy floor." None of these were guessed at above; each is stated as unresolved.