LogCarverGuard

What LogCarverGuard MCP server does

LogCarverGuard MCP server places a policy proxy between an MCP client and SQL Server. Agents use the execute_sql tool for both queries and writes. Query results include the first 100 rows and a count of additional rows; writes execute under the SQL login associated with the request.

The proxy does not replace SQL Server permissions. In central mode, each API key maps to a person's SQL login, and the proxy impersonates that login. Existing GRANT and DENY permissions therefore remain decisive. The service login needs permission to impersonate the mapped logins and a database user in the target database, but it does not need sysadmin.

How it works

Before sending a statement to SQL Server, the proxy parses T-SQL to identify blocked operations rather than relying on keyword matching. It always blocks operations such as database or table destruction, database restore, identity switching, permission changes, dynamic execution, and caller-controlled transactions. TRUNCATE TABLE, selected column removal, and named stored procedure execution remain blocked unless their schema-qualified names appear in the corresponding allow-list.

DML batches containing INSERT, UPDATE, or DELETE run in a transaction controlled by the proxy and roll back as a unit if a statement fails. DDL, TRUNCATE, and EXEC are not rolled back as part of that batch. Successful statements are written to a local SQLite audit database with the actor, timestamp, SQL, and outcome. Invalid API keys and statements rejected by SQL Server are not recorded.

Setup and configuration

LogCarverGuard MCP server supports two deployment styles. Local mode runs on the developer's machine over stdio, needs no API key or separate service, and reads configuration from environment variables. Set LOGCARVERGUARD_CONNECTION_STRING or its file variant, then optionally configure LOGCARVERGUARD_READ_ONLY, LOGCARVERGUARD_AUDIT_DB_PATH, and the three local allow-list variables.

Central deployment runs in Docker on a Linux host and connects to SQL Server using a service login. Configure LOGCARVERGUARD_SQLSERVER_CONNECTION_STRING or its file variant, start the container, and issue per-user API keys with the included CLI. Clients connect to the HTTP endpoint and send the key in X-LogCarverGuard-Key. Central configuration also supports audit and API-key database paths, client IP restrictions, trusted proxies, allow-lists, and ASPNETCORE_URLS.

Read-only mode permits SELECT statements without INTO, along with SET, DECLARE, and PRINT. It blocks other operations, including EXEC, remote or file-source queries such as OPENQUERY, OPENROWSET, and OPENDATASOURCE, and NEXT VALUE FOR.

Limitations and notes

LogCarverGuard MCP server is an additional guardrail, not a substitute for least-privilege SQL accounts. Some potentially consequential operations, including DROP INDEX, sp_rename, BACKUP DATABASE, and OPENQUERY, are not specially blocked when the SQL login can perform them. Read-only mode also does not prevent side effects from CLR or extended-procedure functions, expensive queries, or locking.

Local mode is not a security boundary: the connection string remains on the machine and an agent with shell or configuration-file access may bypass the proxy. It also uses one connection-string login for every request and records the operating-system user in its local audit file. For a stronger separation between users, use central mode, TLS, restricted client IPs, and SQL accounts that are not sysadmin or db_owner.