Cloud security, on the terms we promised

VikingCloud was built around four lines we committed to publicly before we had a single user. Plug and play, plain language, every feature in every tier, minimal footprint. Here is how each of them survives contact with the product.

Cover Image for Cloud security, on the terms we promised

Cloud security ought to protect you, not overwhelm you. That sentence is the argument we have with the rest of the category.

Somewhere along the way the dominant cloud security platforms stopped being tools and became another job. Another set of dashboards to read, another quarterly contract negotiation, another vendor whose engineers know your environment better than your own team does. The bigger those platforms got, the more able they were to define what real cloud security looked like to the rest of the market. The category started following them by inertia rather than by argument.

A category that drifted

Three patterns describe most of what cloud security has become.

The first is complexity-as-feature. Each new module, each new correlation, each new dashboard adds a reason to justify the next pricing tier. The product reads as a stack of capabilities rather than a coherent answer to a question.

The second is basics behind tiers. Attack paths, identity analysis, compliance against the major frameworks — the parts every team needs the moment it has a cloud account — placed behind contract floors most teams cannot reach. The teams least equipped to defend themselves end up with the least access to the tools meant to help them.

The third is AI as a retrofit. Agents added as a side panel to a product whose data layer was designed before agents were a serious answer to anything. The intelligence becomes whatever an LLM can scrape from a schema that was never built for it.

These are the answers a different generation of companies, in a different market, arrived at. They are not our answers, and we are not obliged to inherit them.

The four lines we promised

VikingCloud was built around four lines we committed to publicly before we had a single user. They are not slogans. They are the test we ship against. If a feature passes them, it goes in. If it does not, it does not, even if it would close a deal.

Plug and play. Connect a cloud and the platform is running in minutes. One command, same shape for every provider we support. No agent to install, no professional services to schedule, no six-week onboarding. From the connect command to a populated dashboard: typically 5 to 15 minutes, depending on environment size. If a team needs help to get value out of a security tool, the tool has already failed.

Plain language. Every finding ships with a plain-English summary of what is wrong, why it matters in business terms, and the remediation step a human can take. Generated at scan time by the Viking Analyst, in the language the team has set on their account. Not raw alert text. Not a CVE identifier with a link to a feed. The platform speaks to people who have other jobs and can only spend so much of the day inside it.

Every feature, every customer. Tiered pricing is a fact. Tiered features is a choice, and we made the opposite one. Security scanning, vulnerability scanning, compliance reporting, SBOM export, and the AI Viking Analyst are available at every paid tier. Higher tiers add cloud connections, not capability. The line is enforced in code: an automated test fails any deploy that would gate one of those features behind a higher tier. The one deliberate exception is organization-level scanning across AWS Organizations, GCP folders, and Azure management groups. That ships at Enterprise because it is bought by the kind of buyer who has that org structure.

Minimal footprint. Read-only access wherever the provider supports it. Narrow, scoped access only where the scan itself requires more, and never beyond what we created ourselves. Never broader than the scanning job needs. A cloud security tool that asks for more access than the scan requires has already given an attacker too many places to land.

Why these lines, now

Because the other side of the keyboard moved.

Attackers are using LLMs to triage CVEs and write exploits inside the same window in which defenders are still forwarding the advisory email. Copy Fail (CVE-2026-31431), Dirty Frag (CVE-2026-43284 / 43500), and Fragnesia were three Linux kernel root primitives published inside fifteen days. NGINX Rift (CVE-2026-42945) sat dormant in the world's most-deployed web server for eighteen years and had working exploit code on disclosure day. The window between the world knows and your fleet is being scanned for it is no longer days. A dashboard built for human attention cannot keep that pace. An agent reading the same advisories against the inventory the platform already has, can.

This is the offense-and-defense frontline of the next several years. The platforms designed for it cannot be the same shape as the platforms designed for the era before it.

The cloud security category will be defined by whoever takes these four lines seriously for long enough to make them the default. We intend to be that platform. If you are evaluating a tool today and any of the four lines does not survive contact with its pricing page or its onboarding flow, that is the question worth asking the vendor.

The principles are the product. Anything you cannot evaluate that simply, is a brochure.

Start a free trial, or walk through it with us if you would rather see them at work.

References

  1. VikingStrike. Copy Fail: 732 Bytes to Root, Half a Day to Find. May 5, 2026.
  2. VikingStrike. Dirty Frag Dropped. We Knew Our Exposure In Seconds. May 11, 2026.
  3. VikingStrike. Three Linux 0-Days in Three Weeks. Did Your Briefing Catch All Three? May 15, 2026.
  4. VikingStrike. A 30-hour pentest expires the day after it ships. May 25, 2026.
  5. NIST National Vulnerability Database. CVE-2026-42945 Detail (NGINX Rift).