Give the agent its own identity and a set of views, one per capability, rather than a login to the warehouse. Mask personal fields the capability does not need, hold any request to export results or reach new data, make revocation a single switch, and log every query with the rows it returned and the capability it served.
What does warehouse read access involve, and who owns it?
A data warehouse holds the history of the business in one place: transactions, customers, products, operations. That is why agents want it and why read access is not harmless. An agent that can read everything can repeat it to the wrong person, combine fields that were kept apart for a reason, or copy it into a prompt sent to a model provider.
The data owner for each domain decides what the agent may see. The platform or data engineering team builds the views and the identity. The process owner for the agent states which capability needs which data, and why. Nobody should grant access "for now" while the capability is worked out. The principles behind this are covered in how to give an AI agent least-privilege access.
How do you grant the access, step by step?
- Person, process owner: list the agent's capabilities and the questions each must answer. "Explain a variance in monthly card spend by region" needs aggregated spend by region and month. It does not need card numbers or names.
- Person, data owners: approve the data per capability. Each domain owner signs off the tables, columns and row filters for each capability. Evidence: an approval per view.
- Platform team: create a dedicated identity for the agent. Not a shared service account, and not a person's credentials. Evidence: an identity tied to one agent.
- Platform team: build a view per capability. Rows filtered to what the capability needs; columns limited; personal fields masked or removed unless approved. Evidence: view definitions under version control.
- Platform team: grant read on those views only. No access to base tables, no rights to create objects, no write rights of any kind. Evidence: the identity's grants, exported and reviewed.
- Agent, depth 1: answers questions through the views. Each query is tagged with the capability it serves.
- Platform: holds anything outside the views. A request to read a new table, export a result set, or join across domains is held for the data owner. Evidence: held verdicts with the requested scope.
- Platform: wires revocation. One switch removes all of the agent's grants. A lapsed certificate or a failed certification run triggers it automatically for the affected capability.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| List questions | Nothing | none | Process owner states needs |
| Approve data | Nothing | none | Data owners sign off per view |
| Create identity and views | Nothing | none | Platform team builds and reviews |
| Answer | Queries approved views | 1 | Nothing within the views |
| Reach further | Requests new data or export | held | Data owner approves or refuses |
| Revoke | Nothing | none | Owner or platform removes access |
Which controls keep read access safe, and what evidence do they leave?
Per-capability views. A single view for the whole agent grows until it equals the warehouse. Separate views keep each capability's reach visible. Evidence: one view per capability, each with an owner.
Masking at the source. If a field is not needed, the agent should never receive it, rather than receive it and be told not to repeat it. Evidence: masked columns in the view definition.
Result size limits. A capability that answers aggregate questions does not need ten thousand rows of customer records. Cap the rows returned. Evidence: refused or truncated queries with the cap recorded.
Held exports. Moving results out of the warehouse, into a file, an email or another system, is a different act from reading them. Hold it. Evidence: held verdicts and the approver's decision.
Revocation tied to certification. Access is part of the agent's authority, so it should expire with the certificate. Evidence: revocation events matching certificate lapses.
Query log. Every query, the view it touched, the rows returned and the capability tag. Evidence: the log itself, retained with the verdict record.
What should you measure?
- Rows returned per query, by capability. Spikes suggest the agent is fetching more than its question needs.
- Held requests for new data. A steady stream means the views are too narrow or the capability is drifting.
- Personal fields reaching the agent. This should match what data owners approved and nothing more.
- Time to revoke in a drill. Test it before you need it.
- Unused views. Access nobody uses should be removed.
Where does it usually go wrong?
The agent reuses a BI service account. It inherits access built for dashboards, which is usually wide. Give it its own identity.
Read is treated as safe by default. Read access to customer data carries privacy duties under data protection law whatever the agent does with it. The case for and against broad customer access is argued in whether a bank's agent should have read access to all customer accounts.
Views are built for convenience. One wide view "to save time" undoes the scoping.
Access outlives the agent. An agent is retired or rebuilt and its grants remain.
Reading and changing get confused. Some agents need to see more than they may change, and that is fine if the two are scoped separately. See why finance agents need read access to more than they can change, and for a related system, read access to your general ledger.
Where Pryme fits
In Pryme, warehouse read access is granted per capability and checked at each query as part of the agent's bounds. Facts drawn from the warehouse arrive stamped with their source, a held verdict covers any reach beyond the approved views, and a failed certification run drops the agent to read-only the same day. The governed agentic operating system guide sets out the whole model.
Questions people ask
Should the agent query live data or a copy?
A curated copy or a set of views is safer for most capabilities, because you control its shape. Live access to operational systems is a separate decision with its own owner.
Can the agent see personal data at all?
Only where a capability needs it and the data owner has approved it, with a lawful basis in place. Many analytical questions can be answered with aggregated or masked data.
How often should grants be reviewed?
At every certificate renewal at least, and whenever the agent's brief changes. A grant that no capability uses should be removed at the next review.