MCP-Based Agentic AI Workflows in VCF 9.1 Building the Secure Substrate for Enterprise Agents

This is Part 27 of the series, a frontier-topic article on the architecture pattern emerging for enterprise agentic AI Model Context Protocol (MCP) as the integration standard, and VCF 9.1 as the secure substrate. Where Part 7 covered Private AI Foundation and the inference workload pattern, this article covers the next layer up: agents that act on behalf of users by calling tools, integrating data sources, and taking actions across systems.

Agentic AI is the next workload class. In 2024 and 2025, enterprise customers worked with LLMs as conversational interfaces. In 2026, the conversation has shifted to agents that don’t just answer questions they execute on the user’s behalf. They read calendars and schedule meetings. They query databases and generate reports. They open tickets, deploy infrastructure, send emails, and take actions across the enterprise.

The security and governance challenge is significant. An agent that can call tools is, by definition, a piece of code with delegated authority to act. The questions enterprises now ask which agent can call which tool, on whose behalf, with what audit trail, with what containment if something goes wrong are architecturally new, but they map cleanly to patterns the platform team already knows: identity, RBAC, network segmentation, observability, audit.

VCF 9.1’s Secure MCP-based Agentic AI Workflows provide the architectural substrate. This article walks through what MCP is, why it matters for enterprise agentic AI, the security pattern that VCF 9.1 enables, and the design considerations for architects planning agentic AI deployments.

What MCP is, briefly

Model Context Protocol (MCP) is an open protocol that standardises how AI models call tools and access data sources. Introduced by Anthropic in late 2024 and rapidly adopted across the AI ecosystem, MCP is to the agentic AI integration layer what HTTP is to the web.

The architectural pattern:

• An MCP client lives within the agent typically the application or platform hosting the LLM

• An MCP server exposes tools, resources, and prompts to clients via a defined protocol

• Tools are functions the agent can call (e.g., “query the customer database,” “schedule a meeting,” “deploy a VM”)

• Resources are data sources the agent can read (e.g., documents, database query results, calendar events)

• Prompts are templates the agent can use to construct its reasoning

• The protocol handles invocation, response handling, and error conditions in a standardised way

Why it matters: before MCP, every agent integration was bespoke. Each enterprise tool needed custom adapters per agent platform. MCP standardises the integration layer. Build an MCP server for your tool once; every MCP-compatible agent can use it. The integration economics flip from quadratic to linear.

Why MCP matters for enterprise agentic AI

Enterprise environments are tool-rich ITSM systems, observability platforms, databases, identity providers, infrastructure platforms, communication tools, code repositories, ticketing systems, financial systems. An agent useful to an enterprise user typically needs to integrate with many of these.

MCP addresses three enterprise-specific challenges:

Integration scalability. Enterprise tool counts are large. Building bespoke integrations per agent per tool doesn’t scale. MCP makes integrations reusable across agents and over time.

Security and governance integration. MCP servers can enforce authentication and authorisation at the protocol layer. An enterprise can deploy an MCP server in front of an internal tool and enforce that only authenticated agents acting on behalf of authorised users can call it. This is hugely better than per-agent credential management.

Audit and observability. Every tool invocation flows through the MCP server. This is a natural choke point for logging who called what, on whose behalf, with what arguments, with what response. Enterprises with audit requirements get a uniform observability surface across all agentic activity.

These are the same controls enterprises already apply to human users just applied to agentic AI. The principles aren’t new; the substrate that enforces them at agent scale is.

VCF 9.1 as the secure substrate

VCF 9.1’s Secure MCP-based Agentic AI Workflows take the MCP architectural pattern and provide the platform-level controls enterprises need to deploy agentic AI safely. The capabilities stack into a defensible operating model.

Identity Broker federation. Agents and MCP servers authenticate through the same federated identity model used for human users. The IDP (Azure AD/Entra, Okta, Ping, ADFS) is the source of truth. Agents inherit the same MFA, conditional access, and break-glass procedures.

Per-agent and per-user authorisation. Authorisation flows separately for the agent identity and the user-on-whose-behalf the agent is acting. An agent can be authorised to act, but only on behalf of users who individually have permission for the action. “Delegated authority with downstream authorisation” the pattern human security knows well.

Network segmentation via NSX VPC and DFW. MCP servers and agents deploy into network segments with east-west security enforced by distributed firewall. Agents can reach only the MCP servers they’re authorised to reach. Lateral movement constrained at the network layer.

Centralised observability via VCF Operations. Agent invocations, tool calls, error events, performance metrics surfaced through the same observability surface as all other platform activity. Security operations can monitor agentic activity alongside everything else.

Audit and compliance via VCF Operations for Logs. Immutable, retention-policy-controlled logging of every MCP interaction. The audit evidence regulators and internal compliance teams need.

Private AI Foundation as the inference substrate. LLMs running on-prem within VKS clusters with GPU acceleration. Inference happens inside the enterprise boundary. Data doesn’t leave for inference; only structured tool calls leave the LLM context.

Workload Domain isolation for tenant separation. MSPs or large enterprises with multiple business units can isolate agentic AI workloads per tenant with Workload Domain boundaries. Cross-tenant access requires explicit policy.

ACC and SPM for continuous compliance. The agentic AI deployment carries its compliance scope as a Live Application Stack Blueprint (Part 26). Continuous Compliance Enforcement validates that the runtime matches the declared compliance posture.

The reference architecture

A defensible enterprise MCP-based agentic AI deployment on VCF 9.1 typically has these layers:

Inference layer. LLM models running in Private AI Foundation on VKS clusters with GPU passthrough. Model versions controlled, model weights protected, prompts logged.

