Boundary

Runtime protection with Boundary

Quantlix evaluates policies on your requests before the model runs. That way blocked or redacted content does not reach the provider. This page describes what is included when you use the standard run API, OpenAI-compatible /v1/*gateway routes, and dashboards that execute through those surfaces.

What is protected

Requests you send through Quantlix's primary run API (POST /run) or the OpenAI-compatible gateway (/v1/*), with your deployment identified for that path (deployment_id on /run, X-Quantlix-Deployment-Id on gateway calls), hit the same policy step before inference. The dashboard Playground uses POST /run, so what you see there matches API behavior for the deployment you select.

  • Pipeline and contract checks — validate structure and allowed features before execution.
  • Guardrails — block requests that violate rules you attach to the deployment.
  • Budgets and limits — enforce caps and related gates according to your plan and deployment settings.
  • Outcomes you can configure — allow, block, warn, flag for audit, or redact specific patterns when a contextual pack is enabled (see below).
  • Traces and enforcement history — runs and enforcement events so you can review what happened and why.

Production scope today

This matrix shows what is enforced in production today, what is configurable with caveats, what is pilot or partial, and what remains on the roadmap.

Policy evaluation before inference on POST /run and /v1/* gateway

Enforced today

The structured run API and OpenAI-compatible HTTP gateway evaluate deployment policy before provider inference—for example chat, messages, and embeddings routes—when traffic is routed through Quantlix with a deployment binding.

Schema and contract checks

Enforced today

Pipeline and contract checks run in the policy step and can enforce or warn based on deployment configuration.

Guardrail blocking

Enforced today

Guardrail rules can stop violating requests before they reach the model on supported /run and gateway flows.

Budget and limit gates

Enforced today

Configured budgets and usage gates can block requests on supported /run and gateway flows when limits are reached.

Audit events and run traces

Enforced today

Boundary decisions are recorded in enforcement events and trace metadata for review and export workflows.

Contextual pack detection and redaction

Configurable, with caveats

Sensitive-pattern handling is pack-driven and configurable per org, project, and deployment, rather than universally on by default.

Prompt inspection behavior

Configurable, with caveats

Inspection is implemented as policy evaluation over request payloads, not a separate inspector product surface.

Audit export readiness details

Configurable, with caveats

Enforcement export is available, while production signing and compliance posture depend on environment configuration.

Gateway body-preview redaction

Pilot or partial

Gateway body-preview redaction is currently a partial implementation and should be treated as pilot-only behavior.

Escalate as a runtime policy outcome

On the roadmap

Escalation is not yet a first-class runtime policy outcome in Boundary enforcement decisions.

Full ingress coverage across all surfaces

On the roadmap

Boundary enforcement applies on POST /run and supported OpenAI-compatible /v1/* gateway paths today, with broader coverage of additional ingress surfaces planned over time.

Last reviewed: May 2026 (aligned to internal readiness audit).

Contextual policy packs

Optional contextual policy packs add pattern checks on request payloads before inference. You choose the pack and actions per organization, project, or deployment. Detection is rule- and heuristic-based — not a full ML classifier of personal data and not a substitute for legal, security, or clinical review. Treat packs as one control layer alongside your own data handling, DLP, and compliance programs.

In deployment policy settings you can also choose which surfaces run detection on (for example input, output, tool_args, rag), depending on the pack. Presets differ: for example finance defaults often include more surfaces than healthcare, which defaults to input-only unless you expand it. Each pack's card in the dashboard shows a short safety note and the merged preset when you apply it.

  • Student privacy — student-style identifiers, national IDs where detected, and related PII heuristics; block, flag, redact, and multiple-signal behavior you configure.
  • Enterprise baseline — higher-signal shapes first (secrets-like tokens, payment instruments, national identifiers) before broader weak PII; intended as a general production floor, not exhaustive secret scanning.
  • GDPR data protection — special-category style signals, direct identifiers, weak PII, and optional lexical expansion; ladder or max-severity aggregation and strict mode you can tune.
  • Finance pack — payment instruments, PCI SAD-adjacent heuristics (for example CVV-adjacent and track-like shapes), finance-context keywords, and tiered actions. Not a PCI assessment or issuer control; extend surfaces carefully because output buffering has latency tradeoffs.
  • Healthcare pack — sensitive identifiers (including US-oriented clinical heuristics such as MRN/NPI/DEA, beneficiary-style labels, gated dates, prefixed ICD-10-style codes, and NDC-shaped tokens), personal-data redaction tier, and health-context keyword signals. Optional operating profile (for example research-oriented demotion of coding-only heuristics) and a strict substance-use context flag when detectors attach a substance-use signal near health context — still heuristics, not HIPAA Safe Harbor, clinical NER, or 42 CFR Part 2 enforcement.

Where to configure

Settings merge from organization to project to deployment. More specific levels override broader defaults when you set them.

  • Organization — Settings → Enforcement defaults for org-wide contextual pack defaults.
  • Projects — optional overrides when you create or edit a project.
  • Deployments — per-deployment policy (including contextual packs) in deployment settings or the policy form when you deploy.

Related docs