SQL Execution Call Outs

[dtehan-td]

Customer needs to be able to whitelist databases and needs to be able to mask certain columns specifically for the LLM access path.

The execution of code should have a call out to a user defined function or functions, these could then:

• check a database for whitelisting
• check columns for masking
• etc

Reach out to Iftekhar Moin from Cigna for more details

[dtehan]

SQL Policy Enforcement for Teradata MCP Server

Problem Statement

When an LLM agent interacts with a Teradata database via an MCP server, there is no mechanism to prevent the agent from querying sensitive tables or columns. We need a policy enforcement layer that intercepts SQL before it reaches the database, validates it against an exclusion policy, and blocks queries that reference restricted data — ensuring the LLM never sees forbidden information.

Requirements

• Block queries that reference excluded tables entirely
• Block queries that explicitly reference excluded columns
• Handle SELECT * on tables with excluded columns (the agent should never receive restricted column data, even implicitly)
• Return clear, actionable error messages to the agent explaining what is restricted and what alternatives are available
• Enforce policy in WHERE, JOIN, ORDER BY, and subqueries — not just the SELECT clause
• Configuration-driven via a JSON exclusion policy
• Opt-in — no impact on existing behaviour when not configured

Exclusion Policy Format

{
  "excluded_tables": ["salary_bands", "credentials", "audit_log"],
  "excluded_columns": {
    "employees": ["ssn", "salary", "bank_account"],
    "users": ["password_hash", "security_question"],
    "customers": ["credit_card_number", "date_of_birth"]
  }
}

Enforcement Behaviour

Scenario	Behaviour
Query references an excluded table	Reject — return "table X is restricted"
Query explicitly references an excluded column	Reject — return "column X.Y is restricted"
SELECT * on a table with excluded columns	Reject — return the list of allowed columns the agent can use instead
SELECT * on a table with no exclusions	Pass through unchanged
Excluded column in WHERE, JOIN, ORDER BY	Reject — policy applies to all clauses, not just SELECT
Query with no policy violations	Pass through unchanged
No policy configured	No enforcement — all queries pass through

SQL Parsing Strategy

sqlglot is the recommended parsing library. It has explicit Teradata dialect support and can:

• Parse SQL into an abstract syntax tree (AST)
• Extract every table and column reference across all clauses
• Resolve aliased table references
• Walk subqueries, CTEs, and JOINs
• Handle Teradata-specific syntax

For SELECT * resolution, the enforcer needs to know the table's column list. This is achieved by caching the schema from DBC.ColumnsV on first use.

Teradata MCP Server Architecture Context

The Teradata MCP server has a clean architecture relevant to this design:

• Central execution chokepoint: All SQL queries flow through execute_db_tool() in app.py, regardless of which tool generates them (base_readQuery, registry tools, DBA tools, RAG, etc.)
• Middleware layer: RequestContextMiddleware already intercepts every request for authentication and tracing
• Module loader: Conditionally loads tool domains based on profile configuration
• Config system: Three-tier override (CLI args > environment > packaged defaults) with support for YAML/JSON config files
• Profile system: profiles.yml controls which tools are exposed per profile

Architecture Options

Option A: Extend the Existing Server (Recommended)

Add a policy enforcement layer directly into the Teradata MCP server, designed as an optional, self-contained extension.

How it works:

Agent calls execute_query("SELECT * FROM employees")
    ↓
execute_db_tool() — existing central chokepoint
    ↓
PolicyEnforcer.validate(sql) — new hook, runs before execution
    ↓ if violation detected
Return error message to agent ("column employees.ssn is restricted, available columns are: name, department, title")
    ↓ if clean
Forward to Teradata as normal

Implementation:

1. A policy_config.json file added to the existing config system, loaded alongside profiles.yml and other configs
2. A PolicyEnforcer class in a new tools/policy/ module that:
   • Loads the exclusion config at startup
   • Caches the database schema from DBC.ColumnsV on first use
   • Exposes a validate(sql) method returning either approval or an error message
   • Uses sqlglot with Teradata dialect for SQL parsing
3. A single hook added to execute_db_tool():

   if policy_enforcer:
       result = policy_enforcer.validate(sql)
       if result.blocked:
           return result.error_message

4. Entirely opt-in — if no policy_config.json exists, the enforcer is None and the hook is a no-op

Pros:

• Single enforcement point — catches every query regardless of which tool generates it
• No extra infrastructure — one server, one process
• Direct access to the database connection for schema introspection
• Minimal code change to the existing server (one new module, a few lines in execute_db_tool())
• Could be contributed upstream as an optional feature
• Leverages the existing config loading and module systems

Cons:

