Back to Blog
· Faucet Team

MCP Servers Are the New Shadow IT — Here's How to Give AI Agents Governed Database Access

With 97 million monthly MCP SDK downloads, AI agents are connecting to enterprise databases faster than security teams can govern them. RBAC-first tools like Faucet close the gap.

mcpsecurityenterpriserbacai-agentsgovernance

Last week, Qualys published a warning that should make every CISO pay attention: MCP Servers Are the New Shadow IT. Their argument is straightforward — developers are spinning up MCP servers that give AI agents direct access to production databases, file systems, and internal APIs, often without security review, access controls, or even a ticket in Jira.

They’re right. And the numbers back it up.

97 Million Downloads and Counting

The Model Context Protocol has crossed 97 million monthly SDK downloads across Python and TypeScript. The official MCP registry lists over 6,400 servers. Every major AI provider — Anthropic, OpenAI, Google, Microsoft, Amazon — now supports MCP natively. It’s not experimental anymore. It’s infrastructure.

But here’s what those adoption numbers don’t tell you: most MCP database servers ship with no authentication, no role-based access control, and no audit trail. The default PostgreSQL MCP server on npm gives the connecting agent full read/write access to every table with whatever credentials you paste into the connection string. That’s not a tool. That’s an open door.

The Integration Tax Is Real

According to a recent enterprise survey, 46% of organizations cite integration with existing systems as their primary challenge when deploying AI agents. Not model quality. Not prompt engineering. Integration.

The reason is simple: connecting an AI agent to a database safely requires solving the same problems we’ve been solving in API development for twenty years — authentication, authorization, rate limiting, field-level access control, audit logging. The MCP protocol handles the transport layer beautifully. It says nothing about governance.

This creates a gap. Developers need to ship agent-powered features. Security teams need to review every data access path. The result? Developers reach for the fastest MCP server they can find, configure it with a connection string that has superuser privileges, and promise to “lock it down later.”

Later never comes.

What Governed Database Access Actually Looks Like

Let’s be specific about what “governed” means in the context of AI agents talking to databases:

1. Role-Based Access Control (RBAC) Every API key or agent session should map to a role. That role defines which tables are accessible, which columns are visible, and whether the agent can read, create, update, or delete records. An HR agent should see employees.name and employees.department but never employees.salary or employees.ssn.

2. Per-Table and Per-Column Permissions Table-level access isn’t granular enough. If your AI agent is generating customer reports, it needs access to orders.total and orders.date but not orders.internal_notes. Column-level permissions aren’t a nice-to-have — they’re a compliance requirement under GDPR, HIPAA, and SOC 2.

3. Read-Only by Default The principle of least privilege isn’t new, but it’s routinely violated in MCP setups. Most database agents only need SELECT access. Write access should be an explicit, auditable escalation — not the default.

4. Audit Logging Every query an AI agent executes should be logged with the agent identity, timestamp, table accessed, and filter parameters. When (not if) someone asks “what data did the agent access?”, you need an answer in minutes, not days.

5. Connection Isolation The AI agent should never share the same database credentials as your application. A dedicated connection pool with its own user, its own permissions, and its own resource limits prevents a runaway agent query from degrading your production app.

How Faucet Solves This

Faucet is an open-source server that generates governed REST APIs — including a native MCP server — from any SQL database. One binary. No Docker. No dependencies.

Here’s how you go from bare database to governed AI agent access in under 60 seconds:

# Install
curl -fsSL https://get.faucet.dev | sh

# Connect your database
faucet connection add mydb \
  --driver postgres \
  --host db.internal \
  --port 5432 \
  --database production \
  --username faucet_reader \
  --password "${DB_PASSWORD}"

# Start the server
faucet serve

That gives you a full REST API at localhost:8080 and an MCP server at localhost:8080/mcp. But the key part is what happens next — governance:

# Create a restricted role for AI agents
faucet role add ai-reader --description "Read-only access for AI agents"

# Grant access to specific tables only
faucet role grant ai-reader mydb \
  --tables customers,orders,products \
  --verbs GET

