Agentless vs Agent-Based Cloud Protection: Trade-offs, Architecture and a Practical Decision Guide

Cloud estates change faster than agent rollout plans. Instances appear from autoscaling groups, teams launch accounts outside central IT, and images built months ago keep running with old packages.

Agentless cloud security answers that problem by assessing workloads and configurations through cloud provider APIs and disk snapshots, with nothing installed on the machine itself.

This article explains how agentless scanning works under the hood, where it falls short, what new risks the scanner itself introduces, and how to decide when an agent is still required.

It includes an illustrative least-privilege IAM policy for a scanner role, a CloudTrail detection query for snapshot abuse, and an evaluation checklist.

What agentless cloud security actually means

“Agentless” covers two different techniques that vendors often bundle together. The first is API-based posture assessment: reading resource configurations, IAM policies, network rules and logging settings from the control plane.

This is the core of cloud security posture management (CSPM) and has always been agentless.

The second is workload scanning without an agent. The scanner takes a snapshot of a virtual machine’s disks, mounts or reads it in a separate environment, and inspects the filesystem for vulnerable packages, secrets, malware and misconfigurations.

Orca Security popularised this approach under the name SideScanning and announced a US patent for it in 2022 (Orca press release, 2022). Cloud providers and most CNAPP vendors now offer their own versions.

Why the model spread

• Coverage on day one: connecting a read-only role to an account or organisation reveals every instance, including ones nobody knew about.
• No performance or stability impact: the scan runs against a copy, not the live workload.
• No agent lifecycle: there are no kernel compatibility matrices, upgrades or crashed sensors to maintain.
• Organisational simplicity: security teams do not need workload owners to install anything.

How snapshot-based workload scanning works

The exact mechanics differ by product, but provider documentation shows the common pattern. In Amazon Inspector’s hybrid mode, the service creates EBS snapshots of an unmanaged instance’s volumes, tags them with an InspectorScan key, reads the data through the EBS direct APIs, generates findings and deletes the snapshots.

Agentless scans run every 24 hours on eligible instances, against about every 30 minutes for agent-based inventory, according to the Amazon Inspector EC2 scanning documentation (accessed 2026).

Microsoft Defender for Cloud follows a similar flow for Azure, AWS and GCP machines. It snapshots root and data disks, analyses them in an isolated regional environment, sends extracted metadata to its vulnerability, secrets and malware engines, and deletes the copy, as described in its agentless machine scanning documentation (accessed 2026).

The typical pipeline

1. Discover instances and volumes through the compute APIs.
2. Snapshot the attached volumes, often with a scanner-specific tag.
3. Read the snapshot in the customer account, a dedicated scanning account or the vendor’s environment, depending on the deployment model.
4. Analyse package databases, language manifests, configuration files and binaries.
5. Delete the snapshot and keep only metadata and findings.
6. Correlate findings with posture data, such as internet exposure, attached IAM roles and reachable sensitive data, to prioritise risk.

That last step is where agentless tools add the most value. A critical CVE on an isolated batch node matters less than a medium CVE on an internet-facing instance whose role can read production S3 buckets.

What agents still do better

A snapshot is a point-in-time picture of disk. It cannot see processes, memory, network connections or anything that happens between scans.

Fileless malware, a reverse shell spawned from a vulnerable web app, or an attacker who lands, steals credentials and leaves within an hour will not appear in a daily disk scan.

Agents, typically EDR or cloud workload protection sensors using eBPF or kernel hooks, provide real-time telemetry and can block or kill malicious activity.

They also support forensics: process trees, command lines and file hashes at the moment of compromise. Agentless detection relies on cloud logs instead, which show control-plane actions well but say little about what happened inside the guest.

Gaps to check before relying on agentless alone

• Ephemeral workloads: instances or nodes that live for minutes may never be snapshotted.
• Unsupported storage: Inspector’s agentless mode, for example, requires EBS-backed instances with ext3, ext4 or xfs and limits volume count and total size.
• Encrypted volumes: scanning customer-managed-key volumes needs extra key permissions, which some teams will not grant.
• Containers and serverless: running containers and functions need registry scanning, runtime sensors or provider-native integrations. Managed Kubernetes adds its own identity risks, as shown by Amazon EKS flaws that exposed AWS credentials.

