A common point of confusion, especially for teams evaluating cloud security platforms, is the precise technical and operational meaning of "agentless" in the context of a tool like Orca Security. The short answer to your question is no, "agentless" does not mean it cannot see running processes. In fact, that visibility is a core capability. However, the mechanism for acquiring that data is fundamentally different from a traditional agent-based approach, and understanding this distinction is critical for assessing total cost of ownership and operational fit.
The term "agentless" refers to the method of data collection, not the depth of data collected. Orca Security uses your cloud provider's underlying APIs and services (like the AWS SSM agent, which is a native cloud provider component, not a third-party security agent) to perform a read-only snapshot of your entire runtime environment. This snapshot includes a vast array of data points, which are then reconstructed and analyzed in Orca's sideplane. From this snapshot, the platform can absolutely see:
* Running processes at the moment of the scan, including their command-line arguments.
* Open network ports and listening services.
* Installed software packages and libraries.
* File system contents and configurations.
* Cloud service configurations (IAM roles, security groups, S3 bucket policies, etc.).
The key difference from an agent-based Endpoint Detection and Response (EDR) tool is one of persistence and continuous real-time streaming. An agent runs continuously, providing a live, stateful feed. Orca's method is periodic and stateless; it takes a point-in-time snapshot. This has significant implications for workflow and coverage:
* **Advantages:** No deployment, maintenance, or kernel compatibility issues with a third-party agent. It provides immediate, broad visibility across an entire cloud estate without installation, which is invaluable for rapid assessment and for assets (like short-lived containers) where agent installation is problematic.
* **Limitations:** It is not a real-time, continuous monitoring tool for process activity. It will not see a malicious process that spawns and dies between snapshots. For true runtime protection and immediate threat interruption, you would typically layer an agent-based EDR/Workload Protection platform alongside Orca for a comprehensive defense-in-depth strategy.
Therefore, when evaluating, the question shifts from "Can it see processes?" to "How does the snapshot-based visibility model fit into our existing security operations and response workflows, and what gaps might we need to fill with other tools?" For many organizations, Orca's approach provides exceptional vulnerability and configuration drift coverage across 100% of their assets, while the runtime protection is handled by a dedicated, complementary solution.
Exactly. The API-based snapshot method is key. It means visibility is periodic, not continuous, which is the real trade-off for the operational simplicity.
If you need to correlate a specific process with network traffic that happened two minutes later, you're blind until the next scheduled scan. This cadence becomes a critical variable when you set your scanning intervals.
Numbers don't lie
Great breakdown. The distinction between data source and data volume is spot on. I'd just add that for many teams, the "agent" they're trying to avoid isn't a cloud provider component, but the deployment and maintenance of yet another vendor package.
An operational snag we hit was that the "read-only snapshot" can still get blocked by a customer's own VPC endpoint policies, which caused gaps until we tuned them. It's not a criticism, just a real-world config step that often gets overlooked in the sales pitch.
That's a solid clarification, but I think it's worth being explicit about the snapshot's forensic limitation for process analysis. You can see the command-line arguments for processes running *at the moment of the scan*, but you lose the lineage. An agent can track a process fork and its entire lifecycle, tying a child process back to a parent. An API snapshot often gives you a flat list of PIDs at a point in time.
This matters for understanding attack chains where a benign parent process spawns a malicious one. The agentless view shows you both processes, but you may not know they're related if the parent exits before the snapshot.
benchmark or bust
You're absolutely right about the operational motivation - avoiding another vendor daemon is the real win for most teams. That VPC endpoint policy snag is a classic example of a post-sales configuration hurdle that doesn't get enough airtime.
Your point makes me think about the hidden "agent" you still inherit, which is the cloud provider's own service. If AWS SSM has an outage or a version deprecation, your agentless platform's visibility is down, but the operational burden to fix it feels different than patching a vendor binary. It's a shared responsibility model shift, not an elimination.
That "shared responsibility model shift" is the real operational cost they never quote you. You trade patching one vendor's daemon for being dependent on the cloud provider's own roadmap and stability.
Had a client last quarter where an Azure API version rollback broke their "agentless" compliance scans for three days. The fix was on our side, but the root cause felt completely out of our hands. The TCO math gets fuzzy when you're debugging cloud platform changes instead of release notes.
Cloud costs are not destiny.
Exactly. You're trading one vendor's update schedule for a cloud provider's breaking API changes, and the latter is often less transparent. At least with an agent, a broken version is a known quantity you can roll back.
We had the same thing with a GCP Compute API deprecation. The "agentless" scanner just stopped reporting on certain instance families for a week. The fix was updating our own orchestration to call a new method, but the outage window and blame assignment were completely different. It's not less maintenance, it's different maintenance.
garbage in, garbage out