{"id":7188,"date":"2026-07-01T13:02:11","date_gmt":"2026-07-01T20:02:11","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/azure-sql\/?p=7188"},"modified":"2026-07-01T13:02:11","modified_gmt":"2026-07-01T20:02:11","slug":"sql-mcp-server-obo-auth","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/azure-sql\/sql-mcp-server-obo-auth\/","title":{"rendered":"Audit Frontier AI Agents with SQL MCP Server"},"content":{"rendered":"

All modern AI solutions eventually need agents to query or mutate data in Microsoft SQL. Deciding how to do this safely, for example, how to handle NL2SQL<\/a>, will be an important choice. Next come the twins: authentication and authorization. In this article, we discuss pass-through agentic authentication with the express goal of ensuring operational logs reflect not the agent, not the MCP server, but the user. In future articles, we will discuss the broad array of authorization controls available in Data API builder (DAB) 2.0 with SQL MCP Server.<\/p>\n

There are three approaches to SQL authentication in SQL MCP Server<\/a>.<\/h4>\n

The first is a username and password. Although it is slowly waning in popularity, it remains a viable option for certain customers. In this case, the audit logs show the identity provided through the connection string, not the user invoking the operation.<\/p>\n

User -(any authentication approach)-> Agent\r\nAgent -(any authentication approach)-> MCP server\r\nMCP server -(passes username and password)-> SQL db\r\nSQL db -(logs username as operator)-> Logs<\/code><\/pre>\n
The second is managed identity (MI), which eliminates the password but produces the same logging outcome: the logs identify the application, not the user invoking the data operation.<\/p>\n
User -(any authentication approach)-> Agent\r\nAgent -(any authentication approach)-> MCP server\r\nMCP server -(passes MCP server identity)-> SQL db\r\nSQL db -(logs MCP server identity as operator)-> Logs<\/code><\/pre>\n
The third approach is On-Behalf-Of (OBO), also known as pass-through authentication, using Microsoft Entra ID. It is more sophisticated to set up, but when enabled, services exchange the incoming user token for downstream tokens, forwarding them from service to service.<\/p>\n
User -(authenticates with Microsoft Entra ID)-> Agent\r\nAgent -(forwards user token)-> MCP server\r\nMCP server -(exchanges token and connects as user)-> SQL db\r\nSQL db -(logs user as operator)-> Logs<\/code><\/pre>\n
Ultimately, Azure SQL authenticates the actual calling user, not the application, not the agent, and not the MCP server. When a query or mutation occurs in the database, the resulting audit logs identify the user who invoked the operation.<\/p>\n
Data API builder (DAB) 2.0 with SQL MCP Server OBO support<\/h3>\n
Data API builder (DAB) 2.0 with SQL MCP Server supports On-Behalf-Of (OBO) authentication for Microsoft SQL databases<\/a> using Microsoft Entra ID. When enabled, it changes your audit story for agentic apps. Instead of asking \u201cwhich service queried the database?\u201d SQL can answer \u201cwhich user caused this query?\u201d Let\u2019s take a look.<\/p>\n
Agents need accountability<\/h4>\n
AI agents can reason, plan, and call tools. But when an agent reaches into production data, the enterprise question is not only \u201cdid the agent have permission?\u201d The better question is \u201cwhose permission did the agent use?\u201d<\/p>\n
SQL MCP Server exposes SQL tables, views, and stored procedures through MCP tools. This gives agents a controlled way to interact with data without exposing the database directly. With OBO, that controlled path can also preserve the signed-in user\u2019s identity all the way to Azure SQL.<\/p>\n
Configuring OBO<\/h3>\n
OBO is configured in the DAB data source. The connection string must be a bare Azure SQL connection string. Don\u2019t include User ID<\/code>, Password<\/code>, or Authentication<\/code>. DAB injects the per-user access token when it opens the SQL connection.<\/p>\n
{\r\n  \"data-source\": {\r\n    \"database-type\": \"mssql\",\r\n    \"connection-string\": \"@env('MSSQL_CONNECTION_STRING')\",\r\n    \"user-delegated-auth\": {\r\n      \"enabled\": true,\r\n      \"provider\": \"EntraId\",\r\n      \"database-audience\": \"https:\/\/database.windows.net\"\r\n    }\r\n  }\r\n}<\/code><\/pre>\n
Because each user receives a distinct database connection, caching might be an initial concern. However, DAB has a hard configuration validation rule that makes response caching and OBO\/user-delegated authentication mutually exclusive. The validator rejects any configuration that enables both simultaneously. The OBO token cache itself is scoped per user.<\/p>\n
Validating the identity<\/h3>\n
The online documentation OBO sample<\/a> uses a small WhoAmI<\/code> view to prove the point. This view returns the identity SQL sees on the active connection.<\/p>\n
CREATE VIEW [dbo].[WhoAmI] AS\r\nSELECT SUSER_NAME() AS [UserName];<\/code><\/pre>\n
Expose it through DAB for authenticated users.<\/p>\n
{\r\n  \"WhoAmI\": {\r\n    \"source\": {\r\n      \"object\": \"dbo.WhoAmI\",\r\n      \"type\": \"view\",\r\n      \"key-fields\": [ \"UserName\" ]\r\n    },\r\n    \"rest\": {\r\n      \"enabled\": true\r\n    },\r\n    \"permissions\": [\r\n      {\r\n        \"role\": \"authenticated\",\r\n        \"actions\": [ { \"action\": \"read\" } ]\r\n      }\r\n    ]\r\n  }\r\n}<\/code><\/pre>\n
With this, an authenticated request to WhoAmI<\/code> returns the user principal<\/em> name SQL sees. In the app, the user signs in to the browser with Microsoft Entra ID, sends a bearer token to Data API builder (DAB) 2.0 with SQL MCP Server, and DAB exchanges that token for an Azure SQL token for the signed-in user.<\/p>\n
const headers = await getAuthHeaders();\r\n\r\nconst response = await fetch(`${API_URL}\/api\/WhoAmI`, {\r\n    method: \"GET\",\r\n    headers\r\n});\r\n\r\nconst payload = await response.json();\r\nconst sqlUserName = payload.value[0].UserName;\r\n\r\nconsole.log(`SQL sees this request as: ${sqlUserName}`);<\/code><\/pre>\n
The sample\u2019s UI displays the result as \u201cSQL Server sees you as: [user@example.com](mailto:user@example.com)<\/a>.\u201d The README describes the point plainly: SQL sees the real user, not a service account.<\/p>\n
What this means for MCP<\/h3>\n
<\/i>One configuration for all the endpoints<\/strong><\/p>The same DAB runtime can expose REST, GraphQL, and MCP.<\/div><\/p>\n
In the OBO sample, MCP is enabled with the \/mcp<\/code> path in the same configuration that enables Entra ID authentication and user-delegated auth.<\/p>\n
A conceptual MCP tool request can read the same WhoAmI<\/code> entity.<\/p>\n
{\r\n    \"tool\": \"read_records\",\r\n    \"arguments\": {\r\n        \"entity\": \"WhoAmI\"\r\n    }\r\n}<\/code><\/pre>\n
The agent is still using a tool. DAB is still enforcing its entity permissions. Azure SQL still authenticates the user behind the request.<\/p>\n
That is the key distinction.<\/h4>\n
The agent performs the action, but SQL records the user context that authorized the action.<\/p>\n
Auditing the result<\/h3>\n
Azure SQL auditing tracks database events and can write them to Blob storage, Event Hubs, or Log Analytics. The audit schema includes fields such as database_principal_name<\/code>, server_principal_name<\/code>, statement<\/code>, and obo_middle_tier_app_id<\/code>, which identifies the middle-tier app that connected using OBO access.<\/p>\n
In Log Analytics<\/a>, a simple query can show who SQL saw.<\/p>\n
AzureDiagnostics\r\n  | where Category == \"SQLSecurityAuditEvents\"\r\n  | where database_name_s == \"\"\r\n  | project\r\n  event_time_t,\r\n  action_name_s,\r\n  database_principal_name_s,\r\n  server_principal_name_s,\r\n  obo_middle_tier_app_id_s,\r\n  statement_s\r\n  | order by event_time_t desc<\/code><\/pre>\n
That gives you a better audit frontier for agentic systems. You can see the user, the SQL action, the statement, and the middle-tier app involved in the OBO path.<\/p>\n
Conclusion<\/h3>\n
OBO pass-through authentication makes Data API builder (DAB) 2.0 with SQL MCP Server more than a convenient bridge between agents and data. It makes the bridge accountable. For simple apps, connecting with a managed identity or service credential can be enough. For enterprise agents touching sensitive data, the database often needs to know the real caller. With SQL MCP Server and DAB OBO authentication, Azure SQL can audit the signed-in user behind the agent action. That means your agent can call tools, DAB can enforce permissions, and SQL can still answer the most important audit question: who did this<\/em>?<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"
With On-Behalf-Of authentication, SQL MCP Server lets agents access Microsoft SQL without losing the user identity behind the request. Azure SQL can audit the signed-in user who invoked the operation, not just the agent, app, or MCP server that carried it out.<\/p>\n","protected":false},"author":96788,"featured_media":6602,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[597,720],"tags":[680],"class_list":["post-7188","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-data-api-builder-2","category-sql-mcp-server-2","tag-agentic-ai"],"acf":[],"blog_post_summary":"
With On-Behalf-Of authentication, SQL MCP Server lets agents access Microsoft SQL without losing the user identity behind the request. Azure SQL can audit the signed-in user who invoked the operation, not just the agent, app, or MCP server that carried it out.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/posts\/7188","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/users\/96788"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/comments?post=7188"}],"version-history":[{"count":1,"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/posts\/7188\/revisions"}],"predecessor-version":[{"id":7203,"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/posts\/7188\/revisions\/7203"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/media\/6602"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/media?parent=7188"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/categories?post=7188"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/tags?post=7188"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}