Data access per source
Not every source is equally sensitive. A database with product codes calls for different rules than a payroll system. That is why you set data access per source: you choose a mode, and that mode determines what goes from that source to an AI model.
The three modes
Metrics only
The AI sees structure, counts, statistics and metadata. No rows, no individual values, no business data.
That sounds limited, but a lot of work can be done this way: finding missing keys, null percentages per column, checking uniqueness, tracking down slow queries, giving index advice, mapping dependencies.
Counts below ten become "<10". That way no individual can be inferred from a count.
This is the default.
Encrypted values
The AI gets rows, but every cell is a stable token. The same value always gives the same token. That lets the model count, group and join tables without ever seeing the real value.
Example: in the customer name column, "De Vries Bakery" becomes v_8f3a everywhere. The model can work
out that v_8f3a is the customer with the highest revenue. Your screen shows the real name.
Open
The AI gets literal values. This mode exists for sources where that is justified, for example public reference data or a test database without real people.
Open never applies by itself. The customer designates every open source separately in its ground rules. If a source is not listed there, a request for open values is refused. The platform does not silently fall back to masking, because then the agent would not know what it is reading.
| Metrics only | Encrypted values | Open | |
|---|---|---|---|
| Structure and statistics | ✅ | ✅ | ✅ |
| Rows | — | as tokens | literal |
| Count, group, join | via aggregates | ✅ | ✅ |
| Value visible to the model | never | never | yes |
| Condition | none | none | source designated by customer |
Two locks: customer and source
The mode exists in two places: in the customer's ground rules and on the source itself. The stricter of the two applies.
- If the customer is on encrypted values and the source on open, encrypted values applies.
- If the customer is on open and the source on metrics only, metrics only applies.
A source is therefore always a ceiling and never a widening. You can set a sensitive source stricter than the rest, but you cannot set a source more permissive than the customer allows.
Who changes what
A consultant sets the mode on the source. The platform immediately writes a new version of the ground rules, so you can always see when which mode applied and who chose it.
Exceptions per table or column
Within a source you can refine further. A few examples:
- Always hide name columns (first name, last name, email), even when the source is on encrypted values.
- Suppress a column with free-text remarks.
- Treat a column with customer numbers more strictly than the rest of the table.
A column rule beats a table rule, and a table rule beats the rule of the source. The platform can make a suggestion based on the column names. That suggestion is a list for a human: nothing is applied until you tick it and save.
A separate mode for people
What a person sees in a dashboard is different from what a model sees. That is why every source also has its own mode for dashboards: off, aggregates or rows. It is separate from the mode for the model. See Dashboards.
Free SQL
An agent can run free SQL on a disposable copy. On a real source that is only possible if the source has been released for it, with a reason and an accountable person. Even then the mode of the source applies, and the platform refuses when in doubt: an unknown name, a value that cannot be decrypted, or sorting on a masked column.