Security overview
This page answers the questions district IT leaders ask us most, in the order they ask them. The short version of every answer: the strong guarantees in DistrictWise are architectural — they hold because of how the system is built, not because a policy says so.
What can reach the server that holds your data
Only ports 443 and 80 — the website itself — accept inbound connections. SSH is closed to the internet entirely; administrative access runs over a private network, never the public internet. The server's default policy for anything else is deny.
The server never runs a web browser. Not Chrome, not Chromium, not even Node, inside the container that serves your questions. A browser is the classic way a server gets compromised by hostile content — there isn't one here to attack. It also never crawls or fetches arbitrary sites; its outbound connections go to a short, known list — the AI provider, our cloud infrastructure, and system updates. Any web scraping DistrictWise does happens on separate infrastructure and never touches the machine holding your data.
Does one district's data influence results for another district?
No — structurally impossible in the current architecture. There is no training loop, no shared index, and no cross-tenant retrieval path. Nothing a district's staff types can change what any other district's staff sees.
- No fine-tuning, anywhere. The model is Anthropic's stock Claude via API; the codebase contains no training or feedback code. Anthropic's standard commercial API terms bar training on our traffic.
- Retrieval is per-district. Search runs against one district's corpus per request, in that district's own index. Other tenants' indexes are never loaded. Vector embeddings are computed locally on our server and cached inside the district's own corpus store.
- Queries don't feed anything. Usage logs exist for billing and quality; nothing is ever read back into retrieval, ranking, or any model.
What is shared across customers is the product itself: the application code and the California Ed Code layer (public statute). Nothing derived from any customer's query stream is shared. Full detail: AI transparency.
How are tenants isolated?
Every staff seat is cryptographically bound to its district when it is provisioned. A request that names any other district is refused at the API layer with a 403 — on answers, rule findings, change feeds, and incident filing alike. The binding survives PIN resends and seat reassignment. There is no district picker anywhere in the staff product, because a seat can only ever see its own district.
What happens to student names?
They are masked in the browser, before transmission. Names, emails, phone numbers, addresses, and cued student IDs are replaced with placeholders on the user's device; the map to restore them never leaves the browser. The masking is fail-closed — if it cannot verify success, the request is blocked and nothing is sent. Un-masked student identity does not reach our servers or the AI model. Full detail, including honest limitations: privacy policy §2.
Your corpus is physically read-only
Your policy library is mounted read-only in the serving environment. The application cannot modify or corrupt it — not through a bug, not through an attack. It is enforced by the filesystem, not by application logic that could have a bug in it.
How is access controlled?
- Licensed seats only — each seat is an individual staff email, provisioned by agreement with the district
- Repeated failed sign-in attempts are throttled by account and by source address, and the source address cannot be spoofed by a client-supplied header
- A sign-in attempt for an unknown email and a licensed one return identical responses, so the system cannot be used to discover who holds an account
- Administrative access to the production system is over a private network only — the box exposes HTTPS to the public internet and nothing else
Infrastructure
- TLS for all traffic; standard browser protections are enforced (HSTS, clickjacking protection on sign-in, MIME-sniffing protection, and a referrer policy that keeps a question from leaking to a third party)
- Secrets are held off the application tree with restricted OS permissions; no credential has ever been committed to source control
- Transactional email is sent through a scoped cloud identity limited to our own sending domain — not a stored password or API key that could be exfiltrated
Reporting a security concern
If you believe you've found a security issue, email [email protected]. We will acknowledge reports within three business days and keep you updated as we investigate.
What we don't have yet
A security review deserves the gaps, not just the strengths:
- We have not completed a third-party security audit or SOC 2 report.
- Outbound traffic from the production server is not allowlisted by destination — it is limited by what the application actually does (see above), but the network layer itself does not block arbitrary outbound connections. We're evaluating egress filtering as additional hardening.
- Security reviews to date have been performed internally, not by an independent third party.
- We do not publish a recovery-point or recovery-time objective, and our agreements do not commit to one. We will publish targets only after a backup regime is in place and a restore has been tested and evidenced — not before.
In writing
Our Data Processing Agreement commits contractually to what the architecture already enforces: customer data is not used to train or fine-tune any model, nor to provide services to any other customer. We put it in the contract because a written commitment should outlive any future architecture decision.
Questions your review needs answered that aren't here? Ask us directly — technical answers from the people who built it, not a sales layer.