AI Agent Security vs Cloud Security
Cloud security – CSPM, CWPP, CIEM and the CNAPP platforms that bundle them – secures the environment an AI agent runs in: the workload, the network path, the entitlements attached to its identity. Agent security addresses the agent itself: how it is configured, which tools it can reach, what it decided to do, and whether that matched intent. A correctly postured cloud environment can run a catastrophically configured agent without a single finding being raised.
What does cloud security actually cover for AI agents?
More than the framing of this page might suggest, and it is worth being precise about it rather than dismissive. Cloud security posture management reads the cloud control plane and tells you when something is configured against policy: an overly permissive role attached to an agent runtime, a storage bucket an agent can reach that should never have been public, a managed agent service deployed outside an approved region.
Cloud workload protection adds the runtime layer – the container or function the agent executes in, the processes inside it, the network connections it opens. Cloud infrastructure entitlement management is the strongest of the three for this problem, because it reasons about effective permissions rather than declared ones, and effective permissions are genuinely half of agent risk.
For an agent deployed through a managed service on AWS, Azure or Google Cloud, that stack covers the infrastructure thoroughly. It will tell you the agent’s execution role has write access to a production database. It is a real control, deployed, funded and staffed, and nothing in what follows argues for ripping it out.
What can’t cloud security see about an AI agent?
The limits are architectural rather than a matter of product maturity, and they come down to a single assumption that cloud security is built on and agents break.
That assumption is that a workload’s behavior is a property of its configuration. Secure the configuration and you have secured the behavior, because a conventional workload executes the same code path on the same inputs every time it runs. An agent’s configuration constrains what it is capable of doing, but it does not determine what it does. Two executions of the same unchanged, fully compliant workload will take different actions, because the reasoning step between the input and the action is not deterministic. This is the structural reason why a clean posture report and an agent acting badly are entirely compatible states, and it is not something a better rule set resolves.
Four specific blind spots follow from it.
The agent’s own configuration. An agent’s system prompt, its tool definitions, its memory and context settings, and the harness it runs inside are application-layer content. To a cloud security platform, a strictly sandboxed agent and one instructed to act autonomously on production data are the same container image on the same compliant runtime. The thing that distinguishes them is not visible at the infrastructure layer.
Which tools the agent can reach. Agents acquire capability through MCP servers, skills, plugins, browser extensions and SaaS connectors, most of which are declared in the agent’s configuration rather than provisioned through the cloud control plane. A cloud platform sees the network egress a tool call produces, if it produces any. It does not see a standing skill definition granting a capability that no traffic has yet exercised, and it has no view of the tool supply chain that capability came from.
What the agent did, and why. Cloud telemetry records that an API call was made under a given role. It does not record the reasoning that led to the call, the context the agent held at the time, or the instruction that prompted it. Most agent risk looks entirely legitimate at the infrastructure layer precisely because it is executed with permissions the agent genuinely holds – a coding agent reading source code using credentials associated with a competitor is an ordinary read against an authorized role.
Everything outside the cloud. An agent’s footprint spans cloud, code, endpoint and browser simultaneously. A cloud-anchored control covers one of those four and inherits a hard ceiling on the other three, which is the same ceiling an endpoint-first architecture hits from the opposite direction. Our entries on EDR and NDR make that case from the device and network sides.
Can a CNAPP secure AI agents?
Partially, and the part it secures is worth having. A CNAPP consolidates posture, workload, entitlement and network data into one graph, which is a genuinely better foundation for agent work than any of those components alone – effective permissions reconciled against reachable resources is exactly the kind of reasoning agent governance needs.
What it cannot do is extend that graph into the agent. The CNAPP graph is built from the cloud provider’s APIs, and the cloud provider’s APIs expose infrastructure. They do not expose the agent’s instructions, its tool inventory, its memory, or its decisions, because the cloud provider does not hold those either in any usable form for an agent running on general compute.
There is also a sequencing problem that is easy to miss during an evaluation. The CNAPP’s agent inventory is assembled from what the cloud control plane declares – managed agent services, model endpoints, provisioned runtimes. That is a list of agents somebody deliberately provisioned through an approved path, which is to say the agents least likely to be the problem. In one Geordie deployment the actual agent count ran 327% higher than the CTO and security team’s own estimate, and the gap is not made up of carefully provisioned production services. It is made up of agents nobody registered anywhere.
What is the difference between cloud security and AI agent security?
| Cloud security (CSPM / CWPP / CIEM / CNAPP) | AI agent security | |
|---|---|---|
| Primary object | The environment the agent runs in | The agent as a system |
| Source of truth | Cloud provider control plane and runtime telemetry | Agent configuration, context, tool definitions and execution path |
| Inventory covers | Agents provisioned through approved cloud services | Agents across cloud, code, endpoint and browser, provisioned or not |
| Core assumption | Behavior follows from configuration | Configuration constrains behavior but does not determine it |
| Risk model | Misconfiguration, excessive entitlement, vulnerable workload | Architecture, configuration and behavior assessed together |
| What it detects | Policy violations in infrastructure state | Actions that are permitted but wrong for the context |
| Enforcement point | Cloud API, network path, workload runtime | The agent’s own configuration and execution path |
| Audit record | Infrastructure events under a service identity | What the agent did, under whose authority, in a record the agent cannot edit |
The row that matters most is the fourth one. Everything else follows from it.
Why are cloud security vendors moving into agent security?
Because the agents they can see are running in their customers’ cloud accounts, and because adding an agent inventory to an existing platform is a low-friction way to meet a board-level question. Both of those are reasonable commercial logic and neither is a criticism.
The structural point is one that applies to any incumbent extending into this space, not specifically to cloud vendors. Agent governance arriving as a line item on a platform built for a different object will inherit that platform’s boundary and that platform’s assumptions. In cloud security’s case the inherited boundary is the cloud account and the inherited assumption is the deterministic one described above. A capability added to a CNAPP will see agents the way a CNAPP sees things, which is as workloads with attached entitlements.
The question worth putting to any vendor in this position is not whether they have an agent module. It is what their module reads. If the answer is the cloud provider’s APIs, you now know exactly which agents it will find and which parts of those agents it will understand.
Where does agent security sit alongside cloud security?
Alongside, not instead of. Cloud security remains the right control for the risks it was built for – those risks do not become less real because an agent is the thing running in the misconfigured container, and a badly scoped execution role is still a badly scoped execution role.
The distinction is where each layer stands relative to the agent. Cloud security observes agents from the outside, at a boundary they happen to cross, which means its coverage and its control are locked to that same boundary – it can act on what it can see, and only there. Agent security reads the agent’s own configuration and execution path, which allows interception and enforcement to be separated: several interception mechanisms across cloud, code, endpoint and browser feeding a single enforcement layer that operates through the agent’s own context rather than at an infrastructure edge.
That separation is what makes controls specific rather than binary. A boundary control can allow or deny; it cannot easily distinguish a finance agent legitimately processing financial data from a marketing agent that should not be touching it, because both appear identical at the edge. It also removes the single point of failure that proxy and chokepoint architectures carry at volume, which stops being theoretical at the scale where one customer applies inline controls across tens to hundreds of thousands of agents daily.
A useful integration test for any pairing: agent security that cannot feed your existing cloud and SIEM tooling is creating another silo, and cloud posture findings that cannot be read against what an agent is actually doing stay as findings rather than becoming decisions.
How do you tell whether your cloud coverage is enough?
Four questions, each answerable from tooling you already have.
- What fraction of your agents run in the cloud at all? Count the coding agents on developer machines, the agents embedded in SaaS products, the ones running in browser extensions. Cloud coverage has a ceiling at exactly that fraction, and in most organizations the fraction is lower than expected.
- Where did your agent inventory come from? If it was assembled from cloud provider APIs, it contains the agents that went through provisioning. Treat the number as a floor rather than a count.
- Can you see what each agent is configured to do? Its instructions, its tool connections, its memory settings. If your answer comes from reading infrastructure state, you have the container and not the agent.
- Would you detect an action that was permitted but wrong? Correct credentials, authorized resource, legitimate API call, wrong reason. If detection depends on a policy violation appearing in infrastructure state, this entire class passes through cleanly.
Common questions
Does CSPM cover AI agents?
It covers the cloud infrastructure an agent runs on – the runtime configuration, the attached roles, the resources reachable from that environment. It does not cover the agent's own configuration, its tool connections, or its behavior, and it has no visibility into agents running outside cloud environments. For an organization whose agents are entirely deployed through managed cloud services, CSPM covers a meaningful share of the infrastructure risk and none of the agent risk.
Isn't an agent just another cloud workload?
It runs as one, which is why cloud tooling sees it as one. The difference is that a conventional workload's behavior is determined by its code and configuration, while an agent's behavior is determined by its configuration plus whatever enters its context at runtime. A workload that passes its posture checks behaves as designed. An agent that passes its posture checks has only been shown to be capable of behaving as designed.
We already have a CNAPP. What would agent security add?
Agent discovery that does not depend on cloud provisioning records, visibility into agent configuration and tool connections rather than infrastructure state, behavioral observability over what agents actually do, and controls that apply through the agent's own execution path. The two are complementary: your CNAPP's entitlement graph is a genuinely useful input to agent risk, and it becomes considerably more useful when it can be read against what the agent holding those entitlements is doing with them.
Can cloud security stop an agent mid-action?
It can revoke a credential, block a network path, or terminate a workload, all of which are blunt by design and apply after the fact in most cases. Stopping an action before it executes requires a control point inside the agent's execution sequence rather than at an infrastructure boundary – which is what lifecycle hooks provide, and where the difference between observing an agent and governing one actually sits.
