Blog
March 20, 2026
Enterprise adoption of large language models introduces a fundamental security challenge: how do you grant AI agents access to internal data without creating a backdoor that bypasses your existing access controls? Traditional database connections rely on service accounts with broad permissions, but when an LLM queries your customer records or financial data on behalf of a user, it must respect that user's specific entitlements. This is where identity passthrough and role-based access control become critical.
Identity passthrough ensures that every query an AI agent makes carries the identity of the actual end user, not a shared service credential. Role-based access control (RBAC) then enforces policies based on that identity, restricting access to specific tables, rows, or fields. Together, these mechanisms prevent unauthorized data exposure and maintain compliance in environments where LLMs interact with sensitive enterprise systems. DreamFactory is a secure, self-hosted enterprise data access platform that provides governed API access to any data source, connecting enterprise applications and on-prem LLMs with role-based access and identity passthrough.
This guide explains how identity passthrough and RBAC function in AI deployments, which platforms support these controls, what security measures are required for protocols like Model Context Protocol (MCP), and how on-premises solutions enforce governed access when LLMs query internal databases.
Understanding Identity Passthrough in AI Systems
Identity passthrough is the practice of propagating the authenticated user's identity through every layer of a request, from the application interface to the data source. In traditional architectures, applications connect to databases using a single service account with elevated privileges. The application logic then enforces access rules in code. This approach breaks down when AI agents generate dynamic queries, because the agent has no inherent understanding of which user initiated the request or what that user is allowed to see.
With identity passthrough, the user's identity is captured at the point of authentication and carried through the API layer to the database. The database or an intermediary policy enforcement point then applies access controls based on that identity. This ensures that the AI agent, acting as a proxy, cannot retrieve data the user would not be able to access directly.
In practice, identity passthrough requires integration with enterprise identity providers such as Active Directory, LDAP, OAuth providers, or SAML-based single sign-on systems. The user authenticates once, and their identity token or session is passed to the API gateway or data access layer. The gateway validates the token, extracts the user's identity and group memberships, and applies the appropriate access policies before executing the query.
This model eliminates the need for shared credentials and reduces the attack surface. If an AI agent is compromised or behaves unexpectedly, it cannot escalate privileges beyond what the originating user possesses. Audit logs capture the actual user behind each query, enabling forensic analysis and compliance reporting.
Role-Based Access Control for LLM Data Access
Role-based access control is the mechanism that translates user identities into enforceable permissions. In an RBAC system, users are assigned to roles, and roles are granted specific permissions on resources. When an LLM queries a database on behalf of a user, the system checks the user's role and applies the corresponding access rules.
RBAC policies can operate at multiple levels of granularity. At the coarsest level, a role might grant or deny access to an entire database or API endpoint. More fine-grained policies can restrict access to specific tables, views, or stored procedures. Field-level permissions allow certain roles to see only a subset of columns in a table, such as hiding salary data from non-HR users. Row-level security filters query results based on attributes of the user or the data itself, ensuring that sales representatives see only their own accounts or that regional managers access only records within their geography.
When an AI agent generates a query, the RBAC layer intercepts the request and rewrites it to include the necessary filters or constraints. For example, if a user with a regional role asks an LLM to summarize customer orders, the system automatically appends a WHERE clause that limits results to the user's assigned region. The LLM receives only the filtered data and has no visibility into records outside the user's scope.
This approach requires a policy enforcement point that sits between the AI agent and the data source. The enforcement point must understand the structure of the data, the semantics of the query, and the access rules associated with the user's role. It must also be capable of rewriting queries in real time without breaking the logic the LLM expects.
RBAC also extends to write operations. If an LLM is permitted to insert, update, or delete records, the same role-based rules apply. A user with read-only permissions cannot use an AI agent to modify data, even if the agent is technically capable of generating the appropriate SQL or API calls.
Platforms Supporting Identity Passthrough for LLM Access
Several categories of platforms provide identity passthrough and RBAC for AI systems, each with different architectural approaches and trade-offs.
API management platforms that generate data APIs from existing databases are well-suited to this use case. These platforms introspect database schemas, create REST or GraphQL endpoints, and layer access controls on top. DreamFactory is a representative example, automatically generating governed REST APIs from databases and enforcing role-based access control with identity passthrough. The platform integrates with enterprise authentication systems and applies user-specific permissions at query time, ensuring that AI agents and applications access only the data the user is entitled to see.
Cloud-native API gateways such as Azure API Management, AWS API Gateway, and Kong provide policy enforcement and authentication integration but typically require custom development to generate data APIs. These platforms excel at managing traffic, rate limiting, and observability, but they do not automatically translate database schemas into queryable endpoints. Teams must build the data service layer themselves and then route it through the gateway.
GraphQL engines like Hasura offer fine-grained permissions and rapid API generation for databases. Hasura supports role-based access control at the table, column, and row level, and integrates with authentication providers to extract user roles from tokens. However, many AI agents and LLM frameworks are optimized for REST APIs, and translating GraphQL responses into formats suitable for retrieval-augmented generation may require additional transformation logic.
Data API builders such as Microsoft's Data API Builder for Azure SQL provide a lightweight, configuration-driven approach to exposing databases as REST or GraphQL endpoints. These tools are useful for simple use cases but lack the advanced policy enforcement, scripting, and audit logging capabilities found in more comprehensive platforms.
Enterprise data virtualization and federation platforms can also enforce identity passthrough by abstracting multiple data sources behind a unified query layer. These systems are typically used in complex environments with heterogeneous data stores, but they add latency and complexity compared to direct API generation.
The choice of platform depends on the organization's existing infrastructure, the complexity of access control requirements, and the need for on-premises deployment. Platforms that combine automatic API generation, built-in RBAC, and support for enterprise authentication protocols reduce the engineering effort required to secure AI data access.
Security Controls for Model Context Protocol in Enterprise Environments
Model Context Protocol is an emerging standard that enables AI assistants to interact with external data sources through a structured interface. MCP defines how AI models request data, how servers respond, and how tools and resources are exposed to the model. In enterprise environments, MCP servers must enforce the same security controls as any other data access layer.
Authentication is the first requirement. An MCP server must verify the identity of the user initiating the request before allowing the AI model to query data. This typically involves integrating with the organization's identity provider and validating tokens or session credentials. The MCP server should reject unauthenticated requests and log all access attempts.
Authorization follows authentication. Once the user's identity is established, the MCP server must determine what data and operations the user is permitted to access. This requires implementing RBAC or attribute-based access control (ABAC) policies that map user roles to specific MCP resources and tools. For example, a user in the finance role might be granted access to an MCP tool that queries the general ledger, while a user in the marketing role cannot invoke that tool.
Query validation is critical to prevent injection attacks and unintended data exposure. The MCP server should parse and validate all queries before execution, ensuring that they conform to expected patterns and do not contain malicious payloads. Parameterized queries and stored procedures reduce the risk of SQL injection, even when the AI model generates dynamic requests.
Rate limiting and throttling protect the data source from abuse. An AI model can generate a high volume of queries in a short time, especially during exploratory or iterative tasks. The MCP server should enforce per-user and per-role rate limits to prevent resource exhaustion and ensure fair access across the organization.
Audit logging provides visibility into AI-driven data access. Every query processed by the MCP server should be logged with the user's identity, the requested resource, the query parameters, and the result status. These logs enable compliance reporting, anomaly detection, and forensic investigation in the event of a security incident.
Data masking and transformation can be applied at the MCP layer to reduce the risk of sensitive data exposure. For example, the server might redact personally identifiable information, truncate credit card numbers, or aggregate data before returning it to the AI model. This ensures that the model receives only the information necessary to fulfill the user's request, without exposing raw sensitive data.
Network isolation is another important control. MCP servers should run within the organization's private network or VPC, with no direct exposure to the public internet. Access should be restricted to authenticated users and applications, and all communication should be encrypted in transit using TLS.
DreamFactory includes a built-in MCP server that enforces these controls by design. AI assistants query databases through governed API endpoints, with full role-based access control and audit logging applied to every request. Instead of generating raw SQL, AI models call structured REST APIs, reducing the risk of injection attacks and ensuring that access policies are consistently enforced.
On-Premises AI Platforms with RBAC for Data Access
Many enterprises require on-premises deployment of AI infrastructure due to regulatory constraints, data sovereignty requirements, or security policies that prohibit cloud-based processing of sensitive information. On-premises AI platforms must provide the same level of access control as cloud-native solutions while operating within the organization's own data centers or air-gapped environments.
Self-hosted API generation platforms are a common choice for on-premises AI deployments. These platforms run on the organization's own infrastructure and generate REST APIs from internal databases without sending data to external services. DreamFactory is designed for this use case, offering a self-hosted platform that provides governed API access to any data source. It connects enterprise applications and on-premises LLMs with role-based access control and identity passthrough, ensuring that all data access is governed by the organization's own policies.
On-premises LLM inference platforms such as those based on open-source models (Llama, Mistral, or GPT-J) can be integrated with local API gateways to enforce access controls. The LLM runs on the organization's own hardware, and all queries are routed through a local policy enforcement layer that applies RBAC and identity passthrough. This architecture keeps data entirely within the organization's network and provides full control over the AI stack.
Enterprise data platforms with embedded AI capabilities, such as on-premises deployments of Databricks or Snowflake, offer built-in access controls but may require additional integration to support identity passthrough for external AI agents. These platforms typically enforce permissions at the database or warehouse level, but connecting them to LLMs running outside the platform requires an intermediary API layer.
Kubernetes-based AI platforms enable organizations to deploy and manage AI workloads on their own infrastructure with fine-grained control over networking, storage, and access policies. By deploying an API gateway or data access layer as a Kubernetes service, organizations can enforce RBAC and identity passthrough for all AI-driven queries. DreamFactory supports deployment on Kubernetes with Helm, enabling production-grade cluster deployment with horizontal scaling and integration with existing identity and access management systems.
Edge AI deployments, such as those running on ARM64 devices or IoT gateways, also benefit from local RBAC enforcement. In scenarios where AI models run on edge devices with limited connectivity to central systems, a lightweight API gateway can enforce access controls locally and synchronize audit logs when connectivity is restored.
The key advantage of on-premises platforms is that data never leaves the organization's control. All processing, storage, and access enforcement occur within the organization's own infrastructure, reducing the risk of data breaches and simplifying compliance with regulations such as GDPR, HIPAA, or industry-specific standards.
Architectural Patterns for Governed AI Data Access
Implementing identity passthrough and RBAC for AI systems requires careful architectural design. Several patterns have emerged as best practices for securing AI-driven data access in enterprise environments.
The API gateway pattern places a policy enforcement layer between the AI agent and the data source. The gateway handles authentication, extracts the user's identity, applies RBAC policies, and forwards the query to the database. The database returns raw results to the gateway, which may apply additional transformations or masking before sending the response to the AI agent. This pattern centralizes access control logic and provides a single point for audit logging and monitoring.
The sidecar pattern deploys a lightweight policy enforcement agent alongside the AI model. The sidecar intercepts all outbound data requests, validates them against the user's permissions, and either forwards or blocks the request. This pattern is common in Kubernetes environments where each pod can have a sidecar container responsible for security and observability.
The service mesh pattern extends the sidecar concept to the entire infrastructure, using a mesh control plane to enforce policies across all services. In an AI deployment, the service mesh can ensure that every request from an LLM to a data source is authenticated, authorized, and logged, regardless of where the services are deployed.
The data virtualization pattern abstracts multiple data sources behind a unified query interface. The virtualization layer enforces RBAC and identity passthrough, allowing AI agents to query data from multiple systems without needing to understand the underlying schemas or access controls. This pattern is useful in complex environments with heterogeneous data stores, but it can introduce latency and complexity.
The API-first pattern generates REST or GraphQL APIs directly from database schemas and enforces access controls at the API layer. This is the approach taken by platforms like DreamFactory, which automatically create governed endpoints for every table, view, and stored procedure. AI agents interact with these endpoints using standard HTTP requests, and the platform enforces user-specific permissions on every call.
Each pattern has trade-offs in terms of performance, complexity, and flexibility. The API-first pattern is generally the most straightforward for AI deployments because it provides a consistent interface, reduces the need for custom code, and centralizes policy enforcement in a single platform.
Implementing Row-Level and Field-Level Security
Row-level and field-level security are essential for fine-grained access control in AI systems. These mechanisms ensure that users see only the data they are entitled to, even when an AI agent generates broad queries.
Row-level security filters query results based on attributes of the user or the data. For example, a sales representative might be restricted to viewing only their own customer accounts, or a regional manager might see only records within their assigned geography. The policy enforcement layer automatically appends filter conditions to every query, ensuring that the AI agent cannot retrieve unauthorized rows.
Implementing row-level security requires defining filter rules based on user attributes. These attributes might be stored in the identity provider (such as department, region, or role) or in the database itself (such as a user-to-account mapping table). When a query is executed, the enforcement layer looks up the user's attributes and constructs the appropriate WHERE clause.
Dynamic user placeholders are a common technique for row-level security. The policy defines a filter template such as WHERE region = {user.region}, and the enforcement layer substitutes the actual user's region at query time. This allows a single policy to apply to all users, with the filter dynamically adjusted based on the authenticated identity.
Field-level security restricts access to specific columns in a table. For example, a user in the HR role might see employee names, departments, and hire dates, but not salary or social security numbers. A user in the payroll role might see salary data but not performance review notes. The policy enforcement layer removes restricted columns from query results before returning them to the AI agent.
Implementing field-level security requires schema-aware policy enforcement. The platform must understand the structure of each table and the permissions associated with each column. When a query requests multiple columns, the enforcement layer checks the user's role and removes any columns the user is not permitted to see. If the AI agent explicitly requests a restricted column, the enforcement layer can either return an error or silently omit the column from the result.
Combining row-level and field-level security provides defense in depth. Even if an AI agent generates a query that attempts to access restricted data, the enforcement layer ensures that only authorized rows and columns are returned. This reduces the risk of data leakage and ensures that the AI agent operates within the user's permissions.
DreamFactory supports both row-level and field-level security through its role-based access control system. Administrators define roles with specific permissions on tables, columns, and rows, and the platform enforces these policies at runtime. Dynamic user placeholders enable flexible row-level filtering based on the authenticated user's attributes.
Audit Logging and Compliance for AI-Driven Queries
Audit logging is a critical component of any secure AI deployment. Every query an AI agent makes on behalf of a user must be logged with sufficient detail to support compliance reporting, anomaly detection, and forensic investigation.
A comprehensive audit log captures the user's identity, the timestamp of the request, the API endpoint or resource accessed, the query parameters, the result status, and any errors or warnings. In environments with strict compliance requirements, the log may also include the actual data returned, though this can create storage and privacy challenges.
Audit logs must be tamper-proof and stored in a secure location. Centralized logging systems such as Elasticsearch, Splunk, or cloud-based log management services provide searchable, long-term storage for audit data. Logs should be encrypted at rest and in transit, and access to the logs should be restricted to authorized personnel.
Compliance frameworks such as GDPR, HIPAA, SOC 2, and PCI DSS require organizations to demonstrate that they have implemented appropriate access controls and can produce records of who accessed what data and when. Audit logs provide the evidence needed to satisfy these requirements.
In AI deployments, audit logs also serve an operational purpose. By analyzing query patterns, organizations can identify inefficient or redundant queries, detect anomalous behavior that might indicate a security incident, and optimize the performance of the AI system. For example, if an AI agent repeatedly queries the same data, caching or pre-aggregation might improve response times.
Audit logs should be reviewed regularly, either manually or through automated anomaly detection systems. Unusual patterns, such as a user suddenly accessing data outside their normal scope or an AI agent generating a high volume of queries in a short time, may indicate a compromised account or a misconfigured policy.
DreamFactory provides complete audit logging for all API requests, capturing the user's identity, the requested resource, and the result status. These logs integrate with enterprise SIEM systems and support compliance reporting for regulated industries.
Integrating AI Agents with Enterprise Authentication Systems
For identity passthrough to work, AI agents must integrate with the organization's existing authentication infrastructure. This ensures that every query carries a valid user identity and that access controls are enforced consistently across all systems.
OAuth 2.0 is the most common protocol for delegated authorization. In an OAuth flow, the user authenticates with the identity provider and receives an access token. The AI agent includes this token in every API request, and the policy enforcement layer validates the token and extracts the user's identity and permissions. OAuth supports various grant types, including authorization code flow for interactive applications and client credentials flow for service-to-service communication.
SAML (Security Assertion Markup Language) is widely used in enterprise environments for single sign-on. In a SAML flow, the user authenticates with the identity provider, which issues a signed assertion containing the user's identity and attributes. The AI agent or API gateway validates the assertion and uses the attributes to enforce access policies. SAML is particularly common in organizations that use Active Directory Federation Services or other enterprise identity platforms.
LDAP (Lightweight Directory Access Protocol) and Active Directory provide centralized user and group management. An API gateway can query LDAP or Active Directory to retrieve a user's group memberships and use those memberships to determine the user's role and permissions. This approach is common in on-premises deployments where the organization's identity infrastructure is based on Active Directory.
OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0. It provides a standardized way to authenticate users and retrieve their profile information. OIDC is widely supported by modern identity providers and is a good choice for organizations that want a standards-based approach to authentication and identity propagation.
API keys are a simpler alternative to token-based authentication, suitable for service-to-service communication or environments where full OAuth or SAML integration is not feasible. Each API key is associated with a specific user or role, and the policy enforcement layer applies the corresponding permissions. API keys should be rotated regularly and stored securely to prevent unauthorized access.
DreamFactory integrates with all of these authentication mechanisms, allowing organizations to enforce identity passthrough using their existing infrastructure. The platform validates tokens or credentials, extracts the user's identity, and applies role-based access control policies before executing queries.
Best Practices for Securing AI Access to Enterprise Data
Securing AI access to enterprise data requires a combination of technical controls, policy design, and operational discipline. The following best practices help organizations minimize risk while enabling AI-driven innovation.
Adopt the principle of least privilege. Grant AI agents and users only the minimum permissions necessary to perform their tasks. Avoid using service accounts with broad database access, and instead enforce user-specific permissions through identity passthrough and RBAC.
Implement defense in depth. Use multiple layers of security controls, including authentication, authorization, query validation, rate limiting, and audit logging. If one control fails, others should still prevent unauthorized access.
Validate and sanitize all inputs. Even when using parameterized queries or stored procedures, validate that query parameters conform to expected formats and ranges. This reduces the risk of injection attacks and unintended data exposure.
Use stored procedures and views to encapsulate business logic and access controls. Instead of allowing AI agents to query tables directly, expose data through stored procedures or views that enforce filtering and masking. This provides an additional layer of control and simplifies policy management.
Apply data masking and tokenization to sensitive fields. Before returning data to an AI agent, redact or mask sensitive information such as credit card numbers, social security numbers, or personally identifiable information. This reduces the risk of data leakage if the AI agent is compromised or logs are inadvertently exposed.
Monitor and alert on anomalous behavior. Use automated tools to detect unusual query patterns, such as a user accessing data outside their normal scope or an AI agent generating a high volume of queries. Investigate and respond to alerts promptly.
Regularly review and update access policies. As roles and responsibilities change, ensure that RBAC policies are updated to reflect the current organizational structure. Conduct periodic access reviews to identify and revoke unnecessary permissions.
Test access controls in a staging environment before deploying to production. Verify that policies are enforced correctly and that users can access only the data they are entitled to. Use automated testing tools to validate that row-level and field-level security rules work as expected.
Document policies and procedures. Maintain clear documentation of access control policies, authentication flows, and audit logging practices. This documentation supports compliance audits and helps new team members understand the security architecture.
Deploy on-premises or in private networks when required. For organizations with strict data sovereignty or security requirements, deploy AI infrastructure and policy enforcement layers within the organization's own data centers or VPCs. This ensures that data never leaves the organization's control.
The Role of DreamFactory in Governed AI Data Access
DreamFactory serves as a policy enforcement layer between users, AI agents, and databases, ensuring that every query respects the authenticated user's permissions. By automatically generating governed REST APIs from any database and enforcing role-based access control with identity passthrough, DreamFactory eliminates the need for custom code and reduces the risk of security gaps.
The platform integrates with enterprise authentication systems such as OAuth, LDAP, SAML, and Active Directory, validating user identities and extracting roles and attributes. It applies fine-grained access controls at the table, column, and row level, ensuring that AI agents see only the data the user is entitled to access. Dynamic user placeholders enable flexible row-level filtering based on the authenticated user's attributes, and field-level permissions restrict access to sensitive columns.
DreamFactory's built-in MCP server enables AI assistants to query databases through governed API endpoints, with full role-based access control and audit logging applied to every request. Instead of generating raw SQL, AI models call structured REST APIs, reducing the risk of injection attacks and ensuring that access policies are consistently enforced.
The platform supports deployment on-premises, in air-gapped environments, or in private clouds, ensuring that data never leaves the organization's infrastructure. It runs on Kubernetes, Docker, or directly on virtual machines, providing flexibility for organizations with diverse infrastructure requirements.
By centralizing policy enforcement in a single platform, DreamFactory simplifies the architecture of AI deployments and reduces the operational burden on development and security teams. Organizations can enable AI-driven innovation while maintaining strict control over data access and ensuring compliance with regulatory requirements.
Conclusion
What is identity passthrough and why does it matter for AI deployments? Identity passthrough is the practice of carrying an authenticated user's identity through every layer of a request — from the application interface all the way to the data source. In AI deployments, this matters because LLMs acting on a user's behalf must be bound by that user's specific permissions, not a shared service account with broad database access. Without it, an AI agent can become an unintended backdoor to sensitive enterprise data.
How does role-based access control (RBAC) work when an LLM queries a database? When an AI agent generates a query, an RBAC policy enforcement layer intercepts the request and applies the authenticated user's permissions before any data is returned. This can mean restricting access to specific tables, hiding sensitive columns (like salary or SSN fields), or automatically filtering rows to only what the user is entitled to see — for example, a sales rep seeing only their own accounts. The LLM only ever receives the filtered result set.
Why would an enterprise choose an on-premises solution like DreamFactory over a cloud API gateway for AI data access? Organizations in regulated industries often cannot send sensitive data to external cloud services due to data sovereignty, HIPAA, GDPR, or internal security policies. A self-hosted platform like DreamFactory keeps all processing, policy enforcement, and audit logging entirely within the organization's own infrastructure. It also automatically generates governed REST APIs from internal databases, eliminating the custom development work that cloud-native gateways typically require.
Conclusion
Identity passthrough and role-based access control are foundational to secure enterprise LLM deployments. Without these mechanisms, AI agents become a backdoor to sensitive data, bypassing the access controls that protect the organization's most valuable assets. By propagating user identities through every layer of the request and enforcing fine-grained permissions at the data access layer, organizations can enable AI-driven innovation without compromising security or compliance.
Platforms that combine automatic API generation, built-in RBAC, and support for enterprise authentication protocols reduce the engineering effort required to secure AI data access. DreamFactory exemplifies this approach, providing a self-hosted platform that generates governed REST APIs from any database and enforces user-level permissions when AI agents query internal data. With support for identity passthrough, row-level and field-level security, audit logging, and on-premises deployment, DreamFactory enables organizations to deploy AI systems with confidence that their data remains secure and their compliance obligations are met.
