The two Parascope surfaces that call a language model, what text reaches the provider on each, where it goes, how long it is kept, and how model output is gated before anything acts on it.

Parascope calls a third-party language model on two surfaces. This page names them, states what text leaves the platform on each, and follows that text through to what is retained. A feature that does not appear on this page makes no call to a model provider.

The two surfaces

Natural-language query translation. The Ask button in the query console toolbar opens a chat sidebar where you describe what you want in plain English and get back a ParaQL query. Natural Language Queries covers how the feature is used.

The website advisor. The chat on parascope.io answers pre-sales questions about the product. It is unauthenticated, open to any visitor, and holds no connection to any tenant's data.

Nothing else in the platform calls a provider. The collectors, the processor, the appliance and the email worker contain no provider call. The MCP server's natural_language_query tool is a client of the same tenant API path the sidebar uses, one hop further out, so it sends what that path sends and nothing beyond it.

What is sent

Natural-language translation sends three things to the provider:

Your question, verbatim, together with the current contents of the query editor when there are any.
Schema grounding built from your own database. The configuration-item type inventory, the relationship types, the source names and scope labels that SHOW SOURCES returns, and the column definitions for the types in play.
Real configuration-item names. Before the call, identifiers in your message are matched against your configuration items, and the matched names and types are placed in the prompt so the model has something to anchor its answer to.

The grounding is scoped to the permissions of the person asking, so a user who cannot see a source contributes none of that source's names to a prompt. It is filtered by permission, not redacted: the names a permitted user is entitled to see reach the provider in full.

One prompt-injection control applies, and it is narrower than the word "grounding" suggests. The matched configuration-item names and types are flattened to a single inert line and capped at 128 characters before they enter the prompt. The schema grounding around them, including the source names and scope labels that SHOW SOURCES returns, is placed in the prompt exactly as your source systems wrote it, bounded only by an overall size limit. Neither is a privacy control: both reach the provider either way.

The website advisor sends whatever the visitor types, a system prompt built from the public product knowledge base, and the schemas of the product-facing tools it can call. No tenant data reaches this surface. What visitors do type, in practice, includes a description of their own environment along with their employer and contact details, and that text goes to the provider with the rest of the conversation.

Where it goes

Both surfaces egress from one pod, the control-plane API, and as provisioned that pod is the only place in the platform with a network route to a model provider. Your tenant's namespace runs default-deny egress and carries no policy permitting an outbound connection to a provider endpoint, so a tenant pod cannot reach one. A translation request travels from your tenant's API to the control plane over the internal cluster network, and the control plane makes the provider call on your behalf. It holds the prompt in memory for the length of the turn, logs none of its content, and writes only token counts and cost.

The provider is Anthropic. Calls are made under one platform API key, so there is no per-tenant provider identity: the provider sees a single account, and prompts from different tenants are not distinguishable to any provider-side control that keys on the account or the key. The per-tenant attribution that our spend records carry is ours, recorded on our side, and it creates nothing at the provider.

Anthropic is the only model provider on the sub-processor list. Adding one or changing one means updating that list first, under the 30-day notice described in Sub-processors.

What is kept, and for how long

Store	What it holds	Kept for
Your tenant's security audit log	Each translation: the first 500 characters of your message, the generated query, and the explanation	90 days, then swept
Advisor conversation store	The full transcript, plus the prospect's email address and client IP	90 days, then swept
Our CRM, on a captured lead	Email address, company, described stack, and the model-written summary of the conversation	Until an erasure request
Spend ledgers	Token counts, cost in EUR, request counts, tenant slug and user id. No prompt text	90 days
Application logs	A 200-character excerpt of each generated query, which can echo identifiers you typed. No user message, no advisor transcript	30 days
Anthropic	The prompt and the response, under its published data retention policy	Up to 30 days, with the exceptions it lists

The log row is a separate copy on a shorter clock. A query excerpt in the logs is dropped at 30 days while the audit-log record of the same translation is kept for 90, so the two do not expire together.

The CRM row is deliberate. A captured lead is a business record and it persists until someone asks for it to be erased, which is a different bound from the 90-day transcript sweep and is stated here so the difference is visible. Erasure requests go to privacy@parascope.io and cover the CRM copy along with the transcript. Both are removed from the live stores when we action the request. The encrypted backup copies of those databases are not edited to remove individual rows; they age out on the schedules in Availability, Backups and Disaster Recovery, roughly ninety days at the outside.