# Hide sensitive columns
faucet role deny-columns ai-reader mydb.customers \
  --columns email,phone,address

# Generate an API key bound to this role
faucet apikey create agent-key --role ai-reader

Now when Claude, GPT, or any MCP-compatible agent connects to your Faucet server, it gets:

  • Read-only access to exactly three tables
  • No visibility into customer PII columns
  • Full audit logging of every query
  • Rate limiting and connection pooling
  • OpenAPI 3.1 docs that the agent uses to understand what’s available

The agent can query your data. It cannot exfiltrate emails. It cannot drop tables. It cannot even see that the employees table exists.

The MCP Configuration

Pointing Claude Code at your governed Faucet endpoint takes one command:

claude mcp add faucet-prod \
  --transport sse \
  --url https://faucet.internal:8080/mcp \
  --header "X-API-Key: ${FAUCET_AGENT_KEY}"

The agent now has structured, typed tools for every permitted table — list_customers, get_order, search_products — all generated automatically from your schema and filtered through your RBAC rules.

No custom code. No middleware. No “we’ll add auth later.”

Why This Matters Now

Three converging trends make governed database access urgent in 2026:

1. AI Agents Are Moving to Production

The pilot phase is over. IDC forecasts a 10x increase in agent usage by 2027, with a 1,000x growth in inference demands. Agents aren’t querying your staging database anymore — they’re hitting production, and they’re doing it at scale.

2. Connector Fees Are Coming

Salesforce has already raised prices on apps that access its data through APIs. As agentic AI drives more API calls than human users ever did, expect every SaaS vendor to monetize their data access layer. Self-hosted databases behind governed APIs give you control over your own data economics.

3. Compliance Auditors Are Asking About AI

SOC 2 auditors in 2026 are asking a new question: “How do you control what your AI agents can access?” If your answer is “we gave it a Postgres connection string,” that’s a finding. If your answer is “every agent request goes through an RBAC layer with per-column permissions and full audit logging,” that’s a pass.

Comparing Approaches

ApproachAuthRBACColumn MaskingAudit LogSetup Time
Raw MCP + connection stringNoneNoneNoneNone2 min
Custom middlewareDIYDIYDIYDIYWeeks
FaucetBuilt-inPer-table/columnBuilt-inBuilt-in60 sec
Cloud-hosted MCP proxyVariesBasicRareVariesHours

The raw MCP approach is fast but ungoverned. Custom middleware gives you control but costs engineering weeks. Cloud-hosted proxies add latency and vendor lock-in. Faucet gives you governance out of the box with zero dependencies.

Seven Databases, One Security Model

Faucet’s RBAC layer sits above the database driver, which means the same role and permission model works across all seven supported databases:

  • PostgreSQL — The most common target for AI agent access
  • MySQL / MariaDB — Powers the majority of legacy enterprise apps
  • SQL Server — The enterprise standard, especially in finance and healthcare
  • Oracle — Added in v0.1.7, pure-Go driver, no Instant Client required
  • SQLite — Perfect for embedded analytics and edge deployments
  • Snowflake — For agents that need warehouse-scale analytical queries

Define your roles once. Apply them everywhere. When your AI agent needs to query both your Postgres operational database and your Snowflake analytics warehouse, it gets the same RBAC enforcement on both.

What’s at Stake

The Qualys article frames MCP servers as a security risk. They are — when deployed without governance. But the answer isn’t to block MCP adoption. The answer is to make governed access the path of least resistance.

That’s what Faucet does. It makes the secure option faster than the insecure one. Instead of choosing between “ship the feature” and “pass the security review,” you get both.

AI agents talking to databases is not a trend that’s going to slow down. The MCP ecosystem is doubling every quarter. The question isn’t whether your agents will need database access — it’s whether that access will be governed when the auditor asks.

Get Started

Faucet is open source under Apache 2.0. Install it in one line:

curl -fsSL https://get.faucet.dev | sh

Or via Homebrew:

brew install faucetdb/tap/faucet

Your first governed MCP endpoint is 60 seconds away.

Faucet is an open-source project. Star us on GitHub, join the discussion, or read the docs to learn more.