Customer Snapshot
| Attribute | Details |
|---|---|
| Industry | Healthcare (fertility / IVF) |
| Cloud Environment | AWS |
| Workloads | Docker containers running on EC2 instances |
| Code & CI/CD | GitHub, GitHub Actions |
| IAM Profile | 10–15 users with AWS console access |
| Team | CISO-led, no dedicated security engineering function |
| Code Origin | Partner-developed applications + AI-generated code (Cursor/GPT) |
| Primary Interest | Runtime protection for applications they did not build |
| Cloudanix Scope | CWPP (container + host runtime), CSPM |
The Situation: Protecting Applications at Runtime When You Have No Runtime Visibility
Posture scanning tells you what could go wrong. It does not tell you what is happening right now inside a running container or on the host beneath it. For this healthcare provider, that gap was the concern that kept the CISO up at night.
The organisation ran its patient-facing and internal applications as Docker containers on EC2 instances in AWS. The applications had been built by an external development partner, and more recently the team had started generating code with AI assistants. In both cases, the code was in production and functioning, but nobody on the customer side had deep visibility into what those workloads actually did once they were running: which processes they spawned, which files they touched, which outbound connections they opened, and whether any of that behaviour was normal or the early signature of a compromise.
The CISO’s framing was direct, and it is a question container runtime security exists to answer. “We can scan the code and we can scan the cloud config. But once the container is live and serving patient data, what is watching it? If the partner’s app or the AI-generated code has a flaw that gets exploited at runtime, how would we even know?”
For a lean team with no dedicated security engineers, this was not a theoretical exercise. They had no way to detect a container that suddenly started a crypto-miner, a process that spawned a reverse shell, or a workload that began reading files it had never touched before. Runtime was a blind spot, and it sat directly on top of protected health information.
The Priority: Workload Protection, Explicitly
Among the requirements the team raised, workload protection was called out on its own: they wanted assurance that the running applications were safe, not just that the code and configuration looked correct on paper. That maps to a specific capability category, Cloud Workload Protection (CWPP), and it comes with a specific trade-off that we were upfront about.
Unlike posture management, which Cloudanix performs agentlessly through a read-only role, meaningful runtime protection requires an agent on the workload. There is no agentless way to see, in real time, the processes and syscalls happening inside a running container or on its host. The team accepted this readily; runtime visibility was exactly the value they were asking for, and an agent is the honest cost of getting it.
Where the Gaps Were
1. No Runtime Detection Inside Containers
The Docker containers ran with no runtime security layer. If a partner-built application contained a vulnerability that was exploited in production, the resulting behaviour, an unexpected process, an outbound connection to an unknown host, a file modification in a sensitive path, would happen entirely unobserved. Posture tools do not see this; the difference between posture and workload protection is exactly this runtime blind spot. Neither do the AWS native services the team already had.
2. No Host-Level Visibility Beneath the Containers
Containers share the host kernel. A container escape, a compromised host process, or tampering with the EC2 instance itself would not necessarily show up as a container-level event. The team had no host-level runtime monitoring, meaning the layer that all their containers depended on was itself unwatched.
3. Unknown Behavioural Baseline for Unfamiliar Code
Because the applications were partner-built and AI-generated, the team did not know what “normal” looked like for them. Without a behavioural baseline, even a security-aware engineer would struggle to distinguish a legitimate application action from a malicious one. This is precisely the problem runtime protection with behavioural profiling is designed to solve.
4. A Lean Team That Cannot Watch Dashboards All Day
With a CISO leading and 10–15 console users, nobody had the bandwidth to monitor a runtime feed continuously. Any runtime protection had to surface high-confidence, prioritised alerts, not a firehose of raw events that a small team would inevitably start ignoring.
The Cloudanix Solution
Agent-Based Runtime Protection for Containers and Hosts
Cloudanix Workload Protection deploys a lightweight agent to the EC2 hosts running the Docker workloads. The agent provides runtime detection at two layers that mattered directly to this provider:
- Container runtime: Monitoring process activity, file access, and network connections inside each running container, so an exploited application surfaces as a detectable behavioural anomaly rather than an invisible event.
- Host-level runtime: Watching the EC2 host beneath the containers, catching activity that never appears at the container layer, such as host process tampering or container-escape behaviour.
For a team whose entire application estate was code they did not write, this two-layer coverage was the point: whatever the partner or the AI assistant put into production, its runtime behaviour is now observed at both the container and the host it runs on.
Behavioural Detection for Code You Don’t Fully Understand
Because the team could not define “normal” for their unfamiliar applications, the runtime layer does it for them. It establishes behavioural expectations for the workloads and flags deviations, an application container that suddenly spawns a shell, initiates an unexpected outbound connection, or accesses a file path outside its usual pattern. This turns “we don’t know what this code does” from a permanent liability into a monitored, alertable surface.
Posture and Runtime, Correlated in One Platform
The runtime agent does not operate in isolation. It sits alongside Cloudanix CSPM, which connects agentlessly to the same AWS environment via a read-only role. This means a runtime detection is not just an isolated alert; it carries the context of the workload’s configuration. A suspicious process inside a container that is also running under an over-permissioned IAM role and exposed through a permissive security group is a very different priority than the same process on a well-isolated workload. Cloudanix connects those layers rather than leaving the team to correlate them manually.
Prioritised Alerts, Not a Firehose
For a lean team, signal quality is everything. Cloudanix surfaces runtime findings as prioritised, high-confidence alerts with the workload context attached, and routes them to where the team already works. The goal is that a CISO and a handful of console users can act on what matters without babysitting a dashboard, precisely the operating model this organisation needed.
Preparing for the Kubernetes Migration
The provider planned to move from Docker-on-EC2 to Kubernetes in the near term. Because Cloudanix workload protection is agent-based, the migration is not a re-tooling exercise, it is a re-deployment of the same protection model onto the new runtime. Kubernetes/EKS runtime coverage is generally available, and onboarding a cluster is a single command that installs the agent across the workloads. The behavioural detection, the container and host-level coverage, and the correlation with posture all carry into the EKS environment. The team keeps the same runtime security model before, during, and after the migration.
Platform Impact
2 runtime layers Container + host on every EC2 workload | Agent-based The honest cost of real-time visibility | Behavioural baselines For code the team didn’t write | K8s-ready Same model, one-command EKS onboarding
The Bigger Picture: Posture Tells You What Could Happen, Runtime Tells You What Is Happening
There is a persistent assumption that scanning code and cloud configuration is enough. It is not. Posture management reduces the attack surface, but it cannot see an exploit as it executes. For an organisation running applications it did not build, on infrastructure it must nonetheless secure, the runtime layer is where a compromise actually becomes visible.
The trade-off is real and worth stating plainly: runtime protection needs an agent. Agentless posture is a convenience; runtime detection is a capability that requires being on the workload. For this provider, that trade-off was easy, because the alternative was continuing to run patient-data applications with no idea what they did once live.
The Outcome
The provider moved from zero runtime visibility to continuous, agent-based detection across both their containers and the hosts beneath them. The applications they had inherited from a partner and the code their AI assistants generated are now observed in production, with behavioural baselines flagging the deviations that isolated posture scans would never catch. And because the protection is agent-based, the upcoming Kubernetes migration extends the same model with a single onboarding command rather than a new tooling decision.
Key Results
✅ Container Runtime Protection: Process, file, and network activity monitored inside every Docker container.
✅ Host-Level Runtime Protection: The EC2 host beneath the containers watched for tampering and escape behaviour.
✅ Behavioural Baselines: Deviations flagged for partner-built and AI-generated code the team didn’t fully understand.
✅ Posture + Runtime Correlation: Runtime alerts carry the workload’s configuration context via CSPM.
✅ Lean-Team Friendly: Prioritised, high-confidence alerts routed to where the team works.
✅ Kubernetes-Ready: Agent-based model extends to EKS with one-command onboarding.
Running Applications You Didn’t Build on Containers Nobody Is Watching?
Posture scanning shows you the misconfigurations. Cloudanix Workload Protection shows you what your containers and hosts are actually doing at runtime, so an exploited application surfaces as an alert instead of an incident. Agent-based, container and host-level, and ready for your move to Kubernetes.
Book a Free Assessment to see your workloads through Cloudanix.
Related Resources
- Cloud Workload Protection (CWPP)
- What is CSPM (Cloud Security Posture Management)?
- Runtime Security for Docker Containers Deployed Directly on VMs
- Container Security and Real-Time Visibility for Modern Cloud
- Securing Healthcare Applications Built by Partners and AI
- CSPM for ECS-Heavy AWS Workloads: Small Team, Multiple Accounts