Agent runtime layer. The application hosting the agent logic. Authenticated to Identity Broker. Authorised per-agent. Deployed in its own Workload Domain or namespace. Network-isolated from other agents.

MCP server layer. MCP servers exposing enterprise tools and data sources. Each MCP server authenticated to Identity Broker. Each server’s tools individually authorised. Logging at the protocol layer.

Tool and data layer. The actual enterprise systems behind the MCP servers ITSM, databases, observability, identity, financials. Access from MCP servers governed by traditional enterprise controls.

Observability and audit layer. VCF Operations collecting metrics and traces. VCF Operations for Logs collecting audit events. SIEM integration for security operations.

Governance layer. Live Application Stack Blueprint defining the full agentic AI deployment. ACC compliance scope. SPM benchmarks. Change management workflow for agent and MCP server updates.

The stack looks recognisable same identity, network, observability, and governance patterns the platform team already runs. The novelty is in the workload type (agentic AI), not in the controls (which are enterprise architecture standards).

Common use cases

Where MCP-based agentic AI on VCF 9.1 lands well in enterprise:

IT operations agents. Agents that triage alerts, query observability tools, propose remediation, and (with appropriate guardrails) execute remediation. The MCP servers expose VCF Operations queries, ticketing system actions, and infrastructure commands.

Customer service agents. Agents that handle Tier-1 customer inquiries by querying CRM and order systems, proposing resolutions, and escalating where appropriate. MCP servers expose the CRM, order management, and knowledge base.

Knowledge work agents. Agents that gather information across enterprise systems to support knowledge workers financial analysis from accounting systems, market research from data warehouses, document drafting from internal repositories.

Development assistance agents. Agents that help developers query code repositories, generate code, run tests, and create pull requests. MCP servers expose Git, CI/CD, code search, and documentation systems.

Compliance and audit agents. Agents that gather compliance evidence across systems, validate configurations against baselines, and prepare audit reports. MCP servers expose the configuration data and compliance baselines.

Design considerations and risks

Agentic AI is not a low-risk workload class. Architects planning deployments should think through:

Authorisation granularity. Per-tool authorisation is the minimum. Per-action-within-tool authorisation may be needed for sensitive operations. Don’t deploy an agent with authority to call a tool until you’ve thought through what that tool can be used for at worst case.

Containment patterns. If an agent goes wrong hallucinates a destructive action, gets prompt-injected, or just behaves unexpectedly what stops the damage? Network segmentation, kill switches, action approval gates, and rate limiting all matter.

Audit completeness. Every agent invocation, every tool call, every parameter, every response should be logged immutably. If a future investigation asks “what did the agent do on Tuesday at 14:32,” the answer must be available.

Prompt injection defences. MCP servers should sanitise inputs and constrain what agents can pass through. Direct user-to-tool flows that bypass agent reasoning may be safer than agent-mediated flows for certain sensitive operations.

Model lifecycle management. LLM models update. The behaviour of agents using those models can change. Version pinning, regression testing, gradual rollout patterns matter for agentic deployments.

Cost and capacity management. Agentic workloads can generate unpredictable inference load. An agent in a loop can consume substantial GPU capacity. Rate limiting, budget enforcement, and capacity monitoring are operational requirements.

Liability and accountability. When the agent does something wrong, who’s accountable the developer, the deploying team, the user-on-whose-behalf the agent acted? These are governance questions that should be answered before deployment, not afterwards.

Closing

MCP-based agentic AI is the next workload class enterprise architects need to design for. The protocol provides the integration standard. The governance challenge authentication, authorisation, segmentation, audit, containment maps to enterprise architecture patterns the platform team already knows.

VCF 9.1’s Secure MCP-based Agentic AI Workflows provide the platform-level controls that make agentic AI defensible. Identity Broker for federated identity. NSX VPC and DFW for segmentation. VCF Operations for observability. VCF Operations for Logs for audit. Private AI Foundation for the inference substrate. ACC and SPM for compliance posture. Live Application Stack Blueprints for governance.

In my design conversations, the agentic AI questions I work through:

• Which agent workloads are actually valuable to the business, vs which are demos in search of a problem?

• What’s the identity and authorisation pattern who can the agent act on behalf of, with what controls?

• What tools does the agent need access to, and what’s the worst case for each tool being used badly?

• What’s the containment pattern network segmentation, rate limiting, action approval gates, kill switches?

• What’s the audit completeness requirement every interaction logged immutably with what retention?

• How are LLM model versions managed version pinning, regression testing, rollout patterns?

• What’s the cost and capacity envelope, and how is it monitored?

• Who’s accountable when the agent does something wrong and how is that accountability documented?

Get those answered and agentic AI moves from a security-team nightmare to a governed platform capability.

Part 28 of the series covers Native Object Storage on vSAN (Tech Preview in 9.1) the emerging on-platform object storage capability that becomes relevant for AI training data, backup targets, and cloud-native application patterns.

Sources

• Broadcom Streamline, Simplify and Protect all your AI workloads with VCF 9.1

• Broadcom Avi Innovations for VCF 9.1: Powering Kubernetes, Agentic AI and VPC Workloads

• Broadcom Scale, Simplify, and Secure Your Private Cloud Operations with VCF 9.1

• Broadcom VCF 9.1: The Secure, Cost-Effective Private Cloud Platform for Production AI

• Broadcom Press Release Broadcom Announces VMware Cloud Foundation 9.1

• Broadcom Announcing VCF 9.1: Modern Private Cloud Built for Efficiency and Resilience

• Anthropic Introducing the Model Context Protocol (protocol authoritative source)