Connecting Data Sources Behind Your Firewall

Connecting data is the first step toward putting AI Insights 365 to work inside your own environment. Because the platform is self-hosted on Windows and runs entirely within your infrastructure, every connection you create stays under your control — credentials are encrypted at rest, queries run read-only inside a sandbox, and traffic to on-premises databases never leaves your trusted network or touches the public internet.

This reference walks through the full connector catalog, explains how the platform connects directly to databases inside your network, and shows the end-to-end flow for adding a Microsoft SQL Server source. It closes with guidance on testing, schema introspection, credential storage, the safety model, and troubleshooting.

The Connector Catalog at a Glance

AI Insights 365 ships with more than 30 built-in connectors. Every connector follows the same lifecycle regardless of the underlying technology:

1. Validate the connection parameters you supply.
2. Introspect the schema — enumerate available tables and columns.
3. Run read-only, sandboxed queries with enforced row limits.

Credentials for every connector are encrypted at rest using AES-256, so the secrets you enter never sit in plain text on disk.

It helps to think of the catalog in five groups. The table below summarizes the categories, representative sources, and the typical connection approach.

Relational databases

The relational group covers the transactional and operational systems most teams report against: SQL Server, PostgreSQL, MySQL, SQLite, and Oracle. These are frequently the systems that live deepest inside your network. Because AI Insights 365 is deployed inside that same network, it reaches these databases directly — there is no external hop, no broker, and no need to open inbound ports to the internet. The platform simply opens a standard database connection across your LAN, exactly as any other internal application would.

Cloud data warehouses

For analytical workloads at scale, AI Insights 365 connects to Snowflake, Databricks, BigQuery, Redshift, and Athena. These platforms are designed for read-heavy analytics, so they pair naturally with the platform's read-only query model. Use a dedicated, least-privilege role for the connection wherever the warehouse supports one.

Files and storage

Not all data lives in a database. The platform ingests CSV, Excel, and JSON uploads, can pull a file by URL, and reads from a shared folder over SMB. Cloud file stores — OneDrive, Dropbox, and Google Sheets — round out this group, which is ideal for reference data, manual extracts, and spreadsheets maintained by business teams.

SaaS and APIs

Operational systems of record are covered through first-class connectors for Salesforce, HubSpot, Microsoft Dynamics, Google Analytics, and MongoDB Atlas, plus a generic REST API connector for anything else that speaks HTTP and returns structured data.

Power BI

If your organization already invested in Power BI semantic models, you can connect to them directly. This lets you layer natural-language querying and AI auto-reports on top of governed models you have already built — no rebuild required.

How the Platform Reaches a Relational Source

The single most important thing to understand when connecting a relational source is how the platform reaches it — and the answer is refreshingly simple. Because AI Insights 365 runs entirely inside your own infrastructure, it connects directly to your databases over your internal network. There is no external relay and no third-party component sitting between the platform and your data. You supply host, port, database, and credentials, and the platform opens a connection just like any other trusted application on the same network.

This direct model is what makes the deployment so easy to reason about for security and compliance:

• Same trusted network. When the database lives on the same LAN or in the same VPC/subnet as the platform, connect directly by supplying host, port, database, and credentials. Traffic stays entirely inside your perimeter and never crosses the public internet.
• Different subnet, region, or data center. When a SQL Server or PostgreSQL database (or any other source) sits in a separate network segment, region, or cloud, the right answer is private connectivity — peer the networks, establish a site-to-site or point-to-site VPN, or use a private link/private endpoint so the platform host can reach the database over a private route. The connection is still direct from the application's perspective; you are simply providing a secure network path between the two trusted zones.
• Never expose database ports publicly. Whatever the topology, you should never publish a database port to the open internet to make a connection work. Keep 1433, 5432, and friends reachable only from within your private network, and let private networking — not a public IP — bridge any gap between segments.

Use this quick test:

If the database is reachable on your internal network, connect directly with a least-privilege, read-only account. If it lives in a different subnet, region, or cloud, put a private network path (peering, private link, or VPN) between the platform and the database first — then connect directly across that private route. In no case should the database be exposed to the public internet.

Step by Step: Connecting a SQL Server Source

The following walkthrough adds a SQL Server datasource. The same shape applies to other relational connectors.

1. Gather connection details

Collect the following before you begin:

• Server host and instance (and port, default 1433)
• Database name
• A read-only login — a dedicated service account is strongly recommended
• Confirmation that the platform host can reach the server over your internal network (directly, or via a private network path if the database is in another segment or region)

2. Create the datasource

In your workspace, open Data Sources → New Connection and choose SQL Server. Enter the parameters:

Host:       sql-prod-01.internal.example.com
Port:       1433
Database:   SalesDW
Auth:       SQL login (read-only service account)
Username:   svc_aiinsights_ro
Password:   ********

The host should resolve to a private address on your network. If the SQL Server lives in a different subnet or region, make sure a private route (network peering, private endpoint, or VPN) is already in place so sql-prod-01.internal.example.com is reachable from the platform host — do not route the connection over a public IP.

3. Validate the connection

Click Test Connection. The platform validates the parameters end to end — confirming network reachability, authentication, and database access. A successful test means the read-only login can reach the target database; a failure returns a specific error you can act on (see Troubleshooting).

4. Introspect the schema

Once validated, run Introspect Schema. The connector enumerates the available tables and columns so they are available for natural-language-to-SQL, transforms, and report building. Schema introspection is itself a read-only operation — it inspects metadata without modifying anything.

5. Save

On save, the credentials are encrypted at rest with AES-256. The datasource now appears in the workspace and is ready for querying, charting, and scheduled reports.

