Question 1

What's the difference between active defense and CSPM?

Accepted Answer

CSPM, or cloud security posture management, scans your cloud environment for misconfigurations and surfaces them as findings. It tells you what's wrong, one resource at a time: this S3 bucket has an API flag that exposes it, that role is over-permissioned. The operating model is find the problem, triage it, remediate it, repeat. That loop has real value, but it works at the level of individual resources, and it doesn't address the architectural conditions that let the problem exist in the first place. By the time a finding surfaces, the misconfiguration has already been there, sometimes for weeks, and someone's queue gets longer.
Active defense works at the level of principles, not resources. Instead of scanning for what went wrong, Native enforces the architecture that prevents the problem from occurring. You declare a principle, like “nothing in the regulated zone is reachable from the public internet,” and Native enforces it through the primitives your cloud providers already ship. Where CSPM would flag one exposed bucket, then the next, then the next, the principle closes the whole class at once. Define that data can't leave a region, that non-production can't reach production, or that AI can only use approved models, and the condition that would've generated the finding never occurs.
The two don't map cleanly onto each other, and that's the point. Whole domains Native enforces have no CSPM equivalent: third-party access perimeters, segmentation between production and non-production, region restrictions, AI architecture controls, blast radius containment. These aren't misconfigurations a scanner can flag, they're architectural decisions enforced at the control plane. And plenty of findings don't trace back to a single principle either. That asymmetry is why “preventive security,” the term the market is reaching for, undersells this: it implies everything reduces to stopping a finding. Active defense is more precise. Native enforces the architecture you intend to run, continuously, across every provider, including the controls no scanner will ever flag.

Question 2

Do I still need a CSPM or CNAPP tool if I'm using Native?

Accepted Answer

Most organizations run both, and they're built to complement each other rather than overlap. CSPM and CNAPP tools excel at finding and prioritizing risk that already exists in your environment. Native prevents new risk from being introduced in the first place.
What you'll notice over time is that the volume of findings your CSPM surfaces starts to shrink, because Native enforces the conditions that prevent misconfigurations from occurring. Entire categories of findings, the ones that stem from things that should never have been architecturally possible, stop appearing.
There are also control domains Native covers that CSPM and CNAPP tools don't address: third-party access perimeters, environment segmentation between production and non-production, region restrictions, AI architecture controls, and blast radius containment. These aren't misconfiguration findings. They're security architecture decisions that require enforcement at the cloud control plane, not scanning.

Question 3

What is a cloud security control plane?

Accepted Answer

A cloud security control plane is a system that sits above your cloud providers and translates your security intent into the enforcement controls they already ship. Instead of managing policies separately inside AWS, Azure, Google Cloud, and OCI, you define what must be true once, and the control plane abstracts the provider-specific implementation, handling it across all of them.
Native is the cloud security control plane. When you define a security requirement, whether it's restricting which AI services can be provisioned in a specific account, blocking data movement outside approved boundaries, or enforcing encryption at rest across all workloads, Native compiles that intent into the correct provider-native controls for each cloud: SCPs and RCPs on AWS, organization policies and VPC Service Controls on Google Cloud, Azure Policy on Azure, and many more. Native abstracts the differences between these controls into one model, so you work with intent rather than provider syntax. The enforcement runs through the providers' own infrastructure. It's not a layer built on top. It's built into the architecture.

Question 4

Why build active defense on the cloud providers' own native controls?

Accepted Answer

Because they're the only controls enforced at the provider core, underneath everything you run. Cloud providers invest enormously in security primitives. They're scalable, reliable, attested to every major compliance framework, and they can't be bypassed the way an added-on agent or scanner can. A control that lives in the provider's own infrastructure holds even against direct console access, a compromised credential, or an AI agent acting on its own. Anything bolted on top can be bypassed, disabled, or left behind when the cloud changes.Enforcing at the core also means enforcing once, not everywhere. An IaC scanner has to be wired into every pipeline to catch anything, and a large enterprise can run hundreds of them, so a single gap leaves a hole. A control enforced in the provider's own infrastructure applies across every account and workload from one place, with nothing to install downstream.
The best place to enforce your security architecture is the same place the cloud enforces everything else: its own core. So Native operationalizes these native controls rather than replacing them. The work is in authoring the right control for each requirement, operating 100+ of them across four providers as the providers keep changing, and simulating the impact before anything ships. That's what Native does.

Question 5

How does Native handle multi-cloud security without rebuilding policies for each provider?

Accepted Answer

