How enterprise teams should manage MCP server security risks

If you want AI agents to do more than answer questions, you have to give them access to real systems. For example, an agent that resets MFA or provisions an application needs permission to perform those actions inside a connected environment.

The Model Context Protocol (MCP) provides a standard way to make those connections. And that’s a good thing. But connecting an agent to more tools also gives attackers a lot more to work with. That’s why each connection increases the potential attack surface.

Serval is an AI-native ITSM platform that uses MCP to expose safe, permission-bound tools. It lets enterprise teams connect agents to operational workflows without weakening identity controls or exposing sensitive credentials. This guide explains MCP server security risks and shows how platforms like Serval keep those risks contained.

How MCP servers work (and how they expand the attack surface)

MCP has three main parts: a host, a client, and a server. The host is the application where the AI agent runs. The client maintains the connection to an MCP server. The server exposes the tools or data the agent can access.

MCP servers can run locally on infrastructure you control or remotely as a service managed by someone else. With a local server, your team controls the environment where it runs. A remote server adds another party to the security model because someone else operates the infrastructure behind it.

In both cases, connecting an MCP server gives the agent another set of endpoints it can reach. Each connection expands the attack surface, so access should extend only as far as the agent needs to do its job.

The core security risks of MCP servers

MCP introduces new ways for things to go wrong. But many MCP security issues will already be familiar to security teams. You still deal with untrusted input and access control. The difference is that an AI agent can now turn that input into actions across connected systems. Here are the specific risks that can emerge.

Prompt injection and tool poisoning

Prompt injection happens when untrusted content influences an LLM to behave in ways its operator didn't intend. Once the model is able to call MCP tools, a successful injection can do more than lead to a bad response; it can influence which tools the model calls.

Tool poisoning attacks the other side of the interaction. Malicious instructions can hide in a tool's description or metadata, where the model sees them even if the user doesn't. A compromised tool could tell the model to pull unrelated data or send it somewhere it doesn’t belong. In Serval, workflows that require approval still wait for their approvers when an agent starts them through MCP.

Confused deputy and OAuth authorization flaws

An MCP server can act on behalf of a user. It needs to know who that user is and whether they're allowed to perform the requested action.

Problems start when authentication is treated as authorization. A valid OAuth token proves an identity within the authentication flow. It shouldn't automatically give an agent permission to use every tool or endpoint the server exposes. The server still needs to enforce the user’s permissions on every request. In Serval, MCP runs execute under the user’s identity and permissions, and calls they aren’t allowed to make return a 403.

Supply chain and 3rd-party server risks

Not every MCP server comes from infrastructure your team built or controls. Teams can also connect agents to servers distributed by outside developers.

A malicious server can be dangerous from day one. A legitimate server can become dangerous later if it's compromised or if a malicious update is shipped. Public ecosystems also create room for typosquatting and tool name collisions designed to get an agent connected to the wrong tool.

Third-party MCP servers should go through the same vendor and software review you apply to anything else receiving access to company systems. Installing one shouldn't amount to granting it a permanent vote of confidence.

Excessive permissions and over-delegation

An MCP tool only needs enough access to perform the task it was built for. Giving it more increases what an attacker could reach if the tool or server is compromised.

Credentials need the same treatment. API keys and other secrets shouldn't be exposed to the model or passed to tools that don't need them. A compromised server can do far more damage if it also holds credentials for other systems. Serval’s MCP server uses OAuth for user connections, so there are no credentials to copy or rotate.

The same principle applies to the agent using it. IT teams need control over what AI agents can and can’t do instead of treating a connection as blanket permission to act. If an employee can't perform an action directly, putting an AI agent between the employee and the system shouldn't change that.

Model Context Protocol security best practices

Good MCP security starts with limiting what each connection can do and keeping those actions inside the controls your organization already uses. These MCP security best practices focus on reducing the attack surface without preventing agents from doing the work they were connected to do.

1. Enforce least-privilege access and authentication

Every MCP connection should require authentication. From there, each tool should receive only the permissions it needs to perform its intended function. A tool that reads ticket data doesn't need write access to your identity provider just because both systems are connected to the same agent.

Think about duration too. Just-in-time (JIT) access provisioning can grant access when it's needed instead of leaving permissions in place indefinitely. For sensitive actions, automated workflow approvals can require human authorization before anything runs.

In Serval: Every MCP connection requires OAuth 2.1 authentication. Tool access follows the connecting user's existing role and permissions. This means an agent can't gain broader access simply by connecting through MCP.

2. Route permissions through the same identity system as your other integrations

Don't build a separate authorization model just for MCP. If someone can't perform an action directly, asking an AI agent to do it shouldn't change the answer.

This becomes especially important when you automate access requests. The agent should act within the permissions of the person making the request. For elevated permissions, JIT privileged access management keeps privileged access temporary rather than standing.

In Serval: MCP tool calls go through the same RBAC and permissions layer as Serval's REST API. If a user doesn't have permission to perform an action in Serval, an agent connected through MCP can't perform it on their behalf.

3. Vet and monitor 3rd-party MCP servers you consume

Treat a third-party MCP server like any other software with access to company systems. Before connecting it, review who maintains it and what permissions it requests. Keep monitoring it after approval since the server can change over time.

For higher-risk environments, an allowlist can limit which MCP servers or tools agents are permitted to connect to. And remember that a legitimate server can become a security risk after an update or compromise, which means vetting can't stop once the initial review is complete.

In Serval: Governance controls apply to Serval's own MCP surface. Third-party MCP servers running elsewhere in your environment still need to be vetted and monitored separately.

4. Log and audit every MCP request and tool call

When an agent takes action through MCP, you need a record of what happened. Audit trails should let your team trace activity back to the user who initiated it and see what the agent did.

That record becomes especially important when you're investigating unexpected behavior or reviewing access after the fact.

In Serval: Complete logs of workflow runs and configuration changes are maintained. Access Management also provides real-time audit trails and exportable logs across the access lifecycle.

See how Serval governs MCP access at enterprise scale

Serval's MCP server exposes its public API as MCP tools. Every connection requires OAuth 2.1 authentication. Since the agent inherits the connecting user's existing roles and permissions, connecting through MCP doesn't give it broader access than the user already has.

That means an agent can help with tasks like access provisioning without bypassing the controls already in place. MCP expands what the agent can do, not what the user is allowed to do.

MCP gives agents a standard way to act across real systems. Serval keeps those actions inside the same identity and permission boundaries that govern the rest of the platform.

Book a demo to see how.

FAQ

What’s MCP in AI?

Model Context Protocol (MCP) gives AI applications a standard way to connect to external tools and data sources. An MCP server exposes those capabilities so an agent can retrieve information or take action in another system.

Are local or remote MCP servers riskier?

They create different risks. With a local MCP server, your team controls the environment where it runs. A remote server is operated by another party, so you're also relying on that provider to secure its infrastructure and software. Either type can create risk if it has excessive permissions or weak access controls.

Who should own MCP server security inside an IT organization?

Ownership depends on how your organization handles identity and application security. The important part is that MCP doesn't sit outside your existing security processes. The teams responsible for approving integrations and managing access should have clear responsibility for the MCP servers connected to your environment.