Identity Passthrough for AI: Why Your LLM Needs to Know Who's Asking

When a user asks your AI assistant a question, who actually runs the database query?

In many enterprise AI deployments, the query doesn’t run as the user at all. It runs through a shared service identity—meaning the user’s permissions, roles, and audit context get lost the moment their request enters the AI layer.

That one architectural detail creates a cascade of issues: over-broad data access, weak audit trails, and compliance risk. And it’s one of the biggest reasons teams hesitate to deploy AI on top of real enterprise systems.

The Identity Problem in AI Systems

Here’s a common scenario:

Alice (a sales rep) asks: “Show me Q4 revenue for my accounts.”

The AI agent translates that request into a database query—but when it’s time to execute, the system has to choose one thing:

What identity is used to access the data?

In practice, many teams rely on approaches like these:

None of these maintain Alice's identity through to the data layer.

What Identity Passthrough Actually Means

Identity passthrough means the AI system doesn’t become the identity. It acts on behalf of the authenticated user—so permissions, row-level security, and audit logs still apply.

DreamFactory makes this possible by validating the user’s token on every request and enforcing access controls at the API layer before any query reaches the database.

When Alice asks her question:

-She signs in normally

-The AI agent uses her session/token when calling the data API

-DreamFactory validates her access and applies the right policies

-The database returns only the rows and fields Alice is authorized to see

-The audit trail reflects Alice—not a shared service account

The query doesn’t just run. It runs as Alice.

Why This Matters

Proper Data Access

Without identity passthrough, your AI either:

• Returns data users shouldn't see (security risk)
• Requires complex application-level filtering (error-prone)
• Shows generic results instead of personalized data (poor UX)

With identity passthrough, database-level security handles authorization automatically. Row-level security, column masking, and permission boundaries work exactly as designed.

Meaningful Audit Trails

Compliance requires knowing who accessed what data. When every AI query runs through a shared account, your audit logs show:

2026-01-22 14:32:15 | service_account | SELECT * FROM customers
2026-01-22 14:32:18 | service_account | SELECT * FROM orders
2026-01-22 14:32:22 | service_account | SELECT * FROM financial_records

Useless for compliance. Useless for incident response. Useless for understanding data access patterns.

With identity passthrough:

2026-01-22 14:32:15 | alice.sales | SELECT * FROM customers WHERE rep_id='alice'
2026-01-22 14:32:18 | bob.finance | SELECT * FROM orders WHERE region='EMEA'
2026-01-22 14:32:22 | carol.analyst | SELECT * FROM financial_records (anonymized view)

Now you can answer: "What data did Alice access last month?"

Blast Radius Containment

When something goes wrong—and in production, something always goes wrong—identity passthrough limits the damage.

A compromised session can only access data the user was authorized to see. A misbehaving AI agent can only query within the user's permission boundaries. An accidental data exposure is limited to one user's access rights.

Contrast this with shared service accounts where any exploit potentially exposes everything.

Implementation Patterns

Pattern 1: Token Forwarding

The AI application receives the user's authentication token and forwards it with API calls.

# User authenticates, application receives JWT
user_token = request.headers.get('Authorization')

# AI generates query
query_params = ai_agent.build_query(user_question)

# Call DreamFactory with user's token
response = requests.get(
    f"{DREAMFACTORY_URL}/api/v2/db/_table/orders",
    headers={"Authorization": user_token},
    params=query_params
)

The database query runs with whatever permissions the user's token grants.

Pattern 2: Delegation Tokens

The AI system exchanges the user's credentials for a scoped delegation token.

# Exchange user token for scoped delegation token
delegation_token = dreamfactory.get_delegation_token(
    user_token=user_token,
    scopes=["read:customers", "read:orders"]
)

# Use delegation token for AI operations
response = requests.get(
    f"{DREAMFACTORY_URL}/api/v2/db/_table/orders",
    headers={"Authorization": delegation_token},
    params=query_params
)

This pattern allows limiting AI operations to specific scopes even within the user's broader permissions.

Pattern 3: Impersonation with Audit

For batch or scheduled AI operations, the system impersonates users while maintaining a clear audit trail.

# Service account impersonates specific user
response = requests.get(
    f"{DREAMFACTORY_URL}/api/v2/db/_table/orders",
    headers={
        "Authorization": f"Bearer {service_token}",
        "X-DreamFactory-User-Id": "alice@company.com"
    },
    params=query_params
)

The audit log shows both the service account and the impersonated user, maintaining accountability.

Integration with Enterprise Identity

Identity passthrough requires integration with existing identity infrastructure:

Active Directory / LDAP

• User authenticates against directory
• Group memberships translate to database roles
• Password policies and MFA apply normally

SAML / OAuth / OIDC

• SSO experience preserved
• Identity attributes flow through tokens
• Session management handled by IdP

Database Native Auth

• Direct database user mapping
• Database grants determine access
• No translation layer required

DreamFactory supports all these patterns, translating enterprise identity into database-level authorization.

Common Objections

"Service accounts are simpler"

Initially, yes. But service accounts require application-level permission checking, which means:

• Every query needs permission logic in application code
• Every new feature needs security review
• Every bug is a potential security hole
• Audit trails require custom logging

Identity passthrough moves authorization to the database where it belongs.

"Our database doesn't support row-level security"

Many databases do: PostgreSQL, Oracle, SQL Server, Snowflake. For those that don't, DreamFactory can enforce row-level filtering at the API layer based on user identity.

"It's too complex for our use case"

If your AI system accesses any data that varies by user permission, you need some form of identity handling. The question is whether you build it yourself or use a platform that provides it.

The Trust Equation

Enterprise AI adoption depends on trust. Stakeholders need confidence that:

• AI systems respect existing security boundaries
• Data access can be audited and explained
• Unauthorized access is prevented by design
• Compliance requirements are met

Identity passthrough provides this confidence by extending proven identity infrastructure into AI systems rather than bypassing it.

Conclusion

The identity of the user asking a question should determine what data the AI can access to answer it. This seems obvious, yet most enterprise AI architectures ignore user identity entirely once requests reach the AI layer.

Identity passthrough solves this by maintaining user context through AI-generated queries, enabling proper authorization, meaningful audit trails, and contained blast radius for security incidents.

It's not just a technical pattern—it's the foundation for trustworthy enterprise AI.

Frequently Asked Questions

How does DreamFactory implement identity passthrough for AI applications?

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. When AI applications make API calls, they can include user authentication tokens (JWT, OAuth, SAML assertions) that DreamFactory validates and uses to determine database access rights. The user's identity flows through to the database layer, ensuring queries respect user-level permissions and audit logs reflect the actual requesting user.

Can identity passthrough work with existing database security?

Yes. Identity passthrough is designed to work with, not replace, existing database security. If your database has row-level security, column masking, or user-specific grants, identity passthrough ensures those controls apply to AI-generated queries. DreamFactory translates enterprise identity (AD groups, SAML attributes, OAuth scopes) into database-level authorization, so your existing security investments remain effective.

What happens if the AI needs broader access than the user has?

This is a design choice. Options include: (1) Deny access—the AI only sees what the user sees, which is the safest default. (2) Escalate with approval—certain AI operations can request elevated access through a workflow. (3) Anonymized access—the AI can query aggregate or anonymized data that doesn't require user-level permissions. (4) Separate AI roles—define AI-specific roles that have read access to broader data while still maintaining audit trails. The right approach depends on your security requirements and use case.

Build AI systems that respect enterprise identity. Explore DreamFactory's identity passthrough capabilities.