AI agents are crossing the chasm from developer laptops to enterprise infrastructure. When that happens, security boundaries, multi-tenancy, and compliance become non-negotiable. VMware Tanzu Platform is deploying agents alongside traditional applications in production environments, and the plumbing looks different from what you build in a prototype.
Nick Kuhn from VMware Tanzu Platform walked through what changes when agents run in enterprise environments: agent build packs, MCP gateways, shared memory coordination, identity management, and sandboxing primitives. This is platform engineering applied to agent workloads.
Agent Build Packs vs. Container Build Packs
Traditional container build packs package application code, dependencies, and runtime into a deployable artifact. Agent build packs extend this pattern but add new layers:
- Tool manifests: Declarative specifications of which MCP tools the agent can access
- Credential templates: Pre-configured identity bindings for service accounts and user delegation
- Memory configuration: Shared memory segments for multi-agent coordination
- Execution policies: Rate limits, timeout boundaries, and retry behavior
The build pack outputs a container image, but the orchestration layer treats it differently. Traditional apps respond to HTTP requests. Agents initiate actions, call tools, and maintain state across multiple turns. The platform needs to know which tools an agent can invoke before it starts running.
MCP Gateway Architecture in Multi-Tenant Environments
In a local prototype, your agent talks directly to MCP servers. In production, a gateway sits between agents and tools. The gateway enforces:
- Tenant isolation: Agent A in tenant X cannot invoke tools provisioned for tenant Y
- Tool versioning: Multiple versions of the same tool can coexist, with agents pinned to specific versions
- Audit logging: Every tool invocation is logged with agent identity, tenant context, and parameters
- Rate limiting: Per-tenant quotas prevent runaway agents from exhausting shared resources
The gateway maintains a registry of available tools and their access policies. When an agent requests a tool, the gateway checks:
- Does this agent's identity have permission to invoke this tool?
- Is the tenant within quota for this tool category?
- Does the tool version match the agent's declared dependencies?
If all checks pass, the gateway proxies the request to the MCP server and returns the result. If any check fails, the agent receives an authorization error.
Identity and Credential Management
Agents often need to act on behalf of users. A customer service agent might need to query a CRM system using the support rep's credentials. A deployment agent might need to push code using the developer's GitHub token.
Enterprise platforms solve this with delegation chains:
- User identity: The human who initiated the agent workflow
- Agent identity: The service account under which the agent process runs
- Tool identity: The credentials used to authenticate to downstream systems
The platform manages credential vaulting and rotation. Agents never see raw credentials. Instead, they receive short-lived tokens scoped to specific operations. When an agent invokes a tool, the gateway exchanges the agent's token for a tool-specific credential, performs the operation, and discards the credential.
This prevents credential leakage. If an agent is compromised, the attacker gets a token valid for minutes, not the underlying service account password.
Sandboxing Primitives for Agent Execution
Traditional application sandboxing relies on:
- Network policies: Restrict which services an app can reach
- Filesystem isolation: Mount only necessary volumes
- Resource limits: CPU, memory, and I/O quotas
Agents need additional constraints:
- Tool call limits: Maximum number of tool invocations per execution
- Execution timeouts: Hard stop after N seconds to prevent infinite loops
- State size limits: Cap the size of agent memory to prevent unbounded growth
- Egress filtering: Block direct internet access, force all external calls through the MCP gateway
The platform enforces these limits at the orchestration layer. If an agent exceeds its tool call budget, the orchestrator terminates the process and returns an error to the caller. If an agent tries to open a direct network connection, the network policy blocks it.
Shared Memory for Multi-Agent Coordination
Some workflows require multiple agents to coordinate. A planning agent might decompose a task, then hand subtasks to execution agents. Those agents need to share state without breaking tenant isolation.
Tanzu uses shared memory segments with access control:
- Segment creation: The orchestrator provisions a memory segment when a workflow starts
- Access grants: Only agents in the same workflow can read/write the segment
- Lifecycle management: The segment is destroyed when the workflow completes
- Size limits: Each segment has a maximum size to prevent memory exhaustion
Agents write state updates to the shared segment using a key-value API. The orchestrator mediates access to prevent race conditions. If two agents try to write the same key simultaneously, the orchestrator serializes the writes and returns the final value to both agents.
This is simpler than running a distributed database, but it only works for workflows that fit in memory. For long-running workflows with large state, the platform falls back to a persistent store with the same access control model.
Deployment Shape and Failure Modes
A typical agent deployment in Tanzu looks like this:
apiVersion: agents.tanzu.vmware.com/v1
kind: AgentDeployment
metadata:
name: customer-support-agent
namespace: tenant-acme
spec:
image: registry.example.com/agents/support:v2.3
replicas: 3
tools:
- name: crm-query
version: "1.2"
maxCallsPerExecution: 50
- name: email-send
version: "2.0"
maxCallsPerExecution: 10
identity:
serviceAccount: support-agent-sa
userDelegation: true
limits:
executionTimeout: 300s
memoryMB: 512
toolCallBudget: 100
sharedMemory:
enabled: true
maxSizeMB: 64
The orchestrator schedules agent pods across the cluster. Each pod runs the agent process, connects to the MCP gateway, and waits for work. When a workflow arrives, the orchestrator assigns it to an available pod, provisions shared memory if needed, and monitors execution.
Common failure modes:
| Failure | Detection | Recovery |
|---|---|---|
| Tool call budget exceeded | Orchestrator tracks calls per execution | Terminate agent, return error to caller |
| Execution timeout | Orchestrator enforces hard deadline | Kill process, log timeout event |
| MCP gateway unavailable | Agent receives connection error | Retry with exponential backoff, fail after N attempts |
| Shared memory full | Write operation returns error | Agent must handle gracefully or fail |
| Credential refresh failure | Gateway cannot obtain fresh token | Pause execution, alert ops team |
The platform exposes metrics for all of these. Operators can set alerts on timeout rates, tool call budget violations, and credential refresh failures.
Observability and Debugging
Traditional apps log to stdout. Agents generate structured events:
- Tool invocations: Tool name, parameters, result, latency
- State transitions: Agent moved from planning to execution
- Errors: Tool call failed, credential expired, memory limit hit
The platform collects these events and indexes them by workflow ID, agent ID, and tenant. Operators can trace a workflow from start to finish, see every tool call, and identify where it failed.
For debugging, the platform supports replay. Capture the input to a failed workflow, replay it in a sandbox environment, and step through tool calls one at a time. This is harder than debugging a traditional app because agents are non-deterministic, but capturing tool call results makes it feasible.
What Enterprises Can Reuse from Traditional Platform Engineering
Most of the platform engineering playbook applies:
- Immutable deployments: Build once, deploy many times
- Blue-green rollouts: Run old and new versions side by side, shift traffic gradually
- Health checks: Agents expose readiness and liveness endpoints
- Autoscaling: Scale agent pods based on queue depth or CPU utilization
- Secrets management: Vault integration for credential storage
The new pieces are tool registries, MCP gateways, and execution policies. Everything else is standard Kubernetes orchestration.
Technical Verdict
Use VMware Tanzu or a similar enterprise platform when:
- You need to deploy agents in a multi-tenant environment with strict isolation
- Compliance requires audit logs for every tool invocation
- Agents must act on behalf of users with delegated credentials
- You have existing Kubernetes infrastructure and want to run agents alongside traditional apps
Avoid this approach when:
- You are prototyping and need fast iteration without platform overhead
- Your agents run in a single-tenant environment with no isolation requirements
- You do not have platform engineering expertise to operate the infrastructure
- Your workloads are simple enough that serverless functions suffice
The Tanzu approach makes sense when agents are business-critical and need the same reliability, security, and observability as your other production systems. If you are still experimenting, start simpler and graduate to a platform when the requirements justify the complexity.
Top comments (0)