MCP Server Development: Security and Permissions

An MCP server differs from a prompt in one property: its tools do real things. A prompt error produces wrong text; a permissions error produces a wrong action in your system.

A tool is an action

The model chooses tools probabilistically. It can choose wrongly because descriptions look alike, because the request was ambiguous, or because the right tool does not exist and it takes the nearest one.

Hence the core design rule: assume every available tool will one day be called at the wrong moment. The question is not whether that happens but what happens when it does. If the answer is “nothing bad”, the tool is designed correctly.

On third-party servers again: connecting one means running somebody else’s code with your permissions. That is adding a dependency, not clicking a button. Check the package, the publisher and whether the project is alive - see the server catalogue.

What not to expose

A short list worth honouring:

Deletion, especially bulk deletion. If deletion is required, make it soft and reversible.

Unconstrained production. A live database with write access is the most common and most expensive mistake. Start with a replica or read-only rights.

Money. Payments, refunds, price changes - human confirmation only.

Mailings. Sending messages to customers is irreversible, and mistakes scale instantly.

Bulk operations. A tool that can change one record is safer than one that can change all of them. If bulk is required, cap the number of affected records hard.

Secrets in responses. No tool should return keys, tokens or passwords. What reaches the agent has reached the model provider.

Confirmations

Not everything can be forbidden, so irreversible actions go through confirmation.

How it should work:

• Confirmation as a separate step, not a warning in the tool description. The agent will read the description and call it anyway.
• The person is shown what will actually happen: which records, how many, what action. “Confirm the operation” without detail is not confirmation.
• The agent cannot route around it. If it can call the tool while skipping the confirmation step, the step does not exist.

A further level is checking after the action. The agent’s report that something was done is not evidence. Check the fact: does the record exist, did the state change. The long version is in agent rollout and verification.

Access rights

The rule: minimal permissions, widened only as needed.

The practical order:

1. A dedicated account for the server. Not your personal one and not an administrator.
2. Only the objects required. Access to three tables, not the whole database.
3. Read-only at the start. Writes are added once you have watched the server behave.
4. A restricted directory root for filesystem servers. The working project, not the home directory where the keys live.
5. Separate tokens per environment. Local work, CI and production must not share a key.

Secrets

Three rules that close nearly every leak:

Secrets live in environment variables. Not in the config, and above all not in a project config that lives in the repository.

Secrets are never returned to the agent. A tool that hands back the contents of an environment file is a leak by construction.

A secret that entered context is compromised. Revoke it rather than hope. You cannot delete it from the provider’s copy.

On filesystem servers specifically: restrict the root directory. A key file at the project root will be read on the agent’s first file search, with no malice involved - it simply happens in the course of the task.

Minimum checklist

• A dedicated account with minimal rights.
• Read-only at the start.
• No delete or bulk-update tools.
• Human confirmation for anything irreversible.
• Secrets in the environment and never in responses.
• A restricted root for filesystem servers.
• Third-party servers reviewed before connecting.
• Calls logged.

If an agent is connecting to internal systems and you need a judgement on what can safely be exposed in your environment, that is part of the work described on the services page. The overview is in the MCP guide.