Gen AI apps become far more useful once they can query your database, but that is also where the biggest security risk appears. Many prototypes connect the model to the data through one shared service account, so every user can reach everything the app can reach, and a single prompt injection can expose data that user was never allowed to see.

This session shows how to fix that by building user authentication into the data path from the start. We will cover how to carry the signed-in user’s identity from the front end through the agent to the database, so each query runs with that user’s permissions. We will also look at why authorization must live in the tools and the data layer rather than in the prompt, how to use short-lived delegated credentials instead of shared secrets, and how to log who asked for what so actions are auditable.

Through a practical architecture and a walkthrough of common failure cases, including cross-user data leaks and prompt injection through retrieved content, you will see what to build, what to test, and what to avoid.

You will leave with a clear pattern you can apply to your own gen AI apps, whether you use agents, retrieval or direct database tools.

Key takeaways :
Why a shared service account is the most common security mistake in gen AI apps
How to propagate user identity from the app to the database so each query uses the user’s own permissions
Why the prompt is never a security boundary, and where to enforce authorization instead
How to test for cross-user data leakage and prompt injection
How to add audit logging for who accessed what, through which agent

Gen AI apps that query databases often run on one shared account, so any user, or any injected prompt, can reach everything. Learn how to carry each user’s identity through the agent to the database, enforce permissions in the data layer, and audit every access.