Frequently Asked Questions

This page collects answers to the questions asked most often by Arbitex users and administrators. For deeper dives, each answer links to the relevant guide. If your question isn’t covered here, see the Troubleshooting guide or reach out to support.

Setup & Installation

What are the system requirements for Arbitex?

For SaaS Cloud, there are no infrastructure requirements on your end — all compute is managed by Arbitex. For Self-hosted (Docker Compose or Kubernetes), a minimum of 2 vCPU and 4 GB RAM is recommended for the platform services; DLP inference workloads require additional resources, especially if you enable the Tier 2 (GLiNER) or Tier 3 (DeBERTa) NER models. For Outpost, the proxy itself is lightweight (512 MB RAM), but enabling on-premise DLP inference adds GPU or CPU model overhead. See the Deployment Guide and Outpost Deployment for hardware sizing tables.

What deployment modes are available?

Arbitex supports four deployment modes:

SaaS Cloud — fully managed, no infrastructure required.
Self-hosted — you run the full platform stack via Docker Compose or Kubernetes/Helm in your own environment.
Outpost hybrid — an Arbitex-managed cloud control plane paired with an on-premise Outpost proxy that handles traffic locally.
Air-gap — a fully disconnected variant for environments with no external network access.

Each mode has different operational trade-offs around data residency, latency, and administrative overhead. See Deployment Guide and Deployment Topologies for a side-by-side comparison, and Data Migration if you need to move between modes.

How do I configure SSO with my identity provider?

Arbitex supports SAML 2.0 and OIDC-based single sign-on. From the Cloud Portal, navigate to Settings → Identity Providers, add a provider, and follow the guided setup for your IdP (Okta, Azure AD, Google Workspace, and others are supported). You will need to supply your IdP’s metadata URL or certificate and configure the Arbitex ACS/callback URL on the IdP side. See the full walkthrough in the Identity Providers guide. For MFA enforcement on top of SSO, see MFA Enforcement.

What ports does Arbitex need open?

For Outpost hybrid deployments, the Outpost proxy requires outbound HTTPS (port 443) to the Arbitex platform management URL for heartbeat and policy sync — no inbound firewall holes are required. The Outpost admin API listens on port 8300 by default and should be firewalled to internal management networks only. For self-hosted platform deployments, the required service ports are documented in the Deployment Guide. For air-gap environments, all external connectivity requirements are removed; see the Outpost Deployment guide for air-gap network isolation details.

How do I upgrade to a new version?

For SaaS Cloud, upgrades are automatic with no action required. For Self-hosted and Outpost deployments, follow the Upgrade Guide which covers version-by-version migration notes, pre-upgrade backup steps, the upgrade procedure for Docker Compose and Kubernetes/Helm, and rollback procedures if an upgrade fails. Always read the release notes for the target version before upgrading, particularly if there are breaking schema or config changes.

Can I migrate between deployment modes?

Yes. Arbitex supports export and import of organization data — policies, users, audit logs, and configuration — to facilitate mode transitions. The Data Migration guide covers the full procedure, including what data is portable, what requires manual reconfiguration, and the recommended sequence for transitioning from SaaS Cloud to Self-hosted or from Self-hosted to Outpost hybrid. Plan for a maintenance window; some transitions cannot be done fully online.

DLP (Data Loss Prevention)

What are the three DLP detection tiers?

Arbitex uses a tiered detection pipeline that balances speed and accuracy:

Tier 1 — Regex: Fast pattern matching for high-confidence structured entities (credit card numbers, SSNs, API keys, and similar patterns). Always active; negligible latency.
Tier 2 — GLiNER NER: A lightweight named-entity recognition model that detects a broader range of entity types in free-form text. Enabled via dlp_ner_enabled.
Tier 3 — DeBERTa transformer: A full transformer model for highest-accuracy context-aware detection. Highest latency and resource cost; enabled via dlp_deberta_enabled.

You can enable tiers independently to balance cost and accuracy. See DLP Pipeline Configuration for the full pipeline architecture and DLP Accuracy for accuracy benchmarks.

What’s the difference between block, redact, and log actions?

DLP rules support four actions:

block — the request or response is rejected entirely and an error is returned to the caller.
redact — the matched sensitive content is replaced with a placeholder (e.g., [REDACTED:CREDIT_CARD]) before the traffic is forwarded or returned.
log — the match is recorded in the audit log but the content is passed through unchanged.
allow — explicitly permits the match without any action (useful for exception rules).

Actions are configured per rule within a DLP profile. See DLP Pipeline Configuration for rule authoring syntax.

How do I tune DLP to reduce false positives?

The most effective approaches are: (1) adjusting confidence thresholds on Tier 2/3 rules — lowering the threshold raises recall at the cost of more false positives, raising it reduces false positives; (2) adding allowlist patterns for known-safe strings that match your rules; (3) scoping rules to specific content categories or request types so they only fire where relevant; and (4) switching from block to log for a burn-in period so you can review what’s being matched before enforcement. The DLP Accuracy guide has a full tuning workflow, and Content Categories explains how to scope rules by content type.