The core challenge with multi-cloud security is that every provider has its own policy language, its own enforcement primitives, and its own implementation model. Most organizations have their strongest coverage on their primary cloud and thinner, less consistent coverage everywhere else. In practice there's almost always more that could be enforced even on the primary cloud, and the weakest provider quietly defines your real security posture.
Native solves this by separating intent from implementation. You define what must be true once, and Native compiles that intent into the correct controls for each provider. The same data perimeter definition produces SCPs and RCPs on AWS, VPC Service Controls on Google Cloud, the right Azure Policy constructs on Azure, and many more control types, without your team having to understand the differences between them. A single data perimeter can generate dozens of distinct controls on any one provider, which is exactly why separating intent from implementation matters: you express it once, and Native handles the dozens of controls underneath. When you add a new provider, you extend the existing architecture rather than rebuilding it from scratch.

Question 6

I'm on a single cloud. Do I even need Native?

Accepted Answer

Yes, and the value shows up fast. Multi-cloud is one reason teams adopt Native, but the harder problem is operating a single provider's controls well. One cloud ships 100+ security services and hundreds of new features a year, and a complete data perimeter or segmentation model on just that provider can require dozens of coordinated controls across SCPs, RCPs, network policies, and more.
Most single-cloud teams are nowhere near full coverage, not for lack of skill, but because operating these controls by hand doesn't scale. Native models your architecture, shows what's enforced versus what could be, generates the controls, simulates the impact before rollout, and keeps everything current as the provider changes. If you add a second cloud later, you extend the same architecture instead of starting over.

Question 7

How does Native secure AI agents and address AI-related cloud risk?

Accepted Answer

AI agents operating inside cloud environments present a security challenge that traditional controls weren't designed to handle. They inherit permissions from human and service accounts, they act autonomously, and their behavior is non-deterministic by design. That's the source of their value, but it's also why you can't rely on the agents themselves to stay inside safe boundaries. The risk accumulates silently, team by team, integration by integration.
Native addresses this at the architecture layer, not the application layer. Because agent behavior is non-deterministic by design, Native answers it with deterministic boundaries: limits enforced from outside the agent that hold no matter what the agent decides to do. You can define which AI services can be provisioned in which accounts, which models can be called, what data agents are permitted to access, and what actions are structurally off-limits, regardless of the permissions they inherit. Those boundaries are enforced through provider-native controls: Bedrock policies on AWS, Vertex AI restrictions on Google Cloud, Azure AI Foundry guardrails on Azure. When an agent tries to reach data or take an action outside those boundaries, the enforcement holds. It doesn't depend on the agent behaving correctly.
This also covers the inbound attack surface: restricting which AI services are publicly accessible, preventing prompt injection paths through public exposure, and ensuring training pipelines can't reach regulated data.

Question 8

How does Native support continuous compliance for PCI, HIPAA, FedRAMP, and SOC 2?

Accepted Answer

Traditional compliance works by assessing your environment at a point in time, identifying gaps, and running a remediation cycle before the next audit. The problem is that cloud environments change constantly between assessment cycles, so you're compliant enough when someone looks, but not necessarily in between.
Native maps compliance requirements to enforceable controls deployed at the architecture layer and enforces them continuously. The environment can't drift into a non-compliant state because the controls that prevent non-compliant configurations are already active at provisioning. When an exception is genuinely required, it goes through a structured approval workflow with a documented justification and an expiration date, so it doesn't quietly become permanent.
The practical effect on audit preparation is significant. Instead of a multi-month project to gather evidence, produce reports, and remediate findings, audit prep becomes a report pull. Every enforcement decision is logged in a full audit trail that's always current.

Question 9

What is a data perimeter, and how does Native enforce one?

Accepted Answer

A data perimeter is a set of controls that defines which principals can access your data, from which networks, and through which services, enforced at the organizational level rather than resource by resource. It's one of the highest-impact architectural controls you can deploy, and also one of the hardest to implement correctly.
On AWS alone, a complete data perimeter requires coordinated policies across service control policies, resource control policies, VPC endpoint policies, and more, spanning six distinct access patterns. AWS updates its implementation guidance on an ongoing basis. Most organizations end up with partial coverage and no clear view of where the gaps are.
Native lets you define your data perimeter requirements once and deploys the correct coordinated controls across every provider. Data can't move to unapproved regions or accounts. Third-party access is blocked except through explicitly approved patterns. AI service calls can't reach data outside defined boundaries.

Question 10

Can't I enforce cloud security controls with Terraform and IaC scanning?

Accepted Answer

