The latest articles on DEV Community by sanchar10 (@sanchar10). https://dev.to/sanchar10 https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3666366%2Fa3be2b5f-7250-47c4-a850-8f279465ed0a.png https://dev.to/sanchar10 en sanchar10 Wed, 17 Dec 2025 07:38:31 +0000 https://dev.to/sanchar10/sql-access-for-ai-agents-flexibility-with-guardrails-e50 https://dev.to/sanchar10/sql-access-for-ai-agents-flexibility-with-guardrails-e50 <p>Learn how to safely expose SQL data to AI agents using a two-part pattern: MCP for AI communication and a schema-driven query builder for secure queries."</p> <h2> Operational AI Agents Need Boundaries </h2> <p>AI agents are increasingly used for operational tasks like customer support:</p> <blockquote> <p>“What’s the status of my subscription?”</p> </blockquote> <p>To answer, an agent must:</p> <ul> <li>Look up the customer by email or phone </li> <li>Check active subscriptions </li> <li>Review recent interactions </li> </ul> <p><strong>The challenge:</strong> Allowing AI to query databases safely without giving unrestricted access. </p> <h2> Why Common Solutions Fall Short </h2> <div class="table-wrapper-paragraph"><table> <thead> <tr> <th>Approach</th> <th>Challenge for AI Agents</th> </tr> </thead> <tbody> <tr> <td>Raw SQL</td> <td>Risky, prone to injection and errors</td> </tr> <tr> <td>Hardcoded APIs</td> <td>Inflexible, needs code changes for every query</td> </tr> <tr> <td>GraphQL / OData</td> <td>Powerful but generic; lacks safeguards and declarative interfaces for reliable agentic queries</td> </tr> </tbody> </table></div> <p><strong>Key insight:</strong> AI agents don’t need full database flexibility — they need <strong>predictable, bounded access</strong>. </p> <h2> Our Two-Part Solution </h2> <p>We combined two patterns:</p> <p><strong>1. Model Context Protocol (MCP)</strong> </p> <ul> <li>Standardized interface for AI → tool communication </li> <li>Enables tool discovery, structured parameters, predictable responses </li> </ul> <p><strong>2. Schema-Driven Query Builder</strong> </p> <ul> <li>Converts JSON-defined entity schemas into safe SQL </li> <li>Handles relationships, field allowlists, and multiple backends</li> </ul> <blockquote> <p><em>Supports multiple SQL backends — SQLite for demos, SQL Server or PostgreSQL for production — with the same query logic.</em> </p> </blockquote> <p><strong>Outcome:</strong> Minimal boilerplate, safe boundaries, LLM-friendly query syntax.</p> <blockquote> <p><em>Security is built in: explicit field allowlists (allowedFilterFields) prevent AI from accessing unauthorized data.</em></p> </blockquote> <h2> Why It Matters </h2> <ul> <li> <strong>AI-ready APIs:</strong> Enable operational queries safely </li> <li> <strong>Dual interface:</strong> Same engine serves AI (MCP) and REST clients </li> <li> <strong>Extensible:</strong> Add new tools with minimal code </li> <li> <strong>Secure:</strong> Explicit allowlists prevent unauthorized access </li> </ul> <h2> Key Takeaways </h2> <ul> <li>Operational AI queries ≠ ad-hoc analytics </li> <li>Bounded interfaces improve reliability and predictability </li> <li>Separation of transport (MCP) and query logic (query builder) maximizes flexibility </li> <li>MongoDB-style JSON filters align with LLM training </li> </ul> <h2> What’s Next </h2> <p>In the <strong>next post</strong>, we’ll dive into <strong>MCP in detail</strong>: how AI discovers and calls tools, with real examples. </p> <p>Check out the GitHub repo for the <strong>full implementation, diagrams, and code</strong>: <a href="https://github.com/sanchar10/mcp-sql-query-dotnet" rel="noopener noreferrer">https://github.com/sanchar10/mcp-sql-query-dotnet</a> </p> <blockquote> <p>Follow me for more AI architecture deep-dives, and drop a comment if you have questions!</p> </blockquote> mcp dotnet database architecture