Building Arbitex: Engineering Principles

Enterprise security software has a credibility problem. Vendors publish marketing pages with accuracy claims and architecture diagrams, but the engineering practices behind those claims are rarely visible. We think that should change.

This post describes how we build Arbitex — the engineering principles that govern how code ships, how security decisions get made, and how we validate that the platform does what we say it does.

Testing Is Not Optional

The Arbitex platform runs thousands of tests on every change. Unit tests cover individual functions. Integration tests verify that services interact correctly across process boundaries. End-to-end tests simulate real customer workflows — a prompt enters the gateway, passes through DLP inspection, gets routed to a provider, and the response flows back through the same pipeline.

The DLP pipeline has its own accuracy harness. Every detection pattern is tested against a curated corpus of positive and negative examples. When we add a new compliance pack or modify an existing pattern, the harness reports precision, recall, and F1 scores before the change can merge. If accuracy regresses on any pattern category, the change is blocked.

We do not ship features without tests. A feature that passes manual review but lacks automated coverage is incomplete. The test is part of the deliverable.

Security-First Design

Arbitex inspects sensitive data. That means the platform itself must be built to a higher security standard than the content it protects. A vulnerability in the inspection engine — a memory leak, a logging mistake, an overly permissive default — would undermine the entire product.

Every code change goes through security review. The review checks for the standard categories — injection, authentication bypass, insecure defaults — but also for patterns specific to a content security platform: Does this change log request content? Does it store detection results in a way that could leak the original data? Does a new configuration option default to a secure state?

The DLP pipeline itself is written with fail-closed semantics. If the scanner encounters an error — a malformed document, a timeout, an unexpected encoding — the default action is to block, not to pass the content through uninspected. Every exception path has an explicit policy decision. There are no silent failures.

Container Hardening

Every Arbitex service runs in a hardened container. The principles are straightforward and non-negotiable:

Non-root execution. No service runs as root inside its container. The application user has exactly the permissions needed to read its configuration and write to its log directory.

Read-only root filesystem. The container filesystem is mounted read-only. Writable paths are limited to explicitly declared volumes for temporary data and logs. An attacker who gains code execution inside the container cannot modify the application binary or install additional tools.

Dropped capabilities. Linux capabilities are dropped to the minimum required set. No container retains CAP_NET_RAW, CAP_SYS_ADMIN, or other elevated capabilities unless there is a documented, reviewed reason.

No secrets in images. API keys, database credentials, and encryption keys are injected at runtime through environment variables or mounted secrets. The Docker image contains no sensitive data. A leaked image reveals architecture, not credentials.

These are not aspirational guidelines. They are enforced in CI. A container that fails any of these checks does not build.

DLP Accuracy Methodology

Accuracy claims without methodology are marketing. We publish how we measure because the measurement matters as much as the number.

The DLP accuracy harness tests every detection pattern against a structured corpus. Each pattern category — credit card numbers, national IDs, email addresses, medical record numbers — has its own test set with confirmed positives and confirmed negatives. The corpus includes edge cases: numbers with unusual formatting, partial matches that should not trigger, and content where sensitive data appears inside technical discussion rather than as standalone values.

We measure precision (how many detections are correct) and recall (how many real instances are caught). A high-precision, low-recall scanner misses sensitive data. A high-recall, low-precision scanner drowns administrators in false positives. Both outcomes fail the customer. The goal is to maximize both, and to be transparent about the tradeoffs in each pattern category.

The Rust-powered scanner and the Python fallback run against the same test corpus. The accuracy harness confirms zero detection deltas between backends — same entities detected, same spans, same confidence scores. Backend selection affects performance, not correctness.

These principles are not unique to Arbitex. They are standard practice for teams that build software where correctness and security are non-negotiable. The difference is that we apply them consistently, enforce them automatically, and make them visible.

See what we’re building now or book a demo to see the platform in action.