Scope MCP database connections to one project and read-only roles
You will narrow the MCP database connection to a single project with a read-only role. This limits what a hijacked assistant session can read or leak.
- Pick one projectConnect only the project the assistant needs
- Check the roleConfirm the connection does not use service_role
- Narrow the grantsGive the role only the data it needs
- Enable read-only SQLLimit the path to reads
- Review tool callsCheck each query before it runs
Why it matters
In a demonstration, instructions planted in a customer support ticket redirected a developer's MCP assistant into reading private tables and copying them into a customer-visible reply. The demo used service_role privileges, which bypass row-level security (General Analysis (opens external site)). Not every MCP connection uses that role, so check which role yours uses before assuming you are exposed or protected.
Steps
- Decide which single project the assistant needs and connect only that one. Avoid setups that reach several projects through one connection.
- Check which database role your MCP connection uses. Confirm it is not service_role, since that role bypasses row-level security (General Analysis (opens external site)).
- Use a role with narrower privileges and limit it to the data the assistant actually needs. Read-only access still lets the assistant read whatever that role can see (General Analysis (opens external site)), so the grants themselves matter.
- Enable read-only SQL for the connection. Project scoping, read-only SQL and tool-call review are the controls that limit this path (General Analysis (opens external site)). Check your MCP server's documentation for the exact setting.
- Keep one project and one role in your MCP client configuration, and update the configuration whenever the project or role changes.
- Review each tool call before it runs, especially queries that pull large tables or send results outside your editor. Tool-call review is one of the limits on this path (General Analysis (opens external site)).
- Rotate the database credentials if you suspect a session read data it should not have.
Common mistakes
- Assuming read-only means the assistant cannot see sensitive data. It can read whatever the role is allowed to see (General Analysis (opens external site)).
- Using a service_role key for the MCP connection because it is already in your project settings.
- Approving tool calls without reading the query.
- Adding a second project to the same connection for convenience.
Practical notes
Write down the role and its grants so you can review them later. Narrow scope and rotating credentials after exposure are standard practice and reduce risk, though no single setting removes it entirely.
Checklist
0 of 7 done