Built for the team that has to answer for it.
srooter is the engineering harness your org's AI runs through, so its own security posture is the product. Here's exactly how we handle your code, your keys, and your data, and where we are on formal certification. No hand-waving.
What we store, and how.
Every request through the gateway gets an audit record of metadata and a prompt hash. Separately, srooter keeps a record of conversation content (encrypted on the managed service) so sessions can be reviewed and debugged, and stores some other content listed below. The Privacy Policy has the full details.
Audit log, for every request
- The request envelope. Timestamp, user/key id, requested vs. served model.
- The routing decision. Trivial, council, learned, or fallback.
- Token counts, cost, latency, and status for every call.
- A SHA-256 hash of the prompt. The audit record itself holds no prompt or response text.
Conversation content
- Transcripts. The messages your coding tools send through the gateway and the model responses it observes. This can include code your tools put in prompts. On by default; an org admin can turn it off.
- Session memory. For Anthropic-format traffic: a session's opening request (up to 2,000 characters), the paths of files it edited or wrote, and tool error text.
- Encrypted, with a retention setting. When
SROOTER_SECRETS_KEYis set, as it is on the managed service, this content is encrypted by the application before it is stored. Self-hosted operators control that setting. Transcripts have a retention setting of 30 days by default, which admins can shorten. - Session history is opt-in. Off unless both the org and the user turn it on.
Other content
- Indexed documentation text. The documentation files you index into Cortex, stored after AWS and
sk--style keys are scrubbed. - Assistant and review records. srooter Assistant conversations, short organization-memory notes, risk-review findings, imported agent instruction files, and questions asked through our website assistant.
- Stored as plain text. These are not encrypted by the application. The Privacy Policy lists each one.
What we don't store
- Your source files in the code graph. Cortex keeps symbol names, file paths, and dependencies, not file contents. Code sent inside a conversation is part of the transcript above.
- Provider keys in plaintext. Credentials are encrypted at rest.
- Your data on our servers, in self-hosted mode. The gateway and everything it records stay in your infrastructure.
The strongest controls aren't bolted on. They're how it's built.
Hashed audit, transcripts you control
The audit log holds a hash of each prompt, not its text. Conversation transcripts are encrypted at rest on the managed service, have a 30-day default retention setting, and can be turned off per organization.
Self-host in your VPC
Run the entire gateway inside your own infrastructure, up to fully air-gapped. Your keys, your data, your perimeter.
Your keys
Bring your own API keys, or local models. srooter never resells inference and never sits in your billing path.
Encrypted in transit & at rest
TLS in transit. Provider credentials are always encrypted by the application (Fernet: AES-128 with HMAC-SHA256 authentication); srooter refuses to save them without an encryption key. Transcripts and session memory are encrypted the same way when SROOTER_SECRETS_KEY is set, as it is on the managed service.
Exportable audit trail
Every routing and policy decision is logged and exportable for review, billing, or your auditor.
Role-based access & policy
RBAC across the org, model allowlists, reasoning caps, and hard budget ceilings, enforced at the gateway.
You run our code inside your perimeter. We treat that as a responsibility.
Self-hosting answers data residency, but it makes build integrity the question that matters. Here's how we keep what you deploy trustworthy.
Signed releases
Every release is cryptographically signed so you can verify exactly what you're running.
SBOM with every build
A full software bill of materials ships with each release for your own supply-chain review.
Pinned, scanned dependencies
Dependencies are pinned and continuously scanned for known vulnerabilities and tampering.
Where we are, stated plainly.
The honest version: we're early, and formal certifications are underway rather than finished. We won't display a badge we haven't earned. But because srooter can be self-hosted, with everything it records kept in your infrastructure, security-conscious teams don't have to wait for our paper trail to adopt it. Run it in your own VPC today, keep every byte inside your perimeter, and we'll meet your security review where you need us. As each certification lands, this page updates with the report.
In self-hosted mode, the answer is: nowhere new.
Found something? Tell us.
Report a vulnerability privately and we'll acknowledge within two business days, keep you updated through the fix, and credit you if you'd like. Please don't disclose publicly until we've resolved it. Reach us at security@workhub.ai.
Bring your questionnaire. We'll answer every line.
Evaluating srooter for a regulated or security-conscious team? Send your vendor security questionnaire and we'll work through it with you, and get you self-hosted so nothing leaves your perimeter in the meantime.