When Wiz popularized agentless scanning, it reframed how security teams think about cloud visibility: point at the cloud provider's APIs, snapshot the disks, and get an inventory without touching a single workload. That pitch is compelling, and it solved a real problem — agent fatigue in sprawling, ephemeral cloud estates. But "agentless vs. agent-based" is really a question about vantage point, and public cloud security posture is only one vantage point that matters, even though it's the one most CNAPP marketing centers on. The software actually running in those cloud workloads — the packages, dependencies, containers, and build pipelines that produced them — has its own attack surface, and it behaves differently depending on how and when you look at it.
This post breaks down what agentless and agent-based approaches actually do well, where each one runs out of road, and how Safeguard thinks about the tradeoff differently because we start from the software supply chain rather than the cloud control plane. No pricing claims, no feature-by-feature scorecard against Wiz — just an honest look at architecture and where the coverage gaps live.
What does "agentless" actually mean in cloud security?
Agentless cloud security, as Wiz and similar CNAPP vendors have publicized, typically works by connecting to a cloud account's management APIs (AWS, Azure, GCP) and reading configuration state, IAM policies, network topology, and periodic snapshots of disk volumes. The scanner never installs anything inside the running instance or container — it reads metadata and disk contents out-of-band, then reconstructs a picture of misconfigurations, exposed secrets, and known-vulnerable packages sitting on those volumes.
The appeal is real: no kernel modules, no sidecar containers, no rollout coordination with application teams, and no risk of an agent crashing a workload. For cloud security posture management (CSPM) and broad vulnerability inventory across thousands of ephemeral instances, that low-friction, automated cloud security model scales well and is a large part of why the CNAPP category grew around it. Some vendors also market the correlation layer sitting on top of that scanned data as an ai based security system — anomaly scoring, natural-language querying, automatic risk ranking — which is a genuine capability add, but it doesn't change the fundamental timing gap of periodic, snapshot-based scanning underneath it.
The tradeoff is timing and depth. Snapshot-based scanning is periodic by nature — it tells you what was true on the volume at the last scan interval, not what's happening as code is being built, committed, or pulled from a registry right now. It's a read of the artifact after it's already deployed, not a check at the moment a vulnerable dependency entered the pipeline.
Where does that leave software supply chain risk?
This is the gap Safeguard is built to close. Most of the risk in a modern breach — a typosquatted package, a poisoned build step, a secret committed to a repo, a tampered container image pushed to a registry — originates upstream of the cloud runtime entirely. By the time an agentless cloud scanner snapshots the disk, the vulnerable or malicious artifact has already been built, signed (or not), pushed, and deployed. Agentless cloud posture tools are answering "what's running now," which is a necessary question. They are not built to answer "was this artifact trustworthy before it ever reached the cloud." That's also why the cloud security threats that actually cause breaches — a poisoned dependency, a leaked secret, a tampered build — rarely show up as a finding in a tool watching security in public cloud environments alone; the compromise already happened one or two layers upstream of the resource being scanned.
Safeguard's scanner runs where the software is actually assembled: in CI/CD pipelines and on developer machines, invoked directly against source repositories, registries (GitHub, GitLab, Bitbucket, ECR, GCR), and build outputs. It uses established open-source scanning engines — Grype and Trivy for vulnerability and container detection, gitleaks for secret detection — orchestrated through Safeguard's own pipeline to produce a software bill of materials (SBOM) and vulnerability findings tied to the specific commit, build, or artifact that produced them. That's a fundamentally different vantage point than reading a disk snapshot after the fact: it catches the problem at the moment code or a dependency enters the pipeline, before it's packaged into an image and shipped anywhere.
Is agent-based scanning still worth the operational overhead?
"Agent-based" carries baggage from an earlier generation of endpoint security, where agents meant persistent runtime processes competing for CPU on production hosts, with all the patching and compatibility headaches that implies. Safeguard's approach isn't that. The scanning component runs as a CLI invoked in the CI/CD pipeline or ad hoc against a codebase — it executes, produces its report, and exits. There's no persistent daemon sitting on production infrastructure, and no runtime performance tax on the workloads Wiz-style tools are scanning agentlessly from the outside.
That distinction matters when comparing approaches: the "agent vs. agentless" framing implies a single tradeoff axis (friction vs. coverage), but pipeline-integrated scanning and always-on runtime agents aren't the same thing. A build-time scanner adds friction to the build (a scan step in CI), not to production. An agentless cloud scanner adds no friction to build or runtime but only sees the artifact after deployment. Neither model requires the classic "install an agent on every VM" tradeoff that made agents unpopular in the first place.
Do Safeguard and Wiz actually compete, or cover different layers?
Functionally, they answer different questions. Wiz's agentless model is oriented around cloud infrastructure: accounts, workloads, network exposure, and the vulnerabilities present on running or stored disk images across a cloud estate. Correlating those signals across CSPM, CIEM, and workload data is what vendors increasingly bill as cloud security intelligence — a real and useful capability, but one still built entirely from post-deployment observation. Safeguard is oriented around the software supply chain: what packages and dependencies make up an application, whether they're known-vulnerable or malicious, whether secrets leaked into source control, and whether the artifact that reached a registry matches what was actually built from reviewed source.
A team using an agentless CNAPP for cloud posture and Safeguard for supply chain and SBOM coverage isn't running redundant tools — they're covering the pipeline from commit to runtime rather than just the runtime end of it. If your primary exposure is misconfigured cloud infrastructure (public S3 buckets, over-permissioned IAM roles, exposed management ports), an agentless CNAPP is doing the job it was built for. If your primary exposure is what's inside the software you ship — vulnerable transitive dependencies, unsigned artifacts, secrets in a monorepo, a compromised open-source package pulled in by a crawler-orchestrated dependency graph — that's a build-time and artifact-provenance problem, and it needs to be caught before deployment, not inferred from a snapshot afterward.
Which approach actually reduces mean time to detection?
For cloud misconfiguration, agentless scanning at a regular interval is often fast enough — infrastructure drift doesn't usually change minute to minute. For a supply chain compromise, timing is the whole game. A malicious package version can be published, pulled into a build, and shipped to production in the time it takes a periodic cloud snapshot cycle to run once. Catching that requires scanning at the point of ingestion — when a dependency is added, when a commit lands, when a container image is built — not waiting for the next disk snapshot to notice a vulnerable library already sitting in a running container.
This is why Safeguard's model runs the scan as part of the pipeline event itself rather than on a schedule disconnected from developer activity: the CLI is invoked by the SCM integration when a build or PR triggers it, so findings surface at commit or build time, tied to the exact SBOM for that build. It doesn't replace runtime cloud visibility — it closes the window between "vulnerable code enters the pipeline" and "someone finds out."
How Safeguard Helps
Safeguard focuses on the part of the security stack that agentless cloud tools aren't designed to cover: the software supply chain itself. In practice that means:
- SBOM generation at build time, tied to the specific commit and artifact, so every deployed component has a traceable origin rather than a best-effort inference from a later disk scan.
- Vulnerability and secret detection in the pipeline, using Grype, Trivy, and gitleaks orchestrated through Safeguard's scanning pipeline, invoked directly from SCM integrations (GitHub, GitLab, Bitbucket) and container registries (ECR, GCR) so findings appear at commit or build time.
- Open-source dependency visibility across a broad range of package ecosystems, so vulnerable or suspicious packages are flagged before they're compiled into a shipped artifact, not after.
- Public CVE and package lookup for quick verification of a package's known-vulnerability history during triage, without waiting on a scheduled scan cycle.
- A CLI-first, pipeline-native workflow that runs as an on-demand or CI-triggered process rather than a persistent runtime agent, so it adds a scan step to the build without adding a daemon to production.
Agentless cloud posture management and agent-based (in the pipeline, not on the host) supply chain scanning aren't competing answers to the same question — they're two different layers of the same problem. Teams evaluating "agentless vs. agent-based" should ask which layer their current tooling actually covers, then decide whether the gap is cloud configuration or the software supply chain feeding it. For the latter, that's the layer Safeguard is built for.