Skip to main content
Configuration lives at two levels:
  • Workspace: master toggle, classifier model, metering, optional proxy pre‑prompt. One per tenant.
  • App: thresholds, detectors, custom phrases, custom PII rules, tool policy, forbidden‑provider routing. Many per workspace.
Workspace settings are the floor; App settings are the per‑surface override.

Workspace config

Endpoints

  • GET /api/runtime-security/config, requires runtime_security.view.
  • PUT /api/runtime-security/config, requires runtime_security.manage. Toggling enabled scales the firewall service up or down.

Payload

App config

Endpoints

  • GET /api/runtime-security/apps/{id}/config-versions, list version history.
  • PUT /api/runtime-security/apps/{id}/config, publish a new version.
Every write creates a new config_version_number linked to the event row that produced it. The change_summary field captures the operator’s reason.

Payload

Custom PII rules

Two layers, both queried at scan time:
  1. Per‑App rules, pii_rules on the App config above. Edited inline; versioned on every write.
  2. Workspace‑shared rules, set via the Custom Rules endpoints (/api/custom-rules/...). Apply across the workspace and across batch / data‑integrity workflows.
Both forms are validated for safe execution time before being accepted (catastrophic‑backtracking guard). Workspace‑shared body shape:
Newly‑added patterns become live within ~30 seconds (cache TTL).

NER PII detection

The regex / entropy detectors in detectors.pii are precise on structured PII (email, phone, IBAN with mod‑97 validation, API keys) because those have a lexical shape a pattern can anchor on. They’re blind to unstructured PII: person names, street addresses, dates of birth. detectors.ner adds a zero‑shot transformer NER tier (GLiNER2‑PII, Apache‑2.0, fastino/gliner2-privacy-filter-PII-multi) on top for exactly that gap. On overlapping spans, the regex tier always wins: a checksum‑validated IBAN is strictly more trustworthy than a token classifier reading the same characters. NER only ever adds findings the pattern tier couldn’t see.

AppNerPolicy

Ship new entity types in flag mode first. NER precision is domain‑dependent (cross‑domain benchmarks show real‑world F1 well below headline model‑card numbers), so treat a fresh entity/threshold combination as untrusted until you’ve watched its flag volume and spot‑checked findings in the event log. Promote to redact per App once validated.
Benchmarked against ai4privacy (general PII) and NCBI‑disease / synthetic clinical notes (medical): Latency is CPU‑bound and independent of these choices: p50 ≈ 130–140ms, p99 ≈ 200ms per scan once the model is warm.

Model status

Requires runtime_security.view. Also warms the model: the first call kicks off the (~40s) background load so the tier is ready before traffic needs it. Poll this after enabling detectors.ner for the first time, or to render a live status badge in your own tooling.
The tier fails open at every stage: cold model, load error, or a slim image with no gliner2 package all just mean NER findings are absent for that scan. Every other detector still runs.

Pre‑prompts on the proxy

Admins can configure a system message that the proxy auto‑prepends (or appends, or sandwiches) to every request. The pre‑prompt is admin‑trusted and not scanned. It’s rewritten into the right shape for each provider:
  • messages[] for OpenAI and OpenAI‑compatible.
  • system block for Anthropic and Bedrock.
  • systemInstruction for Gemini and Vertex.
Useful for enforcing a baseline policy across every App without asking every team to remember to inject it themselves.

Forbidden providers

Set routing.forbidden_providers on an App to refuse traffic to certain upstreams. Useful for data‑residency requirements (an EU‑only App might forbid openai, groq, and bedrock US regions). Refused requests return a provider‑shaped error with verdict block and blocked_reason="provider_forbidden:<name>".

Environment variables

Most tuning lives in the App / workspace config APIs above. A smaller set of knobs (mostly about detector rollout, fail‑posture, and abuse caps) are process‑level env vars, useful for self‑hosted deployments. None of these require a config‑API round trip; they take effect on process restart.
The perplexity defaults above were retuned this release (previously 1500 / 5000, which was high enough that the detector effectively never fired). If you run with detectors.perplexity enabled and rely on the old defaults implicitly, expect more redact verdicts from this tier after upgrading. Re‑tune per your own corpus via the env overrides if that’s not what you want.

Common workflows

  1. PUT .../apps/{id}/config with lower thresholds and a clear change_summary.
  2. Watch the drift dashboard for verdict mix shifts over 24h.
  3. Roll back via the version history if anything looks wrong.
  1. Use POST /api/custom-rules with the regex.
  2. New scans pick it up within ~30 seconds.
  3. Test in the dashboard before relying on it.
  1. Set pre_prompt with pre_prompt_placement="prepend".
  2. Run synthetic traffic through every App to confirm the new system message doesn’t break behaviour.
  3. Promote to production by enabling on the workspace config.