Secure Practices for Using MCP Servers: What You Need to Know

If you work with AI tools, you have probably heard of a Model Context Protocol (MCP). If you have not, you will soon. It is becoming the standard way AI agents connect to the tools they need to do real work, and it is worth understanding and developing good habits now while the ecosystem is still in its early stages.

What Is MCP?

MCP (Model Context Protocol) is an open protocol that lets AI agents like Claude, Cursor, Windsurf, and GitHub Copilot connect to external tools. Think of it as a standardized plug system. Instead of each AI building custom integrations for every tool, MCP provides a common interface.

An MCP server is a small program that exposes a specific capability: reading files, querying a database, calling an API, managing users in an identity provider. The AI agent connects to the MCP server, discovers what tools are available, and calls them as needed.

The protocol is still evolving. It was open-sourced by Anthropic in late 2024, donated to the Linux Foundation in late 2025, and adopted by OpenAI, Google, and Microsoft. There are now over tens of thousands of published MCP servers covering everything from file conversion to cloud infrastructure management.

Why Use It?

MCP solves a real problem. Before MCP, connecting an AI agent to your tools meant writing custom code, managing authentication yourself, and rebuilding the integration for every agent you wanted to support.

With MCP:

Write once, use everywhere. Build one MCP server for your tool and any MCP-compatible agent can use it.
Standardized discovery. Agents can ask “what tools do you have?” and get a structured answer.
Structured inputs and outputs. Tools declare their parameters and return types, reducing errors from mis-formatted requests.
Growing ecosystem. With major AI providers adopting MCP, the number of compatible agents and tools is growing rapidly.

For identity teams, MCP is particularly relevant. MCP servers already exist for user provisioning, directory queries, policy management, and credential rotation. An AI agent with the right MCP tools can automate identity operations that currently require manual work.

Turn questions into action

Discover how the OneLogin MCP Server can help administrators and security teams work faster with direct access to OneLogin through MCP-compatible tools: Explore the MCP Server on GitHub

What to Watch For

MCP is powerful, but the ecosystem is still in its early days. The protocol was designed for a world where the agent and the tool run on the same machine, connected by a private pipe. As MCP expands to HTTP connections, remote servers, and multi-user environments, several security gaps have become apparent.

API Keys in Config Files

This is the most common and most preventable issue. The default setup for most MCP tools looks like this:

{
"mcpServers": {
"my-tool": {
"command": "npx",
"args": ["@my-org/mcp-server"],
"env": {
"API_KEY": "sk-proj-abc123...",
"CLIENT_SECRET": "9z8y7x6w5v4u3t2s1r0q"
}
}
}
}

Those credentials are sitting in a plaintext JSON file on your computer. Every MCP tool you install runs with your user permissions, which means every tool can read that file and see every other tool’s credentials.

This is the default pattern in every MCP setup guide today. It works, but it is not secure for production use, especially when the credentials control access to identity infrastructure.

No Authentication on Connections

When an MCP server runs over HTTP (which is becoming more common as the protocol evolves), it listens on a port and accepts requests from any process that can reach it. There is no built-in handshake or token exchange. On a shared network, this means other devices could potentially discover and call your MCP tools.

For tools that only run locally over stdio (the original MCP transport), this is less of a concern because the operating system limits access to the process pipe. But as MCP moves toward HTTP and remote connections, authentication becomes essential.

Unsigned Tool Configurations

MCP tool manifests declare what a tool can do: which files it can access, which network connections it can make, and what permissions it needs. Today, most of these manifests are not cryptographically signed. That means there is no way to verify that a tool’s configuration has not been modified after the author published it.

For tools managing sensitive infrastructure, this is a gap worth watching as the ecosystem matures.

Security Advice

Consider practical steps you can take today to use MCP servers more securely.

Move Credentials Out of Config Files

Instead of putting API keys directly in your MCP configuration, use environment variables as references:

{
"mcpServers": {
"my-tool": {
"env": {
"API_KEY": "${MY_API_KEY}"
}
}
}
}

Better yet, store credentials in your operating system’s built-in credential store: macOS Keychain, Windows Credential Manager, or Linux Secret Service. These stores are encrypted, access-controlled, and have been hardened for decades. The credential never needs to exist in a file on disk.

When I built the OneLogin Migration Wizard, which handles API credentials for multiple identity providers, I created a Python package called layered-credentials that automatically detects credential fields and routes them to the OS keyring instead of writing them to config files. The same principle should apply to MCP tool configuration.

Scope Your Credentials

Do not give an MCP tool your admin API key. Create a dedicated credential with only the permissions the tool needs.

For example, if you are using a OneLogin MCP server:

A user lookup tool should have read-only access, not admin access
A provisioning tool should have user management permissions, not super admin
A reporting tool should not have write access at all

OneLogin’s OAuth 2.0 scopes support this granularity. Most identity providers do. Use it.

Be Selective About What You Install

Not every MCP server is created equal. Before installing a tool:

Check who published it and whether the source code is available
Look at what permissions it requests (file system access, network access, execution permissions)
Prefer tools from known publishers or verified registries
Review the tool’s description carefully. There have been documented cases of tool descriptions containing hidden instructions that manipulate agent behavior (known as “tool poisoning”)

Keep Tools Updated

MCP servers are software, and like all software, they can have vulnerabilities. Keep your installed tools updated, and remove tools you are no longer using. An unused tool with broad permissions is an unnecessary attack surface.

Monitor What Your Tools Are Doing

If your organization is using MCP tools for identity operations, treat them with the same audit expectations you would apply to any administrative tool. Log which tools are being called, by which agents, with what parameters, and what the results were. The MCP protocol makes this possible since all interactions follow a structured request/response format.

What Is Coming Next

The MCP ecosystem is evolving quickly. Several developments are worth watching:

Authentication in the spec. The MCP specification currently has no authentication section. As HTTP-based MCP servers become more common, expect the spec to add standard authentication patterns, likely bearer tokens for HTTP and token-based authentication for WebSocket connections.

Tool signing and verification. The ability to cryptographically sign MCP tool manifests so consumers can verify they have not been tampered with. This is similar to how package managers like npm and PyPI are adding signature verification.

Post-quantum cryptography. NIST finalized new cryptographic standards in 2024 (ML-DSA for signatures, ML-KEM for key exchange) designed to resist attacks from future quantum computers. As MCP tool signing becomes standard, expect these algorithms to be adopted alongside traditional ones. This matters because signed data captured today could be forged in the future if it relies solely on algorithms vulnerable to quantum attacks.

Remote and multi-user MCP. The protocol is moving beyond single-user, single-machine setups toward remote connections and shared environments. This will make authentication, authorization, and credential isolation even more important.

Standardized credential management. Expect MCP frameworks to build in credential management rather than relying on plaintext config files. OS keyring integration, encrypted vaults, and credential rotation should become default features rather than afterthoughts.

The Identity Team’s Role

MCP is bringing AI automation to identity operations. That is a good thing. But it also means AI agents are handling the same credentials, the same APIs, and the same infrastructure that identity teams are responsible for securing.

The security patterns MCP needs are not new. Credential storage, authentication, access scoping, audit logging, and cryptographic integrity are problems the identity industry solved long ago. As MCP matures, those of us in identity management are well positioned to help the ecosystem adopt the practices that make these tools safe for production use.

It is still early. That is exactly why now is the time to establish good habits.