Privacy Policy

1. Who we are

srooter is operated by WorkHub Platform Inc., c/o Raie & co, 1875 S. Bascom Ave, Suite 2400, Campbell, CA, United States. For any privacy question or request, contact us via workhub.ai/contact.

2. Information we collect

We collect only what we need to operate the service:

• Account & organization data. Name, work email, role, and organization, supplied at sign-up, waitlist, or via your SSO provider.
• Gateway metadata. For each request routed through srooter we record the requested and served model, route reason, token counts, cost, latency, and status, scoped to your organization.
• Provider credentials. API keys and OAuth tokens you connect, stored encrypted at rest and used solely to reach the providers you configure. srooter will not save them unless an encryption key is configured.
• Conversation content. Transcripts, session memory and, if you opt in, session history. See section 3.
• Other content you or your tools send us. Indexed documentation, srooter Assistant conversations, organization memory, risk-review findings, imported agent instruction files, and questions asked through the assistant on our website. See section 3.

3. Prompt, conversation and other content

srooter stores some of the content that passes through it. This section explains what is stored, how it is protected, how long it is kept, who can see it, and how to turn it off.

• Audit log. Every request gets an audit record containing the metadata in section 2 and a SHA-256 hash of the prompt. The audit record does not contain prompt or response text.
• Conversation transcripts. srooter records the messages your coding tools send through the gateway's Anthropic- and OpenAI-compatible endpoints, and the model responses it observes, so that sessions can be reviewed and failures diagnosed. Because tools include files and command output in their prompts, transcripts can contain source code and anything else a tool sends. Transcript capture is on by default for each organization. The review, council and MCP endpoints are separate capture sources that are off by default. They are recorded only if they are enabled for your organization, and srooter does not currently offer a setting that enables them.
• Session memory. For Anthropic-format requests (for example from Claude Code), srooter keeps a short working record of each session: the opening request (up to 2,000 characters), the paths of files the session edited or wrote (through Edit, Write or NotebookEdit tool calls), and the text of tool errors. Today it is a record you can inspect: developers see their own sessions in the dashboard (Session memory) and in srooter Studio, and admins see those of their organization, including through the dashboard's Cortex search. Its content is not currently added back into your agents' requests.
• Session history. An optional feature that tags sessions for follow-up. It is off by default and records nothing unless both your organization and the individual user turn it on. Keeping a text excerpt requires a further opt-in. At most 500 open items are kept per organization. Resolved items older than 30 days are removed the next time session history is read or written, not on a fixed schedule.

Encryption. When an encryption key (SROOTER_SECRETS_KEY) is configured, transcript and session-memory content is encrypted by the application before it is written to the database, using Fernet (AES-128 in CBC mode with HMAC-SHA256 authentication). The managed service runs with this key set, and its startup log reports transcript content as encrypted. The key is managed by srooter as the operator of the service; it is not a separate key per customer. Without the key, session memory is stored unencrypted, and transcripts are either not recorded or, if the operator explicitly allows it, stored unencrypted. In a self-hosted deployment you control this setting.

Retention. Transcripts have a retention setting of 30 days by default. An organization admin can shorten it to as little as 1 day; a longer period can only be set by srooter, on request. Expired transcripts are currently removed by a cleanup that runs when the service restarts, and only for organizations that have saved their capture settings, so content can remain longer than the configured period. Removed content also remains in database backups until those backups expire. Session memory does not expire automatically; it is kept until the session is deleted. You can ask us to delete any of this content at any time.

Who can see it. Developers can read their own transcripts in the dashboard (Transcripts). Organization admins can read the transcripts of everyone in their organization. Transcripts are shown as written; they are not redacted. When an admin opens the text of someone else's transcript, the read is recorded in an access log, at most once per admin, session and hour; viewing a transcript's outline without its text is not logged. Admins can review that log through the admin API (GET /admin/ledger/access). Admins can also see session memory across their organization.

Turning it off. An organization admin can turn transcript capture off, or change the retention period, through the admin API (PUT /admin/ledger/config). The dashboard does not yet have a switch for this, so you can also ask us to change it for you. Turning capture off stops new recording; it does not delete what is already stored. Session memory cannot currently be turned off. In a self-hosted deployment all of this stays inside your own infrastructure (see section 5).

Other content we store. The following are stored as plain text in the database: they are not encrypted by the application, have no automatic expiry, and are kept until you ask us to delete them unless noted.

• Indexed documentation. When you index a project into Cortex, the text of its documentation files is stored in sections, after AWS access keys and sk-/pk-/rk- style API keys are removed. Other secrets in those files are not removed. Re-indexing replaces it, and clearing the project's docs deletes it. The code graph itself keeps symbol names, file paths, dependencies and docstring-derived intent, not the contents of your source files.
• srooter Assistant conversations. The questions you ask the assistant in the dashboard and its answers.
• Organization memory. Short notes srooter keeps to improve routing: when a developer pushes back on an answer, up to 160 characters of their message; and the verdicts from council reviews.
• Risk-review findings. Model-written descriptions of risky edits and the corrective note shown to the agent. These can quote code.
• Agent instruction files. The text of instruction files (such as CLAUDE.md or AGENTS.md) that you import into srooter.
• Website assistant. If you use the assistant on our public website, the email address you enter, your question and the answer. Your IP address is stored only as a hash.

4. How we use information

We use the data above to route and govern requests, enforce your organization's policies and budgets, produce audit and billing records, secure the service, and provide support. We do not sell your data and we do not use your prompts, responses, or code to train models.

5. Self-hosted deployments

When srooter is self-hosted inside your own infrastructure (Enterprise mode), all gateway data, credentials, and audit logs remain within your environment. WorkHub does not receive your request metadata or credentials in that configuration.

6. Sharing & sub-processors

For the managed (cloud) service we rely on infrastructure sub-processors (e.g. hosting and database providers) under confidentiality obligations. Requests you route are sent to the AI providers you explicitly configure; their handling of that data is governed by their own terms.

7. Data retention

Account and audit records are retained for the life of your account and any period required for legal, billing, or compliance purposes, after which they are deleted or anonymized. Conversation content has its own retention, described in section 3. You can request export or deletion of your organization's data at any time.

8. Security

Provider credentials are encrypted at rest, and conversation content is encrypted as described in section 3. Access is role-based, and all administrative access requires authentication. No method of transmission or storage is perfectly secure, but we take reasonable measures appropriate to the sensitivity of the data.

9. Your rights

Depending on your jurisdiction you may have rights to access, correct, export, or delete your personal data, and to object to or restrict certain processing. To exercise these rights, contact us at workhub.ai/contact.

10. Changes to this policy

We may update this policy from time to time. Material changes will be reflected by the “Last updated” date above and, where appropriate, communicated to account administrators.