Symantec AgentMinder and VCF Private AI: How to Secure AI Agents Calling MCP Servers On-Prem

The Problem Nobody Is Talking About

Enterprise AI has an identity crisis — literally. Organizations are deploying AI agents that call MCP (Model Context Protocol) servers at machine speed, chaining tool calls across HR, finance, IT, and security systems in a single task. These agents authenticate with a bearer token, and from that point forward, the infrastructure treats every tool call the same way. There is no distinction between an agent looking up an employee record and an agent modifying payroll. There is no concept of "this agent is acting on behalf of Jane from HR for an onboarding workflow." There is no way to revoke all in-flight work for a specific agent without killing the entire service.

Your MCP servers are the new attack surface. And the traditional security stack — firewalls, EDR, network segmentation — cannot see what agents are doing at the application layer. A firewall sees an HTTPS POST. EDR sees a normal process making API calls. Neither understands that the agent just escalated from read-only employee lookup to writing payroll changes within the same session.

This is the gap that Symantec AgentMinder 4.1 fills. And when you combine it with VMware Cloud Foundation Private AI Services, you get something no single product delivers alone: a defense-in-depth security architecture for on-prem agentic AI that covers infrastructure, network, and identity — three layers, zero gaps.

What Is AgentMinder

AgentMinder is a full-lifecycle AI Agent Management and Security Solution from Symantec (Broadcom). It places a Layer7 AI Gateway between every AI agent and every MCP server, integrating with the Symantec Identity Security Platform (IDSP) so that each tool call is authenticated, resolved to a business intent, authorized by policy, scoped to a mission when required, and recorded as a signed audit receipt.

The backend MCP servers do not change. The agents do not need to understand policy. You configure the security model once in IDSP; the gateway and the Policy Decision Point (PDP) enforce it on every call.

AgentMinder organizes the problem into four pillars:

Access — Is this agent authorized to perform this intent, with what constraints? Handled by Auth Manager (PDP) using AuthZEN evaluation, intent-token minting, scoping constraints, and policy directives.

Gateway — How does a tool call become an authorized backend request? The Layer7 AI Gateway terminates the MCP protocol, validates credentials (JWT, DPoP, mTLS), resolves tool-to-intent mappings, calls the PDP, applies header-transform directives, forwards to the backend, and emits OpenTelemetry spans and audit events.

Lifecycle — How are agent identities and missions managed over time? Agent and resource-server applications, intent and mission catalogs, the authorization-surface matrix, mission CRUD, delegated-identity tracking, and a golden-config pipeline that keeps every gateway instance in sync.

Observability — What are agents doing, is it normal, and can you prove it to auditors? OpenTelemetry traces, metrics, and logs flow through NATS JetStream to pre-built dashboards covering agent inventory, mission activity, privileged-action monitoring, and rogue-action detection.

Intent-Based Authorization: Why It Changes Everything

Traditional API security authorizes by URL or method — can this client call POST /api/employees? AgentMinder authorizes by intent — is this agent permitted to perform employee_lookup? The distinction is fundamental.

An intent is a business-level action expressed as a URN scope (e.g., urn:iam:agent:intent:employee_lookup). You define intents from business actions, not API endpoints. You bind tools to intents. Policies grant or deny intents. The gateway resolves each tool call to its intent before the PDP ever evaluates the request.

This means a single policy rule can govern multiple tools that serve the same business purpose, and a change in the underlying API does not require a policy change. More importantly, it means the security team thinks in business terms — "can this agent look up employees" — not in API terms — "can this client call GET /api/v2/employees/:id."

Intent design follows a deliberate granularity: too broad (manage_employees) prevents per-action constraints; too narrow (get_employee_by_id, search_employees_by_name) bloats policy. The right level is the authorization boundary — same grant decision and same constraints means same intent.

Two Security Paths and Three Credential Tiers

Every agent that AgentMinder protects follows one of two security paths, with three progressively stronger credential tiers:

Autonomous (Policy-Only) — The agent presents an access token only. Every tool call goes to the PDP for intent-based authorization. There is no mission boundary; revocation means disabling the agent application. This suits single-purpose autonomous agents: compliance scanners, monitoring bots, scheduled data pipelines.

Delegated (Mission Token) — The agent presents an access token plus a signed JWT in X-Mission-Token. The mission credential carries allowedIntents (baked in at creation), delegatedBy (the user on whose behalf the agent acts), missionId, and a TTL. The gateway performs a fast local pre-check — is this intent in the mission's allowed set? — before ever calling the PDP. This enables per-process scoping, delegation tracking, and mission-level revocation (revoke the mission and the next liveness check fails all in-flight calls).

