Connectors that bring permissions with the data.
A connector that reads everything with one admin account is a liability in an AI system. Data.co connectors run in your network, authenticate with credentials Control holds, and carry source permissions, labels, and version information forward so every downstream decision has what it needs.
What the connector framework is built to reach.
Representative systems by category. Availability of a specific connector is confirmed per deployment during scoping.
| Category | Representative systems | Typical patterns |
|---|---|---|
| Databases + warehouses | PostgreSQL, SQL Server, Oracle, MySQL, Snowflake | Query in place, index selected text columns, CDC where supported |
| Documents + files | SharePoint, network file shares, Google Drive, Box | Index with source permissions, scheduled sync |
| Business systems | ERP, CRM, ticketing, accounting | Governed tools, index records and attachments |
| Healthcare | EHR systems, practice management, clearinghouse files | Index with PHI labels, governed lookups |
| Storage | S3-compatible object storage, Azure Blob, NFS | Index documents, scheduled sync |
| APIs + events | REST APIs, webhooks, message queues | Event-driven sync, governed tools |
What every connector is required to do.
These are properties of the framework, not optional features of individual connectors.
- Run inside the customer network
- Read credentials from the runtime secret store
- Carry source permissions with every record or chunk
- Hand content to classification before it is indexed
- Record source version and sync job for lineage
- Respect source rate limits and maintenance windows
- Report health and sync status locally
- Pass every write through an enforcement point
Declared, versioned, reviewable.
Connector configuration lives alongside policies in Git. Secrets are references, never values, so a pull request never contains a credential.
Illustrative example · final API surface documented in /docs
Read by default. Writes are governed actions.
Most connectors only need read access, and that is how they are configured unless you choose otherwise. When an agent needs to write, such as creating a ticket or updating a record, the write goes through an enforcement point and is evaluated by the policy engine like any other action, including approval requirements.
That keeps the connector from becoming a side door. An agent cannot get write access to a system simply because a connector exists for it.
The hard part of a connector is not reading the data.
Reading rows or files is the easy part of any connector. The difficult part is translating a source system's permission model faithfully: nested groups, inherited folder permissions, broken inheritance on single items, sharing links, row-level rules enforced in application code, and service accounts that see more than any person does. A connector that gets this wrong produces an AI system that answers questions with content the asker could never open directly.
Data.co connectors are built to read permissions at the same granularity the source enforces them and to store them with each record or chunk, so retrieval can filter before generation. Where a source's model cannot be represented faithfully, for example because access is decided inside application logic, the safer pattern is usually a governed tool that queries through the application as the requesting identity rather than an index. Mismatches between stored and source permissions are surfaced in connector status rather than silently ignored.
What a connector is designed to do when something goes wrong.
| Situation | Designed behavior | Where it shows up |
|---|---|---|
| Source unreachable | The run stops and resumes from its last checkpoint on the next attempt; existing content stays as of the last successful sync | Connector status and catalog sync state |
| Credential expired or revoked | Reads stop; nothing falls back to a broader credential | Connector status, for the owning team to rotate |
| Rate limit reached | Requests slow to the configured ceiling rather than failing the source | Sync duration and lag |
| Schema or collection changes | New fields and collections are profiled and flagged for label review before retrieval | Catalog review queue |
| Permissions cannot be read | Content is not made retrievable without its permissions | Connector status and ACL mismatch counts |
Questions to ask about any AI data connector.
- Does it run inside our network, or stage data through a vendor service?
- Which credential does it use, and can that credential be scoped to read-only?
- At what granularity does it carry source permissions?
- Are permissions re-checked at query time or only copied at ingest?
- How are deletes in the source reflected in the index?
- Is content classified before it becomes retrievable?
- Can every write it performs be held for approval?
Questions buyers ask
Is there a list of generally available connectors?
Not a public one yet. The product is early, so we review your systems during scoping and confirm which connectors are available, which need work, and what that work involves.
Can we build our own connectors?
Custom and legacy systems are common in the environments we target. We discuss options for systems outside the standard categories during scoping, including exposing them as governed MCP tools.
How are connector credentials protected?
Credentials are stored encrypted in the runtime's secret store inside your environment. Configuration files reference them by name, and models and agents never receive them.
What network access do connectors need?
Only access from the connector runtime to the source systems inside your network. Connectors do not need outbound internet access.
What if the source system's permissions are wrong?
Connectors carry permissions as they are, so existing over-sharing becomes visible rather than fixed. The catalog helps find broadly shared sensitive content, and policies can restrict AI access further than the source does.
Can a connector use a read-only account?
Yes, and that is the recommended default. Read-only credentials limit the damage if configuration is wrong, and writes, when you need them, go through enforcement points as governed actions.
See it against your own use case.
A 30-minute technical walkthrough, policy simulation on your scenarios, and a deployment recommendation for on-prem, private cloud, or hybrid.