How do I start an Operant 7-day free trial for a staging Kubernetes cluster?

Most teams don’t have time for a months-long POC just to find out whether a runtime AI and API defense platform will actually work on their staging Kubernetes cluster. You want to see Operant enforce real controls—blocking attacks, auto-redacting data, and mapping your “cloud within the cloud”—on live staging traffic in minutes, not weeks.

This guide walks you through how to start an Operant 7-day free trial specifically for a staging Kubernetes cluster, what to prepare, and how to prove value fast during the trial.

What the 7-day staging trial actually gives you

In a staging Kubernetes cluster, the 7-day Operant trial is your chance to validate:

3D Runtime Defense (Discovery, Detection, Defense) on real workloads:
- Discover APIs, services, AI agents, MCP toolchains, and east–west traffic.
- Detect risky behaviors: prompt injection, jailbreak attempts, data exfiltration patterns, suspicious API access, and zombie/ghost APIs.
- Defend inline: block flows, rate-limit, segment services, and auto-redact sensitive data in real time.
Fast, low-friction rollout:
- Single step Helm install.
- Zero instrumentation.
- Zero integrations required to start.
- Works in under 5 minutes on supported Kubernetes platforms.
Policy and control plane behavior:
- How Operant enforces trust zones, allow/deny lists, and identity-aware policies.
- How it protects your staging AI apps, APIs, and internal services “beyond the WAF” and inside authenticated sessions.

The trial is production-grade security running in a non-production environment—exactly what you want for a safe, realistic evaluation.

Prerequisites for a smooth 7-day trial

Before you start the Operant 7-day free trial on your staging Kubernetes cluster, line up a few basics so you’re not burning trial days on internal coordination.

1. A supported staging Kubernetes environment

Operant is Kubernetes-native and supports essentially any standard cloud or on-prem distribution. For a staging cluster, you’re covered if you’re running:

AWS EKS
Azure AKS
Google GKE
Rancher RKE2
Red Hat OpenShift
Upstream Kubernetes
Standalone containers (for lighter-weight staging setups)

If you’re not sure which flavor your staging environment uses, kubectl cluster-info and your cloud console will tell you.

2. Cluster access and permissions

For the Helm-based deployment, you’ll need:

kubectl access to the staging cluster context
Permissions to:
- Create namespaces
- Install cluster-level resources (CRDs, RBAC, etc., depending on your configuration)
- Deploy the Operant runtime components

In practice, this usually means a cluster-admin or a dedicated staging security/DevOps role with Helm install rights.

3. A target scope in staging

To keep the trial focused and low-risk:

Decide whether you’ll:
- Start in a dedicated namespace (recommended for day 1), or
- Apply policies across multiple staging namespaces once you’re comfortable.
Identify the key workloads to evaluate:
- AI apps (LLM-backed services, chatbots, agents)
- MCP servers/clients/tools if you already use the MCP pattern
- Internal APIs and services with significant east–west traffic

The more representative your staging workloads are of production, the more realistic your trial results will be.

Step 1: Request your Operant 7-day free trial

You initiate the 7-day free trial the same way you’d start talking to us about production—but with a staging-specific intention.

Visit: https://operant.ai
Click Get a Demo / Start Now (depending on page variant).
In the form:
- Under “Environment” or comments, explicitly note:
  - “I want to start a 7-day free trial on a staging Kubernetes cluster.”
- Include:
  - Your Kubernetes platform (e.g., EKS, AKS, GKE, OpenShift, bare-metal).
  - An estimate of:
    - Number of namespaces you’ll include.
    - Types of workloads: APIs, AI agents, MCP, etc.
Submit the form.

You’ll typically get a response within 24–48 hours with:

Trial access details
A short onboarding call offer (optional but strongly recommended)
Any cluster-specific notes if you’re on OpenShift or a more specialized K8s stack

If you want to skip the back-and-forth, you can also book directly:
Get Started — use the call to confirm trial details and staging scope.

