Every security program eventually runs into the same uncomfortable truth: the most reliable way to protect data is to not move it anywhere it doesn't need to go. Controls, policies, and contractual assurances all matter, but they are mitigations layered on top of an architecture. If the architecture itself sends your most sensitive tables and your production database credentials across the public internet to a third party, you are managing risk rather than eliminating it. That distinction matters a great deal when you sit in front of an auditor, a regulator, or your own board.
This article makes a deliberately architectural argument. For a security leader evaluating analytics and business intelligence tooling, the strongest data-protection posture is not a longer vendor questionnaire — it is a deployment model where the entire platform runs inside your own infrastructure. When the application, the database it reads, and optionally even the AI engine all live within your network boundary, sensitive data and database credentials never traverse a vendor in the first place. There is no external party to trust, breach, subpoena, or misconfigure. AI Insights 365 — On-Prem Edition is built around exactly this principle, and the sections below walk through what that buys you and how to lock it down.
The Real Risk With Cloud and SaaS BI
Cloud-hosted analytics is convenient precisely because the vendor does the heavy lifting. But that convenience has a structural cost that no amount of compliance paperwork fully removes: to query your data, a SaaS BI product generally needs two things from you, and both are sensitive.
First, it needs access to your data. Either you replicate or sync your data into the vendor's environment, or the vendor's service reaches into your network to pull it. In both cases, copies of your business data — customer records, financials, health or payment information, whatever your tables contain — come to rest, or at least transit, outside your control boundary.
Second, it needs credentials to your database. To run queries, the platform must hold connection details: hostnames, usernames, and passwords or keys for systems that, in many organizations, are among the crown jewels. Those secrets now live in a vendor's secret store, governed by the vendor's key management, accessible to the vendor's operators, and exposed to the vendor's threat surface.
Each handoff expands the attack surface in ways you cannot directly observe or control:
| Exposure | What leaves your network | Why it matters |
|---|---|---|
| Data in transit | Query results, replicated tables | Interception, vendor logging, secondary processing |
| Data at rest (vendor) | Cached or stored copies | Vendor breach, insider access, legal discovery against the vendor |
| Database credentials | Connection secrets | A vendor compromise becomes a compromise of your database |
| Operational visibility | Access patterns, schema | Information disclosure even without a full breach |
None of this implies cloud vendors are careless. The point is narrower and more durable: you are now exposed to a control environment you do not own. A misconfiguration, a compromised support account, or a lawful access request directed at the vendor can put your data and credentials at risk through no failure of your own. For regulated data, data subject to residency requirements, or simply data your organization considers too sensitive to externalize, that residual risk is often the deciding factor.
How a Fully On-Prem Deployment Removes the Exposure
The on-prem model collapses the problem by removing the third party from the data path entirely. There is no vendor environment in the picture because there is no vendor in the picture at runtime. You deploy the platform inside your own network — your data center, your private cloud tenancy, your VLAN — and it operates there.
The defining property is direct connectivity: the application connects straight to your in-network databases. A query runs from a host inside your perimeter to a database inside your perimeter. Results render in a browser session that also stays inside your perimeter. At no point is a copy of your data sent to an external service, and at no point does an external service hold your database credentials.
SaaS BI (data + secrets leave your network):
[Your DB] ──creds + data──▶ [Vendor Cloud] ──▶ [User]
▲ exposure boundary you don't own
On-Prem (nothing leaves your network):
┌──────────── Your Network ─────────────┐
│ [User] ◀──▶ [AI Insights 365 App] ◀──▶ [Your DB] │
│ (optional: local AI engine) │
└────────────────────────────────────────┘
no outbound data path to any vendor
This is the architectural argument in one diagram. Because the platform is self-hosted, the question "where does our data go?" has a simple answer: nowhere it wasn't already. Data residency is satisfied by construction rather than by a clause in a contract. A vendor breach cannot expose data the vendor never held. A legal request to the vendor cannot compel data the vendor never received. You have not transferred risk to a third party; you have retained the data inside the boundary you already secure, monitor, and audit.
That said, architecture is the foundation, not the whole building. Keeping data in-network removes the external exposure, but you still want strong controls inside the boundary. That is where defense-in-depth comes in.
Defense-in-Depth Inside Your Boundary
Self-hosting is necessary but not sufficient. A platform that runs in-network should still assume that internal threats, mistakes, and over-broad access exist. AI Insights 365 — On-Prem Edition layers the following controls so that even within your perimeter, sensitive material is protected and every action is accountable.
Encrypted connection secrets, with rotatable keys
Database connection secrets are stored encrypted at rest using AES-256-CBC. The encryption key is rotatable without a service restart, so you can align key rotation with your existing cryptographic policy and incident-response runbooks without scheduling downtime. The combination matters: encryption protects the secret material on disk, and seamless rotation means a suspected key exposure can be remediated quickly rather than deferred to a maintenance window.
Least-privilege, read-only database accounts
The platform is designed to connect using least-privilege, read-only database accounts. Analytics workloads read; they do not need to write, alter schemas, or drop objects. Provisioning a dedicated read-only account for each connection means that even a worst-case compromise of the application cannot be used to mutate or destroy source data. This is the single most effective database-side control you can apply, and it costs nothing but discipline.
Constrained query execution
Beyond account privileges, query execution itself is constrained. Queries are read-only, row-limited, and sandboxed, which bounds both the blast radius of a malformed or malicious query and the volume of data any single operation can surface. Row limits also act as a practical guardrail against accidental large-scale extraction.
Scoped, time-limited share tokens
Authentication is handled with JWT. When a report is shared or embedded, access is granted through scoped, time-limited, signed embed tokens rather than broad standing credentials. A token authorizes a specific report for a specific window and then expires. There is no shared password to leak and no permanent link that outlives its purpose.
Full audit logging
Every user action is captured in a full audit log. Who viewed which report, who ran which query, who changed which setting — the record exists and stays inside your environment alongside the data it describes. For security reviews and incident investigations, a complete, in-network audit trail is often the difference between a confident answer and a guess.
Role-based access control
Access is governed by RBAC with three roles:
| Role | Typical capabilities |
|---|---|
| Admin | Manage connections, users, roles, and platform settings |
| Editor | Build and modify reports and dashboards |
| Viewer | Consume shared reports and dashboards read-only |
Mapping people to the narrowest role that fits their job keeps the privilege surface small and makes access reviews straightforward.
Enterprise identity via SSO
The platform integrates with Active Directory / Microsoft Entra ID single sign-on, so authentication rides on the identity provider you already operate. That means your existing MFA, conditional access, joiner-mover-leaver processes, and account lifecycle controls extend directly to the analytics platform. There is no parallel identity store to keep in sync and no orphaned local accounts to forget about.
Taken together, these controls implement defense-in-depth: the network boundary keeps data and credentials in, encryption protects secrets at rest, least-privilege and constrained queries limit what any actor can reach, identity and RBAC govern who gets in and as what, and audit logging records everything that happens.
Optional Air-Gapped AI
Analytics increasingly means AI — natural-language querying, narrative summaries, automated insight generation. The obvious concern is that AI features quietly reintroduce the very data-egress problem you eliminated by self-hosting, by sending prompts (which contain your data) to an external model.
AI Insights 365 — On-Prem Edition gives you a choice on this axis:
| AI option | Where inference runs | Data egress |
|---|---|---|
| Local model via Ollama | Inside your network | None — fully air-gapped |
| Cloud Azure AI Foundry | External managed service | Prompts/data sent to the service |
If your posture requires that no data ever leaves the network — including for AI inference — you can run a local model through Ollama so that prompt construction, inference, and response all happen in-network. This keeps the air-gapped property of the whole deployment intact end to end. For organizations comfortable with a managed external model, Azure AI Foundry remains available as the alternative. The key point is that the choice is yours, made deliberately, rather than an opaque default that exports your data the moment someone clicks an AI button.
How This Helps With Security Reviews and Audits
Security reviews repeatedly ask variations of the same questions: Where does the data live? Who can access it? How are credentials protected? What happens if the vendor is breached? An on-prem architecture lets you answer most of these structurally rather than defensively.
This posture supports and helps satisfy common review and audit expectations — it does not, by itself, certify you against any framework, and no honest vendor should claim otherwise. What it does is shorten the distance between your controls and the evidence reviewers want:
- Data residency / sovereignty — data stays in the location you host it; there is no cross-border transfer to a vendor to document or justify.
- Third-party / vendor risk — there is no runtime data processor to assess, because the data is never handed off.
- Access control — RBAC plus Entra/AD SSO maps cleanly to least-privilege and identity-governance expectations.
- Cryptographic controls — AES-256-CBC at rest with rotatable keys aligns with key-management requirements.
- Auditability — a complete, in-network action log provides the trail reviewers ask for.
The honest framing is "this architecture makes the answers easy and the evidence local," not "this product is certified." That framing is also the one auditors trust.
Checklist: Locking Down an On-Prem Analytics Deployment
Use the following as a practical hardening pass once the platform is deployed inside your network.
Network and hosting
- Deploy the app and its database entirely within your network boundary.
- Place the platform on a segmented VLAN/subnet with restricted ingress and egress.
- Confirm no outbound data path to any external analytics service exists.
- Terminate all sessions over TLS, including internal traffic.
Database access
- Create a dedicated read-only account per data source.
- Grant the minimum schemas/tables each report actually needs.
- Keep queries read-only, row-limited, and sandboxed.
Secrets and cryptography
- Confirm connection secrets are stored AES-256-CBC encrypted at rest.
- Schedule periodic key rotation (no restart required) into your crypto policy.
- Restrict OS- and file-level access to the host storing encrypted secrets.
Identity and access
- Integrate AD / Entra ID SSO; disable standalone local accounts where possible.
- Enforce MFA and conditional access at the identity provider.
- Assign the narrowest RBAC role (Admin / Editor / Viewer) per user.
- Review role assignments on a recurring schedule.
Sharing and AI
- Use scoped, time-limited embed tokens for shared reports; avoid standing links.
- Choose the AI mode deliberately — local Ollama for air-gapped, or Azure AI Foundry.
- If air-gapping is required, verify AI inference runs in-network via Ollama.
Monitoring and audit
- Enable and retain full audit logging of user actions.
- Forward audit logs to your SIEM for correlation and alerting.
- Periodically review access patterns and token issuance.
The Bottom Line
Most data-protection programs spend enormous effort compensating for an architecture that moves sensitive data outside the organization. The on-prem model removes the need for much of that effort by removing the movement. When the application, the database, and — if you choose — the AI engine all run inside your network, your data and your database credentials simply never leave it. There is no vendor environment to breach, no external secret store to trust, and no cross-border transfer to explain.
On top of that foundation, AES-256-CBC encryption with rotatable keys, least-privilege read-only accounts, constrained queries, JWT-based scoped embed tokens, full audit logging, RBAC, and Entra/AD SSO provide the defense-in-depth that a serious security program expects inside its own boundary. The result is a posture you can explain to an auditor in one sentence and defend with local evidence: the data is here, it stays here, and we control everything that touches it.