An AI agent can work safely on a PostgreSQL database if the database itself enforces the permissions, not a parser on the application side: a role with only SELECT rights for reading, a separate role for writing that cannot take over the owner account, and access switched on separately for each database. On Aderlo Cloud every PostgreSQL 18 database has an agent-access switch (none / read / full, none by default), connections only over TLS from addresses on your list, and the pgvector, PostGIS and pg_cron extensions.
Why a database password is not enough for an agent
The simplest approach — giving the agent the database owner’s connection string — means the agent can do anything: drop a table, change a password, wipe the data. A session-level “read-only” setting protects nothing, because in PostgreSQL a session removes it with a single SET transaction_read_only = off. The only real security boundary is the role’s privileges.
How Aderlo Cloud solves it
| Agent access level | What the agent can do | What it cannot do |
|---|---|---|
| none (default) | Cannot see the database | — |
| read | SELECT on tables and views, including ones created later | Write anything, even after switching off read-only mode in the session |
| full | Write, create and alter tables | Take over the owner role, change passwords, create databases, read server files |
- The agent sees only the databases of the service the token was issued for — a token handed to someone working on one site does not open the rest.
- The call log records the database name, never the SQL or the data.
- MCP tools:
list_database_access,db_schema,db_query— the same for MySQL and PostgreSQL.
What else a PostgreSQL database on Aderlo Cloud has
- PostgreSQL 18 in its own container for each instance, with separate memory, CPU and disk limits.
- Extensions out of the box: pgvector, PostGIS, pg_cron, pg_net, pg_stat_statements and the trusted contrib ones (pg_trgm, pgcrypto, uuid-ossp, citext, hstore). New databases inherit pgvector and PostGIS.
- Webhooks from the database: a change in a table can call an HTTP address, such as an n8n workflow.
- TLS only (verified
verify-full, TLS 1.3) and only from addresses you allow — up to 5 addresses per instance. - PgBouncer in transaction mode for serverless applications; a separate direct address for migrations.
- Backups: a dump of every database and the roles, restorable to a fresh server together with extensions, pg_cron jobs and agent access.
- Ready-made connection recipes in the panel: Prisma, Drizzle, node-postgres, psql, DBeaver, n8n.
When to give an agent read access, and when full access
- Read: analytics, reports, answering questions about the data, checking data quality. A good default for production databases.
- Full: the agent builds its own schema (for example a table of vectors for search), migrations in a working database, clean-ups you have asked it to do.
- None: databases with customers’ personal data that the agent has no reason to look at.
Frequently asked questions
- Can an AI agent delete my PostgreSQL database?
- At the “read” level the agent cannot change anything. At the “full” level it can alter and drop tables in the database, but it cannot take over the owner role, change passwords or create new databases — so give full access to working databases, and take a backup before larger agent jobs.
- Can I connect to the database from Vercel?
- Yes, over TLS from addresses on the allow-list. Without static IP addresses, Vercel’s outbound addresses change, so you then have to keep the list updated or use Vercel’s paid static IP option.