Step 2: Prepare your staging cluster for deployment

While your trial access is being set up, align your team so day 1 of the trial is about runtime enforcement, not permissions and meetings.

Align security + platform + app teams

Security: Define the initial guardrails you want to test:
- Inline auto-redaction of secrets / PII in staging.
- Blocking high-risk prompt injection patterns in LLM flows.
- Rate limiting or blocking suspicious API calls in staging.
Platform/DevOps:
- Confirm you can run a Helm install in the staging cluster.
- Decide whether to:
  - Run Operant in its own namespace, and
  - Start with a single target namespace vs multiple.
Application/AI teams:
- Identify 1–3 high-value staging applications (e.g., AI agent workflows or key APIs) where you’d like to see:
  - Discovery of internal dependencies.
  - Detection of realistic misuses.
  - Inline defenses in action.

Confirm staging vs production separation

You want your 7-day trial to be unapologetically real but still safe:

Confirm your staging cluster:
- Uses staging credentials (not shared with production).
- Is connected to staging or test versions of your AI models, tools, and APIs.
If staging sometimes hits production resources:
- Document those pathways so you can see how Operant maps and protects them.

Step 3: Deploy Operant via single-step Helm install

Once your trial is approved, you’ll receive:

Helm repository details
A values file template (or configuration guidance)
Any environment-specific instructions

Install outline (high level)

From your operator machine:

# 1. Add Operant Helm repo (example pattern; use actual values from trial email)
helm repo add operant https://helm.operant.ai/charts
helm repo update

# 2. Create a namespace for Operant (if needed)
kubectl create namespace operant-runtime

# 3. Install Operant
helm install operant-runtime operant/operant-platform \
  -n operant-runtime \
  -f values-staging.yaml

Key properties of this step:

Single step Helm install
Zero instrumentation — you don’t have to modify application code.
Zero integrations required to start — you can layer on GitHub, CI/CD, and identity integrations later.
Works in < 5 minutes — you should see discovery and detections almost immediately once traffic flows.

If you’re on OpenShift or a tightly locked-down cluster, you might apply a few additional security context tweaks, but the core flow stays the same.

Step 4: Connect Operant to your staging workloads

With the platform running, the next step is making sure your staging workloads are in scope.

Target the right namespaces

Decide initially whether to:

Scope narrowly:
- One namespace with your most important staging app or AI agent.
Scope broadly:
- All staging namespaces, but start with passive discovery and tighten enforcement gradually.

You’ll configure this in your Operant policies (often via Helm values or policy-as-code) so the platform knows which workloads and namespaces to monitor and protect.

Validate live traffic

Generate real staging traffic:

Run your CI/CD pipeline into staging.
Trigger your AI agents, MCP tools, or internal API workflows.
Hit your staging endpoints with realistic user journeys.

Within minutes, Operant should:

Build a live API and service blueprint:
- Internal services
- External APIs
- East–west traffic
Discover:
- Managed and unmanaged agents
- MCP server/client/tool interactions
- Ghost/zombie APIs that your team may have forgotten

This is the “cloud within the cloud” coming into view—the runtime reality that perimeter tools never see.

Step 5: Turn on runtime defenses in staging

Discovery is useful. But the point of an Operant trial is to prove inline enforcement in a safe environment.

Start with low-risk, high-value controls

For a staging Kubernetes cluster, I recommend enabling:

Inline auto-redaction of sensitive data
- Protect secrets, tokens, keys, and sensitive fields in logs and inter-service flows.
- Prove that Operant can redact as data flows—not just after the fact in a SIEM.
Blocking obvious prompt injection and jailbreak patterns
- If you have LLM-backed services or MCP agents:
  - Enable policies mapped to OWASP Top 10 for LLM.
  - Test with known malicious prompts and jailbreak scripts.
- Observe how Operant blocks or alters agent behavior without breaking normal flows.
API trust zones and microsegmentation for staging services
- Define trust boundaries for:
  - Specific namespaces.
  - Known “sensitive” services (e.g., staging versions of billing or user-data services).
- Enforce:
  - Allow/deny lists for API calls.
  - Identity-aware access controls.
  - Rate limiting for suspicious or unexpected usage patterns.

These controls show how Operant is more than a dashboard: it is an active, inline runtime defense layer.

Step 6: Use policy-as-code and CI/CD guardrails (optional but powerful)

If you want to see how Operant fits into your staging pipeline and not just the cluster runtime:

Connect GitHub:
- Use policy-as-code integrations to:
  - Enforce certain security baselines via GitOps.
  - Catch misconfigurations before they reach staging.
Integrate with CI/CD pipelines:
- Shift left with DevSecOps guardrails:
  - For example, block a deployment to staging if it violates specific runtime security policies.
- This turns staging into a controlled proving ground where Operant enforces policies from commit to runtime.

You don’t need these integrations to start the 7-day trial, but they’re worth exploring if you’re evaluating Operant as a core part of your future AI+API security stack.

Step 7: What to validate during the 7 days

To make the 7-day free trial on your staging Kubernetes cluster meaningful, focus on three buckets: discovery, detection, and defense.

Discovery: What did Operant surface that you didn’t know?

Evaluate:

Unknown or unmanaged APIs in staging (ghost/zombie services).
Hidden MCP server/client/tool paths and agent workflows.
Unexpected east–west traffic across namespaces.
Identities and tokens being used in ways you weren’t tracking.

This is where teams often realize their staging environment has quietly drifted into a production-level attack surface.

Detection: What real risks show up?

Look for detections aligned with:

OWASP Top 10 for APIs:
- Broken object-level authorization
- Excessive data exposure
- Improper inventory of endpoints
OWASP Top 10 for LLM:
- Prompt injections
- Model abuse or scraping attempts (even in staging).
Kubernetes-level threats:
- Lateral movement patterns.
- Misconfigured services that create exposure.

Map these to your existing risk models and see how Operant’s runtime perspective changes the conversation.

Defense: What did Operant actually block or contain?

Confirm, in staging, that Operant:

Blocks or safely modifies agent behavior when prompts go malicious.
Auto-redacts secrets and sensitive data as it flows through your stack.
Enforces trust zones and microsegmentation between staging services.
Rate-limits or drops suspicious API calls without needing code changes.

This is the core question: does Operant move you beyond observability into actual runtime defense for AI apps, APIs, and Kubernetes workloads?

Step 8: Decide on next steps before the trial ends

Before day 7:

Capture:
- A list of discovered assets (APIs, agents, MCP components) you didn’t know about.
- Concrete detections that would have been invisible to your WAF or SIEM alone.
- Inline blocks/redactions that prevented or would have mitigated real risk, even in staging.
Align your teams on:
- Whether you want to:
  - Expand Operant from staging to production.
  - Tighten policies and retain the same staging scope.
  - Extend to additional clusters (e.g., dev, pre-prod, or multi-region staging).

Use that summary to drive your decision on moving from a 7-day staging trial into a broader rollout.

Final thoughts: why starting in staging makes sense

Starting an Operant 7-day free trial on a staging Kubernetes cluster is the pragmatic way to prove:

You can deploy a Runtime AI Application Defense Platform via a single step Helm install with zero instrumentation.
You can see your “cloud within the cloud” in minutes: APIs, agents, MCP, east–west traffic.
You can move from dashboards to enforcement:
- Inline blocking.
- Auto-redaction.
- Trust zones.
- Identity-aware controls.

You don’t need a multi-quarter project or a pile of Jira tickets to get there. You need 7 days, a staging cluster, and a willingness to see what your runtime actually looks like.

Next Step

Ready to start your 7-day Operant trial on your staging Kubernetes cluster and see runtime enforcement in action?

Get Started