Infrastructure as code and IaC scanning are genuinely valuable, and Native works alongside them rather than replacing them. But IaC scanning operates at the code layer, and the most significant cloud security failures happen at the cloud control plane layer, which scanning the code doesn't reach.
Direct console access, credential compromise, and lateral movement between accounts all bypass your CI/CD pipeline entirely. Architectural controls like data perimeters, environment segmentation, and region restrictions live at the organizational level and aren't established through code at all. And in a world where AI agents are generating infrastructure changes autonomously, relying on the code to be correct is a risky dependency.
There's also a coverage problem. IaC scanning only works where the scanners are installed, and in a large enterprise that can mean hundreds of pipelines, each one needing instrumentation and upkeep. Miss one and it's a gap. Native enforces centrally at the cloud control plane, so coverage doesn't depend on every pipeline being wired up.
Native provides a deterministic enforcement layer at the cloud control plane that holds regardless of what the code says or who bypasses the pipeline. It also handles what IaC scanning wasn't built for: simulating the real-world impact of proposed guardrails before they go live, detecting drift when controls are modified outside approved processes, and keeping guardrails aligned as providers ship new services.

Question 11

How does Native reduce CSPM alert volume and finding fatigue?

Accepted Answer

Every alert that stems from a misconfiguration that should never have been possible represents an architectural gap, not a monitoring gap. CSPM tools surface these findings because they have no choice: the configuration is wrong, so they flag it. The backlog grows faster than teams can triage it, and security engineers spend their time chasing resource-level findings instead of operating at the level of architecture.
Native reduces this volume by enforcing the conditions that prevent misconfigurations from occurring. Non-compliant resources can't be created if the guardrail is already active at provisioning. The class of alerts that stems from configurations the architecture should have prevented doesn't appear.
Organizations that deploy Native typically see their CSPM finding volume drop meaningfully for the categories Native covers. That frees security teams to redirect their attention to higher-level architectural questions, rather than closing tickets that document problems the architecture shouldn't have allowed.

Question 12

How is Native different from Wiz, Orca, or Prisma Cloud?

Accepted Answer

The simplest version: tools like Wiz, Orca, and Prisma Cloud scan for misconfigurations and surface risk. Native enforces secure-by-design cloud architecture. They're built around different operating models.
CSPM and CNAPP tools are excellent at finding and prioritizing problems that already exist in your environment. They give you a continuous view of your risk posture and help your team work through what needs fixing. Native operates upstream. It prevents the problem from being introduced in the first place by enforcing the architecture that makes bad outcomes structurally impossible.
Native also covers control domains these tools don't address at all: third-party access perimeters, environment segmentation enforced at the organizational level, AI architecture controls, and blast radius containment. These aren't findings to remediate. They're architectural decisions that require enforcement at the cloud control plane.
Most organizations that deploy Native also run a CNAPP tool, and they use them in parallel because they genuinely complement each other. Native reduces what your CNAPP has to find. Your CNAPP catches anything that gets through. The goal isn't to replace your existing stack; it's to close the gap between what you're finding and what you're preventing.

Question 13

What does zero trust mean for cloud infrastructure, and how does Native implement it?

Accepted Answer

Zero trust in cloud environments means that no identity, whether a person, a service account, or an AI agent, is trusted by default. Access is explicitly granted, scoped to exactly what's required, and continuously enforced. The challenge is that most organizations have the zero trust concept without the zero trust architecture: the intent exists, but the enforcement controls aren't consistently deployed across all providers and all accounts.
Native makes zero trust operational at the cloud architecture layer. You can define least-privilege access boundaries for every actor in your environment and enforce them through the cloud providers' own IAM and network controls, across AWS, Azure, Google Cloud, and OCI simultaneously. When access patterns drift outside the defined boundaries, Native surfaces it before it becomes a gap rather than after it becomes an incident.
This also extends to AI agents, which are a new category of actor that existing zero trust frameworks weren't designed to govern. Native enforces what AI agents can reach and act on regardless of the permissions they inherit, so you get zero trust coverage that extends all the way to the AI services your engineering teams are building with.

Built-In Cloud Security Controls. Active by Design.

How an Outcome Becomes a Control

Eight Ways Teams Put Native to Work

Multi-Cloud Alignment

Secure Cloud Services Adoption

Enable AI for Engineering

Protect from AI Attacks

Enforce Data Perimeter

Compliance Enforcement

Blast Radius Containment

Built-In Prevention

Eight Ways Teams Put Native to Work

Active Defense, by the Numbers

Active Defense, Answered

Ready to enforce secure-by-design?