How Arbitex Gateway Enforces Your AI Security Policies
Detection is not governance. Governance is what you do with what you detect — consistently, on every call, with a record.
A useful mental model for AI governance: detection tells you what is happening. Enforcement determines what is allowed. Visibility proves that the rules were followed.
The previous post in this series covered how Arbitex inspects the content of every AI request and identifies sensitive data before it reaches any model. This post covers what comes next — Stage 3, Control — where the rules your security and compliance teams set are translated into action.
The Problem This Solves
The most common failure mode in enterprise AI governance is not that organizations have no policies. Most do. The failure is that the policies are documented in wikis, enforced by trust, and audited by asking people what they did.
This works reasonably well for cloud storage access. It works poorly for AI traffic, because AI usage is high-volume, fast-moving, and distributed across dozens of applications and teams. A developer does not consult a policy document before making an API call. A governance model that depends on developers reading and following guidelines is not governance — it is hope.
Control in Arbitex moves the rules from the wiki to the wire. Policies are defined in the platform and enforced on every request. A developer cannot route a call to an unauthorized model, exceed a cost cap, or send a request that violates a content rule — not because they are supposed to follow the policy, but because the gateway does not let the request through.
What Policies Define
Policies in Arbitex cover three domains.
Routing rules. Which teams are permitted to use which models. Which providers are approved for which types of data. Fallback chains — if the first choice is unavailable, where does the request go. Automatic health monitoring tracks provider availability; fallback chains are the policy-defined answer to what happens when a provider goes down.
Cost controls are here too. Each team or project can have a budget cap denominated in tokens or dollars. When a team hits their cap, requests are blocked at the gateway before they reach the model and incur cost. The cap is enforced in real time. There is no grace period where overruns accumulate and are caught in a billing review.
Content rules. This is where the inspection results from Stage 2 become enforcement decisions. The Protection pipeline identifies what sensitive data is present. The policy engine determines what to do about it. For a request that contains a social security number: does the policy say block, redact, or log? The answer depends on which framework applies, which team made the request, and what content rules the security team has configured.
Content rules also cover prompt injection defenses — policies that detect and block requests structured to manipulate model behavior in ways that could circumvent governance controls.
Organizational structure. Policies apply at multiple levels: the organization as a whole, individual teams, and specific projects. When a more specific policy exists, it applies. When it does not, the organization-level rule is the fallback. This inheritance structure means a security team can set baseline rules for the entire organization and grant teams flexibility to configure additional controls within those bounds.
Policies Are Testable Before Deployment
One practical concern with governance infrastructure is the risk of misconfiguration causing disruption. A policy that blocks more than intended can break production workflows. A policy that is too permissive defeats its purpose.
Arbitex supports testing policies against historical traffic before activating them. Before a new policy goes live, you can run it against your actual request history in simulate mode and see what it would have done. How many requests would it have blocked? Which teams? Which content types? That information lets you calibrate the policy before it touches live traffic.
Every policy change is version-logged. You can see what changed, when, and who made the change — and revert if needed.
What Enforcement Looks Like
When a request arrives at Stage 3, the policy engine evaluates it against the applicable policy set. The evaluation is deterministic: every request either satisfies the policy or it does not. There is no judgment call made at enforcement time. The judgment call was made when the policy was written.
If the request passes: it continues through the pipeline to the model.
If the request fails a rule:
- Block — the request is stopped. The caller receives an error response that describes which policy was violated. The event is logged with the policy reference, the enforcement action, and the request context.
- Redact — the offending content is removed and the sanitized request continues to the model.
- Quota exceeded — if the failure is a cost cap, the request is blocked and the caller is notified. An admin can raise the cap through a configuration change, which is itself logged.
Every enforcement action produces a log entry. The log records which policy triggered the action, what the action was, which user and team made the request, and which model it was destined for. This is the evidence that Stage 4 — Visibility — organizes into an audit record.
What Control Is Not
It is not a firewall in the network security sense. Arbitex does not inspect network packets or block IP addresses. It operates at the application layer: every request that enters the gateway is authenticated, identified by team and user, and evaluated against policies that know who is asking and what they are asking for.
It is also not a substitute for input validation in your application. Arbitex governance operates at the AI layer. Application-level validation — ensuring that only valid inputs reach your AI features in the first place — is still your application’s responsibility. Governance at the gateway and validation in the application are complementary, not substitutes.
The Security Leader’s View
For a CISO, Stage 3 is the layer that makes the answer to “are our AI interactions governed?” possible.
Routing determines where requests go. Protection determines what they contain. Control determines whether they are allowed. Without this stage, you have observation but not governance.
With it: the security team writes the rules, the gateway enforces them, and the audit log — covered in Part 4 — proves it.
Part 4 in this series covers Visibility — the complete audit record of every AI interaction and what it means for compliance and oversight.
Visibility — the audit record that answers the board’s question →