TL;DR. On October 1, 2026, Microsoft open-sourced two MIT-licensed repositories: postgres-mcp, a Rust MCP server that gives coding agents live PostgreSQL context and permitted operations, and postgres-skills, 33 expert sub-skills that teach those agents the Postgres facts models get wrong. The notable part is the posture. After a season of vendors claiming enforcement spans, Microsoft's security model declines to claim one: the server "doesn't decide what's allowed", role permissions remain the boundary, and the server cannot tell a request you meant from one the model was tricked into making. That honesty draws the remaining gap precisely. The role rules on objects. Nothing rules on the query. And no skill file carries what your data means.
Microsoft announced on October 1 that it has open-sourced the Postgres MCP Server under the MIT License: a server written in Rust that connects MCP-compatible coding agents, GitHub Copilot, Claude Code, Cursor, Codex and others, to PostgreSQL running locally, on-premises, on Azure, AWS, or GCP. Beside it sits a second MIT repository, Postgres Skills, 33 expert-curated sub-skills that load Postgres expertise into the same agents. Connecting an agent to Postgres has been a solved problem for a year; directories track dozens of community servers, and Bytebase's comparison of the open-source field, published the same day, weighs three of them almost entirely on access control. What a first-party pair from Microsoft changes is less the plumbing than the architecture it admits to: expertise ships in a repository because the model does not carry enough of it, and enforcement stays in the database because the server cannot supply any.
Two repositories, one division of labor
The server side is deliberately plain. @microsoft/postgres-mcp runs from npx on Node 22 or later, speaks MCP over stdio, and exposes PostgreSQL operations as tools: a read-only query tool, a separate tool for DDL and DML, schema introspection that returns CREATE scripts for tables, indexes, functions, and sequences, CSV inspection and bulk load through COPY, and diagnostics that probe server capabilities and collect performance metrics. Connection profiles are named, stored passwords go to the OS keyring rather than a config file, and Azure profiles without a stored password authenticate through Microsoft Entra ID. The changelog marks all of it v0.1.0, release status preview.
The skills side is where the effort visibly went. Postgres Skills is a plugin for Claude Code, GitHub Copilot CLI, and Codex CLI that bundles the MCP server and adds a routing skill plus 33 sub-skills in three tiers: 11 foundational skills that apply to any PostgreSQL deployment, 12 for Azure Database for PostgreSQL and the HorizonDB preview, and 10 covering the full Apache AGE graph lifecycle from ontology derivation to openCypher querying. The plugin requires explicit confirmation before database writes, CSV imports, graph writes, or Azure resource changes, treats database content as untrusted data, and ships with the server's telemetry disabled.
The skills catalog is a published list of model failure modes
Each sub-skill table in the README carries a column titled "What the agent learns that LLMs get wrong", and the entries are specific enough to sting. Extensions: that shared_preload_libraries requires a restart. Connection pooling: that work_mem multiplies across pooled connections. Azure recovery: that point-in-time restore creates a new server rather than rewinding the old one, and that a deleted server is revivable for five days through az rest because no CLI subcommand exists for it. Major version upgrades: one-way, no version skipping, validate first. None of this is exotic. All of it is the kind of versioned, managed-service-specific fact that a model trained on the general internet states confidently and gets wrong, and Microsoft, which operates the managed service, has now written the corrections down as files that update like code.
That is the admission worth registering: the vendor closest to the engine concluded that model weights do not hold Postgres well enough to operate it, so the expertise ships beside the model instead of inside it. But notice what kind of knowledge survives being published this way. Every one of the 33 sub-skills is engine knowledge, true of every PostgreSQL on earth, which is exactly why a public repository can hold it. The README's own pitch for what the plugin does with your database is that it "reads your live schema, tier, and settings first, then tailors the answer." Schema, tier, settings: structure. Which of your tables is the source of truth for revenue, which column is validated and which is a stale import, which rows an agent on this task has any business reading: that is not in any skill file, because it is not general knowledge, and it is not Microsoft's to publish.
One sub-skill reaches toward it. The ontology-derivation skill reads your schema and foreign keys, proposes tables as node labels and relationships as edges, and is under a hard rule never to finalize the result without human approval. That is meaning derived from structure, at session time, validated by whoever happens to be at the keyboard, and rebuilt from scratch the next time someone asks. It is the same job a context layer does, minus the properties that make the result trustworthy: persistence, ownership, and a record of what was validated against what was merely inferred.
A security model that declines to claim a span
The README's security section opens with a sentence most vendors would bury: "The server doesn't decide what's allowed". Your database does. The server passes requests along and runs them as the database user in the connection profile, and, in the README's words, "anything that database user can do, the AI can do." It goes one honest step further: the server "can't tell the difference between a request you meant to make and one the AI invented or was tricked into making." The announcement compresses the whole posture into one line: "PostgreSQL role permissions remain the security boundary."
Read against the last six weeks of launches, the modesty is striking. CData's Connect AI Gateway claims enforcement "down to the record" on its mediated paths. Nvidia's Open Agent Safety Platform quarantines an agent that leaves its boundary in milliseconds. Microsoft, shipping the component that actually touches the database, claims nothing: no policy engine, no query inspection, no enforcement span at all. After a season of spans, a vendor drawing none on its own component is the more accurate map.
What the pair does supply is three checkpoints, each ruling on something different. The MCP client's approval prompt rules per tool call, with human judgment as the filter. The connection profile's access_mode rules on tool class: a profile set to ro withholds the write tools, though a freshly created profile permits them unless you set it. The database role rules on objects, GRANT by GRANT, with row-level security where someone has written policies. Microsoft's recommendation for autonomous agents is to stack the last two: a read-only profile and a read-only role.
Three checkpoints, three granularities. The role is the last gate that rules, and it rules on objects. The plan, the rows, and the meaning of what comes back are past the end of the line.
What a role cannot rule on
The boundary Microsoft names is real, and it is object-granular. A role that may read a table may read all of it, for any purpose, at any volume, and the grant is satisfied either way. We measured the practical consequence in read-only is not enough: a SELECT-only role exfiltrated two million rows in 557 milliseconds, every one of them authorized. The injection sentence in Microsoft's README makes the same point from the other side. If the server cannot distinguish a request you meant from one the model was tricked into, then after the role check, the only intent filter left is the approval prompt, and approval prompts are exactly where humans learn to click through.
The skills have a parallel limit: they are advisory. The routing skill loads guidance when the plugin is installed, and nothing routes an agent through it. The same server answers an agent with no skills at all, the same database answers a connection string found in an environment variable, and the governed and ungoverned paths coexist exactly as they do in the dbt MCP server, where governed metric tools ship beside a raw execute_sql. Expertise that the agent may consult is not policy, and a checkpoint the traffic can skip is a convention.
What would it take to rule at the granularity agents actually fail at? The query, at parse time, read against a schema whose meaning is resolved: this role may read these tables for this task, this plan touches what the task predicted, this result set is proportionate to the question asked. Microsoft's pair supplies two of the inputs, live structure and engine expertise, and its security model is candid that the judgment layer between them does not exist in this stack. That layer needs what neither repository can contain: your estate's resolved meaning, validated by the people who own it, and a policy gate that reads it at request time.
Where Datapace fits
Datapace is building that layer: a semantic context layer for AI on databases, with resolved meaning validated by the people who own the data, the workload evidence beside it (cost, performance, usage and freshness, lineage), and a policy gate over what an agent may do and access, served over MCP. Microsoft shipping an honest pass-through server makes the missing piece easier to point at: the boundary is the role, the role rules on objects, and the gap between objects and intent is where agents on production databases get hurt. If your agents are about to get a first-party Postgres connection, safe AI database access is the conversation to have.
The preview label matters, and so does the direction. A first-party server with keyring credentials and Entra ID support will become the default connection path for a large share of agents touching Postgres, the way first-party anything does. The security model that ships with it is the right one to read now, before the default hardens: it tells you, in the vendor's own words, which problems the MCP layer will never solve for you.
Sources
- Microsoft Community Hub, Postgres MCP Server: Connect AI coding agents to PostgreSQL, October 1, 2026 (open-sourcing announcement, MIT license, Rust implementation, supported platforms, Entra ID, role permissions as the security boundary, Postgres Skills description).
- GitHub, microsoft/postgres-mcp README and CHANGELOG (tool list, connection profiles and keyring, access_mode defaults, security model quotes, preview status, Node 22 requirement).
- GitHub, microsoft/postgres-skills README (33 sub-skills and the three tiers, supported agents, confirmation and untrusted-data rules, telemetry configuration, sub-skill tables including ontology derivation).
- Bytebase, Top open source Postgres MCP servers, October 1, 2026 (the open-source field compared on access control and governance).