In this blog post Securing Agentic AI and MCP Servers in Microsoft Environments we will explain how to deploy useful AI agents without giving them uncontrolled access to your data, systems or cloud environment.
Agentic AI goes beyond answering questions. An AI agent can plan a task, retrieve information and take actions such as updating a customer record, creating a support ticket or changing a cloud resource. Model Context Protocol, or MCP, is the standard connection layer that lets the agent reach those business tools.
That combination creates real productivity gains, but it also changes the risk. A chatbot might produce an incorrect answer. An over-permissioned agent can make an incorrect change across hundreds of records before anyone notices.
What MCP does in plain English
MCP gives AI applications a consistent way to discover and use approved tools. Instead of building a different connection for every database, application or cloud service, organisations can expose those capabilities through MCP servers.
CPI Consulting helps organisations design, build and secure Azure AI solutions, from Azure OpenAI and Microsoft Foundry to agents, governance and production deployment.
Visit CPI ConsultingAn MCP deployment normally has three parts:
- The host, such as an employee-facing AI application.
- The client, which manages the connection on behalf of the agent.
- The server, which publishes tools, data and reusable instructions.
The server might offer a harmless tool such as “find an invoice” or a high-risk tool such as “approve a refund”. MCP standardises the connection, but your organisation remains responsible for deciding who can call each tool and what safeguards apply.
We explored that design decision in why the MCP SDK for .NET turns tool access into a security decision. The next step is turning those principles into an enterprise deployment pattern.
A practical Microsoft reference architecture
A secure design should use layers rather than depend on one security product. If a prompt filter misses an attack, identity controls should still limit access. If an identity is compromised, the gateway and backend should still restrict what it can do.
- User access: Employees authenticate through Microsoft Entra ID, Microsoft’s identity and access platform, with multi-factor authentication.
- Agent runtime: The agent runs in Microsoft Foundry, Copilot Studio, Azure or another approved environment.
- Gateway: Azure API Management sits in front of remote MCP servers to validate identities, apply usage limits and record activity.
- MCP server: The server exposes a small, documented set of business tools rather than unrestricted system access.
- Business systems: Microsoft 365, Azure services, databases and third-party applications enforce their own permissions.
- Security monitoring: Microsoft Defender, Azure Monitor and Wiz identify exposed services, unsafe configurations and suspicious behaviour.
For sensitive deployments, use private network connections so the agent, gateway and MCP servers do not need to be publicly accessible. Microsoft’s baseline architecture also supports private endpoints and controlled outbound traffic through Azure Firewall.
Give every agent its own identity
One of the most dangerous shortcuts is allowing several agents to share a service account or administrator credential. When something goes wrong, the security team cannot reliably determine which agent performed the action or why.
Give each production agent a distinct identity in Microsoft Entra Agent ID. Permissions can then be assigned according to the agent’s job, reviewed by an owner and removed when the agent is retired. Our guide to securing AI agent identities with Microsoft Entra ID examines this lifecycle in more detail.
Use managed identities wherever possible. A managed identity is an Azure-controlled account that lets an application access approved services without storing passwords or API keys in code.
Every MCP request should carry a short-lived access token issued for that specific server. The server must check who issued it, which server it was intended for and whether it has expired. Do not simply pass a user token through to downstream systems, because that can allow the token to be reused somewhere it was never intended to work.
Put a controlled gateway in front of MCP servers
Direct agent-to-server connections become difficult to govern as adoption grows. Azure API Management provides a central checkpoint where the business can apply authentication, usage limits, routing rules and monitoring.
An illustrative inbound policy might look like this:
<inbound>
<validate-azure-ad-token
tenant-id="{{entra-tenant-id}}"
header-name="Authorization"
failed-validation-httpcode="401">
<client-application-ids>
<application-id>{{approved-agent-id}}</application-id>
</client-application-ids>
</validate-azure-ad-token>
<rate-limit calls="60" renewal-period="60" />
<base />
</inbound>This pattern checks that the request came from an approved agent and limits how quickly it can call tools. The exact limits should reflect the business process. Sixty invoice searches may be reasonable; sixty supplier payment changes are not.
Separate reading from acting
Do not place every capability on one MCP server. Separate read-only tools from tools that create, change or delete information.
A reporting agent might be allowed to search sales records but not alter them. A service desk agent could draft an account change but require a person to approve it. Financial, identity, security and production changes should usually have stronger approval rules than low-risk information retrieval.
Build approval and stopping conditions into the agent’s design. Define what evidence it must have before acting, what it must never do and when it must hand the task to a person. That keeps automation useful without treating the model’s judgement as unquestionable.
If agents communicate with other agents, the same principle applies. Our guide to using A2A and MCP together explains how to control those multi-agent boundaries.
Treat documents and emails as untrusted input
An agent may read an email, website or uploaded document containing hidden instructions designed to manipulate it. This is called indirect prompt injection. For example, a document could tell the agent to ignore company rules and send confidential information to an external address.
Use Azure AI Content Safety Prompt Shields to inspect user prompts and retrieved content, but do not rely on filtering alone. Restrict the agent’s tools, validate every action and prevent untrusted content from directly triggering high-risk operations.
Record actions without creating a new data leak
Your audit trail should show the user, agent, tool, time, outcome and approval decision for important actions. Azure API Management can send MCP activity to Application Insights and Azure Monitor, giving security and operations teams a central record.
Be careful with full payload logging. Tool arguments and results can contain customer information, prompts, credentials or commercially sensitive data. Log only what is required, remove sensitive fields and apply an appropriate retention period.
Microsoft Defender can help inventory supported agents, assess risk and detect unsafe activity. Wiz can add cloud-wide context by identifying exposed MCP services, excessive permissions and vulnerable infrastructure across complex environments.
A realistic business scenario
Consider a 200-person professional services firm building an agent to handle client onboarding. The agent needs to read submitted forms, create Microsoft 365 folders, open a project in the finance system and notify the delivery team.
The unsafe approach gives one agent broad access to SharePoint, finance and email. The safer design uses a dedicated Entra identity, separate MCP tools for each action, read-only access by default and human approval before a finance record is created.
The business still saves employees from repetitive data entry. The difference is that one malicious document, mistaken instruction or compromised account cannot silently control the entire onboarding process.
How this supports Essential Eight maturity
These controls reinforce several parts of the Essential Eight, the Australian government’s cybersecurity framework. Multi-factor authentication, restricted administrative privileges, application control, patching and reliable backups all remain relevant to agent hosts and MCP servers.
However, deploying these products does not automatically make an organisation compliant. Agent identities, tools, servers and approval processes must be included in security assessments, access reviews and incident response plans.
Start with a controlled deployment
Begin with one valuable process, a small tool set and read-only access. Test hostile prompts, stolen credentials, unavailable systems and incorrect tool responses before allowing the agent to make business changes.
CloudProInc combines more than 20 years of enterprise IT experience with practical Microsoft Partner and Wiz Security Integrator expertise across Azure, Microsoft 365, Defender, OpenAI, Claude and cloud security. We help organisations build controls that work in day-to-day operations, rather than producing an architecture diagram nobody maintains.
If you are planning an agentic AI or MCP deployment and are unsure where the biggest risks sit, we are happy to review the design and identify the practical controls needed before production—no strings attached.