MCP and cybersecurity: when AI moves from answering to acting

Just two years ago, the Model Context Protocol (MCP) was a technical proposal developed to solve a very specific challenge in the development ecosystem: how to let a language model (LLM) interact in a standardized way with external tools, applications, and corporate data sources without having to code a custom integration for every single use case.

Today, the picture has changed radically. MCP has established itself as the de facto standard for agentic AI architecture. It’s now an indispensable part of the technology stack thousands of companies use to automate complex workflows. Thanks to this protocol, an AI agent can connect natively to a CRM, run direct queries against relational databases, review source code repositories, execute scripts on test servers, or interact with business application APIs.

And that’s where the decisive paradigm shift happens:

The critical question inside a company is no longer what a language model knows how to answer, but what actions it can execute within the corporate infrastructure.

This qualitative leap automatically moves MCP out of the exclusive domain of software development and places it at the center of cybersecurity strategy.

What exactly is Model Context Protocol (MCP), and why has it revolutionized enterprise AI?

To understand the associated risks, it’s essential to understand what MCP contributes architecturally. Traditionally, connecting an AI to a corporate system meant building rigid connectors through direct API calls, custom scripts, or proprietary plugins. This approach created technical silos that were difficult to maintain and scale.

Model Context Protocol introduces an open, standardized client-server architecture:

• The MCP Client: The application or environment where the AI model’s interface lives (for example, agentic development environments, enterprise chat platforms, or autonomous assistants).
• The MCP Server: A lightweight component that acts as a gateway or bridge between the AI agent and the target resource (a database manager, a SaaS API, a file system, or an internal tool).
• Tools and Resources: The specific capabilities exposed by the MCP server that the agent can dynamically “discover” and request to execute.

This standardization greatly simplifies technical deployment. However, by making it easier to connect AI to corporate digital assets at scale, it directly multiplies the number of interaction pathways and the volume of requests hitting the internal network.

When a model can act, the risk model changes drastically

During the first phase of Generative AI adoption, organizations treated LLMs as closed conversational assistants. While there were clear risks around data privacy or information leakage through the user’s prompt, the model’s ability to directly act on the real environment was practically nonexistent.

With the arrival of MCP-based agents, the language model stops being a mere text generator and becomes an engine that executes code and commands against the company’s live infrastructure.

Every MCP server that’s enabled directly expands the company’s attack surface by granting operational capabilities over:

• Corporate databases: Executing read, modify, or delete operations through SQL statements.
• Source code repositories: Reading private repositories, modifying code, and integrating into CI/CD pipelines.
• SaaS platforms and business tools: Direct interaction with customer management systems, financial systems, or ERP software.
• Cloud infrastructure and servers: Launching commands in virtual environments, containers, or infrastructure as code.
• Internal file systems: Reading and bulk-processing confidential documentation stored on network servers.

In cybersecurity terms, the AI agent starts acting as an internal user equipped with credentials and permissions. As a result, any software capable of operating on critical assets necessarily requires authentication mechanisms, identity control, granular authorization, and continuous auditing.

The fundamental problem isn’t the protocol, it’s privilege management

It’s important to make an accurate diagnosis here: MCP is not, in itself, an insecure technology, nor does its basic design introduce vulnerabilities. What it introduces is a massive new way of consuming corporate privileges.

The protocol simply formalizes the technical language through which an agent discovers which functions are available to it and sends the request to use them. The real security risk emerges when the agent executes those actions in an environment lacking strict access controls or identity governance mechanisms.

If a service account or token assigned to an agent holds more privileges than necessary, any logic flaw, deviation in the model’s response, or external manipulation will translate into a security incident with potentially devastating impact.

The three major risk vectors in MCP architectures

To build an effective defense, cybersecurity leadership needs to categorize the main risks associated with using MCP inside the organization:

1. MCP servers of unverified origin (Supply Chain Risk)

Deploying an MCP server on the local network or in the corporate cloud is equivalent to installing a piece of software with access to the internal network. Hundreds of community-built MCP servers connecting popular tools have proliferated across the open source ecosystem. If the company doesn’t apply rigorous controls over the origin of that code, it risks introducing malicious components or components with serious security flaws that enable remote code execution (RCE) or arbitrary data extraction.

