For platform and security engineering

Developers choose their agents.
You own how engineering gets done.

Srooter is not an IDE and does not replace Claude Code or Cursor. It is the organizational layer around them: define context, practice, review and model policy once, and it applies to every agent, on every model.

ORG POLICY · acme-platformsrooter.yaml
practice:
tdd: required # tests before implementation
validation: functional + visual
review: council # independent of author model
models:
allow: [glm-5.3, claude-*, ollama/qwen3]
sensitive_repos: ollama/* # never leaves your infra
budget.team.payments: $4,000/mo · on_exceed: downgrade
governance:
sso: okta · residency: eu-west · audit: on
exceptions: approved-by platform-leads
THE CHECKLIST

The six questions every CTO asks. Answered.

Forward this page internally. Each answer names the mechanism, so your security review has something concrete to check.

01

What do developers install or change?

One environment variable, or `srooterctl shell` for a session-scoped setup. Claude Code, Codex, Cursor and aider keep working as they do today. Start with one repository; Srooter indexes it and the harness applies from the next task.

OpenAI- and Anthropic-compatible endpoint · SessionStart indexing
02

What can developers bypass, and who approves exceptions?

Practice and model policy are set at the org level and apply per task. Exceptions are requested in-session and approved by the roles you designate; every exception is recorded in the audit ledger with who, what and why.

policy engine · allowlists · audit ledger
03

What leaves our infrastructure?

Requests to the models you allow, routed through Srooter or your self-hosted gateway. Prompts are hashed and redacted for audit (never stored in plaintext). Your code never executes in Srooter; tests run in your CI. Sensitive repos can be pinned to local models so nothing leaves your network.

prompt redaction · client-side test execution · Ollama / sovereign endpoints
04

What happens when Srooter or a provider is down?

Circuit breakers detect the outage; transport failover moves the session to an alternate provider without a quality downgrade and keeps it there for the session. Over-budget requests downgrade silently rather than block a developer mid-task.

circuit breakers · session-sticky transport failover · silent downgrade
05

Why this instead of agent config plus CI plus an open-source harness?

Because those pieces do not share a code graph, a memory, a review council or a decision ledger. Srooter ships them as one system that already knows your repository, and applies identically to every agent, so standardizing on a tool never means standardizing on its limits.

Cortex code graph · Mnemos · Council · provenance
06

What does it cost in money, latency and operations?

Seat pricing plus tokens at cost; most teams spend less overall because routine work runs on efficient models. Routing adds a single in-band pass. Operations: a hosted service, or a gateway you run with auto-update.

tokens-to-done · one in-band stream · gateway auto-update
DATA BOUNDARIES

What leaves your infrastructure. What never does.

Srooter never executes your code. Tests run in your CI. Sensitive repositories can be pinned to local or sovereign models so no token leaves your network.

STAYS WITH YOU
✓Your source code · never executed by Srooter; tests run in your CI
✓Sensitive repositories · pinned to local or sovereign models by policy
✓Provider credentials · BYOK, encrypted at rest, per org
✓Prompt plaintext · hashed and redacted before audit storage
✓Your region · data residency pinning per org
GOES TO SROOTER (OR YOUR SELF-HOSTED GATEWAY)
→Model requests · to the providers you allow, through the gateway
→Code graph index · symbols and edges for context assembly, or on your self-hosted gateway
→Task memory · typed, per-session, with decay and eviction
→Audit records · every routing and review decision, exportable
KEEP YOUR TOOLS

Already standardized on Cursor? Good. Srooter makes it operate according to your organization.

HARNESS LAYER
Claude Code
Codex
Cursor
aider
srooterctl
Context and knowledge
●
●
●
●
●
Memory
●
●
●
●
●
Model policy and budgets
●
●
●
●
●
Engineering practice
●
●
●
●
○
Gates in your CI
●
●
●
●
●
Independent review
●
●
●
●
●
Audit and provenance
●
●
●
●
●
applied by Srooteron the roadmap
DEPLOYMENT

Centrally managed. Runs where you need it.

Cloud SaaSMulti-tenant, api.srooter.ai
Live
Self-hosted gatewaySingle-tenant, your infrastructure, auto-update
Available
BYOKYour provider keys, encrypted at rest
Available
Local and sovereign modelsOllama and internal endpoints
Available
SSO · data residency · audit exportOIDC / SAML, region pinning, ledger export
Available
Full VPC harness · HelmComplete harness inside your VPC
Talk to us
Cloud marketplacesAWS · Azure · GCP procurement
Roadmap
ROLLOUT

Start with one repository. Expand by policy.

  1. Week 1
    One repository, one teamIndex the repo, connect the agents, apply your existing standards as policy.
  2. Week 2
    Turn on review and validationCouncil review and functional plus visual validation on every change. Watch the audit ledger.
  3. Week 3
    Set model policy and budgetsAllowlists, risk-tier routing, per-team budgets, sensitive repos on local models.
  4. Then
    Expand by policy, not by installsNew repos and teams inherit the harness. Developers keep choosing their tools.
# developers change one line
export ANTHROPIC_BASE_URL=api.srooter.ai
# or srooterctl shell # session-scoped, no global env change

See Srooter on your stack.
One repository, your agents, your policy, in a week.

Get Started →See enterprise pricing
srooter> — the engineering harness for AI coding agents