Your Cloud Posture Tool Can Do More Than Yell About Compliance
In this blog
A cloud security posture management (CSPM) tool gets bought. Good call. It gets connected to the primary cloud account, maybe a second provider too. The first scan spits out 10,000 findings. Critical. High. Medium. A wall of red and orange, screaming for attention.
Then comes the move nearly every team makes. Findings get filtered down to the compliance frameworks the auditors care about: System and Organization Controls 2 (SOC 2), the Payment Card Industry Data Security Standard (PCI DSS) and the Health Insurance Portability and Accountability Act (HIPAA). Enough gets fixed to pass, and the work is called done.
Congratulations. That is a sports car being used to get groceries.
One naming note first, because it affects what can actually be turned on.
Nobody sells a standalone CSPM tool anymore. The product on offer is a CNAPP (Cloud Native Application Protection Platform), and cloud posture is one function inside it, sitting next to workload protection, identity posture, Kubernetes posture, data posture and now AI posture, all feeding one graph. The CSPM label will likely disappear entirely. The more useful read is that posture management became the control plane, the part that decides which of the 10,000 findings gets a human.
Why it matters: half the capabilities covered below live in a CNAPP tier. If deep runtime analysis is missing from the console, it may not simply be buried in a settings menu. It may be a line item that was never purchased. That is worth confirming before a week disappears into hunting for a button.
The compliance trap
It has been said that compliance is not security. Fine. Here is the version nobody says out loud.
The frameworks are not the problem anymore. They got better. Auditors ask harder cloud questions than they did three years ago. The problem is that the attack surface grew an entire category the frameworks have no language for, and a passed audit produces a document that is silent on it. Nothing in SOC 2 asks how many agents in the environment hold long-lived cloud credentials, or who owns them, or what they can reach. The audit will pass. The question will still be unanswered.
But attackers don't care about a compliance score.
Nobody gets breached because a control ID went red. Breaches happen because a chain of small, individually boring problems lines up into a path: a permissive role here, an exposed service there, a trust relationship nobody remembered and something valuable at the end of it. A benchmark report scores each link. It does not say they connect. That is the gap, and no amount of passing turns it into coverage.
The CNAPP already knows about those paths. But when it is used only to chase green checkboxes on a compliance dashboard, the point is missed entirely.
The cool stuff that usually gets ignored
Modern CNAPP tools do far more than compliance checking. Here is what gets left on the table.
Attack path analysis. This is the big one. Instead of presenting 10,000 individual findings, good CNAPP tools show how those findings chain together. A public storage bucket? Annoying but maybe not critical. A public storage bucket connected to an identity and access management (IAM) role that can reach a production database? Now it gets serious.
Attack path analysis answers the question that actually matters: "If someone got in here, how far could they go?" The paths that lead to the crown jewels get fixed first. The rest can wait.
Risk prioritization that makes sense. Not all misconfigurations are equal. An open security group on a dev instance with no data is not the same as an open security group on a payment processing system. Context matters.
Done properly, this does not trim the 10,000 findings. It reorders them, and the top of the list gets short enough that a human can work it. No target number is promised here, because anyone who quotes a reduction ratio is quoting a demo environment. The only number that means anything is the one produced by running it against the real environment.
Runtime context. Static scans show what is misconfigured. Runtime analysis shows what is actually happening. That overprivileged IAM role? Has it ever used those permissions? If not, it may be lower priority. If it is used constantly, it deserves a closer look.
Most CNAPP tools now offer runtime sensors that watch live behavior and correlate it with configuration issues. That is where findings turn into real intelligence.
Drift detection. The misconfiguration got fixed. Great. Someone changed it back three weeks later. Less great.
Drift detection reports when security posture changes. Not just "here is what is wrong today" but "here is what changed since yesterday." That is how well-meaning engineers accidentally opening holes get caught, along with malicious actors quietly adjusting permissions.
Kubernetes posture, which is its own surface. A cluster is not a workload in a cloud account. It is a second control plane with its own identities, its own network policy, its own admission decisions and its own set of ways to be wide open. Most posture programs discover this when somebody finds a service account bound to cluster-admin because a Helm chart wanted it in 2023. When a tool covers Kubernetes security posture management (KSPM) and the capability goes unused, that is the highest-value switch left unflipped in the console.
Data posture, because prioritization is a lie without it. An open security group on a dev box is not the same as one on payment processing, and that judgment requires knowing what data sits where. Deciding it from tags and instance names is guessing. Data security posture management (DSPM) is how the guessing stops. Some CNAPP tools offer their own DSPM capabilities, while others integrate with point tools to pull that classification data into the platform. Either route can work, depending on the environment.
The nodes attack path analysis cannot see
Attack path analysis answers one question: where can this get to? It answers it by walking a graph of resources, identities, exposures and data.
Which means it is only as honest as the graph. And in 2026 the graph may be missing a whole class of identity.
Non-human identities now outnumber humans in the enterprise by roughly 45 to 1, and agents are pushing that ratio every quarter. Most of them were not provisioned by the identity team. Somebody wired an agent into a software as a service (SaaS) app or a cloud service and minted an application programming interface (API) key, an OAuth token or a service account to make it work, outside any review. Industry research found that 97% of non-human identities carry excessive privileges, and H1 2025 data showed more than 5.5% of Amazon Web Services (AWS) machine identities holding full admin rights. Only 14% of organizations have fully automated the creation and removal of AI identities. The rest have a spreadsheet and optimism.
Every one of those is an edge the legacy tools never drew. So when a platform reports that a dev instance can only reach other dev instances, it is not lying. It is answering correctly about a graph that does not see the full picture.
This is not theoretical. In 2026, Google Threat Intelligence Group (GTIG) documented a suspected financially motivated actor who got into an organization's cloud, deployed a multi-agent framework inside that environment so attack traffic came from legitimate IP addresses, and planned, built and executed a mass credential harvesting operation in under six hours. In a separate case, GTIG found an exposed command-and-control server whose live dashboard was validating more than 23,800 harvested secrets, including cloud and AI service API keys. Not a novel exploit. Cloud access, an agent and speed.
Three things a CNAPP can help with:
Get agents into the identity inventory before trusting any path analysis. An unknown identity is an undrawn edge, and an undrawn edge is a path the tool says does not exist. A sensible start is asking every team that shipped an agent this year what credential it authenticates with. The answers tend to be worse than expected.
Treat credential lifetime as a posture finding, not an IAM chore. A 2025 SaaS supply chain incident settled this argument. One integration's stolen OAuth tokens let an attacker export data from numerous corporate customer relationship management (CRM) instances. That was not a misconfiguration. That was an identity with too much reach and too long a life. Most tools can find long-lived keys today, and the search is worth running.
Put Model Context Protocol (MCP) servers on the map. The major cloud and security platforms shipped posture management for AI agents, models and MCP servers this year (Microsoft Defender, for example, now inventories agents with their tools, identities and MCP servers), and extended attack paths to AI assets and agent identity governance. That is the industry saying these are posture objects now. Running the earlier question against an MCP server is revealing. Where can this get to? A server bridging an agent to production databases and internal tooling, holding credentials broader than any single user, produces an answer nobody will like. That is the point.
Agents are infrastructure. They have identities, permissions and reach. Right now most of them sit outside the graph used to make decisions.
Getting more from what is already in place
A new tool is probably not needed. The existing one needs to be used differently.
Stop chasing green dashboards. A 95% compliance score means nothing if the 5% includes an admin backdoor. The thinking has to flip: instead of "how do we get more green," the question becomes "what is the worst thing that could happen with what is red?"
Focus on exploitable paths, not individual findings. Teams need to think like attackers. When a finding pops up, the first question isn't "how do we fix this?" It's "what could someone do with this?" If the answer is "not much," it can wait. If the answer is "get to production data," everything else stops.
Connect CNAPP to the actual threat model. What is the real worry? Data exfiltration? Ransomware? Cryptomining? CNAPP findings should feed those concerns. A finding that enables a top threat scenario gets fixed first. A finding that is theoretically bad but doesn't map to real risk gets queued.
Weekly reviews used to be the floor. That floor is gone. The agent-driven credential harvesting campaign GTIG documented in 2026 went from initial cloud access to thousands of stolen credentials in under six hours. A weekly cadence means that operation finishes, exfiltrates and gets tallied on somebody's dashboard about twenty-seven times before the next review meeting.
So: continuous detection, with alerting on the handful of changes that alter an attack path, and a human review cadence for everything else. And push it into the pipeline. Not if the team is mature enough. Catching a permissive role in a pull request costs minutes. Catching it in production costs an incident.
Making it earn its keep
CNAPP tools aren't cheap. The good ones cost real money. They should be made to work for it.
Set up attack path analysis and actually review it. Build custom policies for the risks specific to the environment, not just the generic compliance frameworks. Integrate the findings into the ticketing system so they get fixed, not just reported. Measure mean time to remediation, not just the number of findings.
And if a CNAPP tool can't do this? Maybe it's time to look at what else is out there. The market has matured. Tools that just do compliance checking aren't keeping up.
Bottom line
What has been treated as a CSPM tool is probably a CNAPP, and it is smarter than it is being allowed to be. It can show attack paths, prioritize real risk, track drift and provide runtime context. But only when it is used that way.
Compliance is table stakes. It gets a seat in the game. But the cloud security that actually stops breaches comes from understanding how an attacker would move through an environment and shutting those paths down.
Green is not the goal. Thinking like a threat actor is.
The CNAPP can help. It only has to be allowed to.
Make a new world happen, the secure way.
Part of the WWT AI Agent Gateway series. Contact the WWT Security Practice to learn more about ARMOR, the WWT AI Readiness Model for Operational Resilience.