The fastest way to make an AI database agent dangerous is to connect it with the same credential a senior engineer uses in production.
The model does not need your admin key.
It needs a narrow, explicit operating lane.
A safer MCP database setup starts with the job:
- answer product analytics questions
- inspect support tickets
- summarize operational metrics
- prepare a write action for human approval
Each job deserves its own credential scope.
Read-only should be the default. Usually against approved views, not raw application tables.
Writes need a different lane entirely:
- separate role
- separate tool
- dry-run preview
- rows/objects affected
- approval requirement
- audit receipt after execution
Longer version: Scoped credentials for MCP database servers
The practical rule:
Do not expose a database connection first and decide policy later. Define the job, then issue the smallest credential that can do that job.
Top comments (1)
Strong agreement on least-privilege. One extension worth making explicit: the audit log for writes needs its own trust boundary. If the agent appends to its audit trail using the same role it writes data with, a compromised or buggy agent can also rewrite its own history — the log only has the agent's word for it.
For post-incident forensics, or when a team other than the one running the agent needs to verify what actually happened, that log should be append-only and integrity-protected independently of the agent's write credential. So it's really a three-way split, not two: read-only, scoped-write, and append-only-to-audit (and nothing else).