What can go wrong when an LLM touches your database
Unbounded DELETE / UPDATE
The agent misunderstands the scope. "Delete inactive users" becomes DELETE FROM users without a WHERE. 847,293 rows gone.
Schema destruction
DROP TABLE in a migration script the agent generated. Or TRUNCATE inside a CTE — syntactically valid, semantically catastrophic.
SQL injection via prompt
A user inputs '1=1 OR true' in a search field. The LLM forwards it as a WHERE clause. VETRO-090 catches the tautology.
These aren't hypotheticals — they're the three most common LLM-DB incidents in 2025. Vetro blocks all three.
What Vetro does in 0.9ms
Three real queries. The AST parser decides in microseconds. No guessing, no ML, no false positives.
3 lines to protect your LangChain agent
Vetro speaks the PostgreSQL wire protocol. Any driver, ORM, or framework that connects to Postgres works without changes.
# Before — direct DB access (dangerous)
db = SQLDatabase.from_uri("postgresql://user:pass@prod-db:5432/mydb")
# After — route through Vetro (safe)
db = SQLDatabase.from_uri("postgresql://user:pass@proxy.vetro.dev:5432/mydb")
# That's it. No other changes.// Change only the connection string
const pool = new Pool({
connectionString: "postgresql://user:pass@proxy.vetro.dev:5432/mydb"
// Was: "postgresql://user:pass@prod-db:5432/mydb"
});// Same pattern — Vetro is a transparent TCP proxy
const sql = postgres("postgresql://user:pass@proxy.vetro.dev:5432/mydb");Vetro speaks the PostgreSQL wire protocol. Any driver, ORM, or framework that connects to Postgres works without changes — SQLAlchemy, Prisma, Drizzle, ActiveRecord, pg, psycopg2, and more.
Every destructive pattern an LLM agent can generate
20 standard rules covering the full threat surface of LLM-to-SQL. All deterministic. All auditable.
A real incident, reconstructed
A support operator asked an LLM assistant to clean inactive users. Here's what happened.
The prompt
A support operator typed: "Clean up users who haven't been active in 90 days." The LLM assistant had database tool access via function calling.
The first query — safe
The agent generated and executed: DELETE FROM users WHERE last_active < NOW() - INTERVAL '90 days'. Valid. Forwarded.
The second query — catastrophic
The agent then generated: DELETE FROM sessions — no WHERE clause. It was "cleaning up" sessions belonging to those users. Without Vetro, this would have deleted every active session in production, logging out all users simultaneously.
What Vetro caught
VETRO-001 fired in 0.7ms. The query was blocked with AST node DeleteStmt > WhereClause = NULL, suggested fix DELETE FROM sessions WHERE user_id = $1, and a CRITICAL alert dispatched to Slack. The operator reviewed the audit trail the next morning.
Common questions about agent protection
Start protecting your LLM agents today
Change one line in your connection string. Every destructive query your agent can generate is blocked before it reaches production.