Which entity types does Arbitex detect out of the box?

Arbitex ships with built-in detectors for a broad set of entity types including credit card numbers, US SSNs, passport numbers, driver’s license numbers, bank account numbers, API keys and secrets, email addresses, phone numbers, IP addresses, dates of birth, medical record numbers, and more. The full list of entity types, including which tier detects each, is documented in the Entity Types reference. Tier 1 regex patterns cover structured entities; Tier 2/3 NER models extend coverage to contextual free-form text.

Can I add custom regex patterns for DLP detection?

Yes. In the DLP profile editor (Cloud Portal → DLP → Profiles → Custom Rules), you can define custom Tier 1 regex patterns with your choice of entity type label, confidence level, and action. Custom patterns follow the same matching and action pipeline as built-in rules. For complex free-form entity detection that regex cannot handle, consider whether a Tier 2/3 NER rule with a custom label is more appropriate. See DLP Pipeline Configuration for the custom rule schema.

What is the first_applicable combining algorithm?

first_applicable is a policy combining algorithm (also used in DLP rule evaluation contexts) where rules are evaluated in order and evaluation stops at the first rule whose conditions match. Only that rule’s action is applied — subsequent rules are not evaluated. This provides predictable, priority-ordered behavior suitable for most deployments. It contrasts with deny_overrides, where a deny from any matching rule takes precedence regardless of order. See Policy Configuration for combining algorithm details and when to use each.

Policy Engine

How does policy evaluation order work?

Policies are evaluated in the order defined within a policy set. Each policy has a priority value; lower numeric values are evaluated first. Within a policy, rules are evaluated top-to-bottom. When using the first_applicable combining algorithm, evaluation stops at the first matching rule and returns that rule’s decision. When using deny_overrides, all rules are evaluated and any deny decision overrides all permits. See the Policy Engine reference for the full evaluation algorithm.

What’s the difference between first_applicable and deny_overrides?

first_applicable stops evaluation at the first matching rule and applies its action. Order matters — put your most specific rules first and your broad defaults last. This is the right choice for allow-by-exception and layered access models.

deny_overrides evaluates all rules and lets any single deny trump all permits. This is safer for compliance-critical scenarios where you want to guarantee that a deny cannot be bypassed by rule ordering. The trade-off is that you must be careful about rules that unintentionally deny valid traffic. See Policy Configuration for worked examples.

Can I route requests to different models based on policy?

Yes. Policy rules support a route action that directs matching requests to a specific model or model group — for example, routing requests containing PII to an on-premise model while routing general queries to a hosted model. Routing rules can use any policy condition attributes: user identity, group membership, content classification, DLP match results, and more. See the Policy Engine User Guide for routing rule syntax and the Policy Engine reference for available condition attributes.

How do I test policies before deploying them?

Use the Policy Simulator in the Cloud Portal (available on Team and above plans). You can submit a synthetic request with any combination of user attributes, content, and context and see exactly which rules match and what decision is returned, with a full evaluation trace showing each rule that was checked. For self-hosted deployments, the policy evaluation API endpoint can be called directly with a dry-run flag. See the Policy Engine User Guide for the simulator workflow.

What happens when no policy matches a request?

The system-wide default decision applies — by default this is deny (fail-closed). If you want a different global default (for example, allow-by-default with explicit deny rules), you can set an explicit default policy at the policy set level. It is strongly recommended to keep the fail-closed default and build explicit allow rules rather than an open default. See Policy Configuration for configuring the default decision and Security Architecture for the rationale behind the fail-closed default.

Can I apply different policies per user group?

Yes. Policy rule conditions can reference group membership attributes sourced from your identity provider via SCIM or SAML/OIDC claims. You can write rules like “members of the data-science group are permitted to query model X” or “members of the contractors group are denied access to any model handling financial data.” Groups are synchronized automatically after IdP configuration. See Policy Engine User Guide and Identity Providers for group attribute mapping.

Outpost Operations

What’s the difference between reloadable and restart-required config keys?

Reloadable keys take effect immediately when Outpost receives a SIGHUP signal — no process restart required, no dropped connections. These include: log_level, dlp_enabled, dlp_ner_enabled, dlp_deberta_enabled, credint_enabled, budget_enforcement_enabled, debug, rate_limit_requests_per_minute, rate_limit_burst, and cloud_heartbeat_interval.

Restart-required keys change fundamental process identity or TLS state and require a full Outpost restart: outpost_id, org_id, platform_management_url, outpost_cert_path, outpost_key_path, outpost_ca_path, admin_port, and outpost_api_key.

See Outpost Operations for the full list and the recommended zero-downtime reload procedure.

How do I apply config changes without downtime?

For reloadable config keys, edit the config file and send SIGHUP to the Outpost process:

kill -HUP $(pgrep outpost)

Outpost will re-read the config and apply changes in-flight without dropping connections. For restart-required keys, the recommended approach is a rolling restart — bring up a new Outpost instance with the new config, shift traffic to it, then tear down the old instance. See Outpost Operations for the full zero-downtime procedure and Performance Tuning for high-availability deployment patterns.

What does the circuit breaker do?

The Outpost circuit breaker protects downstream services from cascading failures when a backend model provider or the Arbitex platform is degraded. It operates in three states:

CLOSED — normal operation, all requests flow through.
OPEN — the breaker has tripped (error threshold exceeded); requests fail fast without hitting the downstream service, returning an error immediately to the caller.
HALF_OPEN — after a cooldown period, a probe request is sent to test if the downstream has recovered; if it succeeds, the breaker closes; if it fails, it re-opens.

See Outpost Operations for circuit breaker configuration parameters (thresholds, cooldown window, and probe behavior).

Can I run multiple Outpost instances for the same org?

Yes. Multiple Outpost instances can be registered to the same organization — this is the standard pattern for high availability and geographic distribution. Each instance registers with a unique outpost_id but shares the same org_id. Policy and DLP configuration is distributed to all instances via the cloud heartbeat mechanism. Load balancing across instances is handled by your existing infrastructure (a load balancer or DNS). See Outpost Deployment for multi-instance architecture and Deployment Topologies for HA deployment patterns.

How do I check Outpost health?

The Outpost admin API exposes a health endpoint:

GET http://localhost:8300/health

A 200 OK response with a JSON body indicates the Outpost is running and connected to the platform. The response includes uptime, current circuit breaker state, DLP model load status, and last successful cloud heartbeat timestamp. You can integrate this endpoint into your monitoring system (Prometheus, Datadog, etc.) or use it in a load balancer health check. See Outpost Operations and Troubleshooting for interpreting health check responses and diagnosing connectivity issues.

What are the DLP inference device options (CUDA/ONNX/CPU)?

Outpost supports three inference device backends for Tier 2/3 DLP models:

cuda — GPU acceleration via NVIDIA CUDA. Highest throughput and lowest latency for NER inference; requires a CUDA-capable GPU and the appropriate CUDA runtime.
onnx-cpu — ONNX Runtime on CPU. Significantly faster than pure CPU inference for most model architectures; the recommended choice for CPU-only deployments.
cpu — PyTorch CPU inference. Highest compatibility, lowest performance; suitable for development or low-traffic environments.

Configure the device in the Outpost config under dlp_inference_device. See DLP Pipeline Configuration for device configuration syntax and Performance Tuning for throughput benchmarks across device types.

Billing & Plans

What plan tiers are available?

Arbitex offers five plan tiers:

Plan	Price	Target
Free	$0/mo	Individual evaluation
Developer Pro	$49/mo	Solo developers
Team	$199/mo	Small teams
Enterprise	$499/mo	Large organizations
Enterprise Outpost	$999/mo	On-premise / hybrid deployments

Each tier differs in request volume, number of users, DLP tier access, policy engine features, and support SLA. See Billing & Plans for the full feature comparison matrix.

How is usage metered?

Usage is metered by request volume (number of API calls proxied through Arbitex) and, for plans with DLP enabled, by the number of tokens processed through Tier 2/3 inference models. Request counts reset at the start of each billing cycle. Detailed usage metrics are available in the Cloud Portal under Settings → Billing → Usage, including per-day breakdowns and projected end-of-cycle totals. See Cloud Portal Billing for usage dashboard navigation.

Can I change plans mid-billing cycle?

Yes. Upgrades take effect immediately and are prorated to the remaining days in the current billing cycle. Downgrades take effect at the start of the next billing cycle — your current plan remains active until then. If you downgrade to a plan with lower limits than your current usage, access to features above the new plan’s limits will be restricted at cycle rollover. See Cloud Portal Billing for the plan change workflow and prorated billing calculation details.

What happens when I hit my plan’s usage limit?

By default, requests that exceed your plan’s monthly limit are blocked and callers receive a rate-limit error response. If you have overage billing enabled (available on Team and above), requests above the limit are permitted at a per-request overage rate rather than blocked. You can configure usage alerts (via email or webhook) at configurable thresholds (e.g., 80%, 95% of limit) to get advance notice before hitting the cap. See Billing & Plans for overage rates and Cloud Portal Billing for alert configuration.

How do I export billing data?

Billing data can be exported from the Cloud Portal under Settings → Billing → Export. Available formats include CSV and JSON, with date range selection. Exports include per-cycle invoice totals, itemized usage by request type and DLP tier, and overage charges. For automated billing data ingestion, the Arbitex API also exposes billing export endpoints — see the Cloud Portal Billing guide for API export reference. Enterprise customers can additionally configure billing data delivery to a storage bucket.

What’s included in the Enterprise Outpost plan?

The Enterprise Outpost plan ($999/mo) includes everything in Enterprise plus:

Full Outpost proxy deployment with on-premise DLP inference (all five tiers, including DeBERTa transformer and CredInt).
Air-gap deployment support with offline model and policy bundle delivery.
Multi-instance Outpost registration for high availability.
Dedicated Outpost configuration management via the admin API.
Priority support SLA with dedicated technical account management.

This plan is required for any deployment where AI traffic must not leave your network perimeter. See Billing & Plans and Outpost Deployment for full capability details.