Delegated (Mission Certificate) — Everything the mission token provides, plus channel binding. The mission credential is an X.509 certificate presented over mutual TLS (mTLS), validated at the TLS layer. It cannot be replayed from another connection. This is the strongest tier — a stolen access token is useless without the DPoP private key, and a stolen mission certificate is useless without the TLS private key.

The progression is designed for incremental hardening. Start with Autonomous to get intent-based authorization and audit. Add missions when you need per-user delegation or per-process scoping. Add mTLS when you need channel-bound non-repudiation.

The Gateway Pipeline: What Happens on Every Tool Call

When an agent makes a tools/call request, the AI Gateway walks a deterministic nine-step pipeline:

Step 1 — Resolve agent identity from the access token. Validate the JWT against cached JWKS (or call introspection). Validate DPoP proof if configured. Read the agent's client_id.

Step 2 — Resolve the tool binding from the local cache. Look up the tool name in the binding index loaded at startup. If the tool is not bound and protectedByDefault = true, deny immediately — the PDP never runs. If found, extract the intent scope, skill, and resource-server application.

Step 3 — Resolve the agent profile. Read cached agent-app properties: identity mode, mission requirement, max delegation depth, risk level.

Step 4 — Check mission requirement. If requireMissionContext = true and no mission credential is present, deny.

Step 5 — Validate the mission credential. JWT signature, expiration, subject match (prevents cross-agent token reuse), extract missionId, missionType, delegatedBy, allowedIntents.

Step 6 — Mission-scope pre-check. Is this intent in the mission's allowedIntents? No? Deny immediately — fast local check, no network call.

Step 7 — Call the PDP (AuthZEN evaluation). The PDP evaluates the full policy, checks mission liveness, applies constraints, and returns permit or deny with scoping constraints and policy directives.

Step 8 — Apply directives. Header transforms, field exclusions, record limits — whatever the policy dictates.

Step 9 — Forward to the backend MCP server with the X-Intent-Token (a signed audit receipt). Emit OpenTelemetry spans and audit events.

Every step is logged. Every decision is auditable. The entire pipeline runs on every single tool call.

How AgentMinder and VCF Private AI Services Create Defense-in-Depth

Here is where the architecture becomes compelling. VCF Private AI Services and AgentMinder operate at different layers of the stack, and together they eliminate the gaps that either one alone would leave open.

Layer 1 — Infrastructure and MCP Governance: VCF Private AI Services

VCF PAI provides both the compute foundation and the governance framework for running agentic AI on-prem. On the infrastructure side, DirectPath I/O passes NVIDIA Blackwell and AMD MI350 GPUs directly to inference VMs with bare-metal performance. vSphere lifecycle management handles patching, HA, and DRS for AI workloads the same way it handles any other VM. The AI Metrics Dashboard provides centralized observability across the entire GPU fleet.

But VCF PAI is not just compute — it is also the MCP governance layer. Private AI Services includes native Model Context Protocol support that provides a standardized method to integrate AI agents with internal content repositories and external enterprise tools — Oracle, Microsoft SQL Server, ServiceNow, GitHub, Slack, PostgreSQL — without building custom connectors for each one. This is significant because it means the integration surface between AI agents and enterprise systems is standardized, not bespoke. Administrators retain full governance control, specifying exactly which tools each agent can access. End-to-end authentication ensures that every connection between an agent and a tool is verified, creating secure, compliant, and scalable workflows out of the box.

This MCP governance capability turns VCF PAI from a pure infrastructure platform into an AI integration platform. Developers can build context-aware applications and task automation using real-time, permissioned data from across the enterprise — without waiting for the integration team to build custom API connectors for every backend system.

This layer answers: Where do the AI workloads run, how do you operate them, and which tools can agents reach?

Layer 2 — Network: vDefend IDS/IPS

vDefend's microsegmentation and virtual patching protect the network traffic flowing between agents, MCP servers, inference endpoints, and backend enterprise systems. IDPS Turbo Mode delivers 9 Gbps per host of inspected throughput. Distributed IDS/IPS rules can be applied at the vNIC level — meaning every inference VM, every MCP server pod, and every agent process gets its own firewall policy without hairpinning traffic through a centralized appliance.

This layer answers: What network traffic is allowed between AI components, and what gets blocked?

Layer 3 — Identity and Authorization: AgentMinder

AgentMinder governs what happens inside the allowed network flows. Even if vDefend permits traffic from an agent VM to an MCP server, AgentMinder controls which tools that agent can call, on whose behalf, within what business process, and for how long. The AI Gateway terminates MCP protocol sessions, resolves tool calls to business intents, enforces mission-scoped credentials, and produces a signed audit trail.

