Client applications
The form sends your name, work email, company, country, optional website, password, workload description, and adult/professional eligibility acknowledgment to Tbench’s existing account service. The service records the eligibility policy version alongside the application time. The workload description is labeled as an Actions application. Tbench administrators review it to decide whether to approve client access and discuss a pilot.
The account service hashes the password rather than storing it in readable form. Do not submit repository source, access tokens, customer datasets, or other secrets in the description. Submitting does not subscribe you to paid compute.
Sign-in and essential session storage
The public frontend runs in Docker on AWS and sends authentication requests server-to-server to Tbench’s account service. Hosting and account infrastructure may process request metadata, such as IP addresses and timestamps, to operate and protect the service. Company sign-in uses your configured identity provider. The work-email discovery form sends only the domain to find a configured provider, not your individual address.
After approved client sign-in, Actions stores an authentication token in an HTTP-only, secure, host-only cookie. Browser JavaScript cannot read that cookie. Its browser cookie is separate from the main and experts websites, but all use the shared account service. Signing out requests revocation of all account sessions and removes the Actions browser cookie. If the account service cannot confirm revocation, you are signed out locally and shown a notice; other account sessions may remain valid until revoked or expired.
This frontend does not add advertising, session replay, or third-party analytics scripts. Essential hosting logs are distinct from application analytics.
Execution metadata
The separate operator console uses an eight-hour secure, HTTP-only session cookie. Tbench’s configured private control-state store retains worker names, enrollment and activity timestamps, hashed worker credentials, request IDs, workflow and commit IDs, outcomes, cancellation requests and event history. Frontend hosting and control-state storage are separate: the GitHub runner-control authority is the private PostgreSQL service on AWS. Historical Blob data is retained separately from the active authority. The current GitHub register retains up to 100 requests per installation; older evidence requires explicit operator handling.
GitHub stores the private repository, workflow logs and artifacts on its integration path. Published test runs configure uploaded artifacts for seven-day retention. GitHub App keys remain on the hosted Actions broker, not on enrolled devices. Devices store a revocable, installation-scoped worker credential and receive short-lived, one-job runner configuration; the GitHub App key is not sent to a device or job container. Workflow secrets that GitHub grants to a job can still be visible to that job and its host. Published execution summaries contain allowlisted results and hashes.
The independent Tbench queue stores approved policy commands and limits, logical repository names, exact commit hashes, enrollment metadata, fenced leases and bounded result metadata in the account backend. Policy documents must not contain secrets. Repository source is prepared in an organization-controlled local Git cache; it is not uploaded to that queue. Devices retain their scoped credential, repository mapping and private recovery receipts.
Trial activation and expiry are stored by the account service and checked server-side. The 15-day organization trial does not create an automatic payment authorization. Customer code, secrets and retention requirements are agreed during organization onboarding. Worker credentials can be revoked after active work is resolved.
Questions, corrections, and deletion requests
Contact support@tbench.in for account-data questions or to request a correction or deletion. Include the account email and request, but never your password. Identity verification may be needed before changes are made.
Applications and account records are held in the shared Tbench account system. Retention and deletion requests are handled by our team. Agree on the data-handling scope before a pilot involving customer code, logs or infrastructure.
Optional AI repair and approval records
An organization can enable local AI repair for explicitly selected source files. Model responses, candidate patches and raw retest logs stay on the developer’s computer. Publishing a repair proposal sends the new branch and code to the organization’s GitHub repository. Tbench stores the repository and pull-request identifiers, commit and policy hashes, retest conclusions, approval expiry, mapped approver and merge outcome. A configured Slack channel receives the proposal link and a bounded results summary. Slack approval remains subject to current organization and GitHub permissions and protected-branch checks.
An explicitly approved OpenRouter profile sends only the selected source files, requirement text and bounded test feedback directly to OpenRouter. Its owner chooses the provider retention policy; zero-data-retention routing is enabled by default and requests deny provider data collection. An owner can explicitly approve collection for nonconfidential, publication-safe input; that profile cannot also require zero retention. The host-only model key is consumed before Git and job subprocesses and is never included in the profile, repair evidence or job container. Provider responses and local evidence are distinct from the metadata stored by the Tbench control service.
Connected Jira and Confluence requirements use explicit organization consent and selected resources. Provider credentials and tracked contributor account identifiers are encrypted. Saved snapshots may contain personal data present in the selected issue or page; the supported scope is professional requirements with provider-identified authors and contributors. The connector tracks retained revisions for provider reporting and invalidates affected revisions when processing a provider erasure instruction. Metadata-only links remain available when selected text is unnecessary.