Integrations
Data system integrations
Put policy between AI and PostgreSQL, MySQL, MongoDB, Snowflake, BigQuery and S3, so a data request is authorized before it is answered.
The control point
The destination, not the request.
A prompt filter must anticipate every phrasing. A destination list enumerates where data may go — in this estate, 2 places.
Approved sinks
2
Export nowhere
2
Where availability is real
Governing a read means knowing how the source is queried.
That is per-source work — the query shape, the classification granularity, the residency metadata a data-protection review asks for. So availability varies here, and the entries that are not ready say what specifically is missing.
- available
- Governed today, with the action vocabulary of that system.
- in progress
- Being built. Partially usable, and the gap is named on the entry.
- not yet
- Not started. Reachable only through a generic connection, if at all.
- PostgreSQL
PostgreSQL
availableReads classified per source, and writes governed as actions with their own bounds.
- MySQL
MySQL
availableSame treatment as Postgres. Classification is a property of the source, not of the engine.
- MongoDB
MongoDB
availableCollection-level classification, because a flexible schema makes field-level promises hard to keep.
- Snowflake
Snowflake
availableWarehouse reads, with the approved destinations for a result declared up front.
- Amazon S3
Amazon S3
availableDataset export, which is the action most worth having a destination list for.
- BigQuery
BigQuery
in progressReads work today; the residency metadata that a data-protection review asks for is still being wired.
- Databricks
Databricks
not yetNot started. A notebook that calls a model and writes a table is squarely in scope, and this is the gap most worth closing next.
IllustrativeAn illustrative catalogue for the OpsAI sample estate. 5 of 7 listed sources are governed today.
Why the destination
Two approved destinations, not an unbounded list of forbidden phrasings.
This is the whole design. A filter on the request has to anticipate every way somebody might ask; a list of destinations enumerates every place an answer may land. One of those is a losing arms race and the other is a short list you can read out loud.
In the sample estate the entire approved-destination list is warehouse.eu and warehouse.in. Every read of every governed source may be written to one of those or to nothing at all.
2 of 9 sources have no approved destination whatsoever, which is the strictest setting: readable into a decision, never written out. That is the right configuration for contracts and payroll, and it is expressible because the control is on the destination rather than on the wording.
Sources
9
classified and governed
Approved destinations
2
in total
Export nowhere
2
read-only into a decision
Residencies
3
the figure a review asks for
What is recorded per source
Classification, residency, destinations and who holds a read grant.
Four facts, and the last one is the least expected. A source nobody reads is worth surfacing: either it is correctly untouched, or something is reaching it by a route OpsAI cannot see.
Data sources in the sample estate
9 sources · 3 holding directly identifying data| Source | Classification | Residency | May be written to | Readers |
|---|---|---|---|---|
| Order historyPostgres · database | pii.indirect | ap-south-1 | warehouse.in | 3 |
| General ledgerZoho Books · application | financial | ap-south-1 | warehouse.in | 1 |
| Vendor masterNetSuite · application | financial | us-east-1 | warehouse.in | 1 |
| CRM accountsSalesforce · application | pii.indirect | eu-west-1 | warehouse.eu | 2 |
| Support ticketsZendesk · application | pii.direct | ap-south-1 | warehouse.in | 2 |
| Executed contractsBox · documents | pii.direct | eu-west-1 | nowhere | 1 |
| Product analyticsAmazon S3 · warehouse | internal | ap-south-1 | warehouse.inwarehouse.eu | 1 |
| Policy handbookBox · knowledge base | internal | eu-west-1 | warehouse.inwarehouse.eu | 3 |
| Payroll recordsWorkday · application | pii.direct | eu-west-1 | nowhere | — |
IllustrativeIllustrative sources for the OpsAI sample estate, in a fictional company.
One source has no reader
Not an error. It is one of the two most useful rows in the register, because it has exactly two explanations and they are very different: either nothing needs that data and the grant was never issued, or something is reaching it another way and the register is describing an intention rather than reality.
- Payroll recordspii.direct
- Workday · eu-west-1. No AI system holds a read grant, and nothing may be written out of it in any case.
- Which one is it
- Discovery answers this by reading the egress proxy and the IdP grants rather than by asking. A source with no reader and observed traffic is the clearest signal in the estate.
Where to start
Write down the destinations before you write down the rules.
The destination list is short, checkable and does most of the work. Classification matters, but a source with nowhere to be written is already governed regardless of how it is classified.