How do I enable Operant “private mode” and inline redaction so PII/PHI doesn’t leave our environment?

Most security teams ask the same core question before rolling Operant into production traffic: “Can we guarantee that PII/PHI never leaves our environment?” That’s exactly what Operant’s private mode and inline auto-redaction are designed to do.

This guide walks through how to enable private mode, turn on inline redaction, and validate that sensitive data (PII/PHI, secrets, keys) is contained before it ever reaches external AI models, APIs, or third parties—without slowing your teams down.

---

What “private mode” and inline redaction mean in Operant

Before we get into steps, it’s worth aligning on behavior.

• Private mode

  • All detection and enforcement logic runs inside your environment (your Kubernetes cluster / VPC).
  • Sensitive payloads are not sent to Operant’s cloud or any third-party inspection service.
  • Only sanitized metadata and security events can be exported, as you configure.
  • Result: You get runtime AI and API defense with zero data egress of PII/PHI for analysis.

• Inline auto-redaction

  • Operant inspects live traffic inline (prompts, completions, API calls, tool/agent invocations).
  • It detects sensitive patterns (e.g., SSNs, credit card numbers, API keys, phone numbers, email addresses, medical record numbers).
  • It then blocks or auto-redacts that sensitive content before:
    • The request leaves your application perimeter, or
    • The response is surfaced back to a user/agent.
  • Redaction happens at wire speed, inside your cluster, with no additional proxies or code changes.

Put together, private mode + inline redaction give you a runtime safety net: sensitive data stays inside your trust boundary, and anything that does cross a boundary is scrubbed by default.

---

Prerequisites

To enable private mode and inline redaction in a way that actually holds up in production, you’ll need:

• Kubernetes access

  • Cluster running EKS, AKS, GKE, OpenShift, or upstream K8s.
  • Permissions to install via helm in the target namespaces.

• Network visibility into your runtime AI paths

  • Operant should see traffic between:
    • Your apps / services ↔ AI endpoints (OpenAI, Anthropic, Azure OpenAI, internal LLMs, RAG services).
    • Your apps / agents ↔ internal/external APIs.
    • MCP clients ↔ MCP servers/tools (if you’re in the MCP/agentic world).

• Namespaces / workloads you want to protect first

  • Start with a “blast radius” you control:
    • AI-facing backends.
    • Ingress layer for AI traffic.
    • Key microservices that handle PII/PHI.

---

Step 1: Deploy Operant in private mode (no PII leaves your environment)

Operant is designed to start enforcing in minutes, not weeks of “instrumentation projects.”

1. Add and update the Operant Helm repo

   helm repo add operant https://charts.operant.ai
   helm repo update
   

2. Prepare a values file for private mode

   Create operant-values-private.yaml with the key controls:

   operant:
     mode: private               # Ensure private / on-prem processing
     dataEgress:
       sendPayloads: false       # Do not send raw payloads to Operant cloud
       sendPII: false            # Explicit safeguard: no PII/PHI egress
       eventExport:
         enabled: true           # Optional – export only sanitized events
         redactFields:           # Fields always redacted in events
           - request.body
           - response.body
   
   analysis:
     inline: true                # All detection happens inline, in-cluster
   

   Key idea: Operant will compute detections and enforce policies locally. Any outbound events are summaries, not raw prompts or records.

3. Install Operant into your cluster

   Target the namespace that front-doors AI and PII flows (or a shared “security” namespace):

   helm install operant-runtime operant/operant \
     --namespace operant \
     --create-namespace \
     -f operant-values-private.yaml
   

   • No code changes.
   • No language SDKs.
   • No sidecars you have to wire in by hand.

   Operant attaches itself to live runtime paths so it can observe and enforce beyond the WAF—inside your actual cloud-native mesh.

---

Step 2: Enable inline auto-redaction for PII/PHI

With private mode set, next step is turning on inline redaction so sensitive data is automatically scrubbed before leaving your perimeter.

1. Turn on the built-in PII/PHI detectors

   Add to your values file (or apply via Operant UI/API):

   redaction:
     enabled: true
     detectors:
       pii:
         enabled: true
         types:
           - ssn
           - credit_card
           - bank_account
           - phone_number
           - email
           - api_key
           - access_token
           - patient_id
           - medical_record_number
       custom:
         enabled: true
         patterns:
           - name: internal_member_id
             regex: "[A-Z]{3}-[0-9]{6}"
           - name: provider_id
             regex: "PRV-[0-9]{8}"
   

   This config ensures Operant will instantly identify:

   • PII/PHI in prompts, RAG queries, tool calls, and API requests.
   • Secrets and keys accidentally embedded in payloads.

2. Configure how to redact inline

   Decide what you want traffic to look like after redaction:

   redaction:
     strategy:
       default: redact            # or "block", "allow"
     maskToken: "[REDACTED]"
     applyTo:
       - request.body
       - request.headers.authorization
       - response.body
   

   Behavior:

   • redact – Replace sensitive substrings with [REDACTED] and let the request continue.
   • block – Drop the request or response that violates policy.
   • allow – Log but don’t modify (useful in early observe-only rollout).

   For most AI production stacks, a safe staged rollout is:

   • Start with default: redact.
   • Add block for the highest-risk patterns (e.g., API keys, tokens).

3. Create a data egress policy for AI endpoints

   You want an explicit gate on anything leaving for LLMs / third-party AI:

   policies:
     - name: "ai-egress-pii-guardrail"
       description: "Inline redaction of PII/PHI before traffic to AI providers"
       match:
         destination:
           domains:
             - "*.openai.com"
             - "*.anthropic.com"
             - "internal-llm.mycorp.local"
       actions:
         - type: redact
           targets:
             - request.body
           detectors:
             - pii
             - custom
         - type: audit
           level: summary        # Only metadata + redacted snippets
   

   With this in place, no prompt or payload reaches an LLM with raw PII/PHI intact. Anything sensitive is either redacted or blocked inline.

---

Step 3: Apply the same redaction to MCP, agents, and internal APIs

The real risk in agentic architectures is the “cloud within the cloud”—internal APIs, MCP tools, SaaS agents, and dev-tool plugins trading data behind the scenes.

Extend redaction controls there as well:

1. MCP servers / tools

   policies:
     - name: "mcp-pii-guardrail"
       match:
         mcp:
           role: server
       actions:
         - type: redact
           targets:
             - request.body
             - response.body
           detectors:
             - pii
             - custom
   

   This keeps MCP exchanges safe:

   • Agent ↔ MCP server.
   • MCP server ↔ tools that might hit EHR, CRM, or billing systems.

2. Internal east–west APIs

   For services that talk to each other with PII/PHI in flight:

   policies:
     - name: "east-west-healthdata-guardrail"
       match:
         destination:
           namespaces:
             - "ehr"
             - "billing"
       actions:
         - type: redact
           detectors:
             - pii
             - custom
         - type: segment
           trustZone: "phi-restricted"
   

   This does two things:

   • Redacts sensitive data when it’s leaving the PHI boundary.
   • Enforces trust zones inside your cluster so not every service can freely read PHI.

3. SaaS & dev-tool agents

   If you’re letting SaaS agents or plugins call into your APIs:

   policies:
     - name: "saas-agent-egress"
       match:
         source:
           identities:
             - "github-actions"
             - "notion-ai"
             - "custom-copilot"
       actions:
         - type: redact
           detectors:
             - pii
         - type: rate_limit
           maxRequestsPerMinute: 60
   

   This keeps:

   • Agent prompts and tool calls from leaking PII.
   • Abuse / 0-click exfiltration attacks throttled at runtime.

---

Step 4: Validate that PII/PHI never leaves your environment

Enforcement isn’t real until you verify it on live traffic.

1. Run a controlled test

   From a test client or staging app, send a request that includes obvious PII/PHI:

   {
     "prompt": "Patient John Doe, SSN 123-45-6789, MRN 998877. Generate discharge instructions."
   }
   

   • Direct it to a path that hits an AI provider or external API.
   • Confirm the request flows through workloads/namespaces covered by your Operant policies.

2. Inspect the outgoing traffic

   • Use your usual network tooling (eBPF, sidecar logs, L7 traces) or Operant’s own live view.

   • You should see outbound payloads look like:

     {
       "prompt": "Patient [REDACTED], SSN [REDACTED], MRN [REDACTED]. Generate discharge instructions."
     }
     

   If any raw PII/PHI appears in traffic destined for external endpoints, tighten:

   • match selectors (domains, namespaces, identities).
   • targets (ensure request.body and relevant headers are included).
   • detectors lists (add patterns you missed).

3. Check Operant’s event stream

   • Verify that events only contain sanitized metadata:
     • Redacted samples.
     • Policy references.
     • Service/identity context.
   • Confirm no raw records, notes, or full prompts with PII/PHI are being exported.

---

Step 5: Move from “observe & redact” to hard enforcement

Once you’re comfortable that inline redaction is behaving as expected, you can turn up enforcement pressure where it matters.

1. Block instead of redact for certain data

   For example, never allow secrets or raw medical IDs to hit third parties:

   policies:
     - name: "ai-egress-secrets-block"
       match:
         destination:
           domains:
             - "*.openai.com"
             - "*.anthropic.com"
       actions:
         - type: block
           detectors:
             - api_key
             - access_token
             - medical_record_number
         - type: audit
           level: detailed   # Still sanitized; no raw secrets
   

   Now, if a dev accidentally includes an API key or MRN in a prompt, the call is stopped at runtime—not just flagged in a dashboard.

2. Bind redaction to identities and trust zones

   • Stronger rules for:
     • Anonymous/public endpoints.
     • SaaS or external agents.
   • More permissive (but still logged/redacted on egress) inside your PHI trust zones.

   Example:

   policies:
     - name: "public-endpoint-strict-pii"
       match:
         source:
           identities:
             - "public-ingress"
       actions:
         - type: block
           detectors:
             - pii
   

3. Attach policies to compliance controls

   Inline enforcement makes compliance tractable rather than aspirational:

   • Map policies to HIPAA safeguards, PCI DSS v4, NIST 800 controls.
   • Use Operant’s logs as evidence of:
     • Runtime data minimization.
     • PII/PHI egress controls.
     • AI use governed by enforceable boundaries—not just policy PDFs.

---

How this fits your security model

Private mode + inline redaction use the same controls security teams already understand—least privilege, segmentation, data loss prevention—but apply them to the runtime AI and agentic stack:

• Discovery – Live map of AI endpoints, MCP tools, APIs, agents, and who’s talking to what.
• Detection – Real-time PII/PHI and secret detection across prompts, APIs, and agent workflows.
• Defense – Inline redaction, blocking, rate limiting, and trust zones enforced on real traffic.

All of it runs inside your environment, so you’re not trading privacy for protection. Sensitive data stays within your perimeters; Operant simply becomes the runtime firewall for your “cloud within the cloud.”

---

What to do next

If you want help tailoring private mode and inline redaction to your specific AI stack—OpenAI, Anthropic, Azure OpenAI, internal LLMs, MCP tools, or custom agents—walk through it live on your own traffic.

Get Started