SQLGuard

Field note 04

Access mode is not authorize.

--access-mode=unrestricted and --security-mode write decide what class of SQL an agent may attempt. They do not answer whether this agent was permitted to run this statement.

By SQLGuard · · 3 min read

Database MCP servers keep inventing the same good idea: a mode switch. Restricted or readonly for production. Unrestricted or write for development. Sometimes an admin or unsafe tier for DDL. That design is correct for blast-radius control.

The pager question shows up after the switch is flipped. Once write mode is on, every mutating tool call shares the same permission envelope. The log may show the connection role. It rarely shows a decision bound to the exact SQL hash and a stable agent_id.

Mode answers capability. Authorize answers permission.

Capability: “this connection may run DML.” Permission: “agent X was allowed to run statement Y under policy Z before execute.” Those are different layers. Collapsing them makes post-incident reconstruction guesswork.

Keep the mode switch. Add a receipt at the mutate boundary. The mode still gates the tool set; the receipt gates the individual write.

Why this shows up in unrestricted Postgres MCP

Teams ship unrestricted because agents need to migrate, fix data, or commit after review. The product is useful. The missing artifact is portable evidence that travels outside the chat: who authorized the statement that just ran?

If this is your write path

Prove the gap with a free DENY on the Pilot Challenge, then Graduate Exact $100 when you want permanent provenance — or evaluate Gateway ($299/mo).