Operant pricing: how does usage-based pricing work and what drives cost (traffic volume, clusters, protected surfaces)?

Most teams first come to Operant with a simple question: “What will this actually cost in my environment?” The short answer is that Operant uses usage-based pricing tied to your real runtime footprint—not per-seat licenses or arbitrary feature tiers. You get the full Runtime AI Application Defense Platform (3D Runtime Defense across Discovery, Detection, Defense) from day one; cost scales with how much live traffic and how many protected surfaces you put behind it.

This guide breaks down how Operant’s usage-based pricing works, what actually drives cost (traffic volume, clusters, and protected surfaces), and how to think about sizing Operant for your stack.

---

How Operant’s usage-based pricing works

Operant is priced around your runtime reality:

• Your live traffic (requests/events flowing through protected surfaces)
• Your runtime environments (Kubernetes clusters and clouds)
• Your protected surfaces (AI apps, MCP, agents, APIs, and cloud-native workloads)

There are three core principles:

1. Usage-based, not user-based

   • Unlimited users. You don’t pay more for adding security, platform, SRE, or app teams.
   • You pay for the protection envelope you put around your applications and AI stack.

2. Complete platform, not feature gating

   • “Complete Coverage: Get complete coverage and unlock the entire platform. Extra-legroom included.”
   • You’re not buying separate SKUs for Agent Protector vs AI Gatekeeper™ vs API & Cloud Protector vs MCP Gateway. The full Runtime AI Application Defense Platform is available; pricing scales with how broadly you deploy it.

3. Footprint-aware, not instrumentation-heavy

   • Single-step Helm install. Zero instrumentation. Zero integrations. Works in minutes.
   • Pricing maps to the traffic and surfaces you actually run, not to how many services you’ve hand-instrumented.

Think of it as: protect more live traffic and more surfaces → pay more; keep scope tight while you ramp → pay less, with room to expand as you prove value.

---

What drives Operant cost in practice

Under the hood, most Operant deployments are sized around three axes:

1. Traffic volume
2. Number and size of clusters/environments
3. Protected surfaces (AI agents, MCP, APIs, and cloud workloads)

1. Traffic volume: how much runtime you push through Operant

Traffic is the primary cost driver, because that’s where Operant does real work: inline discovery, detection, and defense on live flows.

Common traffic factors:

• Requests through protected APIs and services

  • North–south and east–west API calls inside Kubernetes and across clouds
  • Internal service-to-service calls (the “cloud within the cloud”)
  • Ghost/zombie APIs that Operant discovers and optionally protects

• AI and agent traffic

  • Prompt and completion flows from AI apps to LLMs
  • MCP calls between clients, servers, and tools
  • Agentic workflows invoking tools, APIs, and data systems

• Runtime events

  • Policy enforcement decisions (block, rate-limit, segment, redact)
  • Identity-aware routing and trust-zone checks
  • Detected attacks (prompt injection, tool poisoning, exfiltration, etc.)

Why this matters for pricing:
More traffic means more enforcement decisions per second. Operant scales to handle that, and your pricing scales with it. A low-traffic internal agent rollout costs much less than a globally exposed AI gateway fronting billions of API calls.

How to think about sizing by traffic:

• Early-stage / pilot

  • Protect a few core AI apps or critical APIs
  • Focus on 1–2 clusters and a handful of agent workflows
  • Great for proving value without touching the entire estate

• Growth stage

  • Expand to protect major east–west service meshes, agent platforms, or AI gateways
  • Start enforcing trust zones and redaction on high-volume flows
  • Cost starts to reflect broader runtime coverage

• Full-runtime coverage

  • Inline defense across all production clusters, critical internal APIs, and AI workloads
  • Maximum protection and visibility; pricing reflects full footprint

If you know your average RPS or monthly request volume across the services you want to protect, that’s the easiest starting signal for a pricing conversation.

---

2. Clusters and environments: where Operant runs

Operant is Kubernetes-native. You deploy it into your clusters via Helm and it starts working in minutes. Pricing reflects how many clusters and environments you protect and the relative size of those environments.

Typical dimensions:

