As AI systems become agentic and interact directly with enterprise tools through Model Context Protocol (MCP), gateway-based security models may no longer be sufficient. Policy enforcement must move closer to where capability execution occurs.
I was tempted to start by saying that AI operations and AI interactions must be secure, even from local threats.
But that is obvious.
Instead, it is worth looking at a familiar story from the history of enterprise security.
The Rise and Fall of the Security Perimeter
There was a time when organizations believed their systems were secure as long as they built strong walls around them. Enterprises invested heavily in perimeter defenses: firewalls, security gateways, and network access controls designed to regulate who could enter the trusted environment.
As long as enterprise IT lived inside well-defined data centers, this model worked reasonably well. Systems were centralized, networks were predictable, and the boundary between what was inside and what was outside the organization was relatively clear.
But that situation did not last.
As IT became ubiquitous, environments rapidly grew in scale and complexity, and the boundaries of the security perimeter began to blur. Cloud computing, edge computing, mobile access, and IoT systems pushed enterprise infrastructure far beyond the traditional data center, fundamentally reshaping what “inside” and “outside” the perimeter meant.
What had once been a tightly controlled environment became a distributed ecosystem of multi-tenant systems, services, and devices running everywhere and accessed by many actors.
The concept of a clear security perimeter started to break down.
From Perimeter Security to Zero Trust
Enterprises soon realized that perimeter defenses alone were not enough. A growing set of threats exposed the limitations of the model:
- compromised internal devices
- multi-tenant infrastructure
- lateral movement within networks
- malicious insiders
- misconfigured services
These challenges led to the emergence of a new security paradigm: Zero Trust.
Rather than assuming trust based on network location and identity, Zero Trust systems evaluate every action based on identity, resource, context, and authorization. Trust is not granted simply because something is inside the network.
While many Zero Trust implementations focus heavily on identity verification, the underlying principle is broader: authorization decisions should occur as close as possible to the resource being accessed. In the context of MCP, the resource is not simply a network endpoint but a capability invocation.
Every request to every resource must be verified before execution is allowed.
AI Security Is Entering the Same Phase
Today, AI security is entering a similar phase.
As AI systems begin interacting with enterprise infrastructure, many organizations are applying familiar security patterns to these new integration points.
Many current approaches to securing AI systems focus primarily on perimeter-style controls. Organizations place gateways, proxies, or centralized security services in front of AI tooling to regulate access.
This approach may appear sufficient while AI integrations remain small and limited.
For example, an organization might deploy a few Model Context Protocol (MCP) servers connected to selected internal applications. With only a small number of MCP endpoints, it is tempting to secure them using centralized network controls.
But this model will not scale and is not designed to handle the heterogeneity that arises when AI systems can interact with a vast range of devices, services, and applications — from server operating systems to mobile phones and embedded sensors.
As with traditional security, this reflects the core issue: we are trying to build perimeter defenses in a world where the boundary between inside and outside has largely disappeared.
To understand why this matters, we need to look at how AI systems are beginning to interact with real infrastructure.
Understanding the Model Context Protocol (MCP)
Let us pause here to consider the role of AI integration and the Model Context Protocol (MCP).
Generative AI systems have already moved beyond simple, isolated chatbots. They increasingly interact with enterprise systems to gather context, retrieve knowledge, and assist with operational tasks. Just as traditional IT systems rely on APIs for integration, AI systems require structured mechanisms to interact with tools and services.
This is where MCP emerges.
The Model Context Protocol provides a standardized way for AI systems to connect with external services and tools. An MCP server exposes capabilities that allow AI models, through MCP clients, to understand what a system can do and how to interact with it.
In many ways, an MCP server can be seen as a self-describing API designed specifically for intelligent actors, including AI systems and human operators. MCP describes available interactions in natural language, allowing large language models to understand which capabilities exist and decide when to use them, much like consulting system documentation to understand how to interact with it.
This ability dramatically lowers the friction for AI systems to interact with real-world tools and services.
However, exposing capabilities through MCP also introduces a new challenge. If left uncontrolled, MCP servers may expose powerful operations without the same governance mechanisms traditionally applied to human users or system administrators. Even worse, these capabilities could be invoked in unintended ways by LLMs attempting to accomplish their objectives.
Just as organizations would never allow unrestricted access to internal APIs or administrative interfaces, MCP capabilities must also be governed and controlled.
Why Perimeter Security Does Not Scale for MCP
MCP is quickly emerging as a standard mechanism for connecting AI systems with tools, services, infrastructure, and soon even IoT devices at the edge. As adoption grows, MCP servers will stop being isolated components and will instead become a foundational integration layer across enterprise systems.
They will spread across the enterprise.
Servers, applications, devices, and operational systems will increasingly expose capabilities through MCP interfaces. MCP will likely become a fundamental integration layer for AI-driven operations, automation, and system interaction.
When that happens, the perimeter model begins to break down.
A Simple Bypass Scenario
Consider a simple scenario. An organization deploys an AI gateway to control how AI agents interact with internal tools through MCP. All AI-driven requests are expected to pass through that gateway where logging, monitoring, and security policies are enforced.
But an operating system administrator with direct access to the server hosting the MCP service could interact with the MCP endpoint directly, bypassing the gateway entirely. In that situation, the perimeter control still exists, but it no longer governs the actual capability execution. With AI-assisted operations becoming more common, such interactions may increasingly occur outside the expected control path, potentially escaping audit or compliance monitoring.
In the future, this may also become a source of cybersecurity threats. Once a malicious actor gains access inside the perimeter — through malware or other means — they may attempt to interact directly with known MCP services provided by vendors, bypassing centralized AI gateways and invoking capabilities without passing through the expected control path.
This is not a vulnerability in the gateway itself — it is a consequence of relying solely on perimeter controls in a distributed environment.
How effective is a centralized gateway when an internal user can bypass it and interact directly with an MCP server?
How do perimeter controls apply to MCP servers running locally on a developer workstation?
What about MCP interfaces embedded in applications or devices that are not exposed through traditional network paths?
Security Is Also a Governance Problem
And as MCP becomes an integration layer across enterprise systems, the problem is not only security. It is also governance. Organizations must decide:
- what capabilities should be exposed to AI
- what operations should remain restricted to human operators
- what actions should require approval or supervision
- what calls should be restricted or audited.
These decisions cannot be enforced reliably through perimeter controls alone.
Just as enterprise security had to evolve beyond perimeter defenses, AI tool security must evolve as well.
And that evolution requires reinforcing perimeter defenses with policy enforcement closer to where actions actually occur: directly at the MCP server where capability execution occurs**.**
Policy-Driven Endpoint Enforcement
But implementing this kind of endpoint enforcement must remain practical. It should be simple to understand, easy to maintain, and straightforward to extend.
Administrators need a clear and consistent way to define how local MCP capabilities can be used: which resources can be accessed, which actions require approval, and which operations must remain under human supervision.
These controls should be expressed through simple and transparent policies, while still allowing extensibility for more advanced scenarios, such as complex role-based access control (RBAC) validations or organization-specific security logic.
A policy-driven approach makes it possible to govern MCP capabilities without modifying the MCP server itself, enabling organizations to enforce security and operational rules consistently across their AI tooling infrastructure.
Toward Secure and Governable MCP Environments
As MCP adoption grows, the ability for AI systems to interact with tools and infrastructure will expand rapidly. What begins as a few integrations between AI assistants and internal services will evolve into a broad ecosystem where servers, applications, devices, and operational platforms expose capabilities through MCP interfaces.
In such an environment, relying solely on perimeter-based controls will inevitably fall short. Network gateways and proxies remain important layers of protection, but they cannot provide the fine-grained governance required to control how AI systems interact with tools and resources.
Just as modern enterprise security evolved from perimeter defenses toward Zero Trust architectures, MCP environments must adopt a similar model.
Security controls must move closer to where actions actually take place: the execution point of MCP capabilities.
The MCP Server as a Policy Enforcement Point
By introducing policy enforcement at the MCP server itself, organizations gain the ability to evaluate each capability invocation before it is executed. Policies can determine whether an action should be allowed, denied, require human approval, or be restricted to specific actors.
This approach not only strengthens security but also enables operational governance. Organizations can define clear rules about which capabilities are safe for AI agents, which should remain under human control, and which actions require oversight.
A practical way to achieve this is through policy-driven enforcement layers integrated with MCP servers. Such mechanisms allow administrators to define rules declaratively while still enabling extensibility for organization-specific logic and advanced authorization models.
Exploring this idea further, I recently developed a small experimental project that demonstrates how a lightweight policy enforcement filter within MCP servers can evaluate requests before tool execution, allowing administrators to define simple resource- and method-based policies and extend them when needed. A small experimental project illustrating this concept is available on GitHub
In architectural terms, this introduces a Policy Enforcement Point (PEP) directly at the MCP server, where capability invocations can be evaluated before they are executed.
The goal is not to replace existing infrastructure such as AI gateways, proxies or identity providers, but to complement them with endpoint-level enforcement aligned with Zero Trust principles. Over time, this approach could evolve into a better implementation in the form of a wrapper or local filter layer placed in front of MCP servers, enabling policy enforcement without requiring changes to the MCP server implementation.
As AI systems become more capable and more deeply integrated into enterprise environments, securing the interfaces through which they operate will become critical.
These architectural considerations become especially important as organizations move from experimentation toward production AI integration, especially in the case of AI-assisted operations.
Conclusion
Today, AI integration is becoming ubiquitous. Even more advanced uses — such as AI-assisted operations — are now being explored by people everywhere, from students and IT enthusiasts to engineers and organizations.
However, large enterprises tend to adopt these capabilities more cautiously. Operating production infrastructure requires strict control over how automated actions can affect critical systems, and organizations must ensure that governance, auditability, and operational safety are preserved.
Approaches that enforce policy at the MCP server level — enabling granular and controlled use of MCP capabilities — may therefore become an important enabler for the adoption of AI-assisted operations in enterprise environments beyond curiosity, innovation labs, and experimental deployments.
Perimeter defenses will continue to play an important role.
But for MCP to become a safe and reliable foundation for enterprise AI operations, endpoint security and policy-driven governance must become a standard part of MCP server implementations.
If MCP becomes the interface through which AI interacts with real systems, the MCP server itself must become part of the enterprise security boundary.
This article accompanies a small experimental project: https://github.com/sebastianmart-sketch/mcp-policy-filter
Author’s note: The ideas in this article were conceived by the author. AI tools were used for editorial assistance and language refinement.