File this under marketing semantics.
Cloud services should not be considered “agentless” when they involve the deployment of instances or agents that manage, monitor, or perform tasks inside the cloud infrastructure.
The term “agentless” in the context of cloud computing is used to refer to the deployment and management of services without installing additional software to run locally on each target system or virtual machine, operating remotely instead through APIs and network protocols. However, they are still agents in a distributed architecture of compute, and they are still on the “inside” of a notable data boundary.
Despite using a different term, the cloud instances serve functions similar to agents by executing tasks within the compute environment. While similar, the main distinction lies in the fact that instances are generally more centralized and standardized within the cloud framework. This is far more about performance and cost reasons (one large agent with remote capabilities doing the work of many agents) than any safety or security ones.
Many years ago I worked on a version of this at VMware, where we engineered anti-virus out of every individual virtual machine (reducing redundant waste) and to a single shared instance/agent with remote access to all the machines. The same safety issues remained before and after the transition from many dedicated agents to a centrally shared one.
This is like saying an NSA project migrated to one agent who setup a tap on the whole neighborhood backbone for all the house phone calls, because it allowed them to stop hiring many agents who setup a tap on every house listening to phone calls. One agent instead of many agents, even one agent deployed into a central office miles away, still is not agentless. Much efficiency is achieved, but cloud users must beware and not assume inherent security.
An agent that walks and talks like an agent… is an agent.
Let me give a quick example of the kind of semantic games I hear. Some call cloud a “dynamic” environment where “resources spin up rapidly” and they point out “ephemeral workloads”.
All of this is relative, and all of it is meaningless to the foundational principles of an agent. Agents, like anything else, can spin up quickly with dynamic settings and disappear quickly. In fact, those attributes are practically the definition of a good agent.
Ok, ok, I’ll admit reading logs, scanning networks and doing analysis of storage can reduce load to a single big agent, which is smaller and easier to query than a sum of many deployed ones. Maintenance and management cost is lowered. Again, much efficiency is achieved, but cloud users must beware and not assume inherent security.
Who can forget the NSA agent who basically lived inside the San Francisco phone exchange? It seems wrong to say all those houses in San Francisco were truly agentless, given an agent remotely listening to all the kitchen phone lines instead of sitting in any one kitchen eating all the toast. It’s a physical, an architectural, distinction that obscures an agent is still present.
An agent that walks and talks like an agent… still an agent.
Perhaps it helps to point out that the people often pitching agentless architecture either are trying to explain efficiencies, or they’re trying to hide the fact they still run an agent under a different name. If all you care about is performance and cost, the former is fine and you’re relocating the agent. More toast for you and yours. However, if you care about safety and security, watch out for the latter. You might be the toast.
