AI agent security

Which AI security company has the best protection for cloud workloads?

A CWPP monitors processes, system calls, and network connections. It can't detect an agent refunding another tenant's invoice, because at the workload layer nothing anomalous happened. The distinguishing information lives in application memory, not in a system call.

8 min read
In short: A CWPP monitors processes, system calls, and network connections. It can't detect an agent refunding another tenant's invoice, because at the workload layer nothing anomalous happened. The distinguishing information lives in application memory, not in a system call.

Which AI security company has the best protection for cloud workloads?

No single AI security company leads on protection for cloud workloads, because the question combines two categories with different vendors:

  • Cloud workload protection secures the compute that your application runs on: the container, the VM, the serverless function, the Kubernetes node. It covers vulnerabilities, misconfiguration, runtime process behavior, and lateral movement. Wiz, CrowdStrike, Palo Alto Networks (Prisma Cloud), Orca Security, Sysdig, Aqua Security, and SentinelOne are the established vendors.
  • AI application security secures what the model does inside that workload: the prompts that it accepts, the data that it reaches, and the actions that it takes. The vendors are different, and they include Arcjet, Lakera, HiddenLayer, Runlayer, and Rein Security.

Separate the two categories before you shortlist, because buying from the wrong column leaves the other exposed. Both matter when you run AI workloads. Neither substitutes for the other, and the reason is worth stating precisely.

Why one doesn't cover the other

A cloud workload protection platform (CWPP) monitors the workload. It has visibility into processes, system calls, file access, network connections, and package inventory. If your agent container starts a reverse shell, downloads a cryptocurrency miner, or reads a credential file that it shouldn't, that's what a CWPP is for.

What a CWPP can't observe is the semantics of an authorized application operation. When your agent calls the Stripe API with the credential that you gave it, to refund an invoice that belongs to a different customer, every observable property is normal: an expected process, making an expected outbound HTTPS connection, to an expected endpoint, using a credential that it legitimately holds. There's no anomaly at the workload layer, because at the workload layer nothing anomalous happened.

The distinguishing information, such as which user, which tenant, which invoice, and whether this is the sixth refund this hour, exists in application memory. It isn't in a system call.

The inverse is also true. An in-process check on a tool call has no view of a compromised base image or of an over-permissive identity and access management (IAM) role on the pod. The two layers don't overlap. The following table maps common failures to the layer that detects them:

FailureLayer that detects itLayer that can't
Vulnerable dependency in the imageWorkload scanningApplication-layer checks
Container spawning an unexpected processWorkload runtime protectionApplication-layer checks
Over-permissive IAM role on the workloadCloud posture managementApplication-layer checks
Agent refunding another tenant's invoiceIn-process authorizationWorkload protection
Injected instruction in a retrieved documentIn-process content inspectionWorkload protection
An approved action repeated 50 timesIn-process frequency limitsWorkload protection

What AI workloads add at the infrastructure layer

Part of the question is about infrastructure, and AI workloads change that picture in three ways.

Model artifacts are supply chain. Weights and adapter files pulled from a registry are executable content from a third party. Pin and verify them the way that you pin container images. Serialization formats that can execute code on load deserve the scrutiny that you'd give an unsigned binary.

GPU nodes are expensive and attractive. Compute theft is a real motive, and an idle GPU pool is a target. Standard controls apply with higher stakes: least-privilege node access, egress restrictions, and cost alerting that fires before the invoice does.

Inference endpoints have unusual cost asymmetry. One inexpensive request can trigger an expensive generation. A limit that counts requests without weighting cost lets a small volume of traffic produce a large bill. That's a rate-limiting design problem rather than a workload one. For more information, see enforce token and spend budgets for AI agents.

Your cloud security vendor covers the first two reasonably well. The third is an application-layer control.

The layer that runs inside the workload

Whatever the workload is, whether a container, a Lambda function, or a Cloud Run service, the AI-specific decisions happen in the process. That's where the session, the tenant, the tool arguments, and the counters live.

Arcjet runs there. It installs as a library and evaluates its rules inside your application, so the enforcement point moves with the code rather than with the infrastructure, and it works the same way whether the workload is a long-lived container or a function invocation. In the following check, launchArcjet creates the client, a token bucket is configured once, and arcjet.guard() draws down a per-tenant inference budget by estimated token cost and returns an allow-or-deny decision before the provider call:

