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 and whether the agent can read, create, update, or delete records. An HR agent should see a directory of names and departments but never employees.salary or employees.ssn.
2. Per-Table Permissions, with Sensitive Columns Out of Reach
An agent should only see the tables its job needs. And within those tables, if your AI agent is generating customer reports, it needs orders.total and orders.date but not orders.internal_notes — so expose a view without the sensitive columns and grant that instead. Keeping regulated data out of reach isn’t a nice-to-have under GDPR and HIPAA.
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. Per-Agent Identity and Logging Every request an AI agent makes should be attributable to that agent — its own key, not a shared credential — and logged with a timestamp, the table accessed, and the 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 a free, open-source (MIT) single binary that turns your SQL database into a REST API — including a native MCP server — with API keys and role-based access built in. No Docker required. No runtime dependencies.
Here’s how you go from bare database to scoped AI agent access in under 60 seconds:
# Install
brew install faucetdb/tap/faucet # or: npx @faucetdb/faucet serve
# Connect your database with a low-privilege database user
faucet db add --name mydb \
--driver postgres \
--dsn "postgres://faucet_reader:${DB_PASSWORD}@db.internal:5432/production?sslmode=require"Once Faucet is running, 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 — access control:
# Create a restricted role for AI agents: read-only, three tables
faucet role create --name ai-reader --description "Read-only access for AI agents" \
--service mydb --component "_table/customers_public" --verbs GET
faucet role grant --role ai-reader --service mydb --component "_table/orders" --verbs GET
faucet role grant --role ai-reader --service mydb --component "_table/products" --verbs GET
# Generate an API key bound to this role
faucet key create --role ai-reader --label agent-key
# Start Faucet (it connects configured databases at startup)
faucet servecustomers_public is a database view without email, phone, or address. Faucet doesn’t do column-level permissions, so views are how you keep PII columns out of an agent’s reach.
Now when Claude, Cursor, or any MCP client connects to your Faucet server with that key, it gets:
- Read-only access to exactly three tables (RBAC is fail-closed; nothing else is granted)
- No visibility into customer PII columns, because the view doesn’t have them
- Its own key, so its requests are attributable and revocable on their own
- Connection pooling that keeps a chatty agent from stampeding the database
- 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. Raw SQL is off unless you grant it, and update/delete tools refuse to run without a filter.
The MCP Configuration
Pointing Claude Code at your Faucet endpoint takes one command:
claude mcp add --transport http faucet https://faucet.internal:8080/mcp \
--header "X-API-Key: ${FAUCET_AGENT_KEY}"The agent now has eight structured, typed tools — faucet_list_tables, faucet_describe_table, faucet_query and the rest — that work across every permitted table and run through your RBAC rules on every call.
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 has its own key, and every request goes through a fail-closed RBAC layer scoped to the tables it needs,” you’re having a much better conversation.
Comparing Approaches
| Approach | Auth | RBAC | Raw SQL | Per-Agent Identity | Setup Time |
|---|---|---|---|---|---|
| Raw MCP + connection string | None | None | Always on | None | 2 min |
| Custom middleware | DIY | DIY | DIY | DIY | Weeks |
| Faucet | API keys, built-in | Per-table/verb, fail-closed | Off unless granted | One key per agent | 60 sec |
| Cloud-hosted MCP proxy | Varies | Basic | Varies | Varies | Hours |
The raw MCP approach is fast but uncontrolled. Custom middleware gives you control but costs engineering weeks. Cloud-hosted proxies add latency and vendor lock-in. Faucet gives you safe defaults 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 — Powers the majority of legacy enterprise apps
- MariaDB — The MySQL-compatible fork, served by the same driver
- 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 free and open source under the MIT license. Install it in one line:
brew install faucetdb/tap/faucetOr run it straight from npm:
npx @faucetdb/faucet serveYour first governed MCP endpoint is 60 seconds away.
Faucet is an open-source project. Star us on GitHub, open an issue, or read the docs to learn more.