Pillar IV: Data, AIOps, Infrastructure · § 12

Model Context Protocol (MCP)

The naive approach to giving an agent database access, hand it a connection string and let it write SQL, is a security failure waiting to happen. A prompt-injected agent writes malicious SQL. An honest agent still sees tables it should never have seen. MCP is the layer making “agent talks to database” survive contact with real-world threats.

Context

Model Context Protocol is an open standard for connecting AI models to internal systems through an explicit, validated interface. We adopted MCP rather than building an internal protocol because the standard already exists, vendor LLMs support it natively, and the tooling ecosystem is open. We customize the MCP server for Bizzi-specific concerns (multi-tenancy, PII redaction) while keeping the protocol layer standard.

What MCP solves

Three problems break the naive “agent plus connection string” approach.

Security. A prompt-injected agent generates malicious SQL. DROP TABLE, cross-tenant queries, exfiltration through cleverly constructed UNION.
Data exposure. Even a well-behaved agent sees the full schema, including tables holding PII or billing information completely unrelated to the task.
Reliability. Agents write queries taking down the database. Unbounded scans, missing LIMIT, joins across billion-row tables.

How MCP solves them

MCP sits between the agent and the database and enforces.

Schema filtering. The agent only sees the tables it needs for its current task. PII-bearing tables and billing-internal tables are not exposed at all.
Query validation. Before any SQL reaches the database, the MCP server parses it and checks. Tenant_id filter present, no system tables touched, LIMIT present, no DML.
Read-only enforcement. Most agents only see SELECT. DROP, UPDATE, DELETE are not exposed.
Audit logging. Every query through MCP is logged with agent ID, user context, and the original (pre-rewrite) SQL.

Architecture

AI Agent
   │
   │ "What's vendor X spend last month?"
   ▼
Agent generates SQL
   │
   │ SELECT SUM(amount) FROM ... WHERE vendor = 'X' ...
   ▼
MCP Layer
   ├── Parse SQL
   ├── Check whitelist tables
   ├── Inject tenant_id filter
   ├── Add LIMIT if missing
   ├── Reject if PII columns referenced
   └── Forward to DB
   │
   ▼
OLAP database (read-only)
   │
   ▼
Result → Agent

A concrete example, the SQL agent in the AI assistant

When a user asks an analytical question, MCP enforces.

The agent sees only tables relevant to analytics. Not authentication tables, not billing tables.
Every query must include WHERE tenant_id = current_user.tenant_id. The agent does not even know the tenant_id. MCP injects it.
No DML statements are accepted.
PII columns are redacted in the result before the agent sees them.

The point of the tenant_id injection is concrete. Even if an attacker successfully prompt-injects the agent to write “show me all data from all tenants”, MCP rejects the query because the required tenant filter is missing.

Why we chose the open standard

We considered building an internal protocol. We chose MCP because.

Tooling already exists and improves without our investment.
Documentation is public and reviewed by a community of users.
Vendor LLMs support it natively, which means new agents work out of the box.
New engineers onboard faster because they encounter the protocol elsewhere.

We do customize the MCP server itself for Bizzi-specific multi-tenancy and PII redaction. The protocol is standard. The server implementation is ours.

MCP for non-database tools

MCP is not only for databases. We use it for.

File system access. Agents read specific document types through a controlled interface.
External API calls. Agents call vetted public APIs (for example, the State Bank exchange rates) through MCP with rate limits applied.
Internal services. Agents call internal services whose schemas are explicitly defined and exposed through MCP.

The pattern is consistent. Agents never touch a system directly when MCP stands between them.