Jurisdictional control

Warning

There is no region-pinned routing. No per-request inference region, no EU-only endpoint, no data-residency flag. If your requirement is “inference must physically occur inside jurisdiction X”, the firewall does not have a switch for that.

What it has is the ability to enforce which vendors you are allowed to talk to at all — which, in practice, is how a data-residency boundary is actually held.

The lever that does exist

Your data ends up wherever the provider processes it. So the question that actually determines your exposure is which providers can your organisation reach — and that is enforced on every request, org-wide, with no per-user or per-project exceptions.

# Nobody in this organisation may use these
vulnetix ai-firewall policy provider openai --deny
vulnetix ai-firewall policy provider xai --deny
vulnetix ai-firewall policy provider together --deny

# These are approved
vulnetix ai-firewall policy provider mistral --allow

Any request to a denied provider is refused:

{
  "error": {
    "message": "provider openai is denied by organisation policy",
    "type": "policy_violation",
    "code": "provider_denied"
  }
}

It does not matter which developer, which machine, which client, or which project. A denied provider is denied.

Note

A provider with no explicit policy is allowed. The default is permissive. If your posture is “deny everything except what we have approved”, you must explicitly deny the providers you have not approved — there is no global default-deny switch.

Write it down in a policy file so the complete list is reviewable, and so nobody has to remember which providers exist.

Composing a jurisdiction boundary

Suppose your DPA covers only EU-established vendors. The policy file makes the whole posture reviewable in one diff:

# .vulnetix/ai-firewall.yaml
apiVersion: vulnetix.com/v1
kind: AiFirewallPolicy
spec:
  providers:
    # Approved: covered by our DPA
    - slug: mistral
      action: allow

    # Denied: no agreement in place
    - slug: openai
      action: deny
    - slug: anthropic
      action: deny
    - slug: groq
      action: deny
    - slug: xai
      action: deny
    - slug: deepseek
      action: deny
    - slug: together
      action: deny
    - slug: fireworks
      action: deny
    - slug: openrouter
      action: deny
    - slug: alibaba
      action: deny
    - slug: moonshot
      action: deny
    - slug: minimax
      action: deny

vulnetix ai-firewall apply --dry-run
vulnetix ai-firewall apply

Now the boundary is a reviewed artefact with an author and a date, rather than a setting somebody changed once.

Warning openrouter is the one to watch. It is a router: allowing it grants access to models hosted by many underlying vendors, and the firewall’s provider policy sees only openrouter. If you are drawing a jurisdictional boundary, an allowed OpenRouter is a hole in it.

Narrowing further with model policy

Provider policy is the coarse lever. If you need to permit a vendor but only for specific models — a locally-hosted deployment, say, rather than their shared endpoint — layer model policy on top.

The first allow entry for a provider flips it into allowlist mode: everything not explicitly allowed is refused.

vulnetix ai-firewall policy model mistral-large-latest --allow --provider mistral
# mistral is now allowlist-only — every other Mistral model is refused

What this genuinely gives you

  • One place to enforce it. Not a policy document developers are asked to follow — a control that refuses the request.
  • It covers agents. A coding agent cannot silently reach an unapproved vendor, because the refusal happens at the gateway, not in the agent’s configuration.
  • It is auditable. With logging on, every attempt to reach a denied provider is a 403 row naming the provider. You can show that the control fired.

What it does not give you

  • No control over where an approved provider processes your data. If Mistral routes your request through a region you did not expect, that is between you and Mistral. The firewall constrains who, not where.
  • No control over the gateway’s own location. The firewall runs in a single region. Your request transits it. If your requirement forbids that transit entirely, this product is not the answer.
  • No effect on the provider’s retention or training policy. That is your contract with them. See zero data retention.