PostgreSQL controls for AI agents

The control gap

A database credential that enables useful analysis may also permit writes or destructive schema operations.

Database policy needs a stable operation model. Prefer named application operations or parsed statement facts over an opaque SQL string. Include database, schema, tables, tenant, statement class, estimated rows, transaction mode, and environment. Reads can still expose sensitive or cross-tenant data; writes and destructive DDL require stricter defaults and often a separate execution identity.

Test views, stored procedures, dynamic table selection, multi-statement requests, and queries whose apparent read triggers a side effect. Record affected row count and transaction status instead of copying row data. Endram can authorize normalized database actions and correlate outcomes, but SQL parsing, query sandboxing, database credentials, and native grants remain part of the execution architecture.

What good looks like

Routine PostgreSQL work continues automatically while sensitive actions are denied or held for a named reviewer.

• Classify select and insert separately from update and drop_table.
• Scope policy to database, schema, table instead of granting one undifferentiated PostgreSQL capability.
• Allow approved read schemas automatically, require data-owner approval for writes, and deny destructive DDL to agents.
• Preserve the delegated user, agent, request payload hash, decision, reason, and policy version.

A production workflow

1. The agent asks Endram to evaluate a PostgreSQL action before execution.
2. Endram matches the agent, delegated user, action, and target database.
3. Low-risk requests proceed; sensitive requests create a time-bound approval.
4. The approved request executes once, and its outcome is attached to the original decision.

A policy you can test

PostgreSQL high-impact approval is a concrete starting point, not a claim that one generic rule fits every environment. Replace example identities and selectors, validate the request shape, and begin in shadow mode.

name: postgres-high-impact
match:
  tool: postgres
  action: ["update", "drop_table"]
  environment: production
decision: require_approval
approval:
  expires_in: 15m
  reviewers: ["security-on-call"]

Endram keeps the policy version with every decision. A later change creates new evidence instead of rewriting why an earlier request was permitted.

Evidence to require

• A searchable record of attempted select and drop_table operations.
• The exact database and table targeted by each request.
• Which policy version matched and why the request was allowed, denied, or escalated.
• Who approved the action, when approval expired, and whether execution succeeded.

Buyer checklist

• Which PostgreSQL actions must never run without a human?
• Can policy restrict individual database or schema or table?
• How are user delegation and service credentials represented?
• What evidence will incident response need after an unexpected action?