The path most people miss
When teams think about AI agents and the cloud, they usually think about agents that run in the cloud. The more common path today starts on a laptop. A developer's machine holds credentials for cloud accounts, configuration for Kubernetes clusters and a container runtime. A coding agent started in that developer's terminal can use all of them. It does not need to be compromised to cause harm: a misread instruction, or an instruction hidden in a file or a web page it read, is enough.
What one step can do
The cloud command line tools are built to change infrastructure quickly. A single command can delete a storage bucket, open a security group, scale a deployment to zero or apply a manifest to the wrong cluster. A container command can mount the host file system. These are normal commands that developers run every day, which is why simple allow lists struggle: the same command is right in one context and wrong in another.
Controlling the path on the device
Because the command runs on the laptop, the control has to see it there, before it runs, with context. Bay lists cloud CLIs, containers and Kubernetes among the capabilities its rules govern, alongside shell execution, package installation and browser automation, and describes Allow, Ask or Deny decisions that use identity, prior actions and data accessed. For a command that changes infrastructure, an Ask verdict fits well: the developer who started the agent usually knows whether the change was intended.
Other products in our ranking describe controls on shell commands, tool calls or MCP traffic in general terms without naming cloud CLIs. That does not mean they cannot govern them; ask each vendor to demonstrate a cloud CLI command from your developers' main agent.
When the agent itself runs in the cloud
The second path is an agent that runs in a cloud workspace or as a cloud-hosted service. Here there may be no company laptop involved, and device controls do not apply. Vendors that document this path include Onyx Security, which lists cloud workloads among the surfaces it covers; Zenity, which covers cloud and homegrown agents and lists integrations with AWS Bedrock, Azure AI Foundry and Google Vertex AI; and Noma Security, which covers endpoint, SaaS and homegrown agents and describes AI-SPM across cloud, SaaS and developer environments. Palo Alto Networks describes agent discovery across cloud, SaaS and endpoints in Prisma AIRS 3.0, and says it is integrating Koi with Prisma AIRS.
Bay's public pages describe security for AI agents on enterprise endpoints. They do not describe coverage for agents running in cloud workspaces or cloud-hosted apps, which is why Bay scores 3 on our cloud and workspace reach criterion, against 9 for Onyx Security.
A checklist for the laptop path
- Which cloud credentials sit on developer devices, and for which accounts?
- Which agents can run cloud CLI or kubectl commands with them?
- Which of those commands should need a person's confirmation?
- Is every such command recorded with who started the agent session and whether a person approved it?
- Can the agent change its own permission settings to get around a rule?
A checklist for the cloud path
- Which agents run in cloud workspaces or as cloud services today?
- Does your agent control product cover them, or does a separate product?
- Do both products write to the same actor trail, so an investigation sees one sequence of events?
Where this leaves a buyer
Most estates have both paths. Our ranking weights the device path more heavily because that is where most agent activity we can document starts, and it scores cloud reach separately so you can see the difference. If your agents already live mostly in the cloud, raise that weight in the estimator.