One of the consistent objections we hear from Australian enterprise teams evaluating Claude is a governance question: "How do we control what Claude connects to?" Anthropic has answered it. Enterprise admins can now centrally manage authorisation for MCP connectors, controlling which connectors users in their organisation can access, from a single admin interface.
What Changed
Previously, MCP connector authorisation was handled at the individual user level. Each user could approve and configure connectors for their own Claude sessions. For individuals, that is convenient. For enterprise IT, it is a security gap. It is the same category of gap that created shadow IT problems with SaaS adoption a decade ago.
With centralised managed auth, the model inverts:
IT admins set connector authorisation policies for the whole organisation
Users do not individually approve or configure connectors
Connectors not approved by the admin cannot be added by users
The admin has a single view of what is connected and who has access
This is the access control model enterprise security teams already require for every other platform they deploy. It is how Microsoft 365, Salesforce, and Atlassian work. Claude now fits the same pattern.
Why This Matters for Australian Enterprise
Shadow IT is eliminated. Without centralised auth, users could connect any MCP-compatible tool to their Claude sessions, including tools that have not been security-reviewed. Central auth closes that off. The same reasoning that led organisations to block unapproved OAuth app installations applies here.
Audit trails become possible. If you need to demonstrate to your CISO, internal audit team, or an external assessor which systems Claude has access to, that is now a report from the admin interface, not a manual survey of user configurations. For organisations in APRA-regulated industries (banking, insurance, superannuation), this matters directly for CPS 234 information security obligations.
Least-privilege access is enforceable. Admins can approve specific connectors for specific teams. The finance team gets the accounting connectors. The engineering team gets the code repository connectors. Nobody gets more access than their role requires. This is a foundational zero-trust principle that previously had to be enforced by policy alone; now it is enforced by the platform.
Australian Privacy Act compliance. Any system accessing customer personal information needs to operate on a least-privilege, audited basis under the Australian Privacy Act 1988 and the forthcoming APP amendments. Centralised MCP auth provides the control layer that makes this achievable without treating Claude as a special exception to your governance framework.
The Business Case in Numbers
For a mid-sized Australian enterprise (500-2,000 employees) rolling out Claude to knowledge workers, the governance overhead of per-user connector management is significant. At $45,000 per year in IT administrator time to manually audit and manage connector access across a 500-person deployment, centralised auth pays for itself in the first quarter. Beyond cost, the risk exposure from a single unreviewed connector accessing sensitive customer data vastly exceeds the Claude licence cost, making governance tooling not optional but essential.
What to Do Now
If your organisation is running Claude at the enterprise tier, the immediate steps are:
Audit which connectors are currently authorised across your user base. Before you migrate to centralised auth, you need a baseline
Define your connector approval tiers: organisation-wide (e.g. internal knowledge bases), role-specific (e.g. CRM access for sales), and restricted (e.g. financial systems)
Run each candidate connector through your existing third-party risk assessment process: the same process you use for any SaaS tool
Enable centralised auth and document the policy in your information security management system
Establish a review cadence for new connector additions; quarterly is typical for most regulated Australian businesses
Pairing With Workload Identity Federation
Centralised MCP auth works best alongside Workload Identity Federation, also now generally available on the Claude Platform. Together, these two features give enterprise teams the access control and credential management infrastructure needed to run Claude in regulated environments, without maintaining a separate set of service account credentials for every Claude integration.
Workload Identity Federation means Claude workloads can authenticate using your existing identity provider (Entra ID, Okta, or similar) rather than static API keys. Combined with centralised MCP auth, the security architecture for a Claude deployment starts to look like any other enterprise application: federated identity, role-based connector access, central audit logs.
The Broader Pattern
This release is part of a consistent pattern from Anthropic: building the enterprise governance layer that makes Claude deployable inside organisations with real compliance obligations. Earlier releases addressed data residency, usage policies, and audit logging. Centralised MCP auth addresses the connector governance gap that has been the main hesitation point for security-conscious Australian enterprise customers.
For organisations that had previously decided Claude was not ready for production deployment because of the connector governance question, this changes the calculus. The technical blocker is now resolved. What remains is the internal process work of defining your connector policy and getting it approved.
If you want to map out what a compliant Claude deployment looks like for your organisation, talk to Automata AI. We work with Australian enterprise teams on Claude governance, security configuration, and deployment architecture.
