Security and privacy controls

Control what you send, understand automatic redaction and add your own sensitive fields.

Copy this into your coding agent

Use this prompt in Cursor, Codex, Claude Code or another coding agent:

Check my Bench SDK setup for sensitive data. Keep ordinary trace content capture
off unless I explicitly enable it. Use stable, non-sensitive operation names.
Find application-specific fields that should be removed, add a redact function
before transmission, and test it with synthetic values. Do not send real customer
data while testing. Read https://docs.usebench.ai/guides/security-and-privacy.

Choose what you send

Ordinary SDK tracing starts with content capture off. The option is captureContent in TypeScript, capture_content in Python and Rust, and CaptureContent in Go. 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 content capture 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.

How redaction works

Each SDK filters enabled content before sending it. Bench applies server-side filtering again before saving submitted event content. It uses field names and pattern matching, without asking a language model to read the content. Built-in filtering is always on.

What Bench recognizes	How it is filtered
Common secrets and access tokens	Recognized formats become [REDACTED_SECRET].
Email addresses and supported international phone numbers	Recognized patterns become [REDACTED_EMAIL] or [REDACTED_PHONE].
IPv4 addresses	Valid addresses become [REDACTED_IP].
Payment-card numbers	Recognized 13 to 19 digit formats that pass a checksum become [REDACTED_PAYMENT_NUMBER].
Sensitive JSON fields	Fields such as password, email, phone, full_name, ip_address and card_number have their whole value replaced with [REDACTED].

JSON objects, arrays and JSON encoded inside strings are processed recursively. Field matching ignores capitalization. Recognized identifiers in JSON keys are filtered too. Numeric card values are checked, including integral decimal and exponent representations. Ordinary numbers retain their type and value.

Add your own fields

In SDK → Privacy controls, enter extra JSON field names, separated by commas, then choose Save. For example, customer_ref, account_number removes the values of those fields from new events. You do not need to enable the built-in filters.

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 real app test reports.

What these filters cannot detect

Pattern matching is not complete anonymization. Names in prose, postal addresses, medical details, IPv6 addresses, unfamiliar formats and combinations that identify someone can remain. Matching can also remove legitimate values.

API filtering happens after the content reaches Bench. Keep content capture off or use the SDK’s redact function to remove anything that must not leave your app. 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.

GitHub repositories connect through the Bench GitHub App. Bench uses the App’s server-side private key to obtain short-lived installation tokens, and GitHub enforces the repositories and permissions granted to that installation. Connecting does not require a separate GitHub OAuth authorization or client secret. 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.