This article describes the supported network deployment models for Verax and the network connectivity requirements needed to operate Verax securely in cloud, on-premises, and hybrid environments.
Verax is deployed as a network-accessible service that inspects and enforces policy on generative AI traffic. It supports private, public, and hybrid deployment models, with identity-based enforcement applied consistently across all options.
Supported Deployment Models
Verax supports the following deployment models:
Private network deployment
Private deployment with public ingress (hybrid)
Public endpoint deployment with identity enforcement
The appropriate model depends on how users access AI tools and how your organization prefers to enforce trust, through network boundaries, identity, or both.
Option A: Private Network Deployment
In this model, Verax is deployed entirely within a private network segment, such as a private subnet, internal network zone, or restricted VLAN.
This option is recommended when:
Users access the internet through a corporate network or VPN
AI traffic flows through centralized egress points
Network-level isolation is required
Characteristics
Verax is not directly exposed to the public internet
Inbound access is limited to internal networks or trusted routing components
Outbound internet access is provided through controlled egress
[Diagram: private deployment on AWS - example]
Option B: Private Deployment with Public Ingress (Hybrid)
In this model, Verax remains deployed in a private network, but remote users access it through a controlled public entry point, such as a load balancer or reverse proxy.
This option is recommended when:
You need to support work-from-home or remote users
Users are not consistently connected through a VPN
You want to avoid exposing Verax directly to the internet
Characteristics
Verax has only private IP addresses
A public-facing ingress component exposes a public IP or DNS name
Traffic is routed from the ingress component to Verax over private networking
Network exposure is limited to the ingress layer
This model combines strong network isolation with support for remote users.
[Diagram: private deployment with public ingress on AWS - example]
Option C: Public Endpoint Deployment with Identity Enforcement
In this model, Verax is deployed with a public IP address or public-facing endpoint and is reachable directly by both local and remote users.
Access is restricted using identity enforcement at the proxy level, rather than relying on network location.
This option is recommended when:
Users operate from multiple locations and networks
VPN usage is limited or unavailable
You want a single, consistent access path for all users
Characteristics
Verax is publicly reachable
No implicit trust is granted based on network location
All access is gated by identity verification
Only authenticated and authorized organization users can route traffic through Verax
Verax Protect enforces identity at the proxy layer, ensuring that only verified organizational users can access the service, even when exposed through a public endpoint.
[Diagram: public deployment on AWS - example]
Inbound Connectivity (to Verax)
Management Interface — TCP 3000 (required)
Used to access the Verax management console
Allow access only from trusted administrative networks or IP ranges
Administrative Access — TCP 22 (optional)
Used for SSH access by administrators
Allow only from trusted administrative IP addresses
Optional and not required for normal operation
HTTP Proxy Traffic — TCP 443 (conditional)
Required if traffic is routed to Verax using a web proxy endpoint
Applies to DNS-based routing, PAC files, NAT, or host-based redirection
ICAP Traffic — TCP 1344 (conditional)
Required only if ICAP-based traffic redirection is used
Commonly used with secure web gateways or firewalls that support ICAP
Outbound Connectivity (from Verax)
HTTPS — TCP 443 (required)
Outbound HTTPS access is required for:
Proxying requests to generative AI tools
Accessing Verax update services and hotfixes
General outbound connectivity required for normal operation
No additional outbound ports are required.
Security Considerations
Choose network isolation, identity enforcement, or a combination of both based on your security model
Restrict inbound access to trusted sources and required ports only
Prefer controlled ingress components when exposing Verax publicly
Identity enforcement ensures that public exposure does not imply public access
Network location alone should not be treated as a trust signal
Summary
Verax supports flexible deployment models to fit modern enterprise environments:
Private deployments for network-isolated environments
Hybrid deployments for remote users with controlled public ingress
Public endpoint deployments secured through identity enforcement
Across all models, Verax applies consistent inspection, rule evaluation, and enforcement, allowing organizations to adopt generative AI securely without compromising visibility or control.