MCP in a Minute: Permissions and security

In one sentence

Treat every MCP server as code with credentials: only connect what you trust, and only expose tools you would allow a junior engineer to run.

Why it matters

MCP tools can read data and trigger side effects outside the repo. A prompt injection in a webpage, ticket, or file can steer an agent toward those tools.

How it works

Reduce risk in layers:

1. Server allowlist — do not install random servers;
2. Least privilege — tokens scoped to the minimum APIs;
3. Tool subset — disable dangerous tools when the client allows it;
4. Human approval — require confirmation for mutating or irreversible actions;
5. Environment split — different MCP configs for personal experiments vs company repos.

Local servers are not automatically safe; they still run with your user permissions.

Example

A safer issue-tracker setup:

• read-only token for fetching issue text;
• no “close issue” or “delete project” tools enabled;
• ask-before-write for comments if writes are required.

Agentic coding use

Coding agents already have shell access in many setups. MCP multiplies reach into SaaS systems. Your security model must include tool policy, not only file permissions.

Watch out

“Connected for a demo” servers tend to stay connected. Audit MCP configs the same way you audit CI secrets.