# 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. :::accent 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](/dashboards/dashboards). ## Free SQL An agent can run free SQL on a [disposable copy](/concepten/sandbox). 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. ## See also - [Pseudonymisation](/concepten/pseudonimisering) - [Work modes](/concepten/werkmodi) - [Ground rules](/beheer/spelregels)