2. Indirect Prompt Injection

The Prompt Injection attack takes on a far more dangerous dimension in agentic environments. When an MCP server reads an internal document, an email, or a database entry containing text introduced by an external attacker, that text can include hidden malicious instructions. While processing the result, the AI agent may interpret that content as a legitimate order, leading it to modify records, alter configurations, or send confidential information outside the network.

3. Lack of segregation and excessive permission assignment

This is the most common configuration mistake when proofs of concept move into production. The agent is given a single API token with administrator privileges to make it easier to connect to every system. If that agent performs an accidental deletion, or if its credentials are compromised, the attacker immediately gains full control over every asset that key had access to. The lack of segregation also makes it impossible to know which human user requested the action, breaking the chain of traceability.

Security must shift from the AI model to the control architecture

As agentic AI becomes embedded in critical processes, it becomes clear that a company’s security can’t rely solely on the language model’s alignment or “good behavior.” Responsibility must fall on the cybersecurity architecture that wraps around and intercepts the agent’s calls.

To effectively mitigate these risks, the technology infrastructure needs to incorporate the following essential controls:

• Explicit authorization policies: Strict definition of which MCP server tools can be invoked and under exactly what conditions.
• Pre- and in-context validation: Verifying input and output parameters before the MCP server executes the order against the database or target system.
• Access control based on real identity: Carrying the human user’s identity through to the MCP server call, avoiding the use of shared, global credentials.
• Minimum operational privilege: Limiting the connector’s permissions to the exclusive catalogue of tasks the user’s job actually requires.
• Immutable audit logs: Detailed storage of every request sent by the agent, the tool invoked, the data returned, and the user who originated the flow

Data sovereignty and identity management: the two pillars of agentic cybersecurity

From a strategic cybersecurity standpoint, MCP’s emergence doesn’t require inventing entirely new theoretical principles — it requires applying the sector’s most well-established disciplines to a new kind of “user”: the AI agent.

Historically, Zero Trust security frameworks have revolved around continuously verifying human users and devices. Today, that same rigor must extend to agentic agents. This approach requires grounding protection in two major operational pillars:

1. Identity and privileged access governance (IAM / PAM)

An MCP agent operating on behalf of an employee shouldn’t hold more access than that employee has been assigned in their own role. The security architecture must interleave identity control (IAM) and privileged access management (PAM) layers to ensure every action the AI executes authenticates the end user’s identity, applies segregation of duties, and limits execution capabilities both in time and in technical scope.

2. Data protection and Leak Prevention (DLP)

The core value of connecting an MCP server lies in giving the AI context by feeding it enterprise data. However, this continuous stream of reading documents, databases, and records exposes the organization to serious risks of exfiltration or privacy loss. It’s essential to deploy Data Loss Prevention (DLP) capabilities able to inspect, classify, and block the passage of highly confidential information, personal data (PII), or corporate secrets before it’s processed by the agent or returned to the user.

Conclusion: agentic AI as a new actor within the corporate infrastructure

Model Context Protocol has established itself as the technical foundation on which agentic automation will be built across companies in the coming years. The qualitative leap from an AI that “informs” to an AI that “acts” opens up extraordinary productivity opportunities, but it completely redefines the corporate risk surface.

When an AI agent gains the ability to query repositories, execute scripts, modify database records, or send information across the network, it stops being mere auxiliary software. It becomes an actor with operational capability inside the internal network.

Any actor operating on a company’s critical assets must be subject to the same rigor of oversight, identity governance, privilege containment, and data protection applied to the organization’s most privileged users. Ensuring this balance between agentic innovation and security control will be one of cybersecurity leadership’s central responsibilities in this new era of AI.

Cosmikal

At Cosmikal we build cybersecurity solutions designed to protect access to organizations’ infrastructure and critical assets. Our products are developed with the most advanced technologies, securing the two key pillars agentic AI demands: identity and privileged access governance (IAM/PAM) to prevent excessive permissions, and protection against the leakage of sensitive data (DLP) processed by these systems.