Don't give your agent the production database

The second you hit Enter Friday night. You ask Cursor for a query: join orders to users, sort by last login. Three seconds later, an answer arrives with DBA-level confidence: SELECT o . id , o . amount , u . last_login_at FROM biz_order o JOIN sys_user u ON u . id = o . user_id ORDER BY u . last_login_at DESC ; Paste it into your client. Enter: ERROR: column "last_login_at" does not exist LINE 2: SELECT o.id, o.amount, u.last_login_at There is no last_login_at column. There never was. The model did not know — it just decided the column "should" exist. This failure has a name: invented column This is not "AI is not smart enough yet." It has a name — invented column : the model fabricates a plausible column name with no factual source, then writes it into a JOIN with unshakable tone. Invented columns are dangerous because they do not look like errors . last_login_at appears on 90% of user tables. Syntax is correct. Naming is conventional. Indentation is perfect. Mixed into ten correct JOINs, you will not catch it line by line. You find out in code review — or worse, in production logs. Three things you already tried A better prompt. "Do not invent column names; only use the schema I provide" — added to the system prompt. Works day one. By day three, long context and the model forgets. A prompt is a wish, not a constraint. @schema.sql . Export DDL and drop it into context. The most honest approach today — but two holes: it goes stale (last week's export does not know this week's column), and nobody maintains it (not in any approval flow; anyone can edit it; drift from the real database goes unnoticed). Live catalog MCP. Let the Agent query information_schema directly. Directionally correct — give the model a fact source instead of guesses. Tools like postgres-mcp and cloud vendor MCPs do solve half of "stop hallucinating column names." Worth acknowledging. Live catalog only gets you halfway Wire production into the IDE and you hit four walls: Permission-filtered inform