What does Enterprise Ready MCP mean?

How do today’s enterprise tools map onto tomorrow’s AI systems? Start with a familiar path: a user talks to a chatbot, and the chatbot uses Model Context Protocol (MCP) to reach an external resource. That resource might provide database access, run a computation or supply a prompt. The interface connects the AI system to capabilities outside the model.

Now add an IT administrator who launches an asynchronous agent. Nobody needs to be sitting in a chat window while that workload runs, but it still needs access to secured internal tools through MCP. Add another connection: an employee’s chatbot calls an MCP server that queries an agent already running in the cloud. The enterprise problem now spans people, unattended workloads and services acting through other services. Each connection needs an answer to who is acting and what they may do.

Tobin South approaches this architecture from enterprise security work at WorkOS and, in his introduction, research on agent safety at Stanford. The practical question is how to supply the identity and authorization infrastructure that lets an agent move from a working experiment into a product an organization can adopt.

The running example begins with an API that South presents as real: call it to feed goats, then watch them on a livestream. Build an employee emotional-support bot around that capability and give the model a tool for invoking it. The API and goats are the starting point; the expanding SaaS business that follows is an illustrative story. A single tool call is enough to get the first version working.

Why move that integration to MCP? South points to several benefits beyond the individual call:

• Shared ecosystem: integrations, providers and security tools can sit between the model and the resource.
• Standardization: a common interface gives model developers a consistent target for training and evaluating tool use.
• State management: retaining context across interactions can support management of the model’s interaction with a resource.

The last benefit needs a precise boundary. South describes a stateful connection, but the March 2025 transport specification makes Streamable HTTP session assignment optional. A logical session is neither a mandatory persistent connection nor an authorization guarantee. MCP supplies useful structure; the application still has to enforce its security policy.

There is also a lower-stakes reason to start: building an MCP server is an accessible way to experiment with new capabilities. The goat tool makes that appeal concrete. The harder work begins when someone else needs to use it.

A local server proves that the model can reach the API. It does not yet prove that other people can safely use the service. South describes a common stopping point: an internal demo connects successfully, everyone sees that it works, and the project goes no further. The next milestone is authentication and authorization.

For the goat service, that means requiring login, restricting actions through roles or scopes, and reserving administrative privileges so ordinary users cannot overfeed the animals. Authentication establishes the caller’s identity; authorization determines which operations that identity may perform.

A minimal way to make that distinction concrete is to write down separate grants. This illustrative JSON uses separate permissions for feeding goats and changing feeding limits:

{
  "roles": {
    "employee": {
      "permissions": ["goats:feed"]
    },
    "administrator": {
      "permissions": ["goats:feed", "goats:limits:write"]
    }
  }
}

These are example application permission names, not MCP configuration keys. The server must check the relevant grant before performing the operation; putting a role in a record does not enforce it. Permission to feed also does not imply permission to bypass feeding limits.

For an internal deployment, South also suggests a VPC and NAT gateway. Network isolation can reduce exposure, but a NAT gateway is not an authorization mechanism. Private networking and application access checks address different boundaries, and the latter remain necessary for callers inside the network.

Suppose employees love the tool. The next step in the story is a public MCP server that people can connect to Claude or use from their own applications. Add Stripe payment rails, return a URL for the user to complete the payment interaction, and offer introductory credits. The conversational interface still depends on familiar product infrastructure: accounts, billing and an onboarding allowance.

Deployment does not require treating MCP as an entirely new category of compute. An MCP server is a normal workload that conventional cloud providers can host. Specialized hosting options may help, but getting a server online is only one part of making the public service sustainable.

The hypothetical service goes viral, and its free credits become an attack surface. Someone creates an account, spends the allowance, then creates another account and repeats. South recounts an unnamed AI vendor whose credits were being used to generate fan fiction, even though that was not the product’s intended purpose. An application backed by an AI API can become a convenient route to subsidized inference.

Bot blocking at signup and controls throughout the authentication stack address that account-cycling problem. Input validation addresses a different surface: what users send into the tool. South frames this as protecting the goats from prompt injection; validation belongs in that defense, but cannot by itself guarantee that a model will disregard malicious instructions.

