Posture told you what could happen. Runtime tells you what is.

A decade of cloud posture tooling taught enterprises to manage a backlog instead of a risk surface. Runtime context collapses that backlog to what is actually executing and actually reachable, and with AI agents in production, it stops being an architectural preference.

A backlog is not a security posture

Ask a cloud security team how many open findings they have. The number will be in the thousands, and the person telling you will say it with a shrug. Ask how many of those findings represent something an attacker could actually reach and exploit today, and you will get a pause. Not because the team is careless, but because the tooling was never built to answer that question.

This is the quiet failure of the posture era. We spent a decade building systems that are very good at telling you what is theoretically wrong with your cloud, and almost none that can tell you what is actually happening inside it. Those are different problems. We have been solving the first one and reporting it as progress on the second.

What a configuration snapshot cannot see

The posture generation of cloud security was a real advance. CSPM connected to your cloud APIs, read the configuration, compared it against a policy library, and produced findings. Agentless scanning made it painless to deploy: no software on the workload, no argument with the platform team, coverage in an afternoon. For an industry that had spent years fighting over agent installs, this was a genuine relief.

But look at what it actually sees. A configuration snapshot describes what your environment could permit. It is not an observation of what your environment is doing. A container image with a critical CVE in a library that no running process ever loads is, in the posture model, a critical finding. So is one in a library that is loaded, internet-reachable, and running with permissions to your production database. The scanner ranks them the same, because from the outside they look the same.

Multiply that across a real environment and you get the artifact every cloud security team recognizes: a backlog nobody can finish, prioritized by a severity score that has no idea what your business is. Teams then do the rational thing and start ignoring it, at which point the tool has quietly stopped being a security control and become a compliance record.

Upwind's founders did not arrive at this from a security background. They arrived as the people being scanned. After NetApp acquired their previous company, Spot.io, for roughly $450 million in 2020, CEO Amiram Shachar spent time inside a large enterprise on the receiving end of exactly this problem.

One sensor, one source of truth

The word runtime gets used loosely enough to be meaningless, so here is the concrete version. Upwind deploys an eBPF sensor into the workload. eBPF is a facility in the Linux kernel that allows safe observation of process execution, system calls, network connections, and file access without modifying the kernel and without the performance cost that made the previous generation of agents so unwelcome. It is not a scanner running on a schedule. It is a continuous, live view of behavior.

That view changes the arithmetic. When the platform can see that a vulnerable package is never loaded into memory, it drops down the list. When it can see that a package is loaded, in a container that is internet-facing, running as a role with write access to a production bucket, it surfaces that one finding and shows you the path. Same two CVEs, same CVSS score, completely different answer, and the difference came from observation rather than a heuristic.

The architecture also collapses a category. Upwind runs application security, posture, and realtime protection off the same runtime fabric: IaC and supply chain security, CSPM, CIEM, DSPM, AI-SPM, vulnerability management, container and Kubernetes security, API security, attack surface management, and cloud detection and response. That is a dozen product categories that used to mean half a dozen vendors, each with its own console and its own version of the truth. Consolidating them is not primarily a procurement win, though it is that too. It is that every one of them gets better when they share a single source of live context, because prioritization is only as good as the evidence underneath it.

The honest question: I already own a CNAPP. Why does this change?

This is the objection we hear most, and it deserves a straight answer. Most enterprises already bought a cloud-native application protection platform. The category is mature, the incumbents are large, and nobody is enthusiastic about replacing a platform they finished rolling out eighteen months ago.

The answer starts with a distinction the market keeps blurring.

Most incumbent platforms were architected agentless-first, then added runtime as a module: a second sensor, a second data model, a second console, bolted onto a system whose prioritization logic was already built to run without it. Coverage is broad and the findings are real. But runtime arrives as an input to a scoring engine rather than the foundation the engine was designed around, which is why the backlog persists after deployment.

The second issue is where this is heading. Ephemeral infrastructure has no meaningful configuration state to snapshot. Containers, serverless functions, and now AI agents calling tools and each other exist only while they run. The interesting behavior only exists at execution. A platform that treats runtime as a module will keep treating the fastest-growing part of your environment as an edge case.

The choice is not necessarily rip and replace. For many teams it is deciding which layer becomes the source of truth for prioritization, and doing that deliberately, before the AI stack forces the question.

Your AI agents are workloads, and nobody is watching them

Here is where the posture model does not merely underperform. It stops applying.

An AI agent is not a static asset. It is a process that makes decisions at runtime, calls tools, invokes models, reads data it was pointed at, and hands off to other agents. A configuration snapshot of that system tells you close to nothing, because everything consequential about it happens in execution. What did it actually call? What data did it actually touch? Which other agent did it hand off to, and was that handoff supposed to exist? There is no posture equivalent of those questions.

In June, Upwind was named a launch partner for Cisco Cloud Control Studio at Cisco Live, connected through the Model Context Protocol so its live cloud and AI runtime intelligence surfaces directly inside Cisco AI Canvas. Concretely, that means security findings, vulnerability data, API telemetry, and AI visibility all land in the operations environment teams already work in, instead of one more tab. The AI visibility includes communication paths between agents, model usage, and suspicious interactions.

Read that as a signal about the category. The infrastructure vendors building the agentic operations layer had to choose someone to supply runtime truth about AI workloads. They chose the company whose entire architecture is runtime observation.

What Upwind customers report

What this says about how to buy security

Step back from Upwind, because there is a pattern here worth naming. The security categories that consolidate are the ones where a single architectural decision makes every downstream product better. Runtime context is one of those decisions: it improves vulnerability management, posture, detection, and AI visibility simultaneously, because all four were bottlenecked on the same missing evidence.

The categories that do not consolidate are the ones where vendors bolt adjacent features onto a core that was not designed for them. Those platforms grow feature lists without getting better at the job. Telling the two apart before you sign is most of the skill in buying security software.