Australian enterprises are scaling agents faster than governance - MCP is the fix

Nearly every software team has AI in play: recent research found 99% of DevSecOps professionals in Australia are using or planning to use AI in the software development lifecycle. The trust hasn't kept pace. The same research found that 79% say AI is making compliance management harder for their organisation. Agents are arriving faster than the governance around them, and the gap is widening.

Against that backdrop, MCP has become a target for skepticism across many developer circles. Too much overhead and complexity are to blame. For certain small-scale use cases, they have a point. But the argument breaks down the moment you move beyond a solo project into the kind of agentic systems Australian enterprises are actually trying to build.

Give the sceptics their due

When you are the only user and trust is implicit, using an MCP server can add unnecessary complexity. A direct API call is the simpler and often better choice for wiring up a local AI assistant, building a personal automation, or running an isolated script on your own virtual machine. Developers are not wrong in that context.

Where enterprise complexity changes the equation

Enterprise agentic systems are not single-developer, single-trust-boundary setups. Agents operate across teams, systems, and organisations, often acting on behalf of users who are not even aware an agent is involved. In those environments, direct API calls start creating problems that no allowlist can reliably solve.

Credential delegation is one of the first friction points. Building a platform that runs agents on behalf of enterprise customers quickly leads to questions about agent identity, permission inheritance, and whether it runs as a service account. There is no universal right answer, but the wrong choice carries consequences.

An agent with excessive access creates audit and compliance exposure. While insufficient access causes the agent to fail silently, which erodes platform trust over time. Enterprise buyers in regulated industries raise this concern before the formal security review.

In regulated environments, "the AI did it" is not a sufficient audit entry. Teams need to answer what the agent did, on whose behalf, and under what authority. That information needs to be embedded in the system by design, not reconstructed from logs after an incident. A direct API integration can't provide this, but a well-implemented MCP setup can. It surfaces the necessary context at the tool call level, capturing which server, which credentials, and which scope authorised each action. 

An allowlist feels like governance, but it isn't

When someone asks whether an agent can access things it should not, the instinct is to reach for an allowlist. Define the permitted tools, check against it before executing, complete the task, and move on. This approach feels like governance because it resembles a policy. A policy, however, is only as strong as the system enforcing it. In practice, allowlists break down through misconfiguration, unexpected agent behaviour, and edge cases nobody anticipated when the list was originally written.

The more durable option is structural least privilege. When an agent's MCP connection only exposes the tools required for its specific task, the agent cannot exceed that scope. For security teams in regulated environments, "it structurally cannot exceed its scope" and "it follows the rules" are meaningfully different assurances. 

Where MCP still owes us answers

MCP still creates friction in two areas.

Capability-scoped server provisioning remains too manual. When proper configuration requires deep infrastructure knowledge, administrators often skip it and fall back on broad connections with an allowlist as a backstop. Until the industry makes provisioning accessible to non-specialists, broader adoption will stall.

The operational layer for managing MCP connections needs to be accessible to security and platform teams, not just the developers who originally built the integration. An administrator should be able to view every active connection in their environment, understand what each one exposes, and identify who is using it, all without reading a config file or tracking down the original implementer. 

For organisations deploying agents at scale, these requirements are table stakes.

Enterprise scale requires governance 

The AI trust deficit is measurable. The National AI Centre's latest SME AI Pulse found that among Australian businesses not adopting AI, around 65% cited either distrust in AI decision-making or a strong preference to keep humans in control. 

Those concerns should be addressed through structural governance that builds controls directly into the architecture rather than relying on assurances. Weak governance doesn't announce itself in a review. It announces itself through incidents, and autonomous agents operating at enterprise scale will find the gaps before you do. The next steps are clear: audit what your agents can access, align permissions to actual needs, and put structural safeguards in place before a gap becomes a problem.