Access Control with Allowlists

Overview

The MCP Trino server supports hierarchical allowlist filtering to restrict access to specific catalogs, schemas, and tables. This feature provides performance optimization and additional access control on top of your existing Trino security configuration.

Key Benefits

  • πŸš€ Performance: Dramatically reduces AI assistant query time by limiting search scope

  • 🎯 Focus: Eliminates distractions from irrelevant data sources

  • πŸ”’ Security: Additional layer of access control (complements Trino's built-in security)

  • πŸŽ›οΈ Flexibility: Independent filtering at catalog, schema, and table levels

Configuration

Configure allowlists using environment variables with comma-separated values:

Environment Variables

Variable
Description
Format
Example

TRINO_ALLOWED_CATALOGS

Restrict visible catalogs

catalog1,catalog2

hive,postgresql

TRINO_ALLOWED_SCHEMAS

Restrict visible schemas

catalog.schema

hive.analytics,hive.marts

TRINO_ALLOWED_TABLES

Restrict visible tables

catalog.schema.table

hive.analytics.users

Format Requirements

  • Schemas: Must include catalog name (e.g., hive.analytics)

  • Tables: Must include catalog and schema (e.g., hive.analytics.users)

  • Case insensitive: HIVE.Analytics matches hive.analytics

  • Whitespace tolerant: Spaces around commas are automatically trimmed

  • Empty values: Empty allowlists mean no filtering (all items accessible)

Usage Examples

Common Use Cases

1. Focus AI on Specific Schemas (Most Common)

Problem: Claude AI searches through 20+ schemas, causing performance issues

Result: AI assistant only sees 3 schemas instead of 20+, dramatically improving performance.

2. Multi-Catalog Environment

3. Production Security Layer

4. Development Environment

How It Works

Hierarchical Independence

Each allowlist level operates independently:

  • list_schemas returns: analytics, marts (from schema allowlist)

  • list_tables in hive.analytics returns: users (from table allowlist)

  • list_tables in hive.marts returns: all tables (no table restriction for this schema)

Parameter Resolution

The server handles flexible table references:

All these calls work correctly:

  • get_table_schema("hive", "analytics", "users") βœ…

  • get_table_schema("", "analytics", "users") βœ… (uses default catalog)

  • get_table_schema("", "", "analytics.users") βœ… (schema.table format)

  • get_table_schema("", "", "hive.analytics.users") βœ… (fully qualified)

Error Handling

Configuration Errors

The server validates allowlist formats on startup:

Access Denied Errors

When access is restricted:

Performance Impact

Before Allowlists

After Allowlists

Result: 10-20x performance improvement for AI queries

Security Considerations

Complementary Security

Allowlists are additional access control, not replacements:

  • βœ… Use with Trino security: LDAP, Kerberos, role-based access

  • βœ… Defense in depth: Multiple security layers

  • βœ… Fail-safe: Restricted allowlists are more secure than open access

Important Notes

  • Not primary security: Don't rely solely on allowlists for sensitive data

  • Bypass possible: Users with direct Trino access can still access restricted data

  • Audit compliance: Allowlists help with data governance and audit requirements

Troubleshooting

Common Issues

1. "No catalogs/schemas/tables returned"

2. "Table access denied" errors

3. Case sensitivity issues

Debug Mode

Enable debug logging to see filtering in action:

Migration Guide

From No Allowlists to Allowlists

  1. Identify current usage: Check which schemas AI assistants actually use

  2. Start conservative: Begin with schema-level filtering

  3. Monitor performance: Measure query time improvements

  4. Refine gradually: Add table-level restrictions if needed

Rollback Strategy

To disable allowlists completely:

Best Practices

Performance Optimization

  1. Start with schema filtering: Biggest performance impact

  2. Use specific catalogs: Avoid scanning unused data sources

  3. Monitor query patterns: Adjust allowlists based on actual usage

Security Best Practices

  1. Principle of least privilege: Only allow necessary access

  2. Regular reviews: Audit and update allowlists quarterly

  3. Document decisions: Maintain clear justification for allowlist choices

  4. Test changes: Validate allowlist updates in non-production first

Operational Guidelines

  1. Environment-specific: Different allowlists for dev/staging/production

  2. Version control: Store allowlist configurations in infrastructure as code

  3. Monitoring: Track allowlist effectiveness and performance improvements

  4. Documentation: Keep team informed about access restrictions

Last updated

Was this helpful?