MCP also changes the operational shape of client registration. South describes application dashboards becoming crowded with registrations. More precisely, MCP clients register as OAuth clients; the March 2025 authorization specification recommends dynamic client registration rather than requiring every MCP server to register itself as an application. An identity dashboard designed around a small set of manually created applications can become awkward when registrations arrive dynamically. Authentication and management tools need to accommodate that pattern as usage grows.

Selling the agent—or the MCP server itself—to an enterprise follows a familiar SaaS path: single sign-on, lifecycle management and provisioning. South cites Block’s Goose as an example of internal agent adoption and describes provisioning access to both the client and MCP servers. His broader vision is that employees receive access to internal MCP resources through enterprise identity infrastructure and use chat as a routine way to automate work.

That identity foundation needs governance around the actual operations:

• Fine-grained access controls: check which resources and actions a caller may use, with checks fast enough for the workload.
• Audit logs: retain records that support investigation and incident response.
• Data-loss prevention: control sensitive information leaving the organization through MCP interactions.

South also invokes GDPR when discussing additional logging obligations for AI. That should not be read as a blanket GDPR rule for every AI workload: the explicit AI-specific provisions verified here are in the EU AI Act, including logging capabilities and retention provisions for high-risk systems. The applicable obligations depend on the deployment. The operational concern remains concrete: employees chatting with many servers create many opportunities to send information somewhere it should not go.

At this point the service is enterprise-ready only with qualifications. The protocol is developing, and authenticating a server does not settle every question in the opening architecture. Returning to that diagram separates familiar integrations from the remaining agent-specific difficulties.

South treats these connections as implementable, even where integration remains awkward or MCP support is still developing. In particular, a server’s access to a downstream resource needs the right scopes; authenticating the upstream client does not automatically grant the right downstream permissions.

Remote asynchronous workloads make authentication harder to assemble correctly. The agent must connect without an interactive user, handle the registration arrangement and receive appropriate authorization. This was not an absence of application authentication in the historical specification: the March 2025 authorization document already discussed client credentials for application callers. South’s concern is the difficulty of getting the complete headless workflow and its access controls right.

A background agent may also reach a point where it lacks information and needs a person. South introduces elicitation as a new RFC at the time of the talk: a way to ask for additional input rather than continuing without it. Elicitation subsequently appeared in the June 18, 2025 specification as server requests for structured user input through a client. That mechanism does not, by itself, solve how an arbitrary background agent locates and contacts the relevant human.

The broader unresolved problem is what happens to permissions when one AI workload delegates to another. A task description can say what the receiving agent should do, but that description must not be the only thing limiting its authority. Scopes, access controls and the permissions of the receiving workload’s service account need to agree.

South criticizes reliance on natural-language instructions and model alignment in agent-to-agent interactions, using A2A as his example. This is a critique of delegated task permissions, not evidence that A2A lacked security mechanisms: its launch announcement already described authentication and authorization support. The difficult question remains whether the receiving agent has enforceable authority appropriate to the delegated task. Available cloud hosting does not solve delegated authorization. South identifies authorization and access control as the hardest remaining part of bringing these workloads into external enterprises.

South closes by inviting developers to build on the security stack, then offers a more tangible example: a shirt available only through MCP. The demonstration requires a computer and an MCP-capable client; he switches to Cursor. The purchase begins with setup rather than a conventional storefront.

The demonstrated sequence is:

1. Copy the website-provided JSON into the editor’s MCP configuration.
2. Confirm that the MCP server is enabled.
3. Create an account to obtain authorized access.
4. Ask the assistant to buy a shirt.

The conversational request comes after the client connection and account setup. It does not replace them.

A brief Wi-Fi interruption slows the interaction. The assistant then needs a mailing address and shirt size; South supplies an address and asks for a medium. He says the system recognizes his name, has authorized him and has performed a validation check. He also explains that signup bot blocking protects the shirt offer from abuse. Finally, he reports that the shirt has been purchased. The closing demonstration puts the earlier infrastructure behind a small, concrete transaction: connect a client, establish identity, gather the required input and complete an authorized operation.