The Model Context Protocol (MCP) has made connecting AI agents to databases trivially easy, but it has also turned security into a massive blind spot. A new deep-dive from Oracle Developers argues that while MCP servers allow agents to query business data, most implementations fail to account for the chaos that ensues when an agent decides to write its own SQL. The core thesis is simple: security lives in the database, not in the MCP wrapper.

The Illusion of Code-Level Security

Many developers assume that adding a simple checkβ€”like verifying a query starts with 'SELECT'β€”is enough to keep an AI agent safe. The article notes that this check is cosmetic, and cosmetic checks are theater. Pattern-matching on text cannot catch side effects or sophisticated injection tricks, such as smuggling a second command past a single-query check. The real boundary is the database account itself. If the account lacks DELETE or UPDATE privileges, the agent cannot modify data, regardless of what the MCP server code says. This principle of least privilege must be enforced at the identity level, using OAuth or workload identity federation, rather than relying on fragile string parsing in the application layer.

Context Window Economics

Beyond security, there is a hard cost to letting agents talk to databases: tokens. Every row returned by an MCP tool consumes context window space, directly impacting latency and API bills. The authors recommend a strict contract for tool outputs, capping default results at 25 rows with an absolute maximum of 500. To avoid catastrophic context bloat, the server should use a clever trick: fetching one extra row than requested to signal that more data is available without actually sending it. This forces the agent to ask narrower, more specific questions, keeping the interaction efficient and the context window clean.

Why AI-Generated SQL Fails in Production

Perhaps the most controversial takeaway is that letting an AI agent write fresh SQL queries every time it needs data is a bad idea. For recurring business questions, the article advocates for reviewed, parameterized queries or purpose-built tools. This ensures repeatability and accuracy. When an agent generates SQL on the fly, results can vary wildly between runs, making audits difficult and trust impossible. The authors tested a minimal proof-of-concept server, 'oraviz-mcp', against Oracle's official SQLcl MCP server. While the custom server saved 53.3% of tokens in total, it lost performance on three of five individual tasks, proving that official, managed tools are still superior for complex production environments.

Key Takeaways

  • Security must be enforced via database permissions (least privilege), not just MCP code checks.
  • Cap tool outputs strictly (e.g., 25 rows default) to manage token costs and context window limits.
  • Avoid letting agents write arbitrary SQL; use parameterized queries for repeatability.
  • Use official, managed MCP servers for production to ensure centralized identity and audit logging.

The Bottom Line

Stop treating your database like a sandbox. If your AI agent can write SQL, it can break your business logic. Lock down the identity, cap the output, and force the agent to use pre-approved tools.

Sources

DEV.to: Your AI Agent wants your data