Guard AI agent Postgres writes using OpenAI, FirstHelm, and Slack approvals

Quick overview

Your agent can propose a SQL write; this workflow makes sure it never runs one it shouldn't. A deterministic allowlist check, a FirstHelm policy gate and a human approval step sit between the model and Postgres. Nothing destructive executes unlogged.

How it works

1. Receives a POST request via webhook containing an instruction, requester, and environment.
2. Logs the incoming write request to FirstHelm for audit purposes.
3. Uses OpenAI to generate a JSON response containing one proposed Postgres SQL write statement and a short rationale.
4. Deterministically validates the SQL against safety rules (single statement, no DDL/privilege changes, scoped UPDATE/DELETE with WHERE, and allowed tables) and immediately refuses and audits failures.
5. Sends the validated SQL to FirstHelm’s policy gate to return a verdict of allowed, needs_approval, or blocked.
6. If allowed, executes the SQL in Postgres, logs execution details (including rows affected) to FirstHelm, and returns an executed response to the caller.
7. If needs_approval, creates a FirstHelm approval request, posts the SQL to Slack for review, waits, re-checks the FirstHelm gate, and then either executes or blocks and returns a refusal.

Setup

1. Create a FirstHelm agent, generate a FirstHelm API key, and configure the necessary constraints so evaluateConstraint can return allowed/needs_approval/blocked.
2. Replace YOUR_AGENT_ID and YOUR_FIRSTHELM_API_KEY in all FirstHelm HTTP requests.
3. Edit the SQL validator allowlist to set ALLOWED_TABLES to the specific Postgres tables the agent is permitted to write to.
4. Add credentials for OpenAI, Postgres, and Slack, and set the Slack channel (for example #ai-write-approvals) used for approval and blocked notifications.
5. Copy the webhook test URL and configure the calling system to POST requests to it with instruction, requested_by, and environment fields.
6. Use a Postgres role limited to the tables this agent may write to — the guardrail is a control, not a substitute for database permissions.

Requirements

• A FirstHelm account with an agent and API key (firsthelm.dev), OpenAI credentials, a Postgres connection, and a Slack workspace with a channel for approval notifications.

Customization

• Set ALLOWED_TABLES to the tables your agent may touch, tighten or loosen the FirstHelm constraints that decide allowed / needs_approval / blocked, change the 10-minute approval wait, and point Slack at whatever channel your on-call team watches.

Additional info

Scope of the guardrail. The human decision happens in the FirstHelm dashboard, not in Slack — the Slack message posts the proposed SQL and links to the approval queue, and the workflow re-checks the policy gate before anything executes in Postgres.

Where the boundary actually sits. The deterministic validator is a fast first filter, not a security wall: it blocks DDL, multiple statements and unscoped UPDATE/DELETE, and enforces a table allowlist. The real controls are the FirstHelm policy gate and the human approval step. Use a Postgres role limited to the tables this agent may write to, so the guardrail adds to your database permissions rather than replacing them.