Legal
Privacy Policy
Last updated: 27 October 2026
This policy says what LLMGRAPH sends, what we keep, for how long, why, who else handles it, and how you can use your rights. It is a separate notice from the Terms. Where something is not yet proven, it says so.
Who is responsible
Brainfoods Studio, a sole proprietorship at Pratap Nagar, Jaipur, Rajasthan 302033, India, operates LLMGRAPH. It is the data fiduciary under India's Digital Personal Data Protection Act, 2023, and the controller under the EU and UK GDPR.
Data Protection Officer and Grievance Officer: Shambhavi, dpo@llmgraph.in. Write to this address for any request about your data, to withdraw consent, or to complain. We acknowledge a grievance within 48 hours and resolve it within one month. If we do not resolve it, you may complain to the Data Protection Board of India or, in the EU or UK, to your supervisory authority.
EU and UK representative: LLMGRAPH is offered worldwide, including the EU. Contact the Data Protection Officer at the address above for anything addressed to a representative.
Other contacts: support@llmgraph.in for support; security@llmgraph.in for security reports.
What runs where
Your code is read and analysed on your computer. The index LLMGRAPH builds from it is encrypted on disk, in your user cache folder.
Your code never leaves your computer: the only server LLMGRAPH contacts is our licence service, and we checked this on the released program. What it sends there is listed below.
What leaves your machine
The closed beta has three tiers of telemetry. The licence check (T0) stays on: the product needs it. From version 0.4.3, usage counts (T1) and crash reports (T2) are on by default and you can switch them off with npx -y llmgraph-mcp telemetry off, and back on with npx -y llmgraph-mcp telemetry on. A report already being sent when you switch off may still arrive. You are told about it when you approve your first device.
Telemetry never carries your code or the names in it: no file paths, no names of your functions, classes or repositories, none of the questions your agent asks, and none of our answers. Crash reports carry only the names of LLMGRAPH's own functions where an error happened. Every value in telemetry is a whole number, a name from a fixed list, a date, the app version, or the name of one of our own modules or functions.
Usage counts (T1) and crash reports (T2) are linked to your device, and through it to your account.
T0: the licence check
Sent with every licence renewal, about every 30 minutes while the server runs:
- the device id, a random value we assign when you approve the device (it is not made from your hardware);
- the app version;
- the operating system;
- your plan.
A licence check is a request with a body and signed headers. Apart from standard HTTP headers (such as the content type), these are all of them.
The body holds only these fields, and the licence service drops any other:
- the licence token you already hold (not present on the very first check);
- the app version and the operating system, as above;
ek, when present: a one-time public key used to deliver the unlock key for your encrypted index;- the usage counts of one finished day (T1), when one is due.
The headers carry the device id, the time on your computer's clock, and a signature over the body. The request also names the program and its version (llmgraph/<version>). Your plan is read from the licence token, not sent as a separate field.
T1: daily usage counts
Whole-number counters for one finished day (UTC), sent with a licence renewal. Only counters that are not zero are sent. The counters are stored with your device, and your device belongs to your account, so they are linked to your account. The schema holds 69 counter names (schema version 1). This table is generated from the schema file the program ships with, so it is the full list:
| Group | Counters (the group name, a dot, then one of these) |
|---|---|
q.who_calls | calls outcome.ok outcome.ambiguous outcome.not_found outcome.bad_input outcome.no_change outcome.unavailable outcome.deadline outcome.error truncated over_budget expand tokens |
q.what_breaks_if_changed | calls outcome.ok outcome.ambiguous outcome.not_found outcome.bad_input outcome.no_change outcome.unavailable outcome.deadline outcome.error truncated over_budget expand tokens |
q.check_my_changes | calls outcome.ok outcome.ambiguous outcome.not_found outcome.bad_input outcome.no_change outcome.unavailable outcome.deadline outcome.error truncated over_budget expand tokens problems |
q.what_is_unknown | calls outcome.ok outcome.ambiguous outcome.not_found outcome.bad_input outcome.no_change outcome.unavailable outcome.deadline outcome.error truncated over_budget expand tokens |
q.explain | calls outcome.ok outcome.ambiguous outcome.not_found outcome.bad_input outcome.no_change outcome.unavailable outcome.deadline outcome.error truncated over_budget expand tokens |
session | started checker_unavailable big_jump |
The groups beginning q. are the five questions; the counters are how many calls, how each call ended, whether the answer was shortened or expanded, and the size of our answers in the program's own units. session. counters say how often the server started or fell back.
T2: crash reports
Sent when our own program crashes. One report per kind of crash per day, built only from our own code. A report is stored with your device, so it is linked to your account in the same way as the usage counts. A report holds the date, the kind and phase below, our version, the report format number, your operating system and CPU type, the type name of the error (from a fixed list) and, for operating-system errors, its number, one of our own error codes, the module name, function name and line number of each step inside our code (steps outside our code appear only as the word "external"), how the process ended, from a fixed list (for example killed or out of memory), and how many times it happened that day. It holds no exception message, no file path and no text from your project. This table is generated from the schema file:
| Field | Allowed values |
|---|---|
| kind | exception native_crash |
| phase (which part of our program was running) | startup licence index resolve query checker store other |
| operating system | windows macos linux |
| CPU type | x64 arm64 |
| error code of ours (anything else is reported as the last one) | E_UNCODED |
| how the process ended | access_violation stack_overflow out_of_memory killed other_code unknown |
The limits that apply to telemetry, also generated from the files the program ships with:
| Limit | Value |
|---|---|
| A crash report is at most | 4096 bytes and 24 steps |
| Crash reports sent per device per day, at most | 5 |
| Crash reports kept waiting on your computer, at most | 20 |
| Usage counts wait to be sent for at most | 7 days |
| The outbox file keeps what was sent for | 30 days |
How to see it
Everything queued or sent is first written to a file on your computer, and telemetry show prints it:
npx -y llmgraph-mcp telemetry showIt prints what is waiting and what was sent in the last 30 days.
Other data that reaches us
These are the personal fields the licence service stores, by kind.
- Account: your Google email address and Google account id; a collapsed form of the email that is used to keep a trial to one per person; whether the email is verified; the account status (active, suspended or deleted); the trial start and end, and a flag if a further trial is refused; when the account was created.
- Devices: for each device, its random id, its public key, operating system and app version, when it was added, when it was last seen (stored to the hour), when it was removed, and a flag if it is over your plan's device limit.
- Consent: which consent you gave (usage counts), its version, and when.
- Subscription: the Dodo customer and subscription ids, plan, billing interval, status, the end of the paid period, whether it is set to cancel, and when we last heard from Dodo. Billing itself is handled by Dodo Payments.
- Payments: for each payment Dodo reports, its id, status, amount, currency, time and any flag we set.
- Access grants (for example an invite or free access): the plan, until when, the reason, who created it and when.
- Sign-in sessions: a hash of the session secret (not the secret), when it was created, when it expires, and when it was ended.
- Audit log: when something was done to an account or device (for example approving or removing a device), who did it, the action, what it was done to, and details.
- Waitlist for the invite-only beta: which agent you use, your main language, your answer to "What would you use it for?" if you write one, your status (pending, approved or rejected), when you applied, and, once approved or reviewed, who reviewed it, when, and any review notes, and, if the link you followed carried one, a short code naming where it came from (for example
xfor a post on X). - Welcome email: the email address of an approved applicant is sent to Resend to deliver one welcome email, once.
- Connection data: network providers see connection details such as your IP address, like any web service. The licence database has no IP address column.
Why we use data, and on what basis
| Purpose | Data | Basis under the DPDP Act | Basis under the GDPR |
|---|---|---|---|
| Sign you in and run your account | Account, sessions, devices | Provided by you for this use (DPDP s.7(a)); legal obligations for tax and billing records | Contract |
| Issue and renew licences, enforce the device limit and one trial per person | Licence check (T0), devices, collapsed email | Provided by you for this use (DPDP s.7(a)); legal obligations for tax and billing records | Contract; our legitimate interest in preventing repeat trials |
| Billing, payments and refunds | Subscription, payments | Provided by you for this use (DPDP s.7(a)); legal obligations for tax and billing records | Contract; legal obligation for tax and accounting records |
| Understand usage and fix crashes in the beta | Usage counts (T1), crash reports (T2) | Data you provide for this stated purpose, until you switch it off (DPDP s.7(a)) | Our legitimate interest in keeping the beta working; you can object at any time by switching it off |
| Run the invite-only waitlist and review applications | Waitlist answers, audit log | Your consent when you apply | Consent; our legitimate interest in running the waitlist |
| Security, abuse prevention and audit | Audit log, sessions | Uses the law allows for security | Legitimate interest |
| Send the welcome email | Email address | Your consent when you apply | Contract; our legitimate interest in replying to your application |
The licence check is a condition of using the product. You can switch off usage counts and crash reports at any time with npx -y llmgraph-mcp telemetry off (from version 0.4.3); that is how you object to them. You can withdraw consent for the waitlist and the welcome email, or object to any other use, by deleting your account or by writing to dpo@llmgraph.in. We then stop using your data for that purpose. The beta cannot be used without the licence check.
Retention and deletion
We keep T1 usage counts for 90 days and T2 crash reports for 30 days, then delete them. Sign-in sessions are deleted 30 days after they end, and sign-in links a day after they expire. The audit log is kept for one year, except billing events (payments, refunds and disputes), which stay while the account exists so that the trial and refund rules keep working. Waitlist answers are deleted a year after the decision on them (or a year after you applied, if there was none); for an approved request we keep only its status and dates. When the licence service rejects telemetry, it keeps only the day, the reason and a count, for 30 days, and nothing of the content. The device record stays while the device exists. Our hosting provider's own backups or restore points may keep a deleted row for a short period under its own rules.
Deleting your account cancels any subscription at the end of the paid period, then deletes your account, devices, usage counts, crash reports, consent records and waitlist answers from our live database, and erases your email and Google account id. Dodo Payments keeps its own payment records as the seller of record. We keep records the law requires us to keep, such as accounting records, for as long as it requires.
Cookies
Two cookies exist, and only the sign-in and account pages set them. The session cookie (__Host-llmg_session) keeps you signed in; it lasts 30 days by default. A short sign-in state cookie (__Host-llmg_g_state) is set only during Google sign-in and lasts 10 minutes. No other page sets a cookie. The site has no analytics and loads no script, font or image from another host. Both cookies are first-party and strictly needed to sign you in. If the link you followed to the waitlist carried a short source code, the sign-in state cookie also carries that code through the sign-in, and it ends with that cookie.
Who else handles data
| Party | Role | Data |
|---|---|---|
| Cloudflare | Hosts the site and the licence service. The licence database is Cloudflare D1, in the Asia-Pacific location. | What the licence service stores; connection details |
| Handles sign-in | Google account details released at sign-in | |
| Dodo Payments | Seller of record; handles billing and keeps its own payment records | Payment and subscription data |
| Resend | Delivers the welcome email, sending from Tokyo | The email address of an approved applicant |
Network providers see connection details such as your IP address, like any web service. How long Cloudflare keeps its own edge logs is Cloudflare's rule.
International transfers
Our service providers process data in the places shown above, which include India, Japan and other countries where Cloudflare, Google and Dodo Payments operate. Where the law requires a safeguard for a transfer, we rely on the safeguard the law accepts, such as the standard contractual clauses for transfers from the EU or UK, and the transfer rules that apply under the DPDP Act. The standard contractual clauses cover our processors, Cloudflare and Resend. Dodo Payments (seller of record) and Google (sign-in) act as independent controllers under their own terms. You can ask for details at dpo@llmgraph.in.
Your rights
Write to dpo@llmgraph.in from the email address on your account. We may ask you to confirm who you are first.
- India: you can ask for a summary of your data and of the parties it is shared with, ask us to correct, complete or erase it, withdraw consent, have your grievance heard, and nominate another person to exercise your rights if you die or cannot act.
- EU and UK: you can ask for access, correction, erasure, restriction, a portable copy, and you can object to processing based on our legitimate interest and withdraw consent. You may complain to your supervisory authority.
- Everyone: you can delete your account on the account page, and see your telemetry with
npx -y llmgraph-mcp telemetry show.
Children
LLMGRAPH is for people aged 18 and over. We do not knowingly collect data from anyone younger. If you think a child has an account, write to dpo@llmgraph.in and we will delete it.
Security
Your index is encrypted on disk. We store only a hash of your session secret. Licence requests are signed. Report a vulnerability to security@llmgraph.in; see the Security page. If a breach affects your personal data, we will tell you without undue delay, and report it to the Data Protection Board of India and to CERT-In within the times the law sets.
Changes
We may change this policy. The date at the top shows the latest version. For a material change we will give at least 30 days' notice by email or in the program before it takes effect.
Contact
Data Protection Officer: Shambhavi, dpo@llmgraph.in. Support: support@llmgraph.in. Post: Brainfoods Studio, Pratap Nagar, Jaipur, Rajasthan 302033, India. More company details are on the Legal page.