Working safely with data and AI: guarantees you can check
Before any AI model gets near the client records, the privacy officer at Meerwijk Care Group asks one question: what exactly does the model see? A promise in a sales deck is not an answer. Neither is an instruction in a prompt.
Plainwater AI answers with enforcement at the gateway, not with good intentions. Every guarantee on this page is an automated test that runs again with every change to the platform.
Updated .
What does an agent never get its hands on?
An agent never receives a model provider key or a customer database password. It starts with a one-time bootstrap code and uses that to register with the platform gateway.
Mila, the data engineer at Meerwijk, connects the reporting database. The password is stored encrypted, under a key that applies to that one source only. From then on the screen shows a fingerprint and a timestamp, never the secret itself.
- Isolated containers. Every agent runs in its own container. Outbound traffic only reaches addresses on an allowlist.
- No keys in the environment. The agent process environment is built from a fixed list, and a provider key is not on it.
- The gateway does the work. Reading data, calling a model and writing all go through the platform, which checks every request.
What does the AI model see of your data?
The model sees what the customer allows per source, and by default that is metadata and counts only. Rows and business values do not leave in that mode, and tests with marker values prove it.
Ruben, the application manager, picks one of three modes per source. The stricter of customer rule and source rule always wins, so a source can never be more open than the customer.
On top of that, table and column names reach the model as pseudonyms. The client table becomes something like t_0056 for the AI, and the platform translates the answer back for Ruben.
| Mode | What the model receives | When to choose it |
|---|---|---|
| Metrics only | Metadata, counts, statistics; counts below ten shown as "<10" | The default, for any source with sensitive data |
| Encrypted values | Every cell a stable token: joins and counts work, the value stays hidden | Analysis where the AI needs to connect records |
| Open | Literal values | Only on sources the customer explicitly designates |
How is every model request checked?
Every request to a model gets exactly one policy decision, and a refused request never reaches the model provider. The decision checks the allowed model, the budget and the customer's rules.
A customer with real customer data only runs with pseudonymisation switched on. Without it the agent does not start, and if a source is added mid-task, the platform checks every tool call again.
So the rules do not live in a prompt a model could ignore. They live in the gateway, out of the model's reach.
Can you look back at what happened?
Yes: every prompt and answer is stored encrypted with AES-256-GCM, and people with the right permission can read it back. Every such read is itself recorded.
The audit trail is an append-only hash chain. An hourly anchor binds the chains together, so removing a piece visibly breaks it.
- Guidelines per customer. Meerwijk records the rules for tasks, and every task remembers which version applied when it started.
- Automated audit. The platform checks tasks against those rules afterwards.
- Human needed. Anything that cannot be checked automatically is flagged for a person, never counted as a pass.
Who may do what, and who is watching?
Permissions come from the platform database, never from the request, and nobody can raise their own permissions. Not even an administrator.
Access to another customer returns a 404, so the platform does not even reveal that the customer exists. HTML an agent builds runs on a separate domain, never inside the app.
A security monitor looks for patterns: probing, night-time work with no history, a wave of deletions or a budget burning fast. Such a pattern becomes an alert in the app. Usage and credits are append-only and capped per customer.
Where it stops
The platform guards what it passes on itself, and that is where the guarantee ends. If a customer sets a source to open, literal values from that source reach the chosen model.
When you work with your own AI tool over MCP, the model runs outside the platform. The rules still apply at the tool layer, but what your tool does with an answer falls under your own subscription. That is why local sessions are off by default per customer.
Pseudonymisation catches names the platform knows. Free text a person types into a conversation falls under the terms of the chosen model.
Frequently asked questions
Does Plainwater AI send rows from my database to an AI model?
Not in the default mode. Then only metadata, counts and statistics reach the model. Rows or values only go along when the customer chooses a more open mode for a source.
What is the difference between a rule in the prompt and a rule in the gateway?
A rule in the prompt is a request to the model, which it can ignore. A rule in the gateway is enforced before the request reaches the model.
Can I see what an agent sent to the model?
Yes. Prompts and answers are stored encrypted and can be read back by people with the right permission. Every read is logged.
What happens if someone tries to reach another customer?
They get a 404. The refusal is recorded, and a pattern of such attempts becomes an alert.
Are these guarantees actually tested?
Yes. The guarantees on this page are automated tests that run with every platform change, including marker values that must never appear in an answer.