Operant security review: where can I find SOC 2 Type II info and details on data flow/what gets logged?

Most security reviews boil down to two questions: can we trust your controls, and what exactly happens to our data at runtime? For Operant, that means SOC 2 Type II proof on one side, and very concrete answers about data flow, logging, and retention on the other.

This guide walks through where to get Operant’s SOC 2 Type II information and how Operant handles data in practice, so you can complete security due diligence without guesswork.

Where to find Operant SOC 2 Type II information

Operant is built for production AI and cloud stacks, so security reviews and third‑party attestations are a standard part of the buying process.

1. Start with the Operant security and trust materials

For a high‑level snapshot of Operant’s security posture and compliance, your fastest path is:

Operant website → Security / Trust / Compliance pages
These typically cover:
- Summary of SOC 2 Type II scope (systems, services covered)
- Other frameworks Operant maps to (e.g., CIS Benchmarks, PCI DSS v4, NIST 800 series, EU AI Act‑aligned controls)
- High‑level descriptions of data protection measures (encryption, access control, logging, and auditing)

If you don’t see a dedicated “Trust” or “Security” page linked in the footer, go straight to a sales or product conversation (below); SOC 2 artifacts are often intentionally gated and not indexed for public search.

2. Request the SOC 2 Type II report directly

SOC 2 Type II reports are not meant to be freely downloadable; they contain sensitive architectural details. Operant follows this norm. To obtain the full report:

Existing customers:
- Reach out via your customer success manager or Operant account team.
- Ask explicitly for:
  - The latest SOC 2 Type II report
  - Any bridge letters (if the report period doesn’t fully cover your review window)
  - A summary of in‑scope systems (e.g., platform control plane, SaaS portal, relevant APIs)
Prospective customers / evaluation phase:
- Use the “Get a Demo” or “Contact Sales” flows on operant.ai, or:
- Book a call via the Operant calendaring link (e.g., the “Get Started” / 30‑min meeting CTA).
- Ask for:
  - SOC 2 Type II report under NDA
  - Any security overview deck or data flow diagrams that pair with the report

In practice, Operant will:

Put an NDA in place (if not already executed)
Share SOC 2 Type II via a secure channel (e.g., customer portal or encrypted file transfer)
Walk your security team through control coverage (access management, logging, change management, incident response, vendor risk, etc.) in the context of how Operant is deployed in your environment.

3. Map SOC 2 controls to Operant’s runtime model

During the review, it helps to anchor SOC 2 to Operant’s actual surfaces:

Runtime AI Application Defense Platform with:
- Agent Protector
- MCP Gateway
- AI Gatekeeper™
- API & Cloud Protector

For each of these, you should see SOC 2‑mapped controls around:

Access control: Role‑based access, least privilege, identity‑aware enforcement at runtime.
Change management: How rules/policies (e.g., trust zones, allow/deny lists) are updated, tested, and audited.
Logging & monitoring: How runtime events are logged, retained, and surfaced to you vs. kept in Operant’s control plane.
Data protection: Encryption in transit and at rest, secrets handling, separation of customer data.

If you need a control‑by‑control mapping (e.g., for an internal audit or vendor intake form), ask the Operant team for:

A SOC 2 mapping spreadsheet or
A completed SIG / CAIQ‑style questionnaire that aligns Operant’s controls with your standard intake.

Data flow: what Operant sees and how it fits in your stack

Most teams evaluating Operant want to understand the “cloud within the cloud” story: what exactly Operant inspects, where it sits in the path, and what crosses the boundary into Operant’s control plane.

Operant’s architecture is runtime‑native and Kubernetes‑first:

Single‑step Helm install into your cluster(s)
Zero instrumentation, zero code changes
Works inline in < 5 minutes on live traffic

From a security‑review lens, that means:

Operant deploys alongside your workloads (APIs, services, AI apps, agents, MCP servers/clients/tools).
It builds live blueprints/graphs of:
- APIs (including ghost/zombie APIs)
- Kubernetes services and east–west traffic
- AI models and LLM calls
- MCP server ↔ client ↔ tool workflows
- AI agents across dev tools, SaaS, and internal apps
Then it enforces 3D Runtime Defense:
- Discovery: What exists and who talks to what
- Detection: Prompt injection, jailbreaks, tool poisoning, data exfil, model theft, rogue agents, 0‑click attack patterns
- Defense: Inline blocking, rate‑limiting, adaptive internal firewalls, auto‑redaction, trust zones, allow/deny lists

Typical data paths with Operant in place

The specifics will depend on your deployment, but the core flows look like this:

North–south and east–west API traffic
- What passes through Operant:
  - HTTP(S) traffic between services
  - API calls from external clients into your apps
  - Internal service‑to‑service traffic (east–west) inside the cluster
