Inside the Arbitex Policy Engine: Rules and Compliance Packs
Every enterprise AI gateway needs a way to say “this request is allowed” or “this request is blocked.” The simplest version is a binary toggle — all traffic on, all traffic off. The next step up is a list of rules. But when you have hundreds of users across multiple departments, each subject to different compliance requirements, accessing different AI models, with different sensitivity levels — a flat rule list stops working.
The Arbitex Gateway policy engine is the layer that makes these decisions. It evaluates every AI request against an ordered set of rules, applies the first matching rule, and enforces the resulting action. This post walks through how it works — the rule model, the combining algorithms, the condition types, and how compliance packs automate the setup for regulated industries.
The Rule Model
A policy rule has three parts:
- Conditions — what must be true for the rule to match. Conditions can test user identity, group membership, destination model, content detection results, IP range, time of day, or content category.
- Action — what happens when the rule matches. Actions include allow, block, redact (strip detected entities and forward), log-only (allow but flag for review), or ROUTE_TO (redirect the request to a different model).
- Priority — where the rule sits in the evaluation order. Rules are evaluated top to bottom. The first match wins.
This is a first-match model — the same evaluation strategy used in next-generation firewalls, network ACLs, and XACML policy sets with the first-applicable combining algorithm. Specific rules go at the top. Broad catch-alls go at the bottom. If no rule matches, a configurable default action applies.
The benefit of first-match is predictability. When a request is blocked, the audit log shows exactly which rule matched and why. There are no hidden conflicts between overlapping rules, no priority-weighted scoring that produces opaque results. The decision path is linear and traceable.
Combining Algorithms
Not every policy evaluation uses first-match. The engine supports multiple combining algorithms, inspired by the XACML standard:
First-applicable — the default. Evaluate rules in order, apply the first one that matches. Simple, predictable, fast. Best for organizations that want direct control over rule priority.
Deny-overrides — evaluate all matching rules. If any matching rule produces a deny (block), the result is deny, regardless of other rules that would allow the request. Best for compliance-heavy environments where any single violation must result in enforcement, even if other rules would permit the traffic.
Permit-overrides — the inverse. If any matching rule produces a permit (allow), the result is allow. Useful for exception-based policies where specific users or service accounts need guaranteed access regardless of other restrictions.
The combining algorithm is set per policy set, not per rule. An organization can have multiple policy sets — one for their general access policy (first-applicable), one for their compliance enforcement (deny-overrides), one for their service account exceptions (permit-overrides). The policy sets themselves are evaluated in a defined order.
Condition Types
Conditions are the predicates that determine whether a rule matches a given request. The engine supports several condition types, and conditions within a single rule are combined with AND logic — all conditions must be true for the rule to match.
User and group conditions: Match on the authenticated user identity, their group memberships (synced via SCIM or assigned in the admin portal), or their organizational role. Example: “If user is in the Finance group AND destination is an external model — apply this rule.”
Content detection conditions: Match on the results of the DLP pipeline. If Tier 1 detected a PCI entity, or Tier 2 flagged PHI above a confidence threshold, or Tier 3 confirmed an entity — a policy rule can use that detection result as a condition. This is how DLP and policy enforcement connect: the DLP pipeline produces detections, and the policy engine decides what to do about them.
Model and provider conditions: Match on the destination AI model or provider. Rules can target specific models (e.g., “block all requests to Model X”) or categories of models (e.g., “any model with a risk tier above medium”). Model risk tiers are assigned in the admin portal and reflect the organization’s assessment of each model’s sensitivity level.
IP range conditions: Match on the source IP of the request. Useful for location-based policies — different enforcement for office networks versus remote access, or different rules for known VPN ranges.
Content category conditions: Match on the topic category of the request content. The gateway classifies request content into domain categories (financial, medical, legal, technical, etc.), and policy rules can use these classifications as conditions. Example: “If content is classified as medical AND user is not in the Clinical group — block.”
Policy Packs
A Policy Pack is an ordered set of rules that can be applied as a unit. Think of it as a rule template that encodes a governance posture.
Organizations build Policy Packs for their own use cases: a “New Employee” pack with restricted model access and strict DLP enforcement, a “Research Team” pack with broader model access but logging on all requests, a “Service Account” pack with bypass rules for automated pipelines.
The value of Policy Packs is consistency. Instead of rebuilding rules for each team or department, the security team defines the governance posture once and applies it wherever it is needed. When the posture changes — a new model is added, a new compliance requirement takes effect — the change propagates through every team that uses the pack.
Compliance Bundles
Compliance Bundles are Policy Packs pre-configured for specific regulatory frameworks. Applying a Compliance Bundle activates the rules, DLP thresholds, and enforcement actions required by the framework.
HIPAA bundle: Activates PHI detection with lowered escalation thresholds, enforces block-or-redact on confirmed PHI entities, enables audit log retention policies aligned with 45 CFR requirements, and restricts AI model access for users handling protected health information.
PCI-DSS bundle: Activates payment card detection with Luhn validation, blocks CVV transmission unconditionally, enforces redaction on PANs in allowed requests, and produces audit evidence mapped to PCI-DSS control requirements.
GDPR bundle: Activates EU-specific entity recognizers, enforces data minimization rules on personal data detection, enables data subject request workflows in the audit system, and applies lower detection thresholds reflecting EU enforcement expectations.
SOX bundle: Activates financial identifier detection, enforces role-based access control on AI requests involving financial reporting data, enables tamper-evident audit logging with HMAC chain verification, and produces compliance reports aligned to SOX audit cycles.
Compliance Bundles are not static templates. They are maintained alongside the platform and updated when regulatory guidance changes or when the DLP pipeline adds new detection capabilities. Applying a bundle does not lock you into a fixed configuration — it gives you a compliant starting point that you can extend with your own rules.
The Admin Experience
Policy management happens in the admin portal. The interface reflects the rule model directly:
Rule list view shows all rules in evaluation order. Each rule displays its conditions, action, and status (active, disabled, simulation). Drag-and-drop reordering changes the evaluation priority. The current combining algorithm is visible at the top of the list.
Rule editor lets you build conditions visually. Select a condition type (user group, content detection, model, IP range), set the operator and value, and add additional conditions. The rule preview shows a plain-language summary: “If user is in [Finance] AND content detection includes [PCI entity] → Block.”
Simulation mode lets you test policy changes against live traffic without enforcing them. When simulation is active, every request is evaluated against both the current production policy and the proposed change. The simulation report shows what would change — which requests would be newly blocked, which would be newly allowed, which are unaffected. Review the report, confirm the outcome, then promote to enforcement with one action.
Decision trace is available for every request in the audit log. It shows which rules were evaluated, which conditions matched, which rule produced the final decision, and what action was taken. When an auditor asks “why was this request blocked?” — the answer is in the trace, not in someone’s memory.
How It Connects to DLP
The policy engine and the DLP pipeline are separate systems that work together. The DLP pipeline inspects content and produces detection results. The policy engine evaluates those results — alongside user identity, model destination, and other conditions — and decides what to do.
This separation matters because DLP detection and enforcement are different concerns. The same PHI detection might result in a block for an external user, a redaction for a clinical team member, and a log-only flag for a service account running an authorized data pipeline. The detection is the same. The enforcement depends on context that only the policy engine has.
The policy engine is the decision layer. The DLP pipeline is the detection layer. Together, they give security teams the combination of visibility and control that enterprise governance requires.
Explore the Policy Engine or book a demo to see policy rules in action.