MCP security best practices: scoped tokens, audit logs, least privilege

MCP is powerful because it gives an AI agent genuine access to real systems — your database, your cloud, your source code. That same power is what makes misconfigured MCP stacks dangerous. Here is the five-layer defence model we run, plus three specific mistakes we see repeatedly in production.

Layer 1: least privilege, by default

The single biggest win. An agent almost never needs write access for daily work. Always start read-only; escalate only when the use-case genuinely requires it.

Postgres example: create a dedicated role with SELECT only, never connect with the app's own credentials.

CREATE ROLE ai_readonly WITH LOGIN PASSWORD '...';
GRANT CONNECT ON DATABASE prod TO ai_readonly;
GRANT USAGE ON SCHEMA public TO ai_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO ai_readonly;
ALTER ROLE ai_readonly SET statement_timeout = '10s';

Same pattern for AWS (read-only IAM role without iam:*), GitHub (fine-grained PAT scoped to specific repos), Slack (user token, not workspace admin).

Layer 2: scoped tokens, not personal credentials

Never use your own developer credentials in claude_desktop_config.json. Two reasons:

If the config leaks (backup, screen-share, git commit), the agent walks away with your full permissions.
Audit logs attribute every agent action to you personally. Good luck distinguishing "I deleted that" from "Claude deleted that."

Every integration worth using supports machine-to-machine auth: service accounts, GitHub Apps, Stripe restricted keys, AWS IAM roles with short-lived creds. Use them.

Layer 3: secrets in a vault, not in the config file

Even scoped tokens should not live in plain text on disk. Minimum viable setup:

1Password + CLI (op run) — inject at launch time.
macOS Keychain via security find-generic-password.
HashiCorp Vault for teams — short-lived dynamic credentials.

Or use the dedicated 1Password MCP or Vault MCP to fetch secrets just-in-time from inside the agent session.

Layer 4: audit logs you actually read

Every action an agent takes must be attributable. Set this up once and forget about it:

Postgres: pgaudit extension, log every statement from ai_readonly role.
GitHub: Enterprise audit log captures agent-initiated PRs/merges.
AWS: CloudTrail, filter for the MCP role's assumed sessions.
Slack: Enterprise Grid audit logs.

Review weekly. Look for statement patterns you didn't expect — that's either a bug or a prompt injection.

Layer 5: the approval prompt matters

Claude Desktop and Cursor both ask before tool calls. Don't dismiss it reflexively. If an agent is about to write to the database or send an email, take two seconds to read what it says. This is your final line of defence against prompt injection.

Three mistakes we see every week

Mistake 1: GitHub PAT with "repo" scope

The default when you create a classic PAT. This gives the agent access to every repo in every org you're a member of. Use fine-grained PATs instead — scope to one org, specific repos, limited permissions.

Mistake 2: production database in dev config

"I'll just point at prod for a quick check." Two weeks later a dev asks Claude to "clean up unused rows" and your users log in to a broken app. Use a restored snapshot on a dev host, or a managed read-replica.

Mistake 3: committing the config file

Every secret in claude_desktop_config.json becomes a permanent entry in git reflog — even after rotation. Add it to .gitignore and use env-var substitution that reads from a keychain.

Audit your current setup in five minutes

Every token has the minimum scope needed?
No credentials in plain text in the config file?
You know what audit log to check if something goes wrong?
All database connections are read-only where possible?
You've actually read the approval prompts today?

Anything less than five yesses means there's work to do.