This layer answers: What is this agent doing, on whose behalf, and is it authorized?

The gap each fills for the other:

Without AgentMinder, VCF PAI secures the infrastructure, governs MCP tool access, and protects the network — but it does not know what the agent is trying to accomplish. An agent with a valid MCP connection and tool access can call any authorized tool for any purpose, chain calls across systems without mission boundaries, and operate without intent-level audit trails.

Without VCF PAI, AgentMinder secures the agent-to-MCP-server interaction but has no control over the infrastructure those servers run on — GPU allocation, VM lifecycle, network segmentation, and hypervisor-level security are outside its scope.

Together, they close every gap. VCF PAI ensures the AI infrastructure is isolated, patched, and observable at the hypervisor level — and provides MCP governance that standardizes tool connectivity and controls which agents can reach which enterprise systems. vDefend ensures only authorized network flows reach the MCP servers. AgentMinder ensures only authorized agents make only authorized tool calls for authorized purposes within those allowed flows. Infrastructure, connectivity, network, identity — four layers, one architecture.

Deployment Architecture: AgentMinder on VCF

AgentMinder's architecture maps naturally onto VCF infrastructure. The control plane (IDSP Admin Service, OAuth/OIDC service, PDP, Admin Console) runs as a Kubernetes workload — on vSphere Supervisor, the same Kubernetes layer that powers VCF Private AI Services. The data plane (AI Gateway instances) can be deployed in two models:

Embedded — The AI Gateway runs inside the AgentMinder cluster as a managed service. This suits development, proof of concept, and environments where agent traffic already routes through a central ingress. No additional components to deploy.

Edge (Standalone) — The AI Gateway runs in a separate cluster, at the network edge, in a DMZ, or co-located with the MCP server workloads. Each instance registers with the control plane and polls for its golden config. This suits production deployments where the data plane must sit in a different network zone — which is exactly how most VCF environments are architected, with management and workload domains separated.

In a VCF deployment, the natural topology is: AgentMinder control plane in the management domain, AI Gateway instances in the workload domain alongside the MCP servers and inference VMs, and vDefend enforcing network policy between all of them.

MCP Protocol Handling: Two Layers of Governance

Understanding how MCP governance works in this architecture requires distinguishing between two complementary layers — and this is where the VCF PAI and AgentMinder combination becomes more than the sum of its parts.

VCF PAI MCP: The Integration and Access Governance Layer

VCF Private AI Services provides the foundational MCP governance layer. It standardizes how AI agents connect to enterprise tools and data sources — Oracle databases, ServiceNow workflows, GitHub repositories, Slack channels, PostgreSQL instances, Microsoft SQL Server — through a single protocol rather than one-off custom integrations. Administrators define which tools are available and which agents can reach them. Authentication is end-to-end. The result is that standing up a new AI-to-tool connection is a configuration task, not a development project.

This is the layer that answers: Can this agent reach this tool at all?

AgentMinder: The Identity, Intent, and Mission Layer

AgentMinder's AI Gateway sits on top of that foundation and adds the questions VCF PAI's MCP governance does not ask: What is this agent trying to do with that tool? On whose behalf? Within what business process? And should we allow it given the current policy, mission scope, and risk level?

The AI Gateway is not a generic API proxy — it is MCP-native. It terminates the Model Context Protocol directly, handling session management, protocol-version negotiation, and hub aggregation across multiple backend MCP servers.

Hub aggregation is particularly relevant for VCF environments. A single AI Gateway can aggregate multiple backend MCP servers — perhaps one for HR tools, one for finance tools, and one for AI inference services — into a unified namespace. The agent sees one MCP endpoint. The gateway routes each tool call to the correct backend based on the tool binding, applying per-backend authentication and authorization. Tool names from different backends are separated by a __ namespace separator, preventing collisions.

The two layers compose, they do not compete. VCF PAI's MCP governance controls tool availability and connectivity — which agents can reach which MCP servers, which tools are exposed, and how authentication works. AgentMinder controls tool authorization and intent — which agents can call which tools, for what business purpose, on whose behalf, and within what mission scope. Together, they provide a complete governance stack: VCF PAI ensures the agent can only reach the tools it is supposed to reach, and AgentMinder ensures the agent can only do what it is authorized to do with those tools.

Observability: Proving What Agents Did

AgentMinder's observability stack is built on OpenTelemetry with NATS JetStream for durable audit event storage. Every tool call produces a structured audit event carrying correlation keys (clientTxnId, agentClientId, missionId, intentScope) that span the entire lifecycle — from configuration change to runtime decision to audit record.

