Last updated: June 2026
On-premise LLM database access is the practice of connecting a self-hosted large language model to internal production databases without sending data to external cloud services. As enterprises deploy AI agents for data analysis, operational automation, and decision support, the question of where that data travels — and who controls it — has become non-negotiable for regulated industries and security-conscious organisations. This guide covers why on-premise AI data access matters, the architecture options available, the security requirements that cannot be skipped, and how DreamFactory's self-hosted API gateway fits into the stack.
The default assumption for enterprise AI deployments is cloud: send queries to OpenAI, Anthropic, or Google, get answers back. For many workloads, that is fine. For a significant and growing segment, it is not:
A well-designed on-premise AI data stack has four layers:
The MCP server layer is where most implementations fail or succeed. A naive approach — giving the LLM direct database credentials — creates serious risks covered in the security section below. A governed API gateway layer is what makes the architecture enterprise-safe.
| Dimension | On-Premise | Cloud AI Service |
|---|---|---|
| Data never leaves the network | ✓ | ✗ |
| Air-gapped deployment possible | ✓ | ✗ |
| HIPAA / FedRAMP compatibility | ✓ (with controls) | Depends on BAA / authorisation |
| Operational overhead | Higher | Lower |
| Model capability (2026) | Catching up fast | Frontier models |
| Latency for internal data queries | Lower (no egress) | Higher (round-trip) |
| Egress / API costs | None | Per-token billing |
| Audit trail control | Full enterprise control | Provider-managed |
Connecting any AI agent to a production database without the following controls in place is unsafe regardless of whether the deployment is on-premise or cloud:
Each AI agent or user session should map to a specific role that limits which tables, views, and operations are accessible. A customer-service AI agent needs read access to the customer table — it should not have access to payroll, audit logs, or administrative functions. RBAC at the API gateway layer enforces this consistently across all agents without requiring per-database permission changes.
Sensitive fields — SSNs, credit card numbers, PHI, salary data — should be masked before the LLM response is constructed. Masking at the API layer means the LLM never receives raw sensitive values in its context window. This is distinct from database-level encryption: masking controls what the AI sees, not just what is stored.
Every LLM-initiated database query should produce an audit record capturing: the requesting identity, the endpoint called, the parameters passed, the response status, and a timestamp. For regulated industries, this log must be tamper-evident and retained for compliance periods. AI agents make many more queries per session than human users — audit logging must be performant enough to handle the volume.
Prompt injection attacks embed instructions in user input that cause the AI agent to perform unintended actions — including data exfiltration through crafted queries. Defences include: restricting the agent to read-only endpoints where writes are not required, validating query parameters at the API layer before execution, and using stored procedures rather than dynamic SQL where possible.
Where the use case allows, replace open-ended natural language queries with pre-defined, parameterised API calls that the LLM fills parameters into. A query like "GET /customers/{id}/orders" is far safer than "run whatever SQL you need to get customer order history." Deterministic queries are increasingly considered the gold standard for AI database access in enterprise environments.
The LLM receives database connection strings directly and generates SQL queries. This bypasses all access controls, produces no audit trail, and exposes credentials in the model's context window. It is appropriate only for development/sandbox environments with non-production data.
An MCP server sits between the LLM and the database, exposing each table as a set of typed CRUD tools the model can call by name. The API layer handles authentication and basic RBAC. This is the pattern most production on-premise deployments use in 2026. The key requirement is that the MCP server and API gateway run on-premise with no outbound connectivity.
An AI data gateway extends the MCP server pattern with enterprise-grade controls: field-level masking, rate limiting, prompt-level audit logs, identity passthrough (the database sees who the end user is, not just the service account), and policy enforcement at the API layer. This is the architecture appropriate for healthcare, financial services, government, and any environment with a defined compliance posture. See also: what CISOs need to know about LLM database access.
DreamFactory is a self-hosted API platform that auto-generates REST APIs and MCP server endpoints from any database — MySQL, PostgreSQL, SQL Server, Oracle, MongoDB, and more — without custom code. It is designed for exactly this architecture:
For enterprises evaluating on-premise AI data access, the relevant starting points are the PostgreSQL MCP server guide, the MySQL MCP server guide, and the broader AI data gateway overview. For deployment architecture in regulated environments, see air-gapped LLM data access for government and defence.
On-premise LLM database access is the practice of connecting a self-hosted large language model directly to production databases that remain inside an organisation's own infrastructure — never sending data to external cloud services. The LLM queries internal databases through a governed API or MCP server layer, receives structured responses, and uses them to answer questions or complete tasks while all data stays within the organisation's network perimeter.
Three main reasons: regulatory compliance (HIPAA, FedRAMP, GDPR, and sector-specific mandates prohibit certain data from leaving the organisation's control), data sovereignty (particularly for government and defence workloads requiring air-gapped environments), and competitive sensitivity (organisations that cannot risk training data appearing in external model outputs). On-premise deployment also eliminates egress costs and third-party data processing agreements.
MCP (Model Context Protocol) is an open standard that defines how AI agents discover and call external tools and data sources at runtime. An MCP server exposes database operations — reads, writes, stored procedures — as structured tools the LLM can call. For on-premise deployments, an MCP server runs inside the enterprise network, meaning the LLM never needs direct database credentials and all access goes through a controlled, auditable layer.
Direct LLM-to-database connections bypass access controls entirely — the model can read any table it can reach with the credentials provided. Specific risks include: prompt injection attacks that exfiltrate data through crafted queries, over-privileged access (LLMs tend to request broad permissions), unaudited queries with no log trail, and credential exposure in model context windows. The standard mitigation is an API gateway or MCP server layer that enforces RBAC, logs every query, and restricts operations to pre-approved endpoints.
Yes. DreamFactory is available as a self-hosted deployment (Docker, Kubernetes, VM) with no external call-home requirements. It can run in fully air-gapped environments with no internet connectivity. The auto-generated REST APIs, MCP server, and all governance controls operate locally. Licences can be pre-activated for air-gapped deployments. This makes it suitable for government, defence, and regulated financial services environments that prohibit outbound cloud connectivity.
Field-level masking intercepts the API response before it reaches the LLM and replaces sensitive fields — SSNs, credit card numbers, PHI — with masked values (e.g. '***-**-1234') or omits them entirely based on the requesting role. The LLM sees a structurally complete response but never receives raw sensitive values. DreamFactory applies masking rules at the API layer, so they apply consistently regardless of which AI agent or user is querying.
Any SQL or NoSQL database with a supported driver can be connected: MySQL, PostgreSQL, Microsoft SQL Server, Oracle, SQLite, MongoDB, DynamoDB, Snowflake (on-premise or private cloud), and others. DreamFactory auto-generates a REST API and MCP tool set from the database schema without custom coding, exposing tables, views, and stored procedures as typed endpoints the LLM can call by name.
A complete audit trail should capture: the identity of the requesting agent or user, the specific endpoint and parameters called, the timestamp, and the response status. DreamFactory logs every API call to a configurable audit store (local database, SIEM, or log aggregator). For AI-specific workloads, this means every LLM-initiated database read or write is traceable to a session ID, making it possible to reconstruct exactly what data an agent accessed during a given conversation.