Built to be audited
A governance layer has to be trustworthy itself. Here is how runlaw stores data, protects credentials and limits abuse, including what it doesn't do yet.
Where it runs
runlaw runs on Cloudflare's global network as a Worker. Each workspace's policies, traces and approvals live in their own Durable Object, a separate, strongly consistent storage instance that only that workspace's requests reach.
- Account records (users, sessions, API keys, credit balances) are held in a separate store from workspace data.
- All traffic is served over HTTPS.
- Model calls are forwarded to the upstream provider (OpenAI today) from the gateway, using the deployment's provider account.
Passwords, keys and sessions
- Passwords are hashed with PBKDF2-SHA-256 (100,000 iterations) and a per-account random salt. They are never stored or logged in plain text.
- API keys and session tokens are stored only as SHA-256 hashes. A key is shown once, when it's created; revoking it takes effect on the next request.
- Sign-in sessions use an
HttpOnly,Secure,SameSite=Laxcookie and last 30 days. - There is no email-based password reset, so there is no reset link to intercept.
Rate limits and lockouts
- Sign-in, sign-up and access requests are rate-limited per network address.
- After five failed sign-ins, an email address is locked for 15 minutes.
- Each account has a gateway limit in calls per minute and a credit balance; calls beyond either are refused with standard
429and402errors. - Suspending an account signs it out and stops its API keys immediately.
What is stored
For each call, a trace keeps the original request, the provider's response, what was returned to your client, every rule's outcome with its evidence, latency and token counts. Traces keep the original request so you can audit exactly what a rule changed; they are readable only with your sign-in or API key.
- The most recent 5,000 traces per workspace are kept; older ones are deleted automatically.
- Redaction rules apply before the request is forwarded, so redacted values never reach the model provider.
- Plain-language rules are judged by a model call made by the gateway; the text being judged is sent to the provider for that check.
What runlaw does not do
- Plain-language rulings are model judgements and can be wrong. Exact rules on personal data, patterns and tool arguments are deterministic.
- runlaw sees what passes through the gateway. It does not see a provider's hidden reasoning, or what your code does after a tool call.
- Approving a held tool call records the decision; it does not execute the action.
- runlaw does not yet offer SSO, configurable retention, data-residency choices or third-party certifications. If you need these, tell us when you request access.
