Platform
Implementation guideAvailable now

PostgreSQL execution evidence for AI agents

Where SmartVerify sits, what it records, how PostgreSQL can enforce a read-only role, and what the current deployment does not claim to see.

Architecture and deployment position

An Envoy-based inline edge worker runs inside the customer VPC on the PostgreSQL connection path. The agent continues to use the PostgreSQL protocol and the database remains the enforcement authority for database privileges. No application-code instrumentation is required.

Evidence produced

The signed per-session evidence record contains the statement as executed, returned row count, columns read with sensitivity labels, session, and agent identity. Retention is configurable, and longer periods with an immutable export are available for estates with a mandated retention period.

Conceptual record fields, not a public API schema

Execution
Statement as executed; returned row count
Data
Columns read; configured sensitivity labels
Context
Session and agent identity
Integrity
Signed at the moment of observation

Use PostgreSQL privileges for write refusal

For an agent that should only read, connect it as a role with no write privileges. PostgreSQL then refuses writes itself. This available control is distinct from SmartVerify rules that refuse individual statements by kind, target table, column, or value, which remain in design partner build.

Standard PostgreSQL SQL

-- Example names: app_db, app_schema, app_owner, agent_reader.
-- Run as an administrator; provision authentication outside source control.
CREATE ROLE agent_reader LOGIN;
GRANT CONNECT ON DATABASE app_db TO agent_reader;
GRANT USAGE ON SCHEMA app_schema TO agent_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA app_schema TO agent_reader;

-- Default privileges must target the role that creates future tables.
ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA app_schema
  GRANT SELECT ON TABLES TO agent_reader;

-- Do not grant INSERT, UPDATE, DELETE, TRUNCATE, or schema ownership.

Replace the example database, schema, owner, and reader role names for your estate. The FOR ROLE value must be the role that creates future tables. Store credentials in your existing secret manager, rotate them normally, and review grants for every schema the role can reach.

Current limitations

  • Only traffic routed through the inline edge worker is observed.
  • PostgreSQL Record and role-based write refusal are available now; individual statement refusal remains in design partner build.
  • The evidence record does not replace PostgreSQL authorization, database auditing requirements, or credential management.
  • Latency comprises one network hop and inspection; measured results are reported by deployment shape.

Check the Platform coverage grid for the authoritative availability status.