Governance

Conduix gives you many small levers to keep teams in their lane: cap spend, restrict models, pin regions, redact PII, throttle keys. Every lever is enforced before the upstream provider call — not after the bill arrives.

Spend caps

Per-organization daily and monthly hard ceilings. When the cap is exceeded, requests fail with HTTP 402 spend_cap_exceeded and the provider call never runs. Configure at /dashboard/settings.

Daily cap

UTC day boundary; resets at midnight UTC

Monthly cap

UTC month boundary; resets on the 1st

Alert threshold

Default 80%; warns before blocking

Model allowlists

Per-key restriction on which models that key can call. If the request asks for a model not on the list, the response is model_not_allowed (HTTP 403) and never reaches upstream.

{
  "name": "Internal tools",
  "allowed_models": [
    "gpt-5.4-mini",
    "claude-haiku-4-5-20251001",
    "byo:*"
  ],
  "rate_limit": 60
}

Use byo:* as a wildcard to allow any BYO endpoint without naming each one.

Per-key rate limits

Requests per minute, enforced via Redis sliding window. Per-key (not per-org) so different teams can't starve each other. Configure when minting a key. Throttled requests get rate_limit_exceeded (HTTP 429) with a Retry-After header.

Region pinning (data residency)

Conduix maps each provider to its primary inference region: US, EU, or APAC. Set a key's data-residency to one of these and Conduix will only route to providers in that region — including for fallbacks.

us

OpenAI, Anthropic, Google Gemini, xAI, Groq, Together, Fireworks, Azure AI Foundry, Amazon Bedrock

eu

Mistral

apac

DeepSeek

Organization routing policy

Beyond region pinning, org admins can shape routing platform-wide via PATCH /api/organization/policy. Every rule is enforced on the primary and on failover candidates — including candidates behind a routing alias.

allowed_providers

Route only to these providers (null = any)

blocked_providers

Never route to these providers (overrides allowlist)

blocked_models

Never route to these specific model ids

block_open_weights

Exclude open-weights models (Llama/Qwen/GLM/Kimi/…) from all routing

data_residency

us | eu | apac — pin inference to one region

PHI-flagged organizations additionally route only to the operator-maintained BAA provider allowlist (fail-closed). See Security.

PII handling

Detect structured PII — emails, SSNs, US phone numbers, IPs, and Luhn-validated credit cards — in request bodies before they leave Conduix. Three modes:

• Off — no PII processing.
• Redact — destructively replace PII with placeholders ([SSN_REDACTED]). The model never sees the value and can't use it. Conduix sends x-conduix-pii-redacted: <count>.
• Tokenize — replace PII with reversible sentinels (<SSN_1>) before the provider call, then restore the original values in the response (streaming included). Keeps your output usable. Conduix sends x-conduix-pii-tokenized: <count>. Responses are not cached in tokenize mode.

The effective mode is resolved with this precedence (highest first):

• Per-request header: x-conduix-pii-mode: off|redact|tokenize (the legacy x-conduix-pii-redact: on|off still works).
• Per-key override at /dashboard/keys — or inherit the org default.
• Org-level default at /dashboard/settings.

On-detection policy

Independent of the mode above, pii_on_detect governs what happens when PII or a secret is detected in a request (org default, overridable per key — not per request):

• allow — transform per mode and forward (default).
• warn — forward, and surface x-conduix-pii-detected: <types> to the caller.
• require_ack — reject with 422 (pii_acknowledgment_required) unless the request carries x-conduix-pii-ack: true. The human prompt is rendered by your app; Conduix only enforces the contract. Ack is per-request. Recommended for PHI workloads.
• block — hard-refuse any request with detected PII/secrets (422 pii_blocked).

Secret detection

Conduix also flags credentials in request bodies — API keys, AWS access keys, private-key blocks, JWTs. On detection it sets x-conduix-secret-detected: <types> plus a rotation advisory, applies the same pii_on_detect policy, and audits the event (types/counts only — never the value). If a secret reached an upstream provider, rotate it.

Dry-run scan

POST /v1/pii/scan with a messages array returns the detected PII and secret types/counts without running a completion — so your app can check a payload (and prompt its user) before sending. Returns types/counts only, never values.

Egress safety net

In redact/tokenize mode, Conduix re-scans the outbound payload after transform. Residual structured PII is blocked for PHI-flagged organizations (fail-closed) and failsafe-redacted + alarmed otherwise.

PHI tenants & BAA routing

Organizations flagged as PHI (operator-set) get two extra protections: the egress safety net fails closed (residual PII blocks the request rather than being failsafe-redacted), and BYO endpoints without a structured cloud connector are refused with 403 byo_not_permitted_for_phi. Two distinct BAA regimes apply, and they are NOT interchangeable — the section below distinguishes them explicitly.

Conduix-covered PHI routing

Conduix-covered PHI routing is in development and not yet generally available; the Conduix BAA and the signed upstream-provider agreements it depends on are being put in place. The routing itself is implemented: for direct provider routing (non-BYO), PHI requests are pinned — fail-closed — to providers on the operator-maintained allowlist PHI_BAA_PROVIDERS — the intended set of providers Conduix will hold a BAA / no-retention agreement with, covering Conduix's own account with that provider. An organization cannot be flagged PHI until that allowlist is configured. Requests to a non-allowlisted provider return 403 provider_not_permitted. This regime relies on Conduix's BAA with the upstream provider.

Your own cloud connector (Azure / AWS Bedrock, BYO)

A separate BYO path lets a customer route through a cloud connector configured against the customer's OWN cloud tenant (an Azure AI Foundry resource or an AWS Bedrock account). Traffic on this path is covered by the customer's OWN BAA with Microsoft or AWS, under their own cloud account; the customer is responsible for their own cloud BAA and its scope.

Mechanically: the request goes through Conduix's ingress (rate limits, spend caps, audit, PII redaction) and then is dispatched to the customer's cloud endpoint using the customer's credentials — Conduix does not touch the customer's cloud account. PHI-flagged organizations are permitted to use structured cloud connectors (Azure today) even though generic BYO endpoints remain refused, because the compliance regime for cloud-connector traffic is the customer's own cloud BAA rather than an unverified third-party endpoint.

Audit rows tag which regime covered a given request in the baa_scope field: conduix for a Conduix-BAA-covered direct provider, customer_cloud for a cloud-BYO connector, or none otherwise. A compliance reviewer can filter the audit log by regime without cross-referencing endpoint configuration by hand.

Provider-level governance (operator side)

Operators (iVirtualsoft) can also enforce platform-wide constraints — these aren't customer-configurable but customers can rely on them being in place:

• Provider budgets at the platform level — alerts fire to Slack/Teams at 70/80/90/100% of monthly spend.
• Hard cap on provider — when set, traffic auto-fails over to fallbacks if a provider is over budget.
• Circuit breakers per provider — three consecutive upstream failures trip the breaker for 30 seconds, traffic routes around.

Audit trail

Every governance change (cap update, allowlist change, residency change, PII toggle) lands in /dashboard/audit with the user who made the change, the IP, and the request id. Append-only, exportable, compliance-ready.