Skip to main content
Many enterprises operate under policies that prohibit storing conversational content from employee LLM interactions, even briefly. No-spy mode is the privacy posture for those organizations: one Organization-scope rule in the data privacy policy that sets Input, Output, and System instructions to Drop. The content is stripped in the ingestion pipeline, before it ever lands in storage.
Pairs with: Data privacy policy (the full reference for scopes, dispositions, audiences, and redaction), Compliance architecture (the observability substrate this posture operates against), and Self-hosting compliance (where this fits in the SOC 2, ISO 27001, HIPAA mapping).

Setting it up

At Settings > Privacy, add an Organization rule and set the content categories to Drop: Dropping tool calls as well removes tool arguments and tool results. That is the strictest posture, and it may break debugging flows that need to inspect what tools received and returned. Writing an Organization rule requires the organization manage permission, so only org-level administrators can change this posture.

What’s stored, what’s dropped

Dropped categories never reach storage. Observability metadata always survives:
  • model name and provider
  • input and output token counts
  • cost attribution
  • latency, timings, and span structure
  • status and error attributes
  • identity attributes (which person, which organization)
So you can still answer “how much did this engineer’s Claude Code sessions spend this month?” and “did the gateway hit a 5xx?”, without anyone being able to read what was asked or what the model answered.

Scoping the posture

A drop rule applies to every ingestion path for the projects in its scope: AI gateway traffic, the OpenTelemetry endpoint, the REST collector, ingestion keys, and coding-agent logs (for example Claude Code request bodies). The rule’s scope decides which projects those are:
  • Narrowed to personal projects only: every employee’s personal CLI workspace drops its content, while application projects keep capturing for debugging. This is the common shape for “no employee chat surveillance” policies, it covers the coding assistants without touching product observability.
  • Organization-wide: every project in the organization drops the chosen categories, application traces included.
If the requirement is “only a small audience may read it” rather than “it must not exist”, set the categories to Restrict with a narrow audience instead. Restriction keeps the content for the chosen reviewers and applies retroactively to traces already stored.

Drop is forward-looking only

Drop acts at ingestion, so it applies to traces that arrive after the rule exists. Already-stored spans are not scrubbed. To remove historical content, pair the rule with your retention setup so old data cycles out while new ingest lands stripped (see Compliance architecture).

Trust boundary

The strip runs in the ingestion pipeline before the storage write, so the searchable trace store never carries conversational content for dropped categories. The gateway process still handles each request in memory in order to proxy it to the provider. For policies that require content never to transit LangWatch at all, point those tools at the provider directly (BYOK endpoints) and skip the gateway.

Cross-org isolation

Privacy rules belong to a single organization. Two organizations on the same self-hosted deployment hold independent policies: a drop rule at acme has no effect on globex.

Where to next