The Shared Responsibility Model is the most successful marketing campaign in the history of cybersecurity. It is also a convenient fiction. We’ve been trained to believe that if we just trust the "Layer Zero" providers—the Microsofts, the AWSs, and the Entras of the world—the foundation of our stack is inherently secure. But as we move deeper into the age of sovereign infrastructure, an uncomfortable truth is emerging: these providers are architecturally incentivized to keep their security controls shallow.
This is the Layer Zero Paradox. The entities best positioned to solve security are the ones least incentivized to do so with the granularity required by the modern enterprise.
The Phenomenon: Structural Shallowing
In the collision space between infrastructure and defense, we are witnessing "Structural Shallowing". This is the process where foundational providers build security features that are "good enough" for 80% of the market but fail at the edge cases where real damage occurs.
Why? Because Layer Zero optimizes for reliability, scale, and economics. Security, by its very nature, is an act of principled friction. It is the implementation of "no" in a system designed to say "yes" to as many transactions as possible. When a cloud provider adds a deep security control, they aren’t just adding a feature; they are adding a potential failure point for their core product. If a security toggle breaks an application, the customer doesn't blame their security policy—they blame the cloud provider.
Consequently, foundational providers build toggles, not depth. They give you a "Log Everything" button that produces a firehose of telemetry, but they rarely provide the tools to differentiate the signal from the noise within their own interface. To go deep is to increase the support burden, and for a Layer Zero player, support is a cost center that doesn't scale.
The Monopoly on Visibility
The danger of Structural Shallowing is compounded by the fact that Layer Zero players have a natural monopoly on the most critical telemetry. An identity provider (IdP) sees every authentication event. A cloud provider sees every VPC flow. An OS vendor sees every kernel call.
When these providers offer "Security as a Feature," they leverage this visibility to create a walled garden. They argue that because they have "unique signals," their native security tools are superior. However, this is a strategic misdirection. While they have the signals, their internal telemetry is often siloed from the operational reality of the business.
As argued in this Ross Haleliuk analysis, for everyone except the foundation, delivering security becomes a negotiation with the underlying layer. When you rely solely on native tools, you aren't just trusting their security; you are outsourcing your ability to negotiate with your own infrastructure.
Principled Friction as a Service
If Layer Zero provides the "naked" infrastructure, the role of the modern security team is to implement Principled Friction. This is the specialized layer of defense that the foundation cannot, or will not, provide.
We see this repeating in every architectural shift. With the rise of the browser as the new OS, we saw the explosion of Browser Security Platforms. These didn't replace Chrome or Edge; they added the "high-integrity friction" (like granular data loss prevention and contextual access) that Google and Microsoft are architecturally prohibited from building into the browser itself without breaking the global web experience.
The market for specialized security vendors isn't a sign of inefficiency. It is the inevitable response to the Structural Shallowing of the foundation.
The Red Team Perspective: Living off the Foundational Land
From an adversarial standpoint, Structural Shallowing is a gift. Attackers have learned to "live off the foundational land," exploiting the very configurations that Layer Zero providers keep "open" by default to ensure ease of deployment.
The Red Team doesn't need to find a 0-day in the cloud's hypervisor if they can find a "recommended configuration" that prioritizes connectivity over isolation. The failure point isn't the code; it’s the "Least Friction Default". When every security control is a toggle that a junior admin can flip for "troubleshooting," the foundation isn't a fortress—it's a sieve.
Concrete Recommendations
To navigate the Layer Zero Paradox, security practitioners must stop treating native security features as a complete solution and start treating them as raw materials.
- Audit for "Least Friction" Defaults: Conduct a thorough review of your foundation (IdP, Cloud, OS) specifically looking for features where the provider has prioritized "connectivity" over "security." These are your primary blind spots.
- Implement "Layer One" Overlays: Do not rely on native tools for critical visibility. Use third-party telemetry overlays (like CSPMs or Browser Security Platforms) that are architecturally independent of the infrastructure they monitor. This maintains your ability to "negotiate" with the foundation.
- Trust, but Verify via External Telemetry: If your IdP says an account is secure but your external network monitor shows anomalous traffic, trust the external monitor. Native tools are prone to "confirmation bias" in favor of the provider’s own infrastructure.
- Demand Granularity over Bundles: When evaluating Layer Zero security features, ask for the underlying API access, not the shiny dashboard. If you can’t get the raw data out into your own "Principled Friction" layer, you don't own the security—the foundation does.