Privacy and Security Best Practices

You’re three lines into asking the agent to “debug why the prod database keeps timing out,” and you’ve already pasted the full DATABASE_URL — host, user, and password — into the chat. Or you find a community MCP server that promises one-click Postgres access, and you’re about to point it at your production database with your admin credentials. Both moves feel harmless in the moment. Both can leak the keys to your business.

AI assistants are safe on proprietary code if you configure them deliberately: turn on the right data-retention setting for your tool, never let a secret reach the model, and give every MCP server the least privilege it needs.

What You’ll Walk Away With

• Where each tool’s privacy/data-retention setting lives and what it actually guarantees
• A secret-scanning prompt to run on every diff before commit
• A security-review prompt for AI-generated code (XSS, CSRF, SQLi, broken authz)
• A least-privilege pattern for database MCP servers, with the exact GRANT

Find Your Tool’s Data-Retention Setting

“Privacy Mode” is not universal — each vendor has its own control and its own guarantee. Know which one applies to you before you paste a single proprietary line.

Cursor

Cursor has an explicit Privacy Mode toggle (Cursor Settings). With it on, your code is not stored by Cursor and not used for training — a zero-data-retention (ZDR) guarantee. Privacy Mode is on by default for Enterprise teams, and admins can enforce it team-wide so individuals can’t turn it off. Indexing still computes embeddings, but under Privacy Mode plaintext code isn’t retained server-side after the request.

Claude Code

For commercial usage — Team, Enterprise, and API — Anthropic does not train models on your code or prompts by default. Free/Pro/Max accounts may be used for training only if you opt in. Default retention is 30 days; zero data retention is available with appropriately configured API keys (transcripts aren’t retained server-side). If you’re on a personal plan for work, check the data-usage setting and prefer commercial terms for proprietary code.

Codex

Codex inherits ChatGPT Enterprise guarantees: no training on enterprise data, and zero data retention for the CLI and IDE, with residency/retention following your ChatGPT Enterprise policies. On personal ChatGPT plans, review your data controls (chat history / “improve the model” settings) before using Codex on a private repo.

Caution

“Privacy Mode is on” does not mean “secrets are safe to paste.” ZDR governs storage and training — it does not stop a secret from being readable in transit, surfacing in an ephemeral error log, or getting echoed back into a transcript a teammate later reads. Treat retention settings and secret hygiene as two separate controls.

Never Let a Secret Reach the Model

The rule is unchanged from ordinary security hygiene, but the surface is wider: API keys, tokens, passwords, and DB connection strings must never appear in a prompt. Reference process.env.DATABASE_URL, not the literal value. The most reliable enforcement is automation, not willpower — wire secret scanning into a pre-commit hook (e.g. gitleaks) so a leaked credential is caught before it’s ever committed or pasted.

Make the agent itself part of the check:

Tip

Secret-scan prompt (run on the diff before every commit):

Scan this diff for hardcoded secrets: API keys, tokens, passwords,
private keys, and database/connection strings. For each finding, output
file:line, the secret type, and a safe replacement (env var or secret
manager reference). If you find none, say so explicitly. Diff:
<paste `git diff --staged` here>

Review AI-Generated Code Like a Hostile PR

Treat every block the AI writes as a pull request from a brand-new contributor: it may be functionally correct and still ship an injection bug or a missing authorization check. Don’t just skim the diff — make a second pass with the model wearing a security hat, then verify the findings yourself.

Tip

Security-review prompt for AI-generated code:

You are a senior application-security engineer reviewing this change for
a production service. Audit it for: XSS, CSRF, SQL/NoSQL injection,
broken access control (can a user act on another user's resource?),
SSRF, and unsafe deserialization. For each issue: severity, the exact
file:line, why it's exploitable, and a concrete fix. Ignore style. Code:
<paste the change>

This is the human-in-the-loop discipline that separates production work from demos — see Human in the Loop for the full review workflow.

Give MCP Servers Least Privilege

The Model Context Protocol lets your agent connect to external tools — a database, GitHub, a browser. Every MCP server is executable software with whatever permissions you hand it, so an over-privileged or unvetted server is a real attack surface. Two rules cover most of the risk.

First, vet the server before you install it. Prefer official, scoped packages (e.g. @modelcontextprotocol/server-github, @modelcontextprotocol/server-postgres) over an unknown community fork. Have the agent summarize what a server actually does before you wire it up:

Tip

MCP-server vetting prompt:

I'm considering installing this MCP server: <repo URL or npm package>.
Read its source/README and tell me: (1) what tools/commands it exposes,
(2) what network calls or external services it makes, (3) what
credentials or scopes it requires, (4) any command execution or file
write it performs. Flag anything that needs more than read access.

Second, connect it with least-privilege credentials. For a Postgres MCP server, never hand it your app or admin role. Create a read-only role scoped to exactly what the agent needs:

CREATE ROLE ai_readonly LOGIN PASSWORD 'rotate-me';
GRANT CONNECT ON DATABASE app TO ai_readonly;
GRANT USAGE ON SCHEMA public TO ai_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO ai_readonly;
-- new tables inherit read-only access automatically
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO ai_readonly;

Then point the MCP server’s connection string at ai_readonly — identical config across Cursor, Claude Code, and Codex, since all three read the same mcpServers block. Now a hallucinated DROP TABLE is rejected by the database, not by hope. See Database MCP for full setup and MCP Security for the threat model.

Approve Actions Deliberately

Read the diff, not the summary

Before approving a file edit, read the actual diff, not the agent’s one-line description of it. The summary is what the agent intended; the diff is what it’ll write.

Gate destructive commands

Never auto-approve terminal commands that delete, deploy, or mutate data. Run agents in a restricted mode (Cursor’s per-action approval, Claude Code’s permission prompts, Codex’s --ask-for-approval) so risky actions require an explicit yes.

When This Breaks

• You assumed Privacy Mode but were on a personal plan. A teammate logged into a personal Cursor/ChatGPT account on a work machine, bypassing the team’s ZDR enforcement. Fix: enforce Privacy Mode at the team level and restrict logins to corporate accounts (Cursor’s Allowed Team IDs; ChatGPT Enterprise SSO).
• A secret leaked through an MCP server’s logs. The model never saw the credential, but the server printed the full connection string to stderr on a connection error. Fix: scope the server’s credentials (read-only role above), and never put secrets in the MCP args — load them from the environment.
• Over-privileged DB creds. The agent ran an exploratory UPDATE because the role you gave the MCP server could write. Fix: the read-only GRANT above; create a separate, deliberately-invoked write role only when you actually need mutations.
• Sensitive files reached the index. A .env or key file got embedded because it wasn’t ignored. Fix: add it to .cursorignore (Cursor) and .gitignore; rotate any credential that was indexed.

What’s Next

• MCP Security — the full MCP threat model and hardening checklist
• Database MCP — connecting databases safely with least privilege
• Human in the Loop — review discipline for AI-generated code
• Team Collaboration — enforcing these policies across a team