A dashboard filter is not an access control.

For years the answer to which client can see which data was a filter on a dashboard, or a separate copy of a report per client. That worked, and it worked for a reason worth naming: the report was the only way anybody reached the data at all.

The filter was never security. It was the only door, and the door had a lock on it. Nobody had to decide whether the lock was any good because there was nothing else to try.

An agent does not use the door. It queries the tables. Every rule that lived in the reporting layer is now a rule that applies to one of several readers, which is a longer way of saying it is not a rule.

Four consequences, and the last two are the ones that catch people who thought about the first two.

• The filter is a suggestion

  A dashboard scoped to one client restricts what that dashboard shows. It says nothing whatsoever about what the table holds, and an agent asked a broad question answers from the table.

• There is no fixed set of questions

  A report has a reviewable surface. You can open it and see everything it is capable of revealing. An agent's surface is every question anybody thinks to ask it, which cannot be reviewed in advance because it does not exist yet.

• Columns you never displayed are still there

  An email address that was ingested and never put on a dashboard was invisible only because nothing rendered it. A query does not need a column rendered in order to return it.

• Aggregates leak

  Even without access to individual rows, a total over a small enough group identifies that group. Reporting tools rarely had to think about this, because the person building the report chose the groupings. Now the person asking chooses them.

In the data rather than in the tool. In practice that means one of two shapes: separate datasets per client, or rules attached to the tables themselves that apply to every reader regardless of how that reader arrived.

There is a test that settles this in about a minute, and it is worth running before any of the rest. If somebody connected an ordinary SQL client tomorrow using the same credentials the agent uses, what could they see? That answer is your access model. Everything above it is presentation.

Not the generic advice about read-only access, which is a starting condition rather than a design. These are the decisions that differ between one agent and another.

• Which identity does it act as?

  Its own, or the person asking. Acting as itself means everybody who can reach it gets the same access, which becomes the widest access anybody has. Acting as the person asking is more work to set up and is the only version that survives a second team using it.

• What is it allowed to have been asked?

  Keep the question and the query it produced, together. The answer on its own is not a record, because the answer is the part you already doubted. The pair is what lets somebody establish later what was actually looked at.

• What happens to the answer afterwards?

  An answer pasted into a shared channel has left your access model completely. This is the exposure nobody designs for, and it is the most likely one, because it requires no mistake by anybody technical.

With a report, the person who built it decided what it would reveal, once, with time to think. With an agent, the person asking decides, every time, at speed.

That moves a judgement from a few people who considered it carefully to everybody, continuously. Access rules are how that stops being a problem, and they have to be written by somebody who knows which data is sensitive for which client. That person is very rarely the person configuring the agent, and the gap between those two people is where most of this goes wrong.

Everything scopes to a client record, and the modelled tables carry that scoping, so the boundary sits in the data rather than in a dashboard somebody could bypass by querying underneath it.

The chatbot reads those same modelled tables, on your own model key, inside your own warehouse, so both the data and the answer stay where your rules apply rather than being sent somewhere to be reasoned about. A client who logs in to your portal sees only their own data, so a login is never a way into another client's rows.