The spend ledgers count tokens and cost. They are not a record of what anyone asked, and they should not be read as one.

Training and the provider's terms

The account runs on Anthropic's standard paid API terms, and we point you at the provider's own published documents so you can read the commitments in their original form.

Training. Anthropic's Commercial Terms of Service state that Anthropic may not train models on customer content from the services.
Retention. Anthropic's published data retention policy states that API inputs and outputs are deleted on its backend within 30 days of receipt or generation, subject to the exceptions the policy names.
Data processing agreement. Those same commercial terms incorporate Anthropic's Data Processing Addendum by reference, so a DPA is in force for this processing. We verified this on 2026-08-02.

This account holds no separately negotiated zero-retention agreement, and this page claims none. Prompt caching is enabled on the system portion of a translation prompt; the lifetime and storage of that cache are the provider's, governed by the terms above.

How model output is gated

A model response is data to be validated before anything acts on it. Every surface validates output against an explicit expected shape, and a validation failure means the action does not happen.

The natural-language endpoint returns a translation and does not run it. The query lands in your editor for you to read, edit and run. There is no path from a model response to an executed query on that endpoint.
The CLI asks for confirmation before executing a translated query, unless you turn that prompt off.
The MCP tool auto-executes only a query proven to be a bare, bounded read. Anything outside that shape is surfaced for explicit confirmation.
Advisor lead capture passes a fail-closed field whitelist before any record is written, under a per-IP daily write cap. Every record written is labelled unverified, and the prospect's own text is wrapped as quoted data.
Collector-sourced names and values returned through MCP tools are neutralized to a markdown-inert form and wrapped in a delimited envelope that marks the payload as quoted data for reporting.

Adversarial injection suites cover each of these gates and run in the pipeline that gates every merge, so a regression that lets a payload through blocks the change from landing. Software Development and Supply Chain describes that gate.

The controls you have

You can turn natural-language translation off for your tenant. It is a per-tenant setting. With it off, the endpoint refuses the request, the sidebar does not open, and no prompt leaves the platform for your tenant. The setting is applied by us on request to hello@parascope.io; it is not a switch in the interface today. The tenant status endpoint reports which state your tenant is in, so you can confirm the change from your own side.

You can ask for erasure. Requests to privacy@parascope.io reach both the advisor transcript store and the CRM lead record. Data Handling and Privacy covers the wider data-subject request path.

Spend caps exist, and they bound cost. A per-tenant daily cap and a fleet-wide cap are enforced by our own code before a provider call is made, and a request over a cap is refused before any data is sent. They are cost controls. A cap says nothing about who can see what, and it should not be read as a data-protection measure.

What this page does not claim

No zero-retention arrangement with the provider. The bound is the provider's published 30-day policy, quoted above.
No per-tenant boundary at the provider. One account, one key. A per-tenant retention setting or opt-out at the provider cannot be expressed under that arrangement.
No redaction of your configuration-item names. Permission filtering decides which names are eligible to be sent. Eligible names are sent as they are.
No claim about a second provider. The code carries a provider switch that has never been flipped, and flipping it would mean listing the new provider as a sub-processor before any prompt reached it.

Verify it yourself

Watch a translation happen. Open the sidebar in the query console, ask a question, and read the grounding the answer reflects back. What the model was given is what the answer is built from.
Read your own audit trail. Settings → Audit Log records each translation as a paraql_nl_translate event with the message excerpt, the generated query, and the model that served it. Superadmin access is required. Security Audit Log covers filtering and CSV export.
Check whether the feature is on. GET /api/v1/paraql/nl/status on your tenant reports whether translation is enabled and which backend mode the pod is in.
Use the advisor and see what it can reach. The chat on parascope.io answers from the public product knowledge base. Ask it for something from a customer's environment and watch it come back empty.
Read the provider's terms yourself. The Commercial Terms of Service and the data retention policy are published by Anthropic and need nothing from us to read.
Controls with their own verify pointers are listed in the control matrix.

AI Features and Your Data