Pre-built dashboards cover four operational views: Agentic Activity Summary (what agents are doing right now), Executive AI Summary (aggregate metrics for leadership), Privileged Action Monitoring (high-risk intents), and Rogue Action Detection (anomalous agent behavior).

The signed intent token — a JWT emitted by the PDP on every authorized call — serves as a cryptographic audit receipt. It records who (agent), what (intent), on behalf of whom (delegated user), within what process (mission), and with what constraints. Backends can validate these tokens independently, creating an end-to-end non-repudiation chain.

For VCF environments, this observability integrates with the AI Metrics Dashboard that VCF PAI already provides. Infrastructure metrics (GPU utilization, inference throughput) from VCF PAI, network security events from vDefend, and agent authorization decisions from AgentMinder can feed into a unified SIEM — giving the SOC team a single pane of glass across all three security layers.

The Standards Behind It

AgentMinder is not a proprietary black box. It is built on an unusually deep stack of open standards:

Identity and federation: OpenID Connect and SAML upstream; RFC 8693 for token exchange and delegated-identity chains across agent-to-agent hops; RFC 9449 for DPoP token binding; RFC 9728 for protected-resource metadata discovery.

Authorization: OpenID AuthZEN as the PDP wire protocol, with Open Policy Agent (OPA) and Cedar as alternative policy backends. Organizations already running OPA can point the gateway at their existing PDP.

Observability: OpenTelemetry GenAI and MCP semantic conventions for traces, metrics, and logs.

MCP native: Streamable HTTP, session management, and hub aggregation with namespace separation.

This standards alignment matters for enterprise procurement because it means AgentMinder integrates with your existing IAM stack — Okta, Microsoft Entra, Ping — rather than replacing it. It federates human identity from your existing IdP and governs the agent identity domain alongside it.

What AgentMinder Does Not Do

Understanding the boundaries is as important as understanding the capabilities:

AgentMinder does not replace your IdP, your PDP (if you already run OPA or Cedar), your SIEM, or your SOAR. It integrates with all of them. It does not secure the model weights themselves — that is a model-layer concern addressed by using commercially-licensed models from vendors with security guarantees (see: Enterprise Buyer's Guide to On-Prem LLMs). It does not protect against model-layer attacks like backdoored weights or steganographic payloads — those threats operate below the agent layer (see: The Hidden Risks of Open-Source LLMs).

What AgentMinder does is govern the space between the agent and the enterprise — the tool calls, the delegated identity, the mission scope, and the audit trail. That is the gap that no other product in the enterprise security stack currently fills.

The Strategic View: Why This Matters for VCF Customers

VCF customers are already running AI workloads on-prem. VCF Private AI Services gives them the infrastructure. vDefend gives them network security. But as agentic AI moves from "run a model and get a response" to "deploy agents that autonomously call enterprise tools," the identity and authorization layer becomes the critical missing piece.

Consider the trajectory: today, an AI agent might look up an employee record. Tomorrow, it chains tool calls across HR, finance, and IT systems to execute a full onboarding workflow — creating accounts, assigning training, provisioning equipment, updating payroll. The infrastructure and network layers do not distinguish between these use cases. They see the same HTTPS traffic, the same process behavior, the same network flows.

AgentMinder makes that distinction. It knows the agent is running an onboard_new_hire mission on behalf of Jane Smith. It knows which intents are allowed within that mission. It can revoke the mission mid-flight if something goes wrong. And it produces a cryptographic audit trail proving exactly what happened.

For VCF environments, the architecture composes cleanly: VCF Private AI Services for GPU infrastructure and AI lifecycle management, vDefend for network microsegmentation and virtual patching, and AgentMinder for agent identity, intent-based authorization, and mission governance. Three layers, three vendors (VMware and Symantec, both Broadcom), one integrated security architecture for on-prem agentic AI.

For a detailed technical deep-dive into VCF Private AI Services architecture, GPU support, and MCP governance capabilities, see: VCF 9.1 Private AI Services: How to Run Enterprise AI On-Prem.

---

References:

• Symantec AgentMinder 4.1 Documentation — Broadcom↗
• VCF 9.1 Private AI Services — barhum.ai
• Enterprise Buyer's Guide to On-Prem LLMs — barhum.ai
• The Hidden Risks of Open-Source LLMs — barhum.ai
• OpenID AuthZEN Specification↗
• RFC 8693 — OAuth 2.0 Token Exchange↗
• RFC 9449 — DPoP (Demonstrating Proof of Possession)↗
• Model Context Protocol Specification↗