“Is my data private” is really three different questions wearing one sentence, and they have different answers. One is about other farms on the same system — can they see mine, or I theirs. One is about the assistant itself — what does it actually read to answer a question, and how much of it. And one is about the vendor running the system — who, if anyone, can look at what is stored. This page is mainly about the first two, because they are the ones a scoped, read-only architecture actually answers with certainty rather than a policy promise.
An assistant is not a source of regulatory truth. Never take a withdrawal period, a re-entry interval, or a certification requirement from any AI, including ours. Privacy and regulatory authority are separate questions — keeping your data scoped to your account says nothing about whether an interval it quotes is the correct one.
The privacy question is really a scoping question
The version of “is my data private” that matters most on shared farm software is: can another account on the same system ever see mine. That is a question about isolation, not secrecy, and it has a technical answer rather than a policy one. The strongest form of that answer is architectural — isolation enforced by what the software is built to allow, not by a promise about what it will choose not to do.
It is worth asking any farm software vendor, including this one, which of those two forms their answer takes. “We only show you your own data” is a behavioural description, true of the product in ordinary use and silent on what happens under unusual input. “There is no code path by which your account can receive another account’s row” is a structural claim, and it is the one that holds even when something goes wrong elsewhere in the system.
What actually leaves your account when you ask
When you ask the assistant a question, two things happen: your question is read, and a small number of read-only tools run against your account to gather figures relevant to it. Both of those stay inside your account’s own boundary. The tools available to the assistant are the same ones that draw your own dashboards — your financial totals, your livestock events — scoped to the account asking. Nothing about a different farm’s records is ever fetched, quoted, or referenced, because within the connection the assistant holds, another account’s records do not exist to be fetched in the first place.
What a “scoped connection” means, mechanically
This is the detail worth understanding rather than taking on faith. A tenant-scoped database client force-injects your account’s filter into every query before it runs — the filter is not something the assistant chooses to apply, it is a property of the connection it was handed. No tool the assistant can call accepts an account id as a parameter, so there is no field anywhere for a different id to be substituted into, by mistake or otherwise. There is no free-form query the assistant can compose that might omit the filter. And every row that does come back is re-checked for ownership before it is used in an answer, as a second, independent gate behind the first. Four separate mechanisms, any one of which would likely be enough on its own, stacked rather than relied on individually.
What isolation does not promise
It is worth being precise about the edges of this guarantee, because overstating it is its own kind of dishonesty. Database-layer isolation answers the question of whether one account can reach another account’s records through the assistant. It does not answer questions about infrastructure access, backups, staff permissions, or what a vendor’s own systems log — those are governed by a privacy policy and a security practice, not by a database filter, and they deserve their own scrutiny separate from this page.
The distinction is not a technicality. A farm choosing software under a certification or a buyer contract that specifies data handling should ask both questions separately, because a vendor can have a genuinely strong tenant-isolation architecture and a weak internal-access policy, or the reverse, and a single reassuring sentence about “privacy” tends to blur the two into one claim that answers neither precisely.
Why a small tool-call cap is also a privacy boundary
A quieter form of the same discipline is the ceiling on how much a single question can touch. The assistant is capped at a few read-only tool calls per answer, drawing from a fixed, small set of purpose-built queries rather than an open-ended search across everything you have ever recorded. That cap is mostly there for speed and predictability, but it has a privacy consequence too: even within your own account, a single question can only surface a narrow, relevant slice of records, not everything at once. A bounded tool is a bounded exposure, even when the account boundary is not the thing in question.
Think of it as the difference between a locked filing cabinet and a locked filing cabinet that also only ever opens one drawer at a time. The lock is the account boundary; the single-drawer limit is the tool cap. Neither replaces the other, and together they mean a worst-case answer is wrong about a narrow slice of your own records, never wide open across all of them.
It is a useful test to apply to any AI feature bolted onto software that already held sensitive data before the feature existed: did adding a conversational layer on top require weakening anything that was already true about the underlying database, or did it simply add a narrow, read-only window onto a boundary that already held. The first answer should worry you. The second is the one worth building toward.
The plain answer, and its limit
Put simply: Farm40’s assistant is handed a read-only connection bound to your account, with no tool that accepts another account’s id, no free-form query it can write, and an ownership check applied to every row it returns — so another farm’s records are not merely withheld from it, they are unaddressable within the connection it holds. The limit stated plainly: this is a guarantee about tenant isolation specifically. It is not a substitute for reading your provider’s actual privacy and data-handling terms if what you are asking is a broader question about vendor access — the scoped connection answers “can another farm see mine,” not every question the word “privacy” could mean. Ask the second question of your provider directly, in writing, rather than assuming a scoped connection answers it by implication. For the isolation mechanism in more depth, including why a prompt-level rule would not be enough on its own, see prompt injection and farm data and the full architecture in AI for farm management.