# Building Safe Digital FTEs: Restricting MCP Connections > **Author:** Owais Abdullah > **Published:** Oct 22, 2026 > **Categories:** AI Agents > **Canonical URL:** https://owaisabdullah.dev/blog/building-safe-digital-ftes-restricting-mcp-connections ## Overview Learn how to build safe digital employees by restricting MCP database connections with read-only replicas and un-bypassable IAM security boundaries. ## Content > **TL;DR** - Simply restricting your AI agent to read-only mode is not enough, as standard SQL SELECT statements can still trigger dangerous server-side functions. To build truly safe digital employees, you must implement a defense-in-depth strategy that includes read-only database replicas to isolate performance risks and strict, un-bypassable IAM roles as your final security backstop. ## The Flaw in Simple Read-Only Security Many teams believe that configuring their database MCP server to "read-only" mode is all the protection they need to let AI agents analyze production data. It feels like a safe, foolproof barrier—the agent can see your data but can't change it. Unfortunately, this is a dangerous misconception. Most read-only guards rely on basic keyword filtering, blocking commands like INSERT, UPDATE, or DELETE. The problem is that a standard SELECT query can still execute built-in database functions. An AI agent, or even a malicious user prompting that agent, can use these functions to read private server files, open outbound network connections, or crash your system with resource-heavy operations. As highlighted in this technical analysis, a simple query like `SELECT pg_read_file('/etc/passwd')` can bypass these filters entirely because it never uses a write keyword. If your security layer only asks "is this a write?", it will fail to block these legitimate-looking but destructive read-path operations. ## Why Keyword Filters Are an Incomplete Defense Keyword filtering is a weak security strategy because it focuses on the statement type rather than the operation's capability. Every major database—whether PostgreSQL, MySQL, or SQL Server—ships with functions that perform actions far beyond reading rows. These functions are often tucked inside a query’s SELECT, FROM, or WHERE clauses. Because they aren't top-level write statements, they slip past naive guards. To be truly secure, your enforcement layer must: - Reject multi-statement inputs. - Strip comments and string literals to prevent hidden payloads. - Deny dangerous functions by name, regardless of where they appear in the query. We cover how to build these safer systems in our guide on building multi-tool AI agents. ## Protecting Production Systems with Read-Only Replicas Beyond security, there is the issue of performance. Large language models are unpredictable; they often generate unoptimized queries with full table scans or complex joins. Running these directly on your live production database is a recipe for system lag or crashes. ![Implementing robust security layers for AI agents accessing databases.](Image) Connecting your MCP server to a dedicated read-only replica is a much safer alternative. This isolates the performance impact of heavy AI queries, ensuring your primary system remains stable. You can even tune the replica with specific indexes to speed up the natural language searches your agents perform, without affecting your production environment. ## Implementing IAM as Your Un-bypassable Bouncer Client-side tool settings, like `excludeTools` in your MCP configuration, are helpful for guiding an agent's behavior, but they are not a security boundary. A smart agent can easily bypass these UI-layer restrictions by falling back to terminal commands or other available tools. True security requires infrastructure-level controls. By using Google Cloud Service Accounts and IAM roles, you establish a hard boundary that the agent cannot ignore. As detailed in this Google Cloud defense-in-depth guide, IAM roles act as an un-bypassable bouncer. Even if an agent finds a way to trigger a restricted action, the database itself will block the request with a 403 error because the service account lacks the necessary permissions. We also explore securing your workstation in our post on zero-trust security for local MCP servers. ## Bottom Line True security for AI database agents requires moving beyond simple "read-only" settings. Relying solely on keyword filters or tool-hiding leaves your production data exposed to clever workarounds. Instead, use a defense-in-depth approach: connect your agents to read-only replicas to protect system performance, and enforce strict, infrastructure-level IAM roles to ensure agents can never exceed their intended boundaries. By building these hard limits, you can confidently scale your digital workforce while keeping your most critical data safe and secure. For more on scaling, read our thoughts on AI agent automations and architecture. ## Sources - Your Database MCP's "Read-Only" Mode Probably Isn't (AI2SQL) ## Frequently Asked Questions ### Is a SQL SELECT statement always safe to run in read-only mode? No. A SELECT query can call dangerous database functions that read server files, open external network connections, or run OS commands. Statement type alone does not guarantee safety. ### Why is blocking write keywords like INSERT or DELETE not enough? Because risky operations can be executed via function calls inside SELECT queries. A guard that only blocks write keywords will allow dangerous functions like pg_read_file to pass through. ### How does a read-only replica protect a production database? It isolates the performance impact. Since AI-generated queries can be unoptimized and heavy, running them on a replica prevents your primary production system from slowing down or crashing. ### Can client-side tool filters fully secure an AI agent? No. While settings like excludeTools hide write tools, a smart agent might find workarounds, such as using terminal commands or shell tools to execute the same restricted actions. ### What is the ultimate way to secure MCP database connections? Use database-level IAM and Service Accounts with least-privilege roles. This sets up an un-bypassable boundary that blocks unauthorized actions with a 403 error, regardless of how they are triggered. ### How should I test if my database MCP read-only mode is secure? Run a SELECT query that calls a file-read or sleep function for your dialect, such as SELECT pg_read_file('/etc/passwd') on Postgres. If it executes, your read-only layer is incomplete. --- *Generated by Owais Abdullah Portfolio Agent Indexer (https://owaisabdullah.dev)*