Agentless vs agent-based security compared

Dimension	Agentless (API and snapshot)	Agent-based (EDR or CWPP sensor)
Deployment	Cloud role per account or organisation	Install and maintain software on every workload
Coverage of unknown assets	High, finds everything the API can see	Only where the agent is installed
Vulnerability and secrets inventory	Strong, periodic (often daily)	Strong, near real time
Runtime threat detection	Limited to cloud logs and disk artefacts	Process, network and memory visibility
Prevention and response	None in the guest; can trigger cloud-level actions	Block, kill, isolate host
Performance impact	None on the workload; snapshot and storage costs apply	Some CPU and memory overhead
Privilege required	Broad read and snapshot rights across accounts	Root or kernel-level on each host
Best fit	Posture, inventory, prioritisation, compliance evidence	Crown-jewel workloads, detection and response

Neither column is a ranking. Features change quickly across vendors, so confirm current capabilities, supported operating systems and pricing models directly with each provider.

The security risks of the agentless scanner itself

An agentless platform needs read access to every account and the ability to create, read and sometimes share disk snapshots.

That is the same capability an attacker wants for data theft.

MITRE ATT&CK lists snapshot creation as T1578.001 Modify Cloud Compute Infrastructure: Create Snapshot, used to bypass guest-level controls, and sharing snapshots with an external account maps to T1537 Transfer Data to Cloud Account.

Recent incidents show how quickly cloud permissions are abused. GBHackers has covered an AI-assisted intrusion that compromised an AWS environment in 72 hours using stolen credentials and a case where a mis-scoped AWS Organizations policy handed attackers full control of an environment.

A scanner role with organisation-wide trust deserves the same scrutiny as any other high-value identity.

Illustrative least-privilege scanner policy (AWS)

