TL;DR
Independent agent assurance on VMware Cloud Foundation (VCF) 9.1.1 requires more than separate tenants, protected model endpoints, and healthy infrastructure. The agent must remain unable to administer the controls that authorize its actions, obtain the executor’s credentials, or rewrite the evidence used to accept the result. Map those requirements across VMware vSphere Kubernetes Service (VKS), NSX, vDefend, Private AI Services, and the surrounding identity and recovery systems.
Broadcom’s release announcements distinguish available model sharing and operations capabilities from the announced AI Gateway and Secure Agent Framework. Build today’s control boundary from supported components and separately governed services. Evaluate future integrations against that boundary rather than treating an announcement as an installed safeguard.
Share infrastructure where the risk allows it. Keep authority and evidence outside the agent’s control.
Introduction
Consider a hypothetical private AI service used by several business units. An operations agent receives a request to connect one newly approved application to a shared inference endpoint. It proposes a network-policy change, and an AI reviewer approves the explanation.
The endpoint responds. GPU utilization is normal. The operations dashboard is green.
But the change admitted an entire application network rather than the approved workload group. Nobody tested the excluded consumers. The same automation identity can also change the security policy protecting the agent’s management access.
The platform is available. The model is useful. Neither observation establishes that the change respected its authority.
Article 5 defined the architecture that prevents self-authorization. This installment maps it to VCF, focusing on shared-model consumption and a bounded NSX connectivity change. The design is proposed, not a Broadcom-validated implementation or a report of DTD testing. Product-status statements use primary announcements reviewed on September 12, 2026; exact component compatibility, entitlements, and configuration remain deployment prerequisites.
Establish the Release Boundary Before the Trust Boundary
Broadcom announced VCF 9.1.1 general availability on September 3, 2026. That does not make every capability discussed during the same announcement cycle generally available.
Use the following distinctions when creating the implementation baseline. The source documents are Broadcom’s VCF 9.1.1 general-availability announcement, operations announcement, GitOps explanation, and VMware AI Factory announcement.
| Capability | Status described by Broadcom | Consequence for this design |
|---|---|---|
| Multi-tenant model sharing | Generally available with VCF 9.1.1. | Shared inference can be considered; tenant authorization and application-state isolation still need validation. |
| AI Assistant for VCF and enhanced VKS observability | Available operations capabilities, with the assistant requiring configuration. | Useful diagnostic inputs, not an independent action-approval system. |
| Argo CD Supervisor service through vCenter | Identified as production-supported. | An available delivery option, subject to the applicable configuration and support requirements. |
| New VCF Automation organization self-service GitOps integration | Technology preview. | Do not confuse this integration’s status with that of the underlying Supervisor service. |
| Native vSAN S3-compatible object storage | Technology preview in the release announcement. | Do not make it the assumed production evidence repository. |
| AI Gateway and Secure Agent Framework | Listed under future-release capabilities. | No current assurance credit based solely on their announced functions. |
The GitOps distinction matters. Saying “Argo CD on VCF is preview” is too broad. Saying the new organization-level self-service integration is production-supported is also unsupported by the cited announcement.
Record the installed VCF, vCenter, NSX, Supervisor, VKS, Private AI Services, security components, and GPU software separately. A VCF release label is not a complete version manifest. Confirm the support and entitlement basis for the selected vDefend and other services rather than inferring it from the private-cloud branding.
DTD’s existing VCF 9.1.1 release analysis covers the wider release. Here, the decision is narrower: which deployed mechanisms can independently constrain and verify this agent?
Choose Placement Against a Declared Compromise Scenario
For the initial pattern, assume the agent process and its reachable credentials are compromised. The assurance services and their administrators remain trusted. That assumption permits useful separation within a shared private cloud, provided the effective permissions and deployment paths enforce it.
Use a VKS workload cluster for the customer-managed agent application. Let it consume Private AI Services through the supported service interfaces. Place the customer-managed authorization service, execution adapter, and verifier on separately governed virtual machines or a separate workload cluster. Do not relocate managed Private AI Services internals merely to make the diagram symmetrical.
Keep these assurance services off the agent’s deployment credentials and outside its namespace-administration scope. Reserve their CPU, memory, storage, and network capacity independently of the agent’s demand. A network-policy validator should not need a free inference GPU to reject an unauthorized request.
The following diagram is a logical placement proposal. The assurance zone is an administrative requirement, not a new VCF product object.
Escalate the placement when the threat changes. A verifier hosted under the same compromised vCenter administrator cannot establish independence from that administrator. A separate cluster or workload domain also needs an examination of shared NSX administration, identity roots, deployment pipelines, storage access, and backup credentials.
The choice between an NSX VPC and another workload domain should follow those requirements. More infrastructure is justified when it removes a relevant dependency, not because another box looks reassuring.
Keep Tenant Scope, Cluster Scope, and Agent Authority Distinct
Record the VCF organization or project, vSphere Namespace, VKS cluster, and Kubernetes namespace inside that cluster as separate identifiers where applicable. Do not collapse them into one free-text tenant label. The authorization service must validate the relationship between the authenticated caller and those objects.
Broadcom’s Virtual Private Cloud (VPC) networking explanation distinguishes enterprise, project, and VPC administration. That delegation supports self-service within defined bounds; it should not be interpreted as permission for an agent to administer the surrounding provider network.
At the Kubernetes layer, namespaces need accompanying access, network, workload, and resource controls. Kubernetes’ multi-tenancy guidance explicitly treats these as additional isolation concerns rather than properties created by the namespace name alone.
For the agent workload, prefer a dedicated service account with only the required permissions. Avoid mounting a Kubernetes application programming interface (API) token when the application does not need one. Keep privileged execution services out of any namespace the agent can freely populate or administer.
This last restriction has a concrete basis. Kubernetes’ role-based access control (RBAC) guidance warns that workload-creation permission can provide access to mountable secrets and the permissions of service accounts available to those workloads. “The agent cannot read Secrets directly” is therefore an incomplete credential-protection argument.
Use the Assurance Independence Model from Article 3 without assigning automatic scores. Shared model lineage remains a model dependency. Shared administrators remain an enforcement or evidence dependency. Tenant separation does not erase either.
Use NSX and vDefend to Constrain Paths, Not Interpret Approval
NSX networking and vDefend security controls can help restrict the paths between the agent, inference services, assurance components, and infrastructure management endpoints. They do not, by themselves, establish that a particular business request authorizes a particular mutation.
Start with a flow contract before writing rules. The following is a proposed minimum for this workflow, not a deployable NSX policy or a complete port list.
| Source and destination | Permitted purpose | Separate check required |
|---|---|---|
| Agent to model service | Use an approved inference route. | Consumer identity, model entitlement, and data-handling policy. |
| Agent to action controller | Submit a bounded proposal. | Initiating identity, tenant, operation, target, and approval binding. |
| Executor to NSX management API | Apply an approved network change. | Current authority, exact normalized mutation, and applicable preconditions. |
| Verifier to relevant read interfaces and probe endpoints | Establish configuration and observed behavior. | Observer identity, freshness, expected scope, and source integrity. |
| Authorized producers to evidence ingestion | Submit assigned event types. | Producer authentication and protected retention. |
The agent should have no direct administrative path to vCenter, NSX Manager, the execution worker, the policy repository, or evidence-store administration. Explicitly account for necessary name resolution, certificates, registries, and other platform dependencies. An incomplete allowlist is an outage plan, not a finished security design.
Verify the Actual Pod and VM Traffic Paths
Do not assume that a policy protecting a worker virtual machine (VM) proves isolation between every pod inside it. Broadcom describes vDefend 9.1 inspection of VKS workloads through Container Network Interface (CNI) integration. Validate the prerequisites and the installed enforcement path rather than extrapolating from the VM boundary.
Include pod-to-pod, pod-to-VM, ingress, egress, and any secondary or accelerated interfaces in the design. Test the applicable CNI and infrastructure controls on each path. Kubernetes also warns that NetworkPolicy objects require a network plugin that implements their enforcement.
Review effective policy, group membership, and exceptions. A rule named “agent isolation” proves nothing about another rule that permits the same traffic. Keep labels and group membership used by security controls outside the agent’s unrestricted write scope.
Keep the Management Adapter Narrow
Expose an operation such as “apply this approved connectivity change,” not an unrestricted NSX API proxy or a model-generated administrative script.
Constrain downstream credentials as closely as supported permissions allow. Where native permissions are coarser than the application’s action boundary, the adapter and its administrative isolation carry additional responsibility. Document that residual privilege instead of claiming NSX roles enforce every field in the business contract.
Compromise of the execution adapter is a separate scenario from compromise of the agent. It deserves its own limits, monitoring, and recovery plan.
Share Models Without Sharing Authority or Tenant State
Broadcom’s model-sharing capability allows consumers to use shared model infrastructure. It does not require the enterprise to merge application memory, retrieval collections, tool credentials, or approval records.
Keep consumer-to-tenant mapping outside model-generated text. Partition the application’s conversation state, retrieved evidence, caches, and output destinations according to its data policy. Test those boundaries using synthetic tenant-specific content and unauthorized identities.
Treat the shared runtime’s model release as a multi-consumer change. Identify every consuming application, including evaluators, and retain the deployed artifact and serving configuration in the behavior baseline. A generator and reviewer consuming the same model release remain exposed to a shared behavioral change even when their applications run separately.
Also keep model access and tool execution as different authorization decisions. A valid inference credential is not permission to modify a firewall. An application that can ask the shared model for advice must still pass through the independently governed action controller.
Distinguish Model Sharing from GPU Partitioning
Several applications calling one serving endpoint is different from several workloads receiving accelerator allocations.
NVIDIA’s GPU Operator documentation states that device-plugin time-slicing does not provide memory or fault isolation between replicas. It contrasts that with Multi-Instance GPU (MIG) hardware partitioning. Those mechanisms must not be presented as interchangeable tenancy guarantees.
This distinction does not establish which combinations are supported in a particular VCF installation. Confirm the exact graphics processing unit (GPU), assignment mode, host and guest drivers, Kubernetes integration, and supported software baseline. A quota or virtual GPU count is not a substitute for that analysis.
Reserve enough capacity for assurance to remain usable when inference is saturated. If an optional AI reviewer shares the constrained serving pool, define its timeout and hold behavior. Do not turn evaluator starvation into an authorization bypass.
Walk One NSX Connectivity Change Through the Design
Assume a custom controller is asked to permit one approved application group to reach a registered inference front end on Transmission Control Protocol (TCP) port 443. The port is part of this example’s service contract, not a universal Private AI Services requirement.
The request must not authorize broader source membership, other destinations, management access, or changes to the evidence path.
Establish Authority from Independent Records
The controller authenticates the initiator and resolves the approved source group, endpoint identity, tenant, and change window from governed records. It obtains current network configuration through a controlled reader rather than accepting the agent’s inventory summary.
The AI reviewer may flag missing dependencies or excessive scope. Its favorable verdict does not create the approval record.
Bind the accepted proposal to the exact objects, membership assumptions, service definition, and implementation version. If relevant membership or configuration changes before dispatch, reassess. Define how concurrent writers are coordinated; a locally cached inventory is not a concurrency control.
Apply, Observe, and Challenge the Result
After durable acceptance of the required action evidence, the executor applies the bounded change through the selected supported interface. Preserve the target operation result and identifiers the interface exposes.
The separately administered verifier then examines the resulting configuration and applicable realization status. It also runs controlled probes from approved and excluded test identities or workloads.
An allowed consumer should reach the intended service. An excluded consumer should remain blocked. The inference application must separately reject unauthorized application identities even when network reachability exists.
A probe timeout alone is not proof of firewall enforcement. Preserve the relevant configuration, endpoint health, and available enforcement observations so the reviewer can distinguish an intentional denial from a broken route or unavailable service. These tests demonstrate selected cases, not universal absence of bypasses.
Close Only the Claims That Were Verified
The evidence should connect the approved intent, actual mutation, current source membership, observations, and unresolved conditions. Keep the result open when required observations are unavailable or contradictory.
Where access is temporary, implement expiry as an explicit owned obligation unless the chosen mechanism provides and validates it. Do not invent a universal NSX rule-expiration feature. Removal and any containment of established sessions require their own tested behavior.
For recovery, restore or compensate for the specific approved change with current-state checks. Avoid replacing a whole policy collection with an old export that could remove legitimate concurrent changes.
Separate VCF Diagnostics from Action Evidence
Broadcom describes two-second metric streaming for VKS clusters through OpenTelemetry in VCF Operations 9.1.1. That improves infrastructure visibility; it is not a claim that every agent action produces complete, immutable evidence at that interval.
Maintain distinct records for infrastructure health, the agent transaction, authorization and execution, and independent outcome verification. Correlate them using trusted identifiers. Preserve mandatory action evidence independently of diagnostic sampling and dashboards.
The optional AI Assistant for VCF can assist diagnosis. Treat its explanation as analysis of available inputs, not the only source establishing why a change was authorized or whether it succeeded. Generated integrations also need review before receiving collection credentials or entering the control environment.
Identity updates deserve similar precision. Broadcom says VCF 9.1.1 can evaluate directory group membership at login. That does not establish continuous authorization or immediate invalidation of every existing session. Test suspension across the actual agent, executor, queues, and downstream sessions.
Protect evidence collection and storage under a different administrative scope from the actor. When platform-administrator compromise is in scope, place the required evidence custody outside that compromised authority as well. Simply exporting into another virtual machine does not settle the question.
Prove Degraded Operation and Recovery Before Release
Availability and trustworthy operation are separate acceptance criteria.
If vCenter or NSX management becomes unavailable, do not interpret surviving application traffic as permission to keep changing infrastructure. Hold actions whose required authority, current state, or completion cannot be established. Record accepted-but-unresolved work for reconciliation when the interface returns.
If shared inference fails, preserve the deterministic control services and the human operating path. A fallback model, when permitted, needs an approved data route and behavior baseline. It must not silently replace the reviewer or expand the action policy.
If evidence delivery fails before a consequential mutation, hold dispatch under this proposed operating mode. After dispatch, preserve uncertainty and reconcile rather than repeat the change merely to obtain a clean report.
Recovery must include the controller’s durable state, policies, approval records, model and tool baselines, application memory, evidence, and the credentials needed to restore them. Check GPU-backed workload recovery against the supported allocation and protection method. Do not assume that restarting a VM restores the complete AI service.
Use the management-component backup and fleet recovery runbook as the infrastructure companion. Restore agent execution disabled until current authority is re-established and queued work has been reassessed. A backup must not silently resurrect an expired approval or revoked execution identity.
Set Release Gates That Can Reject the Design
The following are proposed tests for an authorized, representative environment. They are not reported benchmark or product-validation results.
| Test | Evidence required before bounded production release |
|---|---|
| Compromised agent attempts direct management access. | Network and identity controls block relevant vCenter, NSX, executor-administration, and evidence-administration paths. |
| Agent attempts to rewrite approval inputs or deployment controls. | Effective permissions and challenge results show that the actor cannot create its own eligibility. |
| Request changes source scope, tenant, target, or tool implementation after approval. | The controller holds or rejects it before dispatch. |
| Shared inference is saturated or unavailable. | Authorization, evidence, and stop authority remain usable; required review failures do not become permits. |
| Tool reports success while required configuration or probes disagree. | Completion remains unresolved or violated, with an accountable investigation path. |
| Services recover with pending actions and revoked authority. | Restart does not automatically dispatch stale work or recreate revoked permissions. |
Include permitted actions and representative concurrent changes. A system that rejects everything has not demonstrated a useful operating model.
Assign owners to failures. The VCF team owns the platform baseline and supported placement. Network security owns effective network controls. The AI team owns model and application behavior. Identity owners govern delegation. Evidence custodians protect records, and the service owner accepts the remaining operating risk. A qualified reviewer must be able to hold release without depending on the agent’s assessment.
Begin with proposal-only operation, validate the controller and observer independently, then enable a small approved action scope. Expand that scope only after the evidence supports it.
Evaluate Future Integrations Against the Same Contract
Broadcom describes a future AI Gateway for model routing, usage controls, and application authorization, and a Secure Agent Framework covering sandboxing and an agent harness. Those are relevant directions, but the enterprise acceptance criteria should remain stable when the implementation changes.
Ask whether the delivered integration preserves initiating identity, binds approval to exact effects, prevents bypass through other tools, protects its own administration, exports sufficient evidence, and handles suspension and recovery correctly. Also ask who supports the integration and which dependencies become shared.
A sandbox restricts where code runs. It does not make every credential or destination available inside that sandbox appropriate. A harness controls parts of execution. Its deployment and policy must still be protected from the actor it governs.
Adopt a future component when its supported implementation improves the required boundary and survives the relevant tests. Do not remove a working external control merely because a product has acquired a similar feature name.
Conclusion
VCF 9.1.1 gives architects useful building blocks for private AI consumption, workload separation, networking, and operations. Independent agent assurance comes from how those components are configured, administered, observed, and recovered around a specific action.
Shared models can be an appropriate efficiency choice. Separately governed execution and evidence make that sharing compatible with bounded authority. The design should expose the dependencies that remain, particularly shared administrators, identity systems, serving infrastructure, and recovery automation.
The next installment, Independent Agent Assurance on Azure Local and Hybrid Cloud, applies the same requirements to a different control-plane and connectivity model rather than translating VMware product names one-for-one.
The control plane must not grade itself.
Before granting an agent its next VCF permission, demonstrate which independently owned mechanism will refuse the action, verify its effects, and remain available when the agent or its model cannot be trusted.
External References
- VMware Cloud Foundation Blog: Announcing General Availability of VMware Cloud Foundation 9.1.1
- VMware Cloud Foundation Blog: Explore 2026: VMware AI Factory and other new AI innovations in VCF
- VMware Cloud Foundation Blog: New AI and Kubernetes Private Cloud Operations Capabilities in VMware Cloud Foundation 9.1.1
- VMware Cloud Foundation Blog: From Bottleneck to Breakthrough: Centralizing GitOps at Enterprise Scale with VCF 9.1.1
- VMware Cloud Foundation Blog: Self-service networking with Virtual Private Clouds
- VMware Cloud Provider Blog: Monetizing Zero-Trust Security with VCF 9.1 and VMware vDefend
- Kubernetes: Multi-tenancy
- Kubernetes: Role Based Access Control Good Practices
- NVIDIA GPU Operator: Time-Slicing GPUs in Kubernetes
Design an AI agent authorization architecture that separates proposals, policy, execution, and evidence, including indirect paths that can bypass approval.
The post Independent Agent Assurance on VMware Cloud Foundation 9.1.1 appeared first on Digital Thought Disruption.