How Queries Stay Safe

The connector model is built security-first. Three controls work together:

• Read-only by design. Connectors execute read-only queries. The platform does not issue writes against your sources through the standard query path.
• Sandboxed execution with row limits. Queries run inside a sandbox with enforced row limits, which protects source systems from runaway scans and keeps result sets bounded.
• Least-privilege credentials. Because connections are read-only, you can — and should — provision logins that only have SELECT rights on the objects you intend to expose.

A representative read-only grant for the SQL Server example above:

-- Create a least-privilege, read-only login for AI Insights 365
CREATE LOGIN svc_aiinsights_ro WITH PASSWORD = '<strong-password>';
USE SalesDW;
CREATE USER svc_aiinsights_ro FOR LOGIN svc_aiinsights_ro;
-- Grant read-only access at the database scope
ALTER ROLE db_datareader ADD MEMBER svc_aiinsights_ro;

This pairing — read-only platform behavior plus a read-only account — gives you defense in depth. Even if a query were malformed, the account simply has no rights to change data.

Secure Credential Storage

Every credential you enter, for every connector, is encrypted at rest using AES-256. Because the entire platform runs inside your own network, those encrypted secrets never leave your security boundary in the first place — there is no external service that ever sees them, and database traffic never traverses the public internet. The credentials are decrypted only in memory on your own host at the moment a connection is opened, and only query results flow back into the platform.

Because the entire deployment is self-hosted on Windows, you retain full custody of the encryption boundary, the host, and the network paths between the platform and each source. Combined with least-privilege, read-only logins, this means even the credentials for your most sensitive systems stay firmly within your control.

Troubleshooting Connectivity

When Test Connection fails, the error message points at the layer that broke. Work through these common causes:

Authentication failures

• Confirm the username and password, and that the login is enabled.
• Verify the account has at least read access to the target database.
• For SQL Server, confirm the instance allows the authentication mode you selected.

Network and reachability

• Check that the host and port are correct and reachable from the platform host.
• Confirm firewall rules permit the connection on the database port — from inside your network only. You should never need to open a database port to the public internet to make a connection succeed.
• If the database lives in a different subnet, region, or cloud, verify that your private network path (peering, private endpoint, or VPN) is up and that DNS resolves the host to its private address from the platform host.
• For named SQL Server instances, verify the instance name and that the SQL Server Browser service is available if you rely on dynamic ports.

Private-network and segmentation issues

• If the platform host and the database are in different segments, confirm the route between them is established and healthy — a down VPN tunnel or a missing peering/route is the most common cause of an otherwise-valid connection timing out.
• Verify name resolution: the host should resolve to a private address reachable across the segment, not a public one.
• Check that network ACLs, security groups, or local firewalls along the private path allow traffic on the database port between the two zones.

Schema introspection returns nothing

• Confirm the read-only account can see the schema objects; a login with no SELECT rights may connect but enumerate no tables.
• Check that you are pointed at the correct database and schema.

Row limits or truncated results

• Result sets are intentionally bounded by row limits in the sandbox. If you expect more rows than you see, this is the safety model working as designed — refine the query or aggregate at the source rather than pulling raw detail.

Connector Behavior in Detail

It is worth understanding what happens under the hood when you add any connector, because the same three-stage contract applies whether you are wiring up Oracle, Snowflake, a Google Sheet, or a REST endpoint.

Validation

When you click Test Connection, the connector does more than ping a host. It exercises the actual authentication path and confirms that the supplied account can open the target database, bucket, model, or API. For warehouse connectors such as Snowflake, Databricks, BigQuery, Redshift, and Athena, validation confirms the outbound credentials and the target account or project are reachable. For SaaS connectors like Salesforce, HubSpot, and Dynamics, validation confirms the API key or OAuth grant is accepted. A green result means the connection is genuinely usable, not merely that a port is open.

Introspection

After validation, introspection enumerates the schema the account can see — tables and columns for relational and warehouse sources, sheets and ranges for spreadsheet sources, fields for SaaS objects, and the response shape for REST endpoints. This metadata is what powers natural-language-to-SQL and the no-code transform builder: the AI needs to know your column names to translate a plain-English question into a correct query. If introspection returns fewer objects than you expect, the cause is almost always a permissions gap on the read-only account rather than a platform issue.

Execution

Every query the platform issues against a saved datasource is read-only and sandboxed, with row limits enforced. This is true uniformly across the catalog. The practical effect is that you can hand a datasource to a Viewer in a workspace with confidence that no interactive question, however phrased, can mutate the source system.

Choosing the right connector for files

The file and storage group deserves a brief note because there are several overlapping options:

• Direct upload (CSV, Excel, JSON) is best for one-time or infrequent reference data.
• File-by-URL suits files published at a stable address that updates over time.
• Shared folder (SMB) is the right choice for files dropped on a network share by an upstream process.
• OneDrive, Dropbox, and Google Sheets fit data that business teams maintain in cloud productivity tools.

Pick the option that matches how the file is produced and refreshed, not just where it currently sits, so your reports stay current without manual re-uploads.

Next Steps

With a validated datasource and introspected schema, you can move on to building. Point natural-language-to-SQL at the new source, generate AI auto-reports, design dashboards from 72+ chart types, schedule email reports, or apply no-code transforms — all governed by your workspace's RBAC roles and captured in audit logs.

For sensitive relational systems, the model is straightforward: keep the database inside your private network, connect directly with a dedicated read-only account, and bridge any segment or region boundary with private networking rather than a public endpoint. For everything else, the direct connectors get you from connection to insight in a handful of clicks, with read-only safety and AES-256 credential encryption applied uniformly across the entire catalog.