Skip to main content

​
Choose what you send

Ordinary SDK tracing starts with captureContent: false. Inputs and outputs are omitted, and attributes are limited to supported operational metadata. Operation names, repository references and other metadata can still identify people or customers; use stable, non-sensitive names. Enable captureContent: true only for data you are authorized to provide. Supply a project-specific redact function in your application when additional filtering is needed, and test with synthetic data before capturing real interactions. Filtering in your application can remove information before it leaves that application. Explicit evaluateSystem calls are a separate test path: they capture redacted test inputs, expected outcomes and execution evidence into a local report even when ordinary trace content capture is off. Uploading that report requires a separate publishSystemEvaluation call. Use synthetic cases and inspect the report before sharing it. See application evaluation.

​
What redaction covers

The SDK and API apply pattern-based redaction to selected fields. The API’s baseline layer replaces common secret formats, email addresses and supported phone-number patterns. When it can parse structured JSON, it also redacts a defined set of sensitive field names and processes nested values. SDK → Privacy controls adds optional filtering for valid IPv4 patterns, payment-card-like number patterns that pass a checksum, and additional JSON field names such as customer_ref. Named fields are matched without regard to case. Enable Extra PII patterns, enter any additional fields and save the settings for the selected repository and branch. These settings apply to future trace ingestion under your own keys for that repository and branch. They do not clean previously saved records or configure every member’s keys, context documents or application test reports. Baseline filtering remains enabled when the additional option is off. This processing uses local pattern and field matching inside the SDK or Bench API process; it does not call a language model to detect personal information. API-side filtering takes place after submission to Bench. There is no named-entity recognition or general anonymization guarantee. Names in prose, addresses, medical information, domain identifiers, unfamiliar formats and identifying combinations can remain. Pattern matching can also remove legitimate values. Pre-redact or exclude data that must not be submitted, and use deletion controls for already stored evidence.

​
Access and credentials

API requests are authenticated and scoped to the user’s permitted records. API keys can restrict repositories and evaluation spending; organization read access does not by itself grant mutation rights. A repository-restricted key must have access to all repositories used by the selected system. Keep SDK keys in server-only configuration. The default setup key has zero evaluation allowance. Receiving a trace does not start a paid check or establish that every deployment is instrumented. Revoke a key when it is no longer needed. Imported-source connector credentials are encrypted using AES-GCM with a separate deployment-managed key. Connector configuration requires HTTPS and approved hosts. These controls describe those credentials and connections; they are not a statement that every storage system or every internal network hop has been independently verified. See context setup and SDK setup.

​
Processing and storage

Bench stores the traces, context, cases and reports you send. Starting an evaluation sends the selected evidence for evaluation processing. Recording a trace alone does not enable an optional additional check. Bench uses AWS for database infrastructure. Storage location does not establish where every evaluation is processed. Contact Bench before submitting data with specific processing-location or contractual requirements. See retention and deletion for what expires and what deletion removes.