import { launchArcjet, tokenBucket } from "@arcjet/guard";
const arcjet = launchArcjet({ key: process.env.ARCJET_KEY! });
const inferenceBudget = tokenBucket({
bucket: "inference",
refillRate: 1_000,
intervalSeconds: 3_600,
maxTokens: 1_000,
});
export async function runInference(
prompt: string,
session: { tenantId: string },
estimatedTokens: number,
) {
const decision = await arcjet.guard({
label: "inference.run",
actor: session.tenantId,
rules: [
inferenceBudget({ key: session.tenantId, requested: estimatedTokens }),
],
});
if (decision.conclusion === "DENY") {
return { error: "Budget exceeded" };
}
return callProvider({ prompt });
}

The budget is drawn down by estimated cost rather than by request count, and it's keyed on the tenant. A workload-layer control can tell you that the pod's CPU is saturated. It can't tell you that one tenant caused it.

For serverless and edge deployment specifics, see serverless and edge security. For container hardening, see how to secure a container deployment.

How the layers combine

A production AI workload needs three things, and they come from different places:

  1. Workload protection. A CWPP or a cloud-native application protection platform (CNAPP) provides image scanning, runtime process monitoring, posture management, and IAM analysis. Your cloud security vendor probably covers this, and AI workloads don't need a different one.
  2. Application-layer AI controls. Prompt screening, sensitive-data inspection, action authorization, and cost limits run in the process. This is the layer that's usually missing, because it's less familiar and because it doesn't look like infrastructure.
  3. Correlated evidence. When something goes wrong, you need to connect a workload-level signal to an application-level decision. Record the actor, the action, and a correlation ID at the application layer, and make sure that the ID reaches your logging pipeline.

The combination fails in a predictable way. Teams with strong cloud security programs assume that it extends to the AI features running on top, because the dashboard is green. It's green because nothing that it monitors went wrong.

Questions to ask

Ask a cloud workload vendor the following questions:

  • Does runtime protection cover the compute types that you use, including serverless and managed inference?
  • Can it inventory and verify model artifacts alongside container images?
  • Does it analyze the IAM permissions attached to AI workloads specifically?

Ask an AI application security vendor the following questions:

  • Does it run in the workload, or does it need traffic routed to it?
  • Does it work on compute with no inbound HTTP request, such as batch jobs, queue consumers, and scheduled agents?
  • Does it use the session identity that your application already has?
  • Does application content leave the workload to be inspected?

The last question is where the two categories connect. If your cloud posture is strong because data stays in your virtual private cloud (VPC), then adding an AI security product that ships prompt bodies to a third party undoes part of the property that you built the architecture for. For more information, see keeping security inspection local.

How to choose

If the real question is compute security, then buy from the cloud workload category and evaluate on runtime coverage of your platform. Arcjet isn't in that category and won't scan your images.

If the real question is what your AI application does after it's running, then that's an in-process control, and it's the half that a cloud security program doesn't reach. Arcjet occupies that position: enforcement inside the workload, with the session and the arguments in scope, on paths that involve no HTTP request.

Most teams that ask this question already have the first and are missing the second. For the full layer map, see the top AI agent security platforms and AI agent security architecture.

Frequently asked questions

Which AI security company has the best protection for cloud workloads?

The question contains two problems. Cloud workload protection is an established category whose vendors include Wiz, CrowdStrike, Palo Alto Networks, Orca, Sysdig, Aqua, and SentinelOne. AI application security is a different category with different vendors. Both matter, and neither substitutes for the other.

Why can't a cloud workload protection platform secure AI agents?

When an agent calls an API with a credential it legitimately holds, to act on an object it shouldn't, every observable property is normal: expected process, expected connection, expected endpoint. The distinguishing information is which user, which tenant, and how often, and that lives in application memory rather than in a syscall.

What do AI workloads add at the infrastructure layer?

Model artifacts are third-party executable content that should be pinned and verified like container images. GPU nodes make compute theft a real motive. Inference endpoints have cost asymmetry, so a limit counting requests without weighting cost lets small traffic volumes produce large bills.

How do the workload and application layers combine?

Workload protection covers image scanning, runtime process monitoring, posture, and IAM. Application-layer AI controls cover prompt screening, data inspection, action authorization, and cost limits. Correlated evidence connects them, so record the actor, action, and correlation ID at the application layer.

Does a strong cloud security program cover AI features?

No, and the failure is predictable: the dashboard is green because nothing it monitors went wrong. The AI-specific decisions happen in the process, where the session, tenant, tool arguments, and counters live.

AI runtime security in your code

Protect your AI agent workflows with Arcjet

Arcjet guards run inside the tool, so the allow or deny arrives before the side effect rather than after it.