Aqua Security built its name on agent-based runtime protection: Aqua Enforcers running as daemons inside Kubernetes clusters and on hosts, watching process behavior, network calls, and file activity as containers execute. It is a mature, well-documented model, and for teams whose primary exposure is a live Kubernetes estate, runtime agents remain a reasonable way to catch drift, unauthorized binaries, and anomalous behavior after deployment. Safeguard starts from a different question entirely: not "what is this workload doing right now," but "was the software that produced this workload trustworthy before it ever reached a cluster." That's a build-time, supply-chain question, and answering it doesn't require a persistent process running anywhere in production — it requires visibility further upstream, at the commit, the dependency resolution, and the registry push that happen long before a scheduler ever places a container on a node.
This post compares the two philosophies honestly — where agent-based runtime visibility earns its keep, where a pipeline-native approach catches things runtime agents structurally cannot, and where the "agentless vs. agent-based" framing oversimplifies what's really a question about vantage point and timing. No invented pricing or feature claims about Aqua — just architecture, and where Safeguard's coverage differs.
What does "agent-based" mean in Aqua Security's model?
Aqua Security's runtime protection is built around the Aqua Enforcer, a component deployed as a daemonset (in Kubernetes) or host agent that runs continuously alongside the workloads it protects. This is publicly documented in Aqua's own architecture materials: the Enforcer watches container and host behavior in real time — process execution, network connections, file system changes — and can apply runtime policies like drift prevention or blocking unauthorized binaries. That's the textbook definition of "agent-based": a persistent, always-on process with visibility into what's actually executing on a host or in a pod.
The value of that model is real for a specific problem: detecting and stopping behavior that only exists at runtime. A container that starts spawning an unexpected shell, a process trying to write to an immutable filesystem, a workload reaching out to an unrecognized network destination — these are runtime events, and a runtime agent with kernel or container-runtime-level visibility is positioned to see them as they happen. No amount of pre-deployment scanning replaces that vantage point if live behavioral anomaly detection is the requirement.
Is Safeguard "agentless," or is that even the right word?
Safeguard's scanning component isn't a cloud-API-polling agentless CNAPP in the Wiz sense, and it isn't a persistent runtime daemon in the Aqua Enforcer sense either — it's a CLI that runs on demand, invoked by CI/CD pipeline events or from a developer's machine, and exits once it produces its report. There's no process sitting on production infrastructure between scans, and there's no cloud account being polled on a schedule. The scan happens at the moment a build runs, a PR opens, or a container image is pushed to a registry (GitHub, GitLab, Bitbucket, ECR, GCR are the integrations Safeguard triggers from), and then it's gone.
That distinction matters because "agentless vs. agent-based" is often presented as a single friction-versus-coverage tradeoff, but pipeline-triggered scanning, snapshot-based cloud posture tools, and always-on runtime agents are three different things wearing two labels. Safeguard adds a scan step to the build, not a daemon to production. Aqua's Enforcer adds a persistent process to production, in exchange for visibility no build-time tool can produce. Neither is strictly "lighter weight" — they're positioned at different points in the software lifecycle.
Where do the two approaches actually diverge?
Aqua's runtime agents are watching the workload after it has already been deployed. That's the right vantage point for catching live compromise, but by the time the Enforcer sees a process behave badly, the image that produced that process has already been built, scanned once, pushed to a registry, and pulled into a running environment — the vulnerable or malicious component has already traveled most of the supply chain. Safeguard is positioned upstream of that: its pipeline runs against source repositories and registries at commit, build, and push time, generating a software bill of materials (SBOM) and vulnerability/secret findings tied to the exact commit and artifact that produced them, before that artifact is ever scheduled onto a node an Enforcer would be watching.
Put differently: Aqua's agent-based model answers "is this running container behaving abnormally right now?" Safeguard's pipeline-native model answers "was the code, the dependency, and the build process that created this artifact trustworthy in the first place?" A typosquatted package pulled into a build, a secret accidentally committed to a repo, an unpinned base image that silently upgraded to a compromised tag — these are supply chain events that happen long before a container is scheduled, and a runtime agent watching syscalls in production has no vantage point on them at all. Conversely, Safeguard's build-time scan has no vantage point on a container that starts behaving anomalously three days after deployment because of a runtime exploit chain, which is squarely Aqua Enforcer territory.
Trivy is open source — why do platforms built around it look so different?
Here's a genuinely verifiable point of overlap: Aqua Security created and continues to maintain Trivy, the open-source vulnerability and misconfiguration scanner, and Safeguard's own pipeline also invokes Trivy — alongside Grype for additional vulnerability coverage and gitleaks for secret detection — as part of its build-time scanning. Both companies rely on the same open-source scanning engine for a meaningful slice of their vulnerability detection, which says something useful: the underlying CVE-matching logic for "does this container image contain a known-vulnerable package" is largely a solved, shared problem across the industry.
What differs isn't the scanner core, it's what wraps around it. Aqua orchestrates Trivy's output into a CNAPP built around Kubernetes admission control, runtime enforcement, and cloud posture dashboards. Safeguard orchestrates Trivy and Grype output into a pipeline that ties findings back to a specific SCM commit and registry push, generates a per-build SBOM, and surfaces results at the moment a developer or a CI job would want them — not as a standalone dashboard to check later. Same open-source detection primitive, two different products because the surrounding orchestration answers two different operational questions.
Which approach catches a compromised dependency first?
Timing is the practical stakes of this comparison. A malicious package version can be published to a public registry, pulled into a build within minutes by an automated dependency resolver, and packaged into a container image the same day. If detection depends on a runtime agent observing anomalous behavior after that image is deployed, the compromised dependency has already been built, signed (or not), and shipped — the agent is reacting to a problem that started upstream, often after damage is already possible. If detection is tied to the CI/CD pipeline event itself — the moment the dependency is resolved, the build runs, and the image is pushed — the same compromise can be flagged before the artifact ever reaches a cluster an Enforcer would be watching.
This isn't an argument that runtime detection is unnecessary — a supply-chain scan can miss a zero-day exploited entirely at runtime with no build-time signature, which is exactly the class of problem agent-based tools are built to catch. It's an argument that "mean time to detection" depends heavily on where in the lifecycle you're looking, and a compromise that originates in a dependency or a build step is caught faster by a tool watching that stage than by a tool watching the workload after the fact.
Do Safeguard and Aqua compete, or cover different layers?
Functionally, the overlap is narrower than the marketing category ("cloud-native security") suggests. Aqua's center of gravity is Kubernetes and container runtime: admission control, drift prevention, workload behavioral monitoring, and cloud posture management for the infrastructure those workloads run on. Safeguard's center of gravity is the software supply chain: SBOM generation, dependency and secret scanning tied to source control and registries, and CVE/package lookup for triage. A team running Aqua Enforcers across a Kubernetes fleet and Safeguard's pipeline scanner across their CI/CD isn't running redundant tools — they're covering commit-to-runtime rather than just the runtime half of it.
If your primary exposure is live container and host behavior in a Kubernetes estate, an agent-based runtime platform is doing the job it's built for, and periodic build-time scanning alone won't replace that visibility. If your primary exposure is what gets built and pushed before it ever reaches that estate — vulnerable transitive dependencies, secrets in source control, unverified provenance between source and registry — that's a pipeline problem, and it needs to be caught at commit or build time, not inferred from behavior after deployment.
How Safeguard Helps
Safeguard is built for the part of the lifecycle that runtime agents, by design, see last: the software supply chain that produces the artifact before it's ever scheduled onto a workload. In practice:
- SBOM generation at build time, tied to the specific commit and artifact, so every component has a traceable origin instead of a best-effort reconstruction after the fact.
- Vulnerability and secret detection in the pipeline, using Trivy, Grype, and gitleaks orchestrated through Safeguard's scanning pipeline, triggered directly from SCM integrations (GitHub, GitLab, Bitbucket) and container registries (ECR, GCR).
- Findings tied to commit and build, not a scheduled scan cycle, so a compromised dependency or leaked secret surfaces at the moment it enters the pipeline.
- Public CVE and package lookup for fast triage of a package's known-vulnerability history without waiting on the next scan.
- A CLI-first, pipeline-native workflow — invoked on demand or by CI events, producing a report and exiting, with no persistent daemon added to production infrastructure.
Agent-based runtime protection and pipeline-native supply chain scanning aren't competing answers to the same question — they're looking at different stages of the same software's life. Teams weighing "agentless vs. agent-based security" should first ask which stage their current tooling actually covers: the running workload, or the pipeline that built it. For the latter, that's the layer Safeguard is built for.