MCP Server Security: Authentication, Permissions, and Prompt Injection

Model the server as a privileged integration.

An MCP server is often a bridge to data or actions that a model could not reach directly. Start by listing the systems it can read, the tools it can call, the identities it can impersonate, and the results it can return. Then separate read scope from write scope and development access from production access.

The goal is not to make the model trustworthy by declaration. The goal is to make an unsafe request fail at a system boundary even if a prompt is misleading, a user is careless, or a model chooses the wrong tool.

Authenticate the client and authorize the resource.

Remote MCP authorization needs more than a token-shaped string. Validate the client identity, intended resource, token audience, expiry, scopes, and transport assumptions. Keep tokens out of URLs and logs, prefer short-lived credentials, and make denial behavior clear to the client.

Use separate identities for local development, staging, and production. A server should not accept a broad personal token simply because it makes the first demo easier. Rotate credentials and test the expired, revoked, and insufficient-scope paths before relying on the connection.

• Use least-privilege scopes and separate read/write identities.
• Bind tokens to the intended resource and audience.
• Keep secrets out of prompts, URLs, tool results, and ordinary logs.

Treat tool descriptions and external content as untrusted input.

Prompt injection can arrive through a user request, a resource, a fetched document, or a tool result. Do not let text from an external system silently change the server's policy or grant a new capability. Keep authorization and validation in code and require approval for material actions.

Review the trust chain when a server combines multiple sources. Tell the user which source influenced the result, which action is about to happen, and what can be reversed. A model should not be the only reviewer between untrusted text and a production write.

Make privacy, logging, and recovery part of the design.

MCP servers may send data to third-party services with their own retention, residency, and monitoring policies. Document what leaves the host, how long it is retained, and which provider owns the next hop. Minimize payloads and redact secrets, personal data, and unnecessary context.

Log enough to reconstruct a request without storing the entire sensitive conversation. Include an owner, an alert threshold, a credential-revocation path, and a safe stop for repeated failures or suspicious tool calls.