SchemaGate 0.1.43 can execute SQL—but its caller identity is still an assertion

SchemaGate 0.1.43 moves the project from helping an agent choose database context to executing the resulting query. The release adds a run_query MCP tool that accepts one read-only SELECT and returns rows, closing the gap after select_schema supplied DDL and the client’s model generated SQL. The project also keeps an answer() path for agents with their own configured model; without one, it returns the schema selection and points the caller to run_query instead of failing. Source: SchemaGate v0.1.43 release

Execution gets three gates

Before a query reaches the database, SchemaGate says it checks that the request contains one statement, that the statement is a read, and that every referenced table is visible to the current principal. The release says the table test covers names inside joins and common table expressions, rather than only the most obvious table token. It also says an earlier authorized call does not carry authorization into a later query. Source: SchemaGate v0.1.43 release

The refusal behavior is deliberately conservative. Anonymous callers, callers with the wrong role and queries that reference unknown tables are rejected. SchemaGate does not tell the caller whether an unknown name is restricted, misspelled or absent from the reflected schema. That avoids turning the error path into a catalog-discovery side channel, although the release does not claim this is a complete database-security boundary. Source: SchemaGate v0.1.43 release

Database errors are returned in the database’s own wording so a model can attempt a repair. That is useful for an agent loop, but operators should still treat those messages as potentially sensitive because they can expose details about the database implementation or query shape. The release documents the pass-through behavior; it does not say errors are redacted. Source: SchemaGate v0.1.43 release

The trust boundary is the deployment decision

The most important caveat is explicit: principal and roles are asserted by the MCP client, and the server believes them. There is no token or session check, and a shared secret is not implemented in this release. The project describes that arrangement as appropriate over stdio or behind an authenticating layer, and inappropriate on an open port. Source: SchemaGate v0.1.43 release

That makes v0.1.43 a meaningful execution release, not a standalone authorization system. Teams adopting it should place authentication in front of any network exposure and bind verified user identity to the principal and role fields before relying on the table checks. The release reports 858 tests plus a property suite, but publishes no production deployment evidence or workload benchmark, so those controls still need testing against each organization’s schemas, drivers and identity path. Source: SchemaGate v0.1.43 release