• Requires maintaining a fork unless accepted upstream
• Changes could conflict with upstream updates (though the footprint is small)
• Coupled to the internal execute_db_tool() API — if it changes, the hook needs updating

Option B: Proxy MCP Server

A standalone MCP server that sits between the agent and the Teradata MCP server, intercepting and validating all queries.

How it works:

Agent
    ↓ calls tool
Proxy MCP Server (policy enforcement)
    ↓ parses SQL, checks policy
    ↓ if violation → return error to agent
    ↓ if clean → forward to:
Teradata MCP Server
    ↓ executes query, returns results
Proxy MCP Server
    ↓ passes results back
Agent

Pros:

• Completely decoupled — works with any version of the Teradata MCP server without modification
• Reusable — could be used with other database MCP servers, not just Teradata
• Easy to test in isolation
• No fork or upstream dependency

Cons:

• Must duplicate or dynamically mirror all tool definitions from the Teradata server
• Two processes to manage and deploy
• Latency overhead from the extra hop
• Needs its own connection to Teradata for schema introspection (to resolve SELECT *)
• More operational complexity

Option C: Extension Module Using the Existing Module System

Build a new module within the server's tools/ directory, loaded via the existing ModuleLoader and controlled by profiles.

How it works:

Adds a new module alongside the existing tool domains (base, dba, rag, etc.) that wraps existing tool execution with policy checks.

Pros:

• Uses the existing architecture idiomatically
• Profile-controlled — enable or disable policy enforcement per profile in profiles.yml
• No fork needed if accepted as a PR

Cons:

• The module system is designed for adding new tools, not intercepting existing ones
• Still requires modifying execute_db_tool() to add the interception hook — making this functionally the same as Option A but with more indirection
• No clear advantage over Option A given the modification is still needed

Recommendation

Option A is recommended. The rationale:

1. The enforcement point already exists — execute_db_tool() is the natural chokepoint
2. The change is minimal and isolated — one new module, a few lines of integration code
3. It is opt-in and backward-compatible — existing deployments are unaffected
4. It is designed to be contributed upstream, reducing long-term maintenance burden
5. Direct database access simplifies schema introspection for SELECT * handling

Option B (proxy) is the right choice only if: the Teradata server cannot be modified at all, or the policy layer needs to work across multiple different database MCP servers.

Component Design

PolicyEnforcer Class

PolicyEnforcer
├── __init__(config_path, db_connection)
├── validate(sql: str) -> PolicyResult
├── _parse_sql(sql: str) -> AST
├── _extract_tables(ast) -> list[str]
├── _extract_columns(ast) -> list[(table, column)]
├── _resolve_select_star(ast, table) -> list[str]
├── _check_excluded_tables(tables) -> list[Violation]
├── _check_excluded_columns(columns) -> list[Violation]
└── _refresh_schema_cache() -> None

PolicyResult
├── blocked: bool
├── violations: list[Violation]
└── error_message: str  (human-readable, returned to the agent)

Violation
├── type: "excluded_table" | "excluded_column" | "select_star_restricted"
├── table: str
├── column: str | None
└── allowed_columns: list[str] | None  (populated for select_star_restricted)

Schema Cache

On first query (or on demand), the enforcer queries:

SELECT DatabaseName, TableName, ColumnName
FROM DBC.ColumnsV
WHERE DatabaseName = CURRENT_DATABASE

This is cached in memory and used to:

• Resolve SELECT * to explicit column lists
• Determine which columns are available when returning error messages

Error Message Examples

Excluded table:

Query blocked: table `salary_bands` is restricted by policy and cannot be queried.

Excluded column (explicit):

Query blocked: column `ssn` on table `employees` is restricted by policy.
Available columns for `employees`: employee_id, name, department, title, hire_date, office_location

SELECT * with excluded columns:

Query blocked: `SELECT *` on table `employees` would include restricted columns (ssn, salary, bank_account).
Use explicit column names instead. Available columns: employee_id, name, department, title, hire_date, office_location

Open Questions

1. Upstream contribution — Should this be proposed to the Teradata MCP server maintainers as a feature? If accepted, it eliminates the fork maintenance burden entirely.
2. Schema cache refresh — How often should the schema cache be refreshed? Options: once at startup, on a timer, or on demand via a tool the agent can call.
3. DDL/DML enforcement — Should the policy also inspect INSERT, UPDATE, DELETE, and DROP statements, or only SELECT queries?
4. Logging and audit — Should blocked queries be logged for audit purposes? The server already has a logging framework and QueryBand tracing.
5. Multiple policies — Should different profiles be able to have different exclusion policies? For example, a dataScientist profile might have stricter exclusions than a dba profile.
6. Dynamic policy updates — Should the exclusion config be reloadable without restarting the server?