The Atlas take.
Upwind’s appeal is a runtime-led explanation of cloud risk: connect what is deployed to what an application actually does, then use that context to investigate and prioritize. Its public documentation distinguishes agentless cloud scanners from the runtime Sensor, which is a useful starting point for an honest evaluation. Atlas would verify both layers on one representative application before extending the platform’s broad CNAPP claims across an estate. Sensor coverage, application identity, scanner permissions, and a reproducible owner handoff matter more than a visually rich topology. Runtime context should refine a risk judgment, not make unobserved workloads disappear from consideration.
02 / DEFINE THE BOUNDARY
What you are actually evaluating.
This profile covers the documented CNAPP approach, including agentless assessment and separately deployed runtime sensors. Verify platform and workload support in a lab; marketing claims about detection speed or reduced noise are not independent performance evidence.
03 / THE CONTROL PATH
Where it sits. How it works.
Cloud scanners provide static asset observations and Sensor components provide runtime context; the platform relates them to application and risk workflows.
- 01
Cloud scanners and integrations
Supported in-account scanners assess workload storage and other cloud resources through provider-specific onboarding.
- 02
Runtime Sensor
A separate workload component supplies behavior and application context; Kubernetes installation uses a DaemonSet by default.
- 03
Contextualized investigation
Teams relate static and runtime evidence to an application owner, a controlled response, and reassessment after change.
04 / WHAT EARNS ITS PLACE
Strengths, with the evidence attached.
Atlas analysis of documented capabilities; availability and behavior depend on the edition and environment.
Collection layers are explicitly distinguished
The CNAPP documentation separates agentless discovery, runtime sensing, application context, data security, and AI-related layers.
Scanner placement is documented
The cloud-scanner guide describes in-account scanning and supported providers, helping evaluators inspect resource and data-processing boundaries.
Inspect the documented capability notes
- Agentless scanning contributes cloud configuration and workload assessment information where supported.
- Runtime sensors and eBPF-related detection provide live behavior and workload context on supported deployments.
- The platform describes combined posture, workload and AI-related inventory capabilities, with scope dependent on the selected integration and sensor.
05 / KNOW THE COMPROMISES
The tradeoffs to take seriously.
Architectural implications and procurement questions from Atlas; these are not independently measured product failures.
06 / FROM PURCHASE TO PRACTICE
Make it work in your environment.
A proposed implementation sequence. Confirm supported versions, permissions, and rollback with the current documentation.
- 01
Map one application’s evidence paths
List its cloud resources, workload nodes, scanner coverage, Sensor placement, and responsible application team.
- 02
Deploy with controlled credentials
Follow the documented secret-handling and installation path; restrict access to deployment credentials and verify outbound connectivity.
- 03
Test change and collection failure
Repeat the investigation after a workload rollout and a deliberate disconnected component, preserving the resulting visibility gaps.
07 / THE OPERATING COMMITMENT
The bill is only part of the cost.
Commercial shape
Obtain a quote that names the required platform modules, protected populations, runtime components, and cloud-scanner deployment. Public technical documentation does not establish a complete price or universal counting rule.
- Quoted cloud and workload populations plus selected capabilities
- In-account scanner infrastructure and runtime component resources
- Deployment engineering, support, investigation retention, and policy maintenance
08 / COMPARE THE JOB
Put these beside it.
Alternatives worth examining for the same problem. Check each offering’s scope before treating it as a substitute.
Sysdig
Compare Linux and Kubernetes instrumentation, metadata, and runtime-policy operations against the same workload and acceptance evidence.
Orca SecurityOrca Security
Compare an agentless-first platform with a separately scoped runtime Sensor when out-of-band workload assessment is a primary requirement.
09 / MAKE THE DECISION OBSERVABLE
Earn confidence through a real evaluation.
Suggested by Atlas. Agree acceptance criteria, use synthetic fixtures in an authorized environment, and capture both useful work and failed controls.
- TEST 01
Join static and runtime evidence
Acceptance evidence: Use a harmless vulnerable lab component and a legitimate application request; trace both to the same workload and owner without assuming observation proves exploitation.
- TEST 02
Verify Sensor coverage after rollout
Acceptance evidence: Compare Kubernetes node and workload inventory with Sensor health before and after a deployment change.
- TEST 03
Demonstrate a collection gap
Acceptance evidence: Disconnect a lab Sensor or scanner and show the health signal, missing evidence, investigation limitations, and recovery after reconnection.
START WITH ONE EXERCISE
Run a documented harmless process or network event on an isolated, instrumented workload while maintaining a known inventory of uninstrumented controls.
Evidence to look for: The event is attributed to the correct workload, sensor health is visible, and the report clearly distinguishes observed assets from coverage gaps.
Questions to bring to the vendor
- Which kernels, workload types and managed services support the required runtime behavior?
- How is an absent or unhealthy sensor distinguished from an application with no detected activity?
- Which AI inventory or posture functions are actually available, and do they inspect behavior or only describe deployed resources?
10 / SHOW THE WORK
Evidence, and what is still unknown.
What this research cannot establish
- No independent detection, noise-reduction, sensor-overhead, or prioritization benchmark was conducted.
- Exact provider and workload support, response behavior, entitlements, and data-retention terms must be validated for the proposed deployment.
Dossier research reviewed October 18, 2026. Earlier profile references are retained for traceability; products and commercial terms change.
- Upwind CNAPP architecture and collection layers ↗Documentation
- Upwind Cloud Scanners architecture ↗Documentation
- Upwind Kubernetes Sensor installation ↗Documentation
KEEP BUILDING YOUR JUDGMENT