Question: should BigQuery MCP clients re-check trust if SQL scope or protected-mode config changes?

[MaazAhmed47]

Hi,

I’m Maaz, founder of Interlock, an open-source MCP runtime trust layer focused on post-approval MCP tool drift.

I was looking at mcp-bigquery-server because it has a well-defined safety boundary: read-only BigQuery access, SELECT-only validation, dry-run checks, max-bytes controls, protected mode, allowed tables, and sensitive-field restrictions.

The question I’m exploring is:

If a client approves the server in that constrained state, should the runtime notice if the approved surface changes later?

Examples:

• SELECT-only behavior expands to DML, DDL, EXPORT DATA, or broader execution
• protected mode is disabled
• allowed tables broaden
• sensitive/prevented fields change
• max-bytes or query limits change
• service account or dataset scope expands

I’d be interested in running a small non-production drift check:

• baseline a safe BigQuery MCP config
• simulate one safe SQL/scope/config change
• see whether Interlock detects the drift before execution
• review the audit evidence produced

No production BigQuery, no sensitive data, no real credentials required.

Does this kind of post-approval drift boundary seem relevant for BigQuery MCP users, or is this already handled elsewhere in your threat model?