"The MCP server did it" is a bad line in your audit log

Somewhere in a Slack thread, a security team is asking who ran a query against production. The answer that comes back is "the MCP server did it." That's technically true and completely useless — it's the database equivalent of a building's security log saying "someone used the front door" instead of naming a person.

The mistake is baking access control into the query-logging layer instead of the credential layer. pgaudit, scrubbed views, statement timeouts — all of that is good hygiene, and none of it fixes attribution if every engineer's query flows through one shared service-account connection. The audit log is only as identity-aware as the credential that's actually touching the database.

Fewer shared credentials, not more logging

The fix isn't more logging, it's fewer shared credentials. If each engineer's MCP connection carries their own identity — their own IAM role, their own session — the query log stops needing to guess who asked. It already knows.

That's the model Bufflehead uses: each engineer runs their own binary and connects with their own AWS IAM role, including over SSM tunnels for private Postgres and MySQL instances. "The MCP server did it" becomes "this engineer's connection did it" for free, without building a custom credential-vending system.

It's also read-only by design, so it's not the tool that lets someone accidentally mutate production through an MCP call — usually a scarier failure mode than an audit log gap. Today it connects to Postgres, MySQL, BigQuery, S3, and local files.

Attribution and blast radius are two different problems. Solve them at the credential layer, and the logging problem mostly disappears on its own.