LogCarverGuard

LogCarverGuard

English | [繁體中文](README.zh-TW.md)

An MCP proxy that lets an AI coding agent (Claude Code, Cursor, …) read and write a production SQL Server without handing it the real credentials or a free hand. Every statement runs under the caller's own SQL login and grants, dangerous statements are blocked before they reach the database, and everything is written to an audit log.

Status: early (v0.1).

What it does

AI agent --(MCP, API key)--> LogCarverGuard proxy --(EXECUTE AS the caller's own login)--> SQL Server

• One tool, `execute_sql`. Reads and writes go through it. A SELECT returns its rows (first 100 shown, with a count of the rest). A write is executed and audited.
• A real T-SQL parser decides what is allowed, not keyword matching, so a fake keyword inside a comment or string does nothing.
• The AI never sees the database password. The proxy holds one service login. Each person gets an API key that maps to their own SQL login, and the proxy impersonates it, so their existing GRANT/DENY still decide what they can do.
• The service login does not need sysadmin. It needs IMPERSONATE on each user's login, and a database user in the target database so it can connect. The host tests run SELECT, UPDATE and a permission-denied DELETE through a service account that is not sysadmin.
• Data changes run in a transaction the proxy controls. A batch containing INSERT / UPDATE / DELETE is rolled back as a whole if any statement fails. DDL (ALTER TABLE…), TRUNCATE and EXEC run as they are and are not rolled back as part of a batch. BEGIN TRAN / COMMIT / ROLLBACK from the caller is blocked.
• Audit log in a local SQLite file: who, when, which SQL, and whether it was blocked or executed. Executed statements are recorded after they commit. A statement that SQL Server rejects (for example permission denied) or a request with a bad key is not recorded.

Always blocked

DROP TABLE, DROP DATABASE, RESTORE DATABASE / RESTORE LOG, ALTER DATABASE … SET, sp_executesql, xp_cmdshell, dynamic EXEC of a variable or string, identity switching (REVERT, EXECUTE AS, SETUSER), permission changes (GRANT, DENY, REVOKE), and caller-managed transactions (BEGIN TRAN, COMMIT, ROLLBACK, SAVE TRANSACTION).

Blocked unless the admin allow-lists it

TRUNCATE TABLE, ALTER TABLE … DROP COLUMN, and EXEC of a named stored procedure (including INSERT … EXEC). Allow-list entries are written as schema.name; a statement that names a database or a server (OtherDb.dbo.T, [srv].db.dbo.P) is never matched against them.

This list is deliberately narrow. It is not "everything an AI could break": DROP INDEX, sp_rename, BACKUP DATABASE, or a Linked Server OPENQUERY are not specially handled and run if the real login may run them. The real security boundary is the SQL login's own grants, so issue each API key against an account with the least privilege you can accept, never sysadmin or db_owner.

Local mode

Runs on your own machine, started by your AI tool over stdio. No server, no Docker, no API keys. Settings come only from environment variables (not from appsettings.json or the command line). Tested on Windows with integrated authentication.

dotnet tool install -g LogCarverGuard.Local

claude mcp add logcarverguard --env LOGCARVERGUARD_CONNECTION_STRING="Server=localhost;Database=MyDb;Integrated Security=true;TrustServerCertificate=true" -- logcarverguard

Or run it without installing, through dnx (end the command with -- dotnet dnx LogCarverGuard.Local --yes).

Read-only mode lets SELECT (without INTO) through, plus SET, DECLARE and PRINT. Everything else is blocked with a reason, including EXEC even when it is allow-listed, NEXT VALUE FOR, and the remote or file sources OPENQUERY, OPENROWSET and OPENDATASOURCE (they can run a write on another server). What read-only mode does not cover: a SELECT that calls a CLR or extended-procedure function with side effects, long-running or expensive queries, and locks. Also give the login only the permissions it needs; the guard is a second layer, not the first.

What local mode is, and is not. It is a guardrail against an agent doing something destructive by accident. It is not a security boundary:

• The connection string, and so the credentials, live on your machine and in your AI tool's configuration. An agent that can run shell commands or read that configuration can connect to SQL Server directly and skip this proxy.
• Every statement runs as the one login in the connection string. There is no per-person identity; the audit log records the operating-system user name and is a local file.
• For a real boundary use the central service below: SQL Server only accepts connections from the proxy, and each person has their own login.

Install the central service

Needs a Linux host with Docker (or the .NET 10 SDK for the native install below), and a SQL Server with TCP/IP enabled and mixed-mode authentication.

1. Create the service login and let it impersonate each user's own login:

   CREATE LOGIN logcarverguard_svc WITH PASSWORD = '…';

GRANT IMPERSONATE ON LOGIN::[alice_sql_login] TO logcarverguard_svc;

In the target database, create a database user for the service login and one for each person's login, then give each person the permissions they normally have; the proxy never widens them:

   CREATE USER logcarverguard_svc FOR LOGIN logcarverguard_svc;

CREATE USER alice_sql_login FOR LOGIN alice_sql_login; GRANT SELECT, UPDATE ON dbo.Orders TO alice_sql_login;

1. Clone and configure

   git clone https://github.com/caiderek/LogCarverGuard

cd LogCarverGuard

Edit docker-compose.yml and set LOGCARVERGUARD_SQLSERVER_CONNECTION_STRING. For production prefer a mounted secret file and LOGCARVERGUARD_SQLSERVER_CONNECTION_STRING_FILE.

1. Start

   docker compose up -d --build

docker compose logs -f

1. Issue an API key (--login is the user's own SQL login, not the service login). The key is printed once:

   docker compose exec logcarverguard dotnet cli/LogCarverGuard.Cli.dll \

issue-key --owner alice --login alice_sql_login

1. Point your MCP client at http:// :8080/ and send the key in the header X-LogCarverGuard-Key.

Other key commands: list-keys (never prints the key itself) and revoke-key --id .

Linux notes

• Docker is the main install path for the central service on Linux. The image is built from the official .NET 10 images (mcr.microsoft.com/dotnet/sdk:10.0 to build, aspnet:10.0 to run). It does not depend on a particular distribution. I have not tested this Docker setup on a specific distribution. Native (non-Docker) steps for Rocky Linux are below.
• You need Docker with the Compose plugin on the host, and the container must be able to reach SQL Server over TCP (the sample connection string uses port 1433). Rocky Linux does not ship Docker (its default is Podman); Docker and the Compose plugin come from Docker's own docker-ce repository.
• The container runs as a non-root user and listens on port 8080. The audit log and the API key store are SQLite files in the /data volume, so keep that volume and back it up.
• docker-compose.yml publishes the port on 127.0.0.1 only. To reach it from other machines, put a TLS-terminating reverse proxy in front, as described in Hardening for production. Opening port 8080 directly to the network sends the API key over plain HTTP.
• If the host runs a firewall or SELinux, I have not tested how this Docker setup behaves under them (the native Rocky test below did include both).
• Local mode was tested on Windows with integrated authentication only. I have not tested it on Linux. Integrated authentication is a Windows feature, so on Linux you would need a connection string with SQL authentication.

Native install on Rocky Linux (without Docker)

The steps below follow the guide I wrote for the Pro build, which I ran on a real Rocky Linux 9 VM and a real Rocky Linux 10 VM. That was an earlier Pro build: it adds undo on top of the same request handling, and it connected to SQL Server as sa, so the non-sysadmin service login described above was not part of those runs. I have not re-run these steps from this Free repo; if one fails, please open an issue.

# 1. .NET 10 SDK (Rocky 9 shown; on Rocky 10 use rhel/10 in the URL)

sudo dnf install -y https://packages.microsoft.com/config/rhel/9/packages-microsoft-prod.rpm sudo dnf install -y dotnet-sdk-10.0 git

2. Service account, build

sudo useradd --system --no-create-home --shell /usr/sbin/nologin logcarverguard sudo git clone https://github.com/caiderek/LogCarverGuard /opt/logcarverguard/src cd /opt/logcarverguard/src sudo dotnet publish src/LogCarverGuard.Server/LogCarverGuard.Server.csproj -c Release -o /opt/logcarverguard/server sudo dotnet publish src/LogCarverGuard.Cli/LogCarverGuard.Cli.csproj -c Release -o /opt/logcarverguard/cli

3. Data directory and the service login's connection string

sudo mkdir -p /var/lib/logcarverguard /etc/logcarverguard sudo chown logcarverguard:logcarverguard /var/lib/logcarverguard sudo tee /etc/logcarverguard/sql-connstring.txt > /dev/null <<'EOF' Server=your-sql-server-host,1433;Initial Catalog=your-database;User Id=logcarverguard_svc;Password=CHANGE_ME;TrustServerCertificate=true; EOF sudo chown logcarverguard:logcarverguard /etc/logcarverguard/sql-connstring.txt sudo chmod 600 /etc/logcarverguard/sql-connstring.txt

Drop TrustServerCertificate=true once SQL Server has a certificate this host trusts (see Hardening for production).

Create /etc/systemd/system/logcarverguard.service:

[Unit]

Description=LogCarverGuard MCP proxy After=network.target

[Service] Type=simple User=logcarverguard Group=logcarverguard WorkingDirectory=/opt/logcarverguard/server ExecStart=/usr/bin/dotnet /opt/logcarverguard/server/LogCarverGuard.Server.dll Restart=on-failure RestartSec=5 Environment=ASPNETCORE_URLS=http://127.0.0.1:8080 Environment=LOGCARVERGUARD_SQLSERVER_CONNECTION_STRING_FILE=/etc/logcarverguard/sql-connstring.txt Environment=LOGCARVERGUARD_AUDIT_DB_PATH=/var/lib/logcarverguard/logcarverguard-audit.db Environment=LOGCARVERGUARD_APIKEYS_DB_PATH=/var/lib/logcarverguard/logcarverguard-apikeys.db

[Install] WantedBy=multi-user.target

sudo systemctl daemon-reload

sudo systemctl enable --now logcarverguard sudo systemctl status logcarverguard --no-pager sudo journalctl -u logcarverguard -n 20 --no-pager # expect "Now listening on: http://127.0.0.1:8080"

Issue a key. Run the CLI as the service user so the key file stays writable by the service.

sudo -u logcarverguard dotnet /opt/logcarverguard/cli/LogCarverGuard.Cli.dll \ issue-key --owner alice --login alice_sql_login \ --apikeys-db /var/lib/logcarverguard/logcarverguard-apikeys.db

• ASPNETCORE_URLS above listens on 127.0.0.1 only. For access from other machines, put a TLS-terminating reverse proxy in front (see Hardening for production). In my Rocky tests the service listened on all interfaces (http://+:8080) and I opened the port with firewall-cmd --permanent --add-port=8080/tcp and --reload; that sends the API key over