Running an AI model is one thing.
Running an AI agent that can actually perform actions inside an enterprise environment is a very different architecture problem.
A traditional model interaction is roughly:
An agent can go much further:
For me, the important word is execute.
Once an AI system can call APIs and change something, this is no longer only a model-hosting problem. It becomes a security, infrastructure and operational architecture problem.
Think of an Agent as a Workload with Authority
Imagine an infrastructure operations agent.
It might read monitoring data, inspect logs, search documentation and recommend a remediation.
So far, the blast radius is limited.
But then somebody asks:
"Why can't it just fix the problem automatically?"
That question changes the architecture.
A knowledge agent that reads documents and an operations agent that can restart workloads may use the same LLM, but they have completely different risk profiles.
Four Boundaries I Would Define
| Boundary | Architecture Question |
|---|---|
| Model | Which model can process this information? |
| Data | What information can the agent retrieve? |
| Tools | Which APIs and tools can it invoke? |
| Action | What can it actually change? |
I would deliberately keep these boundaries separate.
An agent might be allowed to read configuration without changing it. It might recommend a restart without having permission to perform one.
That separation becomes important as autonomy increases.
Design the Blast Radius
With conventional automation, such as PowerCLI, Terraform or Ansible, much of the execution path is defined in code.
An AI agent can dynamically select tools and decide between permitted actions.
That means a bad assumption can potentially propagate:
This is why I would explicitly define the maximum blast radius of an agent rather than simply asking whether it is "secure".
Don't Jump Straight to Autonomy
I prefer to introduce authority gradually.
Level 5 should not automatically be the goal.
For many infrastructure operations, Level 2, 3 or 4 may provide most of the value with substantially less risk.
Autonomy is not automatically maturity.
Where MCP Fits
Model Context Protocol, or MCP, makes tool integration much easier for AI applications.
VMware Private AI Services supports MCP servers and provides Agent Builder, allowing agents to use models together with knowledge bases and MCP tools.
From an architecture perspective, I would therefore treat the MCP layer much like an API security boundary.
I want to know:
- Which agent can use the tool?
- What identity is used?
- What can the tool read or modify?
- Can the action be audited?
- Can access be revoked quickly?
AI may introduce a new interaction model, but these are familiar security questions.
Use Infrastructure Boundaries Too
Identity shouldn't be the only protection.
If an agent only needs a model endpoint, knowledge service, approved tools and telemetry, I would not give the workload unrestricted network reachability.
↓
Model Knowledge MCP Telemetry
Everything else: deny unless required
This is where familiar private-cloud design principles such as segmentation, least privilege and controlled connectivity remain very relevant.
Separate Reasoning from Privileged Execution
For agents performing sensitive operations, I would also consider separating the agent from the component performing the actual change.
The agent doesn't necessarily need an administrative credential to the infrastructure.
Instead, it requests a predefined operation from a controlled execution service.
This is not really a new idea. We have used similar patterns in infrastructure automation for years. I would carry the same principle into agentic AI.
Human Approval Is Not a Weak Architecture
For consequential actions, having a person in the loop can be a deliberate architecture decision.
Evidence: Health checks failing for 8 minutes
Proposed action: Restart instance app-03
Impact: One instance in a six-instance cluster
[ APPROVE ] [ REJECT ]
The agent performs the investigation while the platform retains control over the consequential action.
For many enterprise use cases, I think this is a more practical starting point than unrestricted autonomy.
My Production Checklist
Before giving an agent production authority, I would want clear answers to these questions:
- What exactly is the agent responsible for?
- Which data can it access?
- Which systems can it reach?
- Which tools can it invoke?
- Which actions modify state?
- Which identity executes those actions?
- Which actions require approval?
- What is the maximum blast radius?
- Can we reconstruct what the agent did?
- Can we immediately stop its ability to act?
Final Thoughts
I have spent a good part of my career working around virtualization, infrastructure, networking and automation.
One lesson keeps coming back:
The more powerful automation becomes, the more important its boundaries become.
AI agents are no different.
The interesting problem is no longer whether an LLM can call an API. That is becoming relatively easy.
The architecture challenge is deciding which API, using which identity, against which resource, under which conditions, with what blast radius, and with enough evidence afterwards to understand exactly what happened.
VMware Cloud Foundation and Private AI Services provide building blocks for running these workloads. But I would still apply the infrastructure principles that have served us well for years: least privilege, segmentation, controlled automation, observability and clearly defined failure boundaries.
The technology is new.
The need for good architecture isn't.