{
  “Version”: “2012-10-17”,
  “Statement”: [
    { “Sid”: “Describe”,
      “Effect”: “Allow”,
      “Action”: [“ec2:DescribeInstances”, “ec2:DescribeVolumes”, “ec2:DescribeSnapshots”],
      “Resource”: “*” },
    { “Sid”: “CreateTaggedSnapshotsOnly”,
      “Effect”: “Allow”,
      “Action”: [“ec2:CreateSnapshot”, “ec2:CreateTags”],
      “Resource”: “*”,
      “Condition”: { “StringEquals”: { “aws:RequestTag/scanner”: “agentless” } } },
    { “Sid”: “ReadAndDeleteOwnSnapshots”,
      “Effect”: “Allow”,
      “Action”: [“ebs:ListSnapshotBlocks”, “ebs:GetSnapshotBlock”, “ec2:DeleteSnapshot”],
      “Resource”: “arn:aws:ec2:*::snapshot/*”,
      “Condition”: { “StringEquals”: { “aws:ResourceTag/scanner”: “agentless” } } },
    { “Sid”: “NeverShare”,
      “Effect”: “Deny”,
      “Action”: [“ec2:ModifySnapshotAttribute”, “ec2:CopySnapshot”],
      “Resource”: “*” }
  ]
}

Treat this as a starting point to test, not a drop-in policy; vendors document the exact permissions their products need, and CreateSnapshot tag conditions must be validated in your accounts.

Add an external ID to the role trust policy, restrict the trusted principal to the vendor’s documented account, and use KMS key policies that allow decryption only for the scanning role.

Detection: snapshot activity outside the scanner

— Illustrative Athena query over CloudTrail management events
SELECT eventtime, useridentity.arn, eventname, awsregion,
      json_extract_scalar(requestparameters, ‘$.snapshotId’) AS snapshot_id,
      requestparameters
FROM cloudtrail_logs
WHERE eventname IN (‘CreateSnapshot’, ‘CreateSnapshots’, ‘CopySnapshot’, ‘ModifySnapshotAttribute’)
  AND useridentity.arn NOT LIKE ‘%:assumed-role/AgentlessScannerRole/%’
  AND eventtime > to_iso8601(current_timestamp – interval ‘1’ day)
ORDER BY eventtime DESC;

Alert with high priority on any ModifySnapshotAttribute call that adds create-volume permission for an account outside your organisation.

Attackers also target the logs that feed this query, as in reports of attackers abusing AWS CloudTrail and Google Cloud Logging to hide activity, so protect trails with organisation-level configuration and alert on StopLogging or DeleteTrail (T1562.008 Disable or Modify Cloud Logs).

Reads of snapshot blocks through the EBS direct APIs are logged separately from management events.

Choosing between agentless, agents and hybrid

For most organisations the answer is a hybrid. Agentless cloud security gives broad, low-friction coverage and risk context, while agents go on the workloads where real-time detection and response justify the operational cost.

The providers’ own products reflect this: Inspector’s hybrid mode uses agents where they exist and snapshots elsewhere.

Decision guide

1. Start agentless everywhere to build an accurate inventory and posture baseline across every account and subscription.
2. Classify workloads by exposure and data sensitivity using the scanner’s attack-path context.
3. Deploy agents on internet-facing workloads, systems holding regulated or crown-jewel data, Kubernetes nodes and anything in scope for incident response retainers.
4. Keep agentless running on agent-covered hosts as a cross-check that catches broken or removed agents.
5. Review the gap list monthly: unsupported storage, encrypted volumes without key grants, and short-lived compute.

Evaluation checklist for agentless platforms

• Where are snapshots read: your account, a dedicated scanning account, or the vendor’s environment? What data leaves your boundary?
• Exact IAM, Azure RBAC and GCP role permissions required, and whether they can be scoped by tag.
• Scan frequency, supported operating systems and file systems, and handling of customer-managed encryption keys.
• Snapshot cost model and cleanup guarantees if a scan fails midway.
• Correlation of vulnerabilities with exposure, identity and data findings, and export to your SIEM or ticketing.
• Evidence mapping to frameworks your auditors use.

Mapping agentless cloud security to frameworks and breach data

The National Institute of Standards and Technology Cybersecurity Framework 2.0 gives a neutral way to place each approach.

Agentless posture and snapshot scanning support Identify (ID.AM asset management, ID.RA risk assessment) and parts of Protect (PR.PS platform security), while agents contribute most to Detect (DE.CM continuous monitoring) and Respond.

In CIS Controls v8 terms, agentless tools feed Control 1 (enterprise asset inventory), Control 4 (secure configuration) and Control 7 (continuous vulnerability management); agents support Control 10 (malware defenses) and Control 13 (network monitoring and defense).

Breach data supports investing in both. Verizon’s 2025 DBIR found that exploitation of vulnerabilities was the initial access vector in 20% of breaches, up 34% from the prior year, with credential abuse at 22% (Verizon DBIR 2025).

Agentless inventory shortens the time to find exposed, unpatched workloads, as with the ShutterGap research into millions of misconfigured AWS resources, while agents and cloud log detection are what catch credential misuse in progress.

Key takeaways

• Agentless cloud security combines API-based posture checks with snapshot scanning of workload disks.
• It excels at coverage, inventory and risk prioritisation, but sees disk state on a schedule, not runtime behaviour.
• Agents remain necessary for real-time detection, prevention and forensics on high-value workloads.
• The scanner role is a high-value identity: scope snapshot rights by tag, deny sharing and monitor snapshot APIs.
• A hybrid model, agentless everywhere plus agents where risk justifies them, fits most enterprises.

FAQ

What is agentless cloud security?

It is an approach that assesses cloud resources without installing software on them. Configuration and identity data come from cloud provider APIs, and workload contents are inspected by scanning disk snapshots outside the running machine.

Is agentless scanning better than agent-based security?

Neither is better in all cases. Agentless scanning gives fast, broad coverage and context with no workload impact, while agents provide real-time detection and response. Most teams use both.

How does agentless snapshot scanning work?

The scanner creates snapshots of a virtual machine’s disks, reads the snapshot data in an isolated environment, extracts package, configuration, secret and malware findings, and then deletes the snapshot.

Can agentless security detect runtime attacks?

Only partly. It can flag suspicious control-plane activity through cloud logs and find malware left on disk at scan time, but it cannot see processes, memory or network activity inside the guest the way an agent can.

What permissions does an agentless cloud scanner need?

Typically read access to resource configurations plus the ability to create, read and delete snapshots, and decrypt permissions for encrypted volumes. Scope these by tag, deny snapshot sharing, and monitor their use.