• Number of clusters

  • EKS, AKS, GKE, OpenShift, on-prem K8s
  • Multi-cluster and multi-cloud setups
  • Separate clusters for dev, staging, prod

• Cluster scale and density

  • Node count and pod density
  • How many microservices run inside each cluster
  • Whether clusters host high-throughput APIs or low-volume internal tooling

• Environment scope

  • Do you protect just prod, or also staging and pre-prod?
  • Do you include shared infra clusters that host internal agent platforms or control planes?

Why this matters for pricing:
Larger and more numerous clusters mean:

• More surfaces to discover (APIs, agents, MCP endpoints, identities)
• More potential enforcement points (sidecars, gateways, trust zones)
• More dynamic topology to track in Operant’s live blueprints

You’re not charged per node or per pod, but those attributes correlate with how much runtime Operant observes and protects in each cluster.

Common patterns:

• Prod-only scope

  • Lower cost, surgical protection of your most critical surfaces
  • Good fit if you’re under immediate pressure to secure a specific AI or API workload

• Prod + staging

  • Slightly higher cost, in exchange for testing runtime policies against real pre-prod traffic
  • Ideal if you want to validate enforcement (blocks, redaction, trust zones) before pushing to prod

• Multi-region, multi-cloud

  • Operant spans EKS, AKS, GKE, and on-prem, with coherent policies
  • Pricing reflects the aggregate protected footprint, not each environment in isolation

---

3. Protected surfaces: which assets you actually defend

The third axis is how widely you apply Operant’s 3D Runtime Defense—what surfaces are under active protection versus just being observed or left out-of-scope.

Protected surfaces include:

• AI and agent surfaces

  • AI apps and APIs using LLMs (internal or external)
  • Autonomous agents in SaaS/dev tools, CI pipelines, and internal platforms
  • MCP clients, servers, and tools (secured via MCP Gateway and Agent Protector)
  • Agentic workflows orchestrating multiple tools and data systems

• LLM and prompt flows

  • Prompt injection and jailbreak attempts
  • Tool poisoning inside agent toolchains
  • Data exfiltration and model theft attempts
  • AI supply chain risk—untrusted models, tools, or MCP endpoints

• APIs and services

  • External APIs (north–south) exposed to users and partners
  • Internal APIs and services (east–west) that WAFs never see
  • Ghost/zombie APIs discovered by Operant and optionally brought under enforcement

• Cloud and runtime infrastructure

  • Kubernetes workloads and traffic patterns mapped against OWASP Top 10 for K8s and APIs
  • “Cloud within the cloud” interactions across services, identities, and tenants
  • Trust zones and identity-aware policies enforcing least privilege inside your own perimeter

Why this matters for pricing:
Every protected surface is a contract: Operant commits to inline discovery, detection, and defense. When you turn on enforcement for more assets—more agent platforms, more MCP connections, more APIs—the total protection area grows, and so does cost.

Typical expansion paths:

1. Start with a flagship AI or API use case

   • Protect a public AI-facing API or a high-value internal agent workflow
   • Turn on inline blocking, rate limiting, and automatic redaction of sensitive data
   • Validate that you’re actually stopping prompt injection and exfiltration, not just logging it

2. Add MCP and agent surfaces

   • Catalog and secure MCP servers, clients, and tools
   • Build allow/deny lists and trust zones around agent toolchains
   • Detect “0-click” agentic risks and “Shadow Escape” style attacks where tools cross hidden boundaries

3. Expand to broad API and cloud coverage

   • Use Operant as your runtime-native defense for APIs and Kubernetes workloads
   • Go beyond the WAF: protect east–west traffic and the identities that live behind your perimeter
   • Consolidate overlapping tools as you prove Operant can both see and block attacks inline

In each phase, the set of protected surfaces is an explicit scope that drives pricing.

---

How Operant keeps pricing predictable

Usage-based pricing can be scary if it’s opaque. “You’ll just pay for what you use” is not what you want to hear when you’re trying to budget around production workloads. Operant’s approach is to tie usage to clear, scorable dimensions and then bound them so your bill is predictable.

Key predictability levers:

• Scoping by cluster and namespace

  • You can decide which clusters and namespaces are in-scope for full enforcement.
  • Observability-only or out-of-scope namespaces don’t drive cost in the same way as fully protected surfaces.

• Tiered traffic bands

  • Pricing generally follows traffic bands (e.g., up to X RPS or Y million requests/month across protected surfaces).
  • As you approach a higher band, you know you’re moving into a different cost tier before it happens.

• Transparent footprint modeling

  • Before rollout, Operant works with you to estimate protected traffic, cluster counts, and surface types.
  • You get a baseline projection: “With N clusters, M APIs, and this traffic, your monthly spend should fall roughly in this range.”

• No per-seat creep

  • Add as many users as you need—security, platform, SRE, app owners—without line-item surprises.
  • Adoption doesn’t punish you for collaborating.

This is why Operant positions pricing as: Predictable pricing based on your stack and usage. Start as you like, grow when you’re ready.

---

What you get for that usage: full platform coverage

Because the model is usage-based, you’re not playing feature roulette. From the moment you deploy, you get:

• 3D Runtime Defense (Discovery, Detection, Defense)

  • Live discovery of AI agents, MCP connections, APIs, and cloud workloads
  • Runtime detections mapped to OWASP Top 10 for APIs/LLMs/K8s and modern agentic risk patterns
  • Inline defenses: block, rate-limit, segment traffic, and auto-redact sensitive data as it flows

• Agent Protector & MCP Gateway

  • Discover and secure MCP servers, clients, and tools
  • Enforce trust zones, allowlists, deny lists, and identity-aware access for agent workflows
  • Block prompt injection, jailbreaks, tool poisoning, and AI supply chain abuse in real time

• AI Gatekeeper™ and API & Cloud Protector

  • Protect AI apps and traditional APIs beyond the WAF
  • Close the gap inside your perimeter—authenticated sessions, east–west flows, multi-tenant clouds
  • Reduce tool sprawl by consolidating API threat protection, runtime CADR, and AI controls into a single platform

• Compliance and auditing support

  • Controls you can map to CIS Benchmarks, PCI DSS v4, NIST 800, and EU AI Act requirements
  • Runtime evidence that you’re not just logging policy; you’re enforcing it

You don’t toggle features to stay inside a plan; you scope how much of your runtime you want to defend.

---

How to estimate your Operant pricing envelope

If you’re trying to get a mental model before you talk to sales, you can roughly estimate your Operant spend by answering three questions:

1. Traffic volume

   • Across the surfaces you care about, what’s your average and peak RPS?
   • How many monthly requests or events will actually pass through Operant for detection and defense?

2. Clusters and environments

   • How many Kubernetes clusters do you want in-scope?
   • Are you starting with prod only, or also staging/pre-prod?
   • Are there multi-region or multi-cloud considerations?

3. Protected surfaces

   • Which AI/agent use cases are non-negotiable to secure now?
   • Which APIs or internal services are high-value and high-risk (e.g., data-rich, customer-facing)?
   • Do you want to include MCP and agent toolchains from day one, or in phase two?

Bring those answers to the pricing conversation and you’ll get a concrete, predictable proposal—not a guess.

---

Why Operant prices this way

As someone who has lived through the “CNAPP + hope” era, where you pay for dashboards that can’t actually block anything, I’m biased toward pricing that’s tied to real enforcement:

• Operant doesn’t charge you for yet another security console that generates Jira tickets.
• It charges you for runtime protection that sits in the path of live traffic and takes action—blocking “0-click” agentic exploits, auto-redacting sensitive data, and containing “Shadow Escape” style lateral moves inside your own clouds.

That’s why the pricing model orients around traffic, clusters, and protected surfaces: they’re the closest proxies to the actual attack surface and to the work the platform is doing on your behalf.

---

Next step: get a tailored pricing model for your stack

If you want precise numbers, the fastest path is to plug your traffic, clusters, and target surfaces into a short conversation with the team. You’ll walk away with:

• A scoped deployment plan (where to start, what to protect first)
• A clear estimate anchored in your real usage (not generic list pricing)
• A path to expand coverage as you see Operant block real attacks in your environment

Get Started