How to Secure MCP Servers on AKS with a Governed AI Agent Gateway

In this blog post How to Secure MCP Servers on AKS with a Governed AI Agent Gateway we will explain how to stop every AI tool from becoming another unmanaged doorway into your business systems.

This matters because Model Context Protocol servers, usually called MCP servers, do more than provide information. They can let AI agents search documents, update customer records, create support tickets or trigger operational processes. If those servers are exposed without consistent controls, a useful AI project can quickly become a serious security and compliance risk.

What the technology does at a high level

Model Context Protocol is an open standard that gives AI applications a consistent way to discover and use tools, data and reusable instructions. An MCP server might connect an AI assistant to your CRM, service desk, document library or internal database.

Azure Kubernetes Service, or AKS, is Microsoft’s managed platform for running containerised applications. It is a common place to host MCP servers when a business needs more control, scale or isolation than a simple development environment can provide.

Application Gateway for Containers sits in front of those AKS workloads. It is a managed traffic service built specifically for Kubernetes and can now act as an MCP-aware gateway through the new MCPRoute resource.

In plain English, AI agents connect to one controlled address rather than connecting directly to every MCP server. The gateway then sends each request to the correct service inside AKS.

Why direct MCP server exposure becomes difficult to manage

One directly exposed MCP server may not seem risky. The problem appears when different teams create servers for finance, sales, IT support and document management.

Each new endpoint brings another certificate, access rule, monitoring configuration and public attack surface. Client applications must also be updated whenever an address changes.

This is the issue explored in our overview of what the AKS MCP gateway means for production AI security. Application Gateway for Containers turns those separate endpoints into one governed entry point.

One endpoint reduces unnecessary exposure

Instead of publishing five MCP servers to the internet, a business can publish one gateway address and keep the underlying services behind it. Backend services can scale, move or be replaced without forcing every AI client to change its configuration.

For particularly sensitive workloads, private ingress can remove the public frontend entirely. Access can then be limited to approved private network connections, reducing the number of systems that attackers can scan or reach.

Identity checks happen before traffic reaches the application

Application Gateway for Containers can validate JSON Web Tokens, or JWTs, which are digitally signed identity passes issued by Microsoft Entra ID or another trusted identity provider. Invalid or expired tokens can be rejected before the request reaches an MCP server.

This provides a consistent first identity check, but it does not replace authorisation inside the MCP server. The server must still decide whether that particular person or agent can use a tool, access a customer record or perform an administrative action.

A good rule is simple: the gateway confirms who is calling, while the MCP server confirms what that caller is allowed to do.

Web protection is useful but not an AI safety control

Azure Web Application Firewall, or WAF, can inspect incoming traffic and block common web attacks before they reach AKS. This reduces exposure to malicious requests and known application attack patterns.

However, a WAF does not understand whether an AI agent has been tricked into performing a valid but dangerous business action. It will not automatically recognise that deleting a customer, approving a refund or exporting payroll data is inappropriate.

Tool permissions, approval steps, data controls and detailed audit logs are still required. Our reference architecture for securing agentic AI and MCP servers explains these wider controls.

How MCP routing works behind the scenes

The platform team creates a Kubernetes Gateway with a dedicated MCP listener. An MCPRoute then connects that listener to one or more MCP services running inside AKS.

The ALB Controller, which translates Kubernetes instructions into Azure gateway configuration, detects these resources and configures the managed gateway data plane. Application teams can manage their services using familiar Kubernetes files while the platform team retains control of the shared entry point.

A simplified route may look like this:

apiVersion: alb.networking.azure.io/v1alpha1
kind: MCPRoute
metadata:
 name: business-tools
 namespace: ai-platform
spec:
 parentRefs:
 - name: mcp-gateway
 sectionName: mcp
 rules:
 - backendRefs:
 - name: crm-mcp
 port: 8080
 - name: service-desk-mcp
 port: 8080

This example places CRM and service desk tools behind the same logical endpoint. The gateway can combine their discovery results, separate overlapping capability names and direct a selected tool call to the backend that owns it.

The configuration is only one layer of the design. Production deployments should also include encrypted connections, identity validation, backend health checks, namespace controls and policies limiting which teams can attach services to the gateway.

A practical business scenario

Consider a 200-person professional services company building an internal AI assistant. The assistant needs to search project documents, create IT tickets and update selected CRM records.

Without a gateway, the company publishes three MCP endpoints and gives each development team responsibility for certificates, authentication and logging. Six months later, nobody has a complete list of connected agents, and the CRM server uses different access rules from the service desk server.

With Application Gateway for Containers, the company provides one approved MCP endpoint. Entra ID verifies callers, WAF filters common malicious traffic, and each backend continues to enforce its own detailed permissions.

The business outcome is not simply cleaner architecture. It means fewer public entry points, faster onboarding of approved AI applications, more consistent security controls and clearer evidence when auditors ask who can access sensitive tools.

Production controls that still need to be added

An MCP gateway is a strong control point, but it is not a complete AI security strategy. Before production use, we recommend checking the following areas:

• Use least-privilege identities. Give each agent only the permissions needed for its job rather than broad access shared across multiple applications.
• Separate read and write tools. Searching a knowledge base carries less risk than changing customer or financial data.
• Add approval for high-impact actions. Payments, deletions, account changes and external communications should not rely on an AI decision alone.
• Encrypt traffic end to end. Protect both the client-to-gateway connection and the connection from the gateway to MCP servers.
• Monitor tool activity. Record the identity, tool, result, time and target system without placing sensitive prompts or credentials in logs.
• Scan the AKS environment. Tools such as Microsoft Defender and Wiz can identify vulnerable container images, risky permissions and cloud configuration problems.
• Test failure behaviour. Confirm what happens when a backend is unavailable, a token expires or an agent repeats an action.

These controls also support the intent of Essential Eight, the Australian Government’s cybersecurity framework that many organisations use as a baseline. The gateway does not make a business Essential Eight compliant by itself, but it can support stronger access control, monitoring and system hardening.

Treat the current release as a controlled adoption

MCP routing, gateway JWT validation and several related Application Gateway for Containers capabilities are currently preview features. That does not make them unsuitable for evaluation, but it does mean production adoption should include documented testing, rollback plans and confirmation of regional availability and support requirements.

Start with a low-risk, read-only MCP server. Measure reliability, review logs and test identity boundaries before connecting the gateway to systems that can change business data.

CloudProInc brings more than 20 years of enterprise IT experience to this kind of work. As a Microsoft Partner and Wiz Security Integrator, our Melbourne-based team can assess the complete path from Azure and AKS through to agent identity, MCP permissions, Defender monitoring and cloud security posture.

Application Gateway for Containers can provide the controlled front door that production MCP environments have been missing. It reduces exposure and simplifies operations, but the real security outcome depends on what happens behind that door.

If you are not sure whether your MCP servers, AKS environment or AI agents have the right security boundaries, CloudProInc is happy to review the design and highlight the practical gaps—no strings attached.