MCP Security Best Practices for Enterprise Infrastructure

Start with the threat model

Connecting an AI agent to infrastructure creates a new path to production systems. The main risks are an agent doing more than intended, an attacker steering the agent through injected content, leaked credentials or tokens, and malicious or vulnerable MCP server packages. Controls should assume that any one of these can happen.

Authentication and authorisation

• Use the MCP authorisation model for HTTP transports: OAuth 2.1, with the MCP server acting as a resource server.
• Validate that every token was issued for this specific server. Never accept tokens issued for other services and never pass client tokens through to downstream APIs.
• For local stdio servers, provide credentials through the environment of the server process, not through tool arguments or prompts.
• Tie every action to a real user or service identity, so the audit trail shows who requested it, not just which tool ran.

Least privilege

Least privilege applies at several layers at once:

• Scopes: request minimal scopes first and step up only when a privileged operation is needed; avoid wildcard scopes.
• Tools: expose only the operations a use case needs, and keep read-only and change operations apart.
• Targets: restrict each server to an allowlist of devices or tenants that model output cannot extend.
• Device accounts: use dedicated service accounts with role-based access on the device itself, such as TACACS+ command authorisation, so the device enforces limits even if the tool layer fails.

Credential protection

• Keep secrets in a vault or a masked local prompt, never in prompts, model context, command-line arguments, logs or reports.
• Mask secrets in configuration and command output before it reaches a model.
• Prefer short-lived credentials and rotate long-lived ones on a schedule and after any exposure.
• Where possible, keep device credentials on the machine that runs the operation, so a hosted service never holds them.

Server supply chain and untrusted content

• Review MCP server packages before use, pin versions and record a fingerprint of what was approved.
• Show the exact command a local server will run before it is configured, and run servers with minimal privileges.
• Treat tool descriptions, tool results and retrieved documents as untrusted data. Instructions embedded in them must not change what the agent is allowed to do.
• Do not assume a tool is read-only because its name or description says so; qualify its real behaviour in a test environment.

Audit logging

Logs should allow an investigator to reconstruct who asked for what, what was approved and what actually happened. Record at least:

• Requesting identity, time and the approval reference.
• Server, package version, tool name and a hash of the arguments.
• Target device or tenant and the per-target outcome.
• Verification results and the evidence they were based on.

Store logs append-only, separate from the systems being changed, and with secrets removed.

Human approval for sensitive operations

Any operation that changes configuration, restarts services or affects users should require explicit human approval. Approval should be bound to the exact plan that will run, including targets and arguments, so that any change to the plan invalidates it. High-impact changes can require a second approver.