---
title: "Access controls and data protection"
description: "Distinguish console permissions, MCP scope and PostgreSQL roles."
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.pgnext.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Access controls and data protection

PG 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.

Source: https://docs.pgnext.dev/integrations/access/index.mdx