Jarvis security: using an AI tool safely with company data.

Anyone pasting company information into an AI tool for the first time usually asks themselves one broad question: is this safe. That is a question nobody can honestly answer with yes, because safety is not a property of a product but the outcome of a number of choices. So it helps to cut the question into the four places where company data in practice leaks or becomes useless.

The first place is the boundary. If the knowledge of several organisations lives in the same space and only a filter in the query decides who sees what, then one mistake in that filter is enough. The boundary does not belong in the query but underneath it: every server query is bound to one organisation, and a parameter from the client cannot stretch that binding.

The second place is permissions. In many AI setups the assistant gets access to everything the user can reach, and that is almost always more than the task needs. A search that fits perfectly in meaning can still be off limits for this person, this role or this task. Which means authorisation has to come before relevance, not after it.

The third place is the outgoing action. The moment an AI may email, publish or pay, the risk moves from reading to doing. A button with the word approve on it is then not enough: that button is only worth something if it points at a fixed version of the content, if the server checks whether you were allowed to press it, and if one press does not accidentally produce two emails.

The fourth place is the memory itself. A system that remembers but cannot explain where something came from turns inaccuracy into policy. A sentence such as quotes are valid for thirty days sounds clear, but without source, scope, version and validity nobody knows whether it still holds and who was allowed to change it.

The rest of this page walks through those four points, plus what is not finished at our end. If you want to see the workings in outline first, read how Jarvis works. If you want the choices behind the design, those are in the knowledge section.

An organisation brain is attractive because it adds experience up. What we learn at one setup about source quality, roles or approvals, the next one does not have to work out again. And that is exactly where the risk sits: if adding up means all knowledge ends up in the same context, then every new customer inherits a piece of the previous one.

So we separate two things that often get thrown on one heap. The super brain holds method: how do you classify a source, which evidence belongs to an incident, what does an approval look like that holds up. The client brain holds content: your people, prices, templates, processes, documents and decisions. Those two do not have the same owner and so they should not share the same boundary.

The permitted flow

A general improvement does not go live directly in your brain here. It becomes a proposal with source, version, purpose, scope and impact. You, or the administrator you name, assess that proposal. Only after agreement does anything change, and the audit trail keeps which version was approved. That is slower than pushing it through automatically, and that is the intention: a product improvement that overwrites your pricing policy or your working method without anybody seeing it is not an improvement.

The forbidden detour

The other direction is shut. Raw customer documents, prompts or output are not copied automatically to the super brain under the label learning. Anonymised analysis also needs a real purpose and data minimisation, because unique text can still be traced back to an organisation. There is no free exchange between client brains and there is no training on customer content.

What this means for an AI worker

A managed AI worker does not have to start from zero: the general framework for roles, approvals, source quality and logging comes from the super brain. The working method specific to your organisation is then loaded only into your own brain. So a new setup benefits from product experience without inheriting knowledge from another customer. We deliver those AI workers under Mansotti, the company of which TheSEO is the trading name, from 950 euro per month excluding VAT; what that involves is on the AI worker page (NL). The core promise there is the same as here: output stays a draft until a person agrees.

The full working out of this choice is in super brain and client brains.

Least privilege. Users, AI workers and connectors get the scopes their task needs and no more. In the interface you see in advance which scopes a connection asks for, so giving permission is a choice and not a formality. For owners and administrators, two factor authentication is policy.

Keys do not belong in content. Tokens and keys of connected services belong in a secret store, and never in prompts, logs, exports or in the code that goes to the browser. This is one of the points where the production control still has to be demonstrated; it stands further down as a release gate.

Support on permission. Looking along from a distance is a separate workflow here, not a by-product of administration. Access is temporary, tied to a purpose, approved and checkable afterwards. A support worker does not get a permanent key to every customer environment. For the emergencies where deeper access is needed anyway, the starting point is that two people are involved.

Your own AI subscriptions stay yours. You connect Claude, ChatGPT and Codex through your existing subscription. Jarvis does not sell a hidden bundle of tokens and puts no meter on your prompts. That is not only a pricing choice but a data choice: the relationship with the model supplier stays yours, on your terms. Why we make that choice is in why Jarvis does not charge per AI question.

What exactly happens when a service is connected, and which suppliers are involved, is in the sub-processor list. That list applies, is public and states per party what it is used for and where the data is processed, including the country. What holds in your case is in the annex to your data processing agreement.

We keep policy and evidence in a classification of our own: which measures exist, who owns them, which evidence belongs to them and how often it is tested. That is useful, even without an auditor. We do not attach somebody else's standard to it, because putting that name next to it adds nothing to the evidence and does suggest something that is not there.

But it is emphatically not the same as certification, and we will not sell Jarvis as certified for as long as there is no valid external certification with a clear scope. Putting certification logos on a sales page that do not exist is exactly the kind of promise that makes a trust page useless.

What there is: a public register with the documents, and a status per document. Anyone looking today for a supplier who can produce a certificate now knows that it is not here. That is a more honest answer than a page that dodges the question.

The best order is not: connect first, then work out what happens to your data. Walk through the demo first, read the pieces in the trust centre that count for you, and ask the questions those pieces do not answer. We answer architecture, privacy and contract questions with the current document version alongside, including when the answer is that something is not finished.

If you want to feel what a shared company memory does in the meantime, start with the company brain template (NL). It is free, works in the AI you already use and costs you nothing more than an hour of filling in. If it feels right and the file starts to pinch, the conversation about Jarvis gets a good deal more concrete.