PG Next DocsPG Next access has several layers. Permission in one layer does not automatically grant access to every resource in another.
| Layer | Scope |
|---|---|
| Console session | Account identity, project ownership and admin privileges if assigned. |
| MCP key | Key owner, purpose, scope and permissions; the backend still checks authorization. |
| PostgreSQL role | SQL privileges within the connected database; separate from a console user. |
Use the minimum permissions
Grant read permissions for read tasks. Add credentials:read, write/delete permissions or password reset access only when needed. Service read-only mode may still block changes even if the key has write permissions.
Do not share secrets with an assistant through chat text. Use the client’s secret mechanism and verify identity with neon_whoami before each live task.
The IP list is not a PostgreSQL firewall
Current source stores project IP/CIDR rules as metadata. Compute runtime does not enforce that list for PostgreSQL connections. Do not rely on the console IP list as an active network access restriction.
Adding a rule does not establish that clients outside the list have been blocked. Actual network controls need separate operator verification.
Keep sensitive information private
Passwords, credential-bearing connection strings, MCP keys and verification/reset links can grant access. Redact them in screenshots, logs and support records. Test branches and exported CSVs still need data protection.