Operant is an in-path gateway: your agents' model traffic passes through it on the way to the providers you already use. A product in that position owes you a precise account of what it sees, what it keeps, and what it never touches. This page is that account, stated plainly — including the parts that are still open items.
1. What the gateway sees, and when
The gateway sees the requests your agents send and the responses that come back — that is the nature of being in the path. What it does with them is deliberately narrow:
- Request bytes pass through untouched. Only a rule you have ratified re-serializes a body (a model swap, a skill append, masking, or cache annotations); everything else is forwarded as the same bytes that arrived. In observe-only mode — the default — nothing is rewritten at all.
- The provider never sees an Operant identifier. Conversation and tenant path prefixes are stripped before forwarding, and the routing metadata a rule reads is stripped on the rewrite path.
- Capture is written off the hot path. A response is never blocked on a write.
- Operant's own machinery — goal summaries, embeddings, cluster labels, the outcome judge, the eval gate, the skill learner — runs through the same gateway under a reserved internal id, is booked as overhead, is excluded from clustering, and is never captured as content. Nothing goes to any third party other than the model providers your organization already uses.
2. Capture tiers, and what each stores
Capture is tiered, and each escalation is explicit and recorded — the console shows a row for every pattern whose capture depth was raised, and a deployment can switch escalation off entirely.
- Tier 0 — shape (always). Per call: model, token counts and cost, timing, and hashes of the system prompt, the tools, and each turn's content. Hashes, not text.
- Tier 1 — goal (on by default). A one-line goal summary of the user turns, PII-scrubbed, and its embedding. Harness wrappers and system reminders are stripped first, so only the user's own words are summarized.
- Task-shape artifacts (on by default). The tool definitions and system prompt text — developer-authored configuration, not end-user content — kept once per distinct artifact, scrubbed and size-capped.
- Tier 2 — full trajectory (per pattern, when it qualifies). User and assistant turns, tool inputs and outputs, and error flags — only for member conversations of a pattern that passed member-count and spend thresholds, forward-only from the moment of qualification, and scrubbed. Earlier turns are filled in only from history a later call re-sends anyway.
One open item, stated as such: a retention window for full-text traces is not yet enforced. A deployment with a hard retention requirement should raise it with us before sending traffic.
3. Your keys
- A provider key your caller sends passes through verbatim. The gateway stores nothing from the request path; the call reaches the provider with your key, unchanged.
- An Operant key is never forwarded. It is recognized by prefix, stripped, and your organization's stored credential injected in its place. Operant keys are hashed at rest, their creator is recorded, and every captured call is stamped with the key that sent it.
- Stored provider credentials are encrypted at rest with AES-256-GCM under a master key the deployment holds. One internal service writes them, the gateway alone reads them, and injection is headers-only at forward time; the console shows only that a credential exists and when it was stored. Not built yet, stated honestly: credential rotation and a key-access audit trail.
4. Tenant isolation
An organization is a tenant, and isolation is enforced where it cannot be forgotten: in the database rows, not just the application logic. Row-level security places a policy on every tenant-bearing table, and queries run as a restricted role, so a query that forgets its tenant returns nothing rather than someone else's data.
The gateway is the only public service. The router, the cortex, and the skill learner accept requests only with the internal token the gateway attaches — and the tenant on those requests comes from the signed-in session, never from anything the request claims about itself.
5. Turning it off
Revocation is a base-URL change: point your agents back at the provider and Operant is out of your path in about a minute, with nothing left running between you and your models. Because the default is observe-only, turning Operant on never committed you to anything a base-URL change cannot undo.
Stopping traffic stops all new capture. Data already captured at the tiers above stays in your organization's tenant, under the isolation described in section 4; removing it is a data question for the mailbox below. For the strongest posture, a deployment you run yourself keeps everything inside your own network: the only things that leave are the model calls to the providers you configured — and e-mail, if you use a hosted sender rather than your own relay. There is no telemetry.
6. Contact for data questions
Questions about anything on this page — what is captured for your organization, escalation settings, removal of captured data, or the posture of a self-run deployment — go to hello@operantlabs.com. We answer data questions with the same specificity this page uses.