Who's asking? Give every agent query a name.

When an AI agent talks to your database, “who ran that query?” should not be a mystery. Two things make it answerable: a scoped, read-only role for the agent, and database logs that show what actually ran.

Bilge Ince's PGDay Lowlands talk, “Your Database Has No Idea Who's Asking”, is a good look at this pattern for governed Postgres access. According to its description, it covers EDB's open-source pg-airman-mcp, curated named queries, and purpose-tagged sessions that show up in the database logs. This post is not affiliated with or endorsed by the speaker; it is a pointer to a talk worth watching.

What it looks like with Bufflehead

We ran this on a throwaway local PostgreSQL 12 instance with one table of three fictional orders and one login role, agent_reader, that has SELECT on that table and nothing else. Connection and statement logging were on, with the application name in the log prefix:

log_connections = on
log_statement = 'all'
log_line_prefix = '%m [%p] user=%u db=%d app=%a '

We then connected using Bufflehead's direct Postgres connection code (the Go function the app uses for direct Postgres connections, called from a test rather than clicked through the UI) and ran a known-answer query: three orders totalling 4000 cents.

SELECT count(*), sum(total_cents) FROM orders

It returned count=3, sum=4000. Here is what the Postgres log recorded for that session (trimmed to the relevant columns):

user=agent_reader db=shop app=[unknown] LOG:  connection authorized: user=agent_reader database=shop application_name=openclaw
user=agent_reader db=shop app=openclaw LOG:  statement: SET default_transaction_read_only = on
user=agent_reader db=shop app=openclaw LOG:  execute stmtcache_0aa63086…: SELECT count(*), sum(total_cents) FROM orders

Every line carries the role (agent_reader) and an application name. Anyone reading the logs can pick out that session and see exactly which statement ran.

We also tried a write from the same session:

user=agent_reader db=shop app=openclaw ERROR:  cannot execute INSERT in a read-only transaction
user=agent_reader db=shop app=openclaw STATEMENT:  INSERT INTO orders VALUES (9,1)

The attempt is refused, and the refusal is logged with the same name attached.

What the name actually is

Two details matter here. First, Bufflehead sets the Postgres application_name to the operating-system username of whoever runs it. In our run that was openclaw. It identifies the person or machine, not the purpose of a query, so it is not the purpose tagging the talk describes. Second, Bufflehead turns on default_transaction_read_only for its session, which is why the INSERT failed. The stronger boundary is still the role: agent_reader only had SELECT to begin with.

For attribution that survives a shared laptop or a service account, give each person or agent its own role, so the user= field in the log does the work.

What Bufflehead does and does not do

Bufflehead is read-only. The roles, logging settings and any curated queries are set up outside it, in Postgres. This walkthrough shows that a read-only session shows up in the logs under a named role. It does not make Bufflehead a governance product, and we only tested Postgres.

To repeat it on a disposable database, the whole setup is a few statements:

CREATE ROLE agent_reader LOGIN PASSWORD 'demo';
CREATE DATABASE shop;
\c shop
CREATE TABLE orders (id int PRIMARY KEY, total_cents int);
INSERT INTO orders VALUES (1, 1000), (2, 2500), (3, 500);
GRANT CONNECT ON DATABASE shop TO agent_reader;
GRANT SELECT ON orders TO agent_reader;