News Why Your AI Agent Needs a Guard Layer Before It Touches SQL Giving AI agents direct database access is a recipe for disaster. ajan-sql introduces an MCP server that enforces read-only, schema-aware SQL access with hard safety constraints. Every team connecting LLMs to production data should understand this pattern. Jan Schmitz | March 23, 2026 | 11 min read On this page TL;DR: A new open-source MCP server called ajan-sql tackles one of the hairiest problems in agentic AI: letting LLMs query your database without letting them wreck it. Instead of handing your model raw SQL execution, ajan-sql inserts a guard layer that enforces read-only access, caps result sizes, blocks dangerous statements, and provides structured schema discovery. With MCP server security incidents mounting throughout 2025 and into 2026, this “safe by default” pattern deserves a closer look from anyone connecting AI agents to production data. Why Your AI Agent Needs a Guard Layer Before It Touches SQL The pitch is seductive. Connect your AI agent to a database, let it explore the schema, write queries on the fly, and surface insights from your data without you ever opening a SQL client. Half the demos at every AI conference this year follow that exact script. What they skip over is the part where things go wrong. And things go wrong fast when you hand a language model the keys to your data layer. Bora Kilicoglu, a developer who clearly spent some time thinking about this gap, recently shipped ajan-sql , a small MCP server purpose-built to give AI clients schema-aware, read-only SQL access with a guard layer sitting between the model and actual query execution. It’s not flashy. It’s not trying to replace your BI stack. But it solves a specific, important problem that the “just let the AI query it” crowd tends to hand-wave away. Here’s why this matters, what the server actually does, and what it means for where AI-database access is heading. The gap between “can write SQL” and “should run SQL” Every major LLM can generate SQL. GPT-4, Claude, Gemini. They’ll all happily take a natural language question and produce a syntactically correct query. The capability has been table stakes for over a year. The problem was never generation. It’s always been execution. When you let an AI agent execute the SQL it generates against a real database, you’re trusting a non-deterministic system to do something that traditionally requires precision and predictability. The same prompt, run twice, might produce different queries. A slightly ambiguous question might trigger a full table scan on a 200-million-row table. A prompt injection buried in user-supplied data could steer the model into running a DELETE statement. These aren’t hypothetical risks. Microsoft’s own SQL MCP Server documentation explains why they intentionally avoided natural-language-to-SQL in their implementation: models aren’t deterministic, and complex queries are the most likely to produce subtle, hard-to-catch errors. Instead, Microsoft built a deterministic query builder that uses entity abstractions to produce well-formed Transact-SQL. They made that choice for a reason. For teams that do want their agents to write and run SQL (and there are legitimate reasons to), the question becomes: what sits between the model’s output and your database engine? That’s the guard layer. And until recently, most people weren’t building one. What happened when people skipped the guard layer The consequences are already documented. In mid-2025, a developer using Cursor connected to their Supabase database via MCP with a privileged service_role key. An attacker filed a support ticket — the kind of routine task you’d ask an AI assistant to help triage — with hidden instructions embedded in the ticket body. When the developer asked the agent to review open tickets, it read the attacker’s message, interpreted the embedded instructions as legitimate commands, queried the private integration_tokens table, and wrote the results back into the support thread. The attacker refreshed the page and read their targets’ credentials in plain text. Three things combined to make this possible: privileged database access, untrusted input reaching the model, and no intermediate layer validating what the agent was actually doing. Around the same time, Datadog Security Labs published a case study on SQL injection in a PostgreSQL MCP server, showing how attackers could exploit the gap between what a prompt asks for and what actually gets executed. Anthropic’s own SQLite MCP server, forked over 5,000 times on GitHub, contained an injection vulnerability that could seed stored prompts and exfiltrate data. Thousands of downstream implementations inherited that flaw before it was caught. The pattern repeats because the underlying mistake repeats: treating AI-generated SQL as trusted input. ajan-sql: Safety as the primary design goal This is the context in which ajan-sql becomes interesting. Not because it’s the only MCP serve...