The Security Case Against Text-to-SQL \u2014 and the Governed API Pattern That Replaces It
\nPaper: “Beyond Text-to-SQL: An Agentic LLM System for Enterprise Analytics”
\narXiv: 2605.21027
\nPublished: May 2026
\nResearchers: Gundeep Singh, Parsa Kavehzadeh, Jing Xia, Xue-Yong Fu, Julien Bouvier Tremblay, Md Tahmid Rahman Laskar, Vincent Lum, Shashi Bhushan TN
\nThe morning article on this paper focused on what Chief Data Officers and Heads of Business Intelligence should build next \u2014 the architecture and strategy of governed API orchestration. This article addresses a more urgent audience: the Chief Information Security Officer, the compliance officer, and the internal auditor.
\nBecause the same architecture that delivers 92 percent task success on enterprise analytics also solves a security problem that has quietly worried every CISO who has been asked to approve an LLM data query tool. The problem is simple: every Text-to-SQL system needs direct database access to do its job. Direct database access bypasses every access control, audit trail, and business rule that protects enterprise data.
\nThe paper documents the gap empirically. Traditional Text-to-SQL systems achieve 18 percent task success on real enterprise analytics tasks \u2014 not because the SQL is wrong, but because the system cannot navigate permissions, governance, and organizational context. The 18 percent failure rate is not a model problem. It is a security problem that has been miscast as a software engineering problem.
\nDialpad’s Analytic Agent replaces direct database access with governed API orchestration \u2014 and in doing so, creates something that has not existed in enterprise AI analytics: an auditable, permission-controlled, retry-aware query pipeline that security teams can actually approve.<\/p>\n
Why This Paper Matters for Security and Compliance Leaders
\nEvery enterprise deploying AI for internal analytics confronts the same tension. The business wants democratized data access \u2014 let product managers, marketing teams, and operations staff ask questions in plain English and get answers from the data warehouse. Security teams want controlled, auditable, permission-aware data access. These two objectives have appeared incompatible.
\nText-to-SQL systems resolve the tension by ignoring security. They request direct read access to the database. They hope the LLM only queries approved tables. They produce no audit trail of what the LLM actually queried, against which tables, with what filters. For a CISO, approving a Text-to-SQL deployment means approving a black box with database access and no governance layer.
\nThis is why Text-to-SQL has failed in enterprise. Not because the SQL is wrong. Because CISOs, compliance officers, and internal auditors say no.
\nThe paper’s contribution is proving that the tension is false. Governed API orchestration delivers better analytics outcomes (92 percent vs 18 percent) while simultaneously solving every security concern that kills Text-to-SQL deployments.
\nPermission validation happens before data access, not after. The paper’s architecture validates user permissions at Stage 2 \u2014 before the system makes any API call. If the user does not have permission to see data for the target team or department, the system stops. It does not query. It does not return partial data. It does not silently return empty results. It denies the request explicitly and returns an explanation to the user.
\nEvery query produces an audit trail. Because the system routes all queries through governed APIs, every query is logged at the API layer. Who asked. What they asked. Which endpoint it hit. Whether it succeeded or failed. What data was returned. A compliance officer can audit any query in the system. A Text-to-SQL system with direct database access cannot provide this trail because the query hits the database directly \u2014 there is no intermediary that logs what happened.
\nRetry logic is not just a reliability feature \u2014 it is a security feature. The paper’s retry loop (Stage 4 back to Stage 3) handles failed API calls by correcting parameters and re-executing. From a security perspective, the retry loop means the system never needs escalated permissions. If an API call fails because the user lacks access, the system does not escalate privileges \u2014 it reports the denial and, in some cases, falls back to a simpler endpoint that the user can access. The system works within existing permissions. It does not request new ones.
\nThe LLM never sees raw data. The paper’s architecture ensures that the LLM never has access to the underlying database. It sees API responses \u2014 pre-aggregated, filtered, and shaped by the governed API layer. This is the fundamental security advantage. An LLM with direct database access can hallucinate queries that return unintended data. An LLM that calls governed APIs can only return what the API allows. The surface area for data leakage collapses.
\nHow the Architecture Creates Auditability
\nThe paper does not present itself as a security architecture paper. But its system diagram (Figure 2) maps directly onto a security controls framework:
\nStage 2 is an access control gateway. The Target Search Agent does two things: it resolves what the user is asking about, and it checks whether the user is permitted to ask about it. The permission validation step is embedded in the architecture, not bolted on afterward. This is what security teams call “policy enforcement at the request layer” \u2014 and it is the correct place for it.
\nStage 3 is a purpose-built query interface. The Database Querying Agent selects from a known set of analytics API endpoints \u2014 not arbitrary SQL tables. The endpoint set is finite, documented, and permission-scoped. There is no way for the LLM to construct a query against an endpoint that does not exist or that the user should not access. The query construction is constrained by the API surface, not by the model’s imagination.
\nStage 4 is a policy enforcement point. The execution and validation step checks the constructed query against business rules before it runs. If the query violates a rule \u2014 requesting a metric the user should not see, querying a date range that exceeds policy limits \u2014 the system blocks it and retries with corrected parameters. The validation is programmatic and deterministic, not LLM judgment.
\nStage 5 has no data access at all. The Visualization Agent generates chart configurations from already-returned data. It never touches the database. It never makes API calls. It sees aggregated results, not raw rows.
\nFor a CISO reviewing this architecture against a standard security control framework, the pattern is clean: authentication at the entry point, authorization at the entity resolution layer, policy enforcement at the execution layer, data minimization at the API layer, and full audit logging throughout.
\nThe Compliance Advantages of Governed API Orchestration
\nThe paper’s architecture also addresses several regulatory requirements that are becoming material for enterprises deploying AI for internal use.
\nGDPR and CCPA data subject access rights. An employee asks the analytics system “show me my team’s sales data.” Under governed API orchestration, the system checks: does this user have permission to see this data? Does the team consent to having their aggregate data surfaced? Are any of the underlying records subject to data subject deletion requests? The API layer can answer each of these questions before the data is retrieved. A direct SQL system cannot.
\nSOX and financial reporting controls. A controller asks “what was Q4 revenue by product line?” The governed API endpoint for revenue reporting includes the business rules that ensure the calculation matches the official financial reporting methodology. The LLM cannot construct a different SQL query that produces a different revenue number. The answer is always consistent with the sanctioned definition.
\nIndustry-specific data segregation. In healthcare, insurance, or financial services, data is segregated by business line, by regulation, and by jurisdiction. The governed API layer enforces these boundaries. A query from a US claims analyst about the same company’s UK policyholders hits a UK-specific API endpoint or is blocked entirely. The LLM does not need to understand regulatory boundaries \u2014 the API layer enforces them.
\nThe paper demonstrates at two Fortune 500 companies that this architecture works at scale: 90 expert-curated enterprise analytics tasks, 300 person-hours of evaluation, 94.44 percent execution success with the production model, and a retry loop that handles the edge cases that break demos.
\nWhat Security Leaders Should Do Now
\nAudit any Text-to-SQL pilot in your organization against this paper’s findings. If your data team is running a Text-to-SQL pilot with direct database access, the paper provides the framework for asking the right questions: who validated permissions? What audit trail exists? What stops the LLM from querying restricted tables? The baseline failure rate in the paper suggests the pilot will fail for operational reasons before security becomes the deciding factor \u2014 but security should not wait for operational failure.
\nInclude the retry loop in your security review criteria. A system that retries failed API calls by escalating privileges is a security risk. A system that retries by correcting parameters within existing permissions is not. The paper’s two-tier retry design \u2014 programmatic recovery for predictable errors, LLM-powered recovery for ambiguous ones \u2014 is the pattern to require.
\nEvaluate governed API orchestration as an alternative to data masking. Some enterprises address the Text-to-SQL security problem by masking or redacting sensitive data in database query results. This creates a false sense of security. The LLM has still queried the data. The masking layer is an additional failure point. Governed API orchestration eliminates the need for masking by ensuring the LLM never touches raw data.
\nRequire a permission-validation layer at the request level, not the database level. The paper’s architecture validates permissions before the query runs. Most enterprise data access controls validate permissions at the database level \u2014 after the query has been constructed and submitted. The difference is between “stop the car before the intersection” and “stop the car after it has entered the intersection and let it coast to a halt.” Both stop the car. One is safer.
\nKey Takeaways for Security, Compliance, and Audit Leaders
\nThe permission validation pattern is the single most important architectural decision an enterprise can make for AI analytics. Validate before the query, not after. Embed it as a dedicated agent stage, not a middleware filter.
\nThe retry loop is a security enclosure, not just an engineering convenience. By keeping retries within the existing permission framework, the system never needs to request escalated access. This is the production security pattern for LLM-based data access.
\nThe architecture eliminates the LLM data leakage debate. An LLM that calls governed APIs cannot leak data it never sees. The data stays behind the API layer. The conversation about “can we trust the model not to leak data?” becomes irrelevant.
\nTwo Fortune 500 deployments prove the pattern is real. The paper is not theoretical. Dialpad deployed this at two large enterprises. The 90-task evaluation is the most practical enterprise analytics evaluation published.<\/p>\n
Thanks to All Authors
\nGundeep Singh \u2014 Dialpad Inc., San Francisco, CA
\nParsa Kavehzadeh \u2014 Dialpad Inc., San Francisco, CA
\nJing Xia \u2014 Dialpad Inc., San Francisco, CA
\nXue-Yong Fu \u2014 Dialpad Inc., San Francisco, CA
\nJulien Bouvier Tremblay \u2014 Dialpad Inc., San Francisco, CA
\nMd Tahmid Rahman Laskar \u2014 Dialpad Inc., San Francisco, CA
\nVincent Lum \u2014 Dialpad Inc., San Francisco, CA
\nShashi Bhushan TN \u2014 Dialpad Inc., San Francisco, CA<\/p>\n
Want to know how this applies to your company?
\nAt Silicon Valley Certification Hub, we help you align AI + Strategy. Our team works directly with your directors and teams to assess AI readiness, identify gaps, and build a clear path forward \u2014 tailored to your business context.
\nBook a time with our CEO, Alejandro Cuauhtemoc-Mejia:
\nhttps:\/\/calendar.app.google\/2ihQf2JH3D9uJBe68
\nSilicon Valley Certification Hub
\n3000 El Camino Real, Building 4, Palo Alto, CA<\/p>\n
You can now deploy AI analytics systems with genuine security controls rather than choosing between capability and compliance. The governed API pattern eliminates the false choice between locking down LLM access entirely or granting unrestricted database permission, delivering 92 percent task success while maintaining auditable, permission-based access to data.<\/p>\n<\/div>\n
The failure isn’t due to SQL generation quality\u2014it’s because these systems cannot navigate organizational permissions, governance rules, and business context that protect sensitive data. Direct database access without permission awareness creates a security blind spot that the model has no way to resolve, making the task unsolvable by design.<\/p>\n<\/div>\n
Begin with an AI Assessment for companies that maps your current data governance model, permission structures, and audit requirements against the governed API orchestration pattern described in this research. Silicon Valley Certification Hub can help your team evaluate whether your organization has the API infrastructure and permission frameworks in place to adopt this more secure approach without major architectural rewrites.<\/p>\n<\/div>\n
Determine whether your existing API layer can serve as the governance enforcement point\u2014if not, build that first before deploying agentic LLM systems for analytics. This single decision gates your ability to maintain audit trails, control access, and comply with data regulations while giving your teams the AI-powered insights they need.<\/p>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
Silicon Valley Certification Hub Chief AI Officer reviews how governed API orchestration creates an auditable, permission-controlled AI analytics pipeline. For <\/p>\n","protected":false},"author":155,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"content-type":"","_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"advanced_seo_description":"","jetpack_seo_html_title":"","jetpack_seo_noindex":false,"_price":"","_stock":"","_tribe_ticket_header":"","_tribe_default_ticket_provider":"","_tribe_ticket_capacity":"0","_ticket_start_date":"","_ticket_end_date":"","_tribe_ticket_show_description":"","_tribe_ticket_show_not_going":false,"_tribe_ticket_use_global_stock":"","_tribe_ticket_global_stock_level":"","_global_stock_mode":"","_global_stock_cap":"","_tribe_rsvp_for_event":"","_tribe_ticket_going_count":"","_tribe_ticket_not_going_count":"","_tribe_tickets_list":"[]","_tribe_ticket_has_attendee_info_fields":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[24],"tags":[543,544,557,554,561,542,558,559,560,552,555,541,480,553],"class_list":["post-58587","post","type-post","status-publish","format-standard","hentry","category-research","tag-ai-assessment","tag-ai-for-executives","tag-ai-security","tag-api-orchestration","tag-audit","tag-chief-ai-officer","tag-ciso","tag-compliance","tag-data-governance","tag-enterprise-analytics","tag-llm-architecture","tag-silicon-valley-certification-hub","tag-svch","tag-text-to-sql"],"acf":[],"jetpack_featured_media_url":"","jetpack_likes_enabled":true,"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/svch.io\/es\/wp-json\/wp\/v2\/posts\/58587","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/svch.io\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/svch.io\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/svch.io\/es\/wp-json\/wp\/v2\/users\/155"}],"replies":[{"embeddable":true,"href":"https:\/\/svch.io\/es\/wp-json\/wp\/v2\/comments?post=58587"}],"version-history":[{"count":0,"href":"https:\/\/svch.io\/es\/wp-json\/wp\/v2\/posts\/58587\/revisions"}],"wp:attachment":[{"href":"https:\/\/svch.io\/es\/wp-json\/wp\/v2\/media?parent=58587"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/svch.io\/es\/wp-json\/wp\/v2\/categories?post=58587"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/svch.io\/es\/wp-json\/wp\/v2\/tags?post=58587"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}