- What Operant does:
  - Parses requests and responses at runtime
  - Detects OWASP API Top 10 patterns and higher‑order behaviors (e.g., data exfil sequences, Shadow Escape‑style lateral movement)
  - Applies Adaptive Internal Firewalls and other runtime policies to block or contain attacks
LLM and AI agent traffic
- What passes through Operant:
  - Prompts, responses, and tool calls for AI apps
  - Agent workflows across services, tools, and NHIs (Natural Human Interfaces)
- What Operant does:
  - Detects prompt injection, jailbreaks, tool poisoning, and malicious context modifications
  - Uses AI Gatekeeper™ and Agent Protector to block risky actions and auto‑redact sensitive data inline
  - Enforces NHI access controls so that human‑facing interfaces can’t exfiltrate sensitive data through chat, tickets, or other conversational surfaces
MCP‑based workflows
- What passes through Operant:
  - MCP server ↔ client ↔ tool interactions
  - Tool invocation metadata and outputs
- What Operant does:
  - Discovers and catalogs MCP servers, clients, and tools (MCP Catalog / Registry)
  - Detects and blocks MCP‑layer attacks (supply chain abuse, tool poisoning, unauthorized tool use)
  - Applies trust zones and allow/deny lists at the MCP boundary so only approved clients/tools can interact

From a data‑flow standpoint, the important point is:
Operant sits inline with live traffic to enforce security decisions in real time. That necessarily means it sees the same data your APIs and AI agents handle. The question then becomes: what gets processed only in‑cluster, and what gets logged or sent to Operant’s control plane?

What gets logged and where: runtime events, metadata, and content

When you’re doing a security review, you should distinguish between:

Runtime inspection and enforcement (inside your environment)
Telemetry and logs (what’s stored, where, and for how long)

Operant is built to act inline first and generate usable telemetry second, not the other way around. So most heavy lifting happens in your runtime, with selective logging for visibility, auditing, and tuning.

Categories of data Operant typically logs

The exact schema can be tuned with the Operant team, but a realistic baseline looks like this:

Security events & detections
- Examples:
  - Blocked prompt injection / jailbreak attempts
  - Detected tool poisoning or MCP tool misuse
  - Data exfil attempts (e.g., SSNs leaving via LLM chat or API responses)
  - 0‑click attack chains across agents and APIs
- Data elements:
  - Event ID, timestamp, cluster/environment
  - Service/API/agent/middleware identifiers
  - Rule or model that triggered (e.g., OWASP LLM Top 10 category)
  - Decision taken: block, allow, rate‑limit, redact, challenge, etc.
  - High‑level metadata about the request (method, path, status codes, sizes)
- Content vs. metadata:
  - By default, these logs focus on metadata + decision context.
  - Actual payload content is typically minimized or redacted; where content snippets are retained (e.g., for investigation), they are subject to redaction controls.
Configuration and policy changes
- Examples:
  - Creation/updates to trust zones
  - Changes to allow/deny lists
  - Edits to rate‑limits or blocking rules
  - Onboarding of new MCP tools or agents
- Data elements:
  - Who made the change (identity / role)
  - What changed (before/after)
  - Time and environment
- These are crucial for SOC 2 audits and for tracing “who loosened that guardrail and when?”
Discovery and inventory telemetry
- Examples:
  - New APIs or services discovered (including ghost/zombie APIs)
  - New agents or MCP tools detected in runtime
  - Changes in identity relationships (which service/agent can call which API/tool)
- Data elements:
  - Identifiers for APIs/services/agents/tools
  - Network/identity relationships
  - Risk tags (e.g., unmanaged agent, shadow API, unapproved MCP tool)
- Primarily metadata; no need to store payloads here.
Operational metrics
- Examples:
  - Throughput, latency introduced by enforcement
  - Number of blocked vs. allowed requests
  - Rate‑limit counters
- Used for capacity planning and as evidence that Operant is not breaking SLAs while enforcing security.

Payload content, PII, and inline redaction

If you’re handling high‑sensitivity workloads (healthcare, financial, or regulated PII), you will want a clear answer on where payload data can appear in logs.

In Operant’s model:

Inline auto‑redaction is a first‑class control:
- Sensitive fields (e.g., SSNs, credit card numbers, API keys, tokens, secrets, health data) can be auto‑redacted as they flow through agentic workflows, APIs, and LLM traffic.
- This protects against both live exfiltration and over‑collection in logs.
Log content can be scoped by policy:
- You can configure what categories of data are:
  - Fully excluded from logs
  - Redacted before logging
  - Tokenized or hashed
  - Logged only in aggregate
- This configuration is key for compliance regimes like PCI DSS v4 and privacy obligations while still preserving enough signal for detection and forensics.
No training‑on‑your‑data by default:
- Operant is not positioned as an analytics‑only or model‑training platform; its primary job is runtime enforcement.
- That means payload data is not used to train external models outside your control except where explicitly configured as part of a controlled feature (and then subject to your data processing agreements).

During your security review, ask the Operant team to:

Walk through log redaction defaults
Show how inline auto‑redaction policies are configured for:
- PII fields
- Secrets and tokens
- Regulated data categories in your environment
Provide a sample event log (with structure) so your privacy and compliance teams can sign off.

Where logs live: Operant vs. your observability tools

Many teams already have SIEM and observability stacks (e.g., Datadog, Grafana, Splunk). Operant is explicitly designed to complement observability, not replace it.

Operant ≠ observability dashboard.
It’s a Runtime AI Application Defense Platform that blocks, rate‑limits, and redacts inline. Telemetry is a byproduct of those actions.
Integrations with observability:
- Operant can stream security events into tools like Datadog, Grafana, or your SIEM.
- For example, pairing Operant MCP Gateway with Datadog’s MCP Server gives you:
  - Operant: runtime detection + blocking of MCP attacks, auto‑redaction
  - Datadog: long‑term storage, correlation, dashboards

From a security‑review perspective, you should clarify:

What is stored in Operant’s control plane?
- Security events and summaries
- Configuration and change logs
- Discovery metadata and risk labels
What is pushed to your own tools?
- Event streams for:
  - Alerting and incident response
  - Long‑term forensic retention
- Typically via:
  - Webhooks
  - Log shipping
  - Native integrations where available
Retention and deletion policies
- Ask Operant for:
  - Default retention windows for logs in their control plane
  - Options for:
    - Shortening retention
    - EU/region‑specific data residency
    - Data deletion on contract termination

This is where SOC 2 Type II and your DPA (Data Processing Addendum) intersect. The SOC report will outline control maturity; your contract/DPA will encode retention, residency, and deletion specifics.

How Operant’s runtime design affects your risk profile

When I evaluate tools as an operator, I look at two conflicting risks:

A tool that sees everything but can’t act (observability‑only)
A tool that acts inline but forces invasive instrumentation or data centralization

Operant is explicitly designed to avoid both traps:

Kubernetes‑native, inline, zero instrumentation:
- No code changes required.
- Security logic lives close to your workloads and network overlays.
- You can prove value on live traffic in minutes, not months of “instrumentation projects.”
Runtime‑native context:
- Because Operant sees APIs, services, identities, MCP, and agent toolchains together, it can:
  - Attribute attacks to real identities and components
  - Apply least privilege at runtime (trust zones, allowlists)
  - Detect complex attack paths (e.g., an agent chain using a ghost API to exfil data)
Enforcement‑first, telemetry‑second:
- Operant’s job is to:
  - Block prompt injection and jailbreaks
  - Contain rogue agents and tool poisoning
  - Stop data exfil and model theft in real time
- Logging is shaped around those actions, not a firehose of raw payloads.

From a security review angle:
You are not signing up for a black‑box data siphon. You are enabling a runtime‑native control plane that operates where attacks actually happen—the “cloud within the cloud”—with tunable logging and redaction.

What to ask for in your Operant security review

To close your review efficiently, here’s a concise checklist to use with the Operant team:

Compliance & documentation
- Latest SOC 2 Type II report (under NDA)
- Any bridge letters for gaps in the audit period
- Mapping to CIS Benchmarks, PCI DSS v4, NIST 800, EU AI Act‑relevant controls
- Security whitepaper or architecture overview
Data flow & architecture
- High‑level architecture diagram showing:
  - Where Operant runs in your clusters
  - How traffic flows through Agent Protector, MCP Gateway, AI Gatekeeper™, API & Cloud Protector
  - What data leaves your environment (if any) and for what purpose
- Description of region and data residency options
Logging & telemetry
- Sample security event logs (structure and fields)
- Documentation of:
  - Default payload redaction
  - How to configure inline auto‑redaction
  - Any data categories that are never logged
- Log retention defaults and configuration options
Access control & auditing
- Role‑based access model for the Operant console
- How policy changes and enforcement changes are audited
- Identity integrations (e.g., SSO via OAuth2/OIDC)
Incident response & support
- How Operant supports you during a security incident:
  - Real‑time rule updates
  - Emergency policy changes
  - Forensic evidence via logs and runtime graphs

Having these items in hand, plus SOC 2 Type II, usually satisfies even strict internal risk committees, especially in organizations rolling out agentic AI and MCP at scale.

Next step

If you’re ready to dig into Operant’s SOC 2 Type II details, data flow documentation, and logging behavior for your specific environment, the fastest path is a working session with the team.

Get Started