Anthropic MCP Update Makes Enterprise Agent Connections Safer

In this blog post Anthropic MCP Update Makes Enterprise Agent Connections Safer we will explain what the latest Model Context Protocol changes mean for business. Many organisations want AI agents to work with company systems, but their security teams are uncomfortable with employees approving connections individually or agents receiving more access than they need.

At a high level, Model Context Protocol, or MCP, is a standard way for AI tools such as Claude to connect with business data and services. Think of it as a common plug that lets an AI agent securely interact with approved systems such as Microsoft 365, a customer relationship management platform, a service desk or an internal database.

The 28 July 2026 MCP specification is the largest revision since the protocol was introduced. It makes MCP easier to operate at enterprise scale, strengthens its alignment with established identity standards and provides a clearer structure for adding new capabilities.

Why AI agent connections have become a business problem

An AI assistant that only drafts emails presents a relatively contained risk. An AI agent that can read SharePoint, update customer records, create support tickets or run financial reports is different.

The agent is no longer simply producing text. It is acting inside your business systems.

Until recently, MCP connections often relied on individual users authorising each service. That approach may work during a small trial, but it becomes difficult to control across 50, 100 or 500 employees.

Security teams can struggle to answer basic questions. Who connected the agent? Did they use a company or personal account? What information can it read? Can it change or delete records? Will its access disappear when the employee leaves?

These are governance questions, not technical details. A poor answer can lead to data exposure, compliance failures and expensive incident investigations.

What changed in the latest MCP update

Connections are simpler to run at scale

Previous versions of MCP relied more heavily on sessions. In plain English, the server had to remember an ongoing connection and ensure later requests returned to the correct place.

That created extra infrastructure, monitoring and troubleshooting work. Larger deployments could require shared session databases and special routing rules, adding both cost and points of failure.

The new MCP core is stateless. Each request carries the information needed to process it, so it can be handled by any available server rather than being tied to one ongoing session.

This does not automatically make an AI agent secure. It does, however, simplify the architecture, remove unnecessary stored session information and make individual requests easier to route, inspect and trace.

The business outcome is lower operational complexity. Companies can expand successful AI pilots without building an oversized platform simply to keep agent connections working.

Authorisation now fits enterprise identity systems better

The most important security improvement is MCP’s closer alignment with OAuth and OpenID Connect. These are widely used standards that allow applications to confirm identity and issue controlled access without sharing a person’s password.

MCP also supports enterprise-managed authorisation. This allows an organisation’s identity provider, such as Microsoft Entra ID, which manages employee identities and access, or Okta, to become the central decision-maker.

Instead of asking every employee to approve every connection, IT can define access according to job role, group membership and security policy. Employees can then use approved MCP services through their normal company sign-in.

This improves the employee experience, but the bigger benefit is control. Access can be reviewed centrally and removed when somebody changes role or leaves the business.

For a deeper look at identity between autonomous systems, see our guide to securing agent-to-agent communication with Microsoft Entra ID.

New capabilities can be introduced in a controlled way

MCP now uses a clearer extension model. Extensions are optional capabilities that both the AI application and connected server must explicitly support.

Examples include Tasks for work that continues over a longer period and MCP Apps for displaying interactive forms, charts and other interfaces inside an AI conversation.

This matters because new agent features should not quietly appear across your environment. They should be assessed, approved and monitored before employees can use them with sensitive systems.

The extension model gives technology leaders a cleaner point at which to ask whether a feature is needed, what data it touches and whether human approval should be required.

Changes should become easier to plan

The updated specification introduces a formal process for retiring older features. Organisations should receive a clearer transition period instead of discovering that a critical integration has unexpectedly stopped working.

This is important for budgeting and risk management. AI platforms are developing quickly, but production business systems still need predictable maintenance, testing and support arrangements.

What safer MCP could look like in practice

Consider a 200-person professional services firm connecting an AI agent to SharePoint, its service desk and customer management platform.

Under an employee-by-employee model, dozens of people may authorise separate connections. Some choose the wrong account, former employees retain access longer than expected, and IT has no simple view of which agent can perform which action.

With centrally managed authorisation, the firm can create an approved group in Microsoft Entra ID. Staff only receive access if they have multifactor authentication, use a company-managed device and belong to an appropriate business team.

The agent may be permitted to read approved customer information and create draft service tickets. Updating customer details or closing a ticket could require a manager’s confirmation.

Every request should also be logged. If an unusual action occurs, the security team can identify the user, agent, tool, time and requested operation without reconstructing events from several unrelated systems.

The result is not merely a more convenient connection. It is faster onboarding, cleaner offboarding, fewer support requests and a stronger audit trail.

The update does not remove the need for good security design

MCP provides a stronger foundation, but it cannot decide which business data an agent should access. That remains your organisation’s responsibility.

Before connecting Claude or another AI agent to production systems, define separate permissions for reading information and changing it. An agent that summarises invoices does not automatically need permission to approve payments.

High-impact actions should require human confirmation. This can include deleting records, sending external communications, changing permissions, creating accounts or making financial commitments.

You should also protect the MCP server itself. This is the service that exposes approved tools and data to the agent, making it a valuable target for attackers.

Controls should include regular patching, restricted administrative access, multifactor authentication, application control and central monitoring. These measures also support Essential Eight, the Australian Government’s cybersecurity framework that many organisations use to reduce common security risks.

Cloud security platforms such as Wiz can help identify exposed services, excessive permissions and risky paths through Azure environments. Microsoft Defender can then help detect suspicious activity across identities, devices, cloud services and business applications.

Practical steps for technology leaders

1. Inventory existing connections. Identify every MCP server, AI agent, data source and business service currently in use or being tested.
2. Define the business purpose. If a connection does not save time, reduce cost or improve service, question whether the additional access is justified.
3. Map access to company identities. Avoid shared credentials and personal accounts. Use centrally managed identities wherever possible.
4. Separate reading from action. Start with read-only access and add write permissions only when there is a clear need and suitable approval process.
5. Record agent activity. Logs should show who initiated an action, which agent and tool were involved, what was requested and whether it succeeded.
6. Test before upgrading. Existing MCP deployments are not automatically switched off by the new specification, but newer software development kits may contain breaking changes. Test migrations in a controlled environment before touching production systems.

If your team is still deciding how MCP should fit into its wider AI platform, our articles on connecting Claude to business systems safely and connecting Microsoft Foundry agents using MCP and OpenAPI provide useful next steps.

Development teams using Microsoft technologies should also review why the MCP SDK for .NET turns tool access into a security decision. The key issue is not whether an agent can call a tool, but whether it should.

A better foundation for enterprise AI

The latest MCP update removes some of the friction that has made enterprise agent connections difficult to scale and govern. Central identity control, simpler infrastructure and clearer capability management give CIOs and CTOs a more practical foundation for production AI.

CloudPro Inc combines more than 20 years of enterprise IT experience with hands-on expertise across Azure, Microsoft 365, Microsoft Entra ID, OpenAI, Claude, Defender and Wiz. As a Melbourne-based Microsoft Partner and Wiz Security Integrator, we help organisations connect AI to real business systems without losing control of identity, data or risk.

If you are not sure what your current AI agents can access, or whether your MCP design is ready for production, we are happy to take a practical look with you — no strings attached.