Security and guardrails

Learn how to maintain security in your database when working with Exasol MCP Server.

When you connect an AI assistant to your database, the assistant can read metadata, explore schemas, and execute SQL queries on your behalf. This article explains how authentication works in the Exasol MCP Server, what restrictions exist today, and what additional safeguards you should consider for production deployments.

Authentication

The Exasol MCP Server authenticates to your database using three environment variables that you set in your MCP client configuration:

In a typical Claude Desktop setup, these values go into your claude_desktop_config.json file:

{
  "mcpServers": {
    "exasol_db": {
      "command": "uvx",
      "args": ["exasol-mcp-server@latest"],
      "env": {
        "EXA_DSN": "my-dsn",
        "EXA_USER": "my-user-name",
        "EXA_PASSWORD": "my-password"
      }
    }
  }
}

The MCP server uses these credentials to open a connection to Exasol.

Credential handling considerations

The credentials in the MCP client configuration file are stored in plaintext on your local machine. Keep the following in mind:

• File permissions: Restrict read access to the configuration file to your own user account. On macOS and Linux, use chmod 600 on the file.
• Shared machines: Do not configure the MCP server on machines where other users can read your home directory.
• Version control: Never commit MCP client configuration files that contain database credentials to a Git repository.

Query restrictions

The Exasol MCP Server sends SQL queries to the database using the credentials you provide. The database user's permissions determine what the AI assistant can and cannot do. If your database user has read-only access, the assistant can only run SELECT statements. If the user has write access, the assistant can run INSERT, UPDATE, DELETE, and DDL statements.

The MCP server itself does not enforce any query restrictions. It does not filter queries by type or block potentially destructive operations. All access control depends on the permissions of the Exasol database user you configure.

Recommended approach

Create a dedicated database user for AI assistant access with the minimum permissions required:

CREATE USER mcp_readonly IDENTIFIED BY '<strong-password>';
GRANT CREATE SESSION TO mcp_readonly;
GRANT SELECT ON SCHEMA my_schema TO mcp_readonly;

This ensures that the AI assistant can explore and query data but cannot modify tables, drop objects, or change permissions.

Result size limits

The MCP server does not currently impose limits on query result sizes. If an AI assistant runs a query that returns a large number of rows, the full result set is returned through the MCP protocol. Depending on your MCP client, this may cause slow responses, high memory usage, or truncation at the client level.

To control result sizes, add explicit LIMIT clauses in your queries, or instruct the AI assistant to do so. For example, you can include guidance in your system prompt: "Always limit query results to 1000 rows unless I ask for more."

Audit and logging

The MCP server does not currently provide its own audit log of queries executed by AI assistants. However, queries run through the MCP server appear in the standard Exasol audit tables (EXA_DBA_AUDIT_SQL or EXA_USER_AUDIT_SQL), because they are executed as regular database sessions.

You can identify MCP server sessions by the database user. If you create a dedicated mcp_readonly user as recommended above, you can query the audit log for all activity from that user:

SELECT session_id, sql_text, start_time, duration
FROM EXA_DBA_AUDIT_SQL
WHERE user_name = 'MCP_READONLY'
ORDER BY start_time DESC;

Remote HTTP deployment

When you run the MCP server in remote HTTP mode (exasol-mcp-server-http), the server accepts connections over the network. This introduces additional security considerations compared to the local stdio mode:

• Network exposure: Bind the server to a specific internal interface rather than 0.0.0.0. Use the --host flag to control which network interface the server listens on.
• Transport encryption: Place the server behind a reverse proxy (such as Nginx or Caddy) that terminates TLS. The MCP server itself does not handle TLS.
• Access control: Restrict network access to the server using firewall rules or security groups. Only authorized clients should be able to reach the HTTP endpoint.

The remote HTTP server does not currently support authentication at the HTTP layer (such as API keys or OAuth tokens). All access control depends on the database credentials configured in the server's environment. Restrict network access to the HTTP endpoint to compensate.