Configure Network and Security Appliances for Harvey

Overview

Harvey communicates over HTTPS and WebSocket connections on port 443. Firewalls, VPNs, and security appliances that terminate, inspect, or redirect that traffic can break specific Harvey features while leaving others working normally. Because of this, network policy issues may look like bugs within Harvey.

Use this guide to configure your network for Harvey and to troubleshoot problems that occur when users access Harvey through a secure web gateway, SASE, or SSL inspection product.

Please note that this guidance applies to Zscaler, Netskope, Palo Alto Prisma Access, Cisco Umbrella, Forcepoint, and similar security products.

Configuration Checklist

◻ Allowlist Harvey Domains on Port 443

Allow outbound access on port 443 to the following domains in your firewall, VPN, and security appliance, including both wss:// and https:// entries:

• https://app.harvey.ai
• https://eu.app.harvey.ai
• https://au.app.harvey.ai
• https://api.harvey.ai
• wss://api.harvey.ai
• wss://eu.app.harvey.ai
• wss://au.app.harvey.ai
• https://harvey-ai.us.auth0.com
• https://api.elevenlabs.io
• wss://api.elevenlabs.io
• https://api.eu.residency.elevenlabs.io
• wss://api.eu.residency.elevenlabs.io
• https://assets.harvey.ai
• https://azure.assets.harvey.ai

  • Ensure all sub-paths on this host are allowed. Do not restrict the rule to specific paths.
• https://*.blob.core.windows.net

  • If your security appliance does not support wildcards, allowlist the parent domain: blob.core.windows.net

Also confirm that authentication traffic passes through untouched. If the security appliance returns a 30x redirect for Harvey's /user_info request instead of forwarding it, sign-in will fail even though the domain is reachable.

Users may report the following if this item is not configured:

• Prompts stay in a Thinking state and never return a response
• Sign-in failure
• Unexpected redirects during SSO
• A block page appearing in place of Harvey
• Harvey loading only partially
• Harvey mobile app displaying a Connection issue error message on the corporate network, but working on cellular

◻ Exclude *.harvey.ai from SSL Inspection

Ask your security appliance administrator to exclude *.harvey.ai from SSL inspection, and confirm that nothing on your network downgrades traffic from HTTP/2 to HTTP/1.1.

Ensure your exclusion matches all direct and nested subdomains and paths of harvey.ai, for example:

• assets.harvey.ai (direct)
• azure.assets.harvey.ai (nested)

Harvey streams model responses over WebSocket and long-lived HTTPS connections. When a security appliance terminates and re-encrypts that traffic, it can drop the connection or buffer the whole response. SSL inspection is the most common cause of Harvey problems on a corporate network, and this exclusion resolves most of them.

Excluding a domain from inspection does not reduce the security of the connection. All traffic to Harvey remains encrypted end to end with TLS 1.2 or higher; the security appliance simply no longer decrypts and re-encrypts it in the middle. Harvey maintains SOC 2 Type II compliance, and current certifications and security documentation are available at trust.harvey.ai.

Users may report the following if this item is not configured:

• Prompts stay in a Thinking state and never return a response
• Responses arrive all at once at the end instead of streaming in progressively

◻ Exclude Azure Blob Storage from DNS Interception and SSL Inspection

Ask your security appliance administrator to exclude blob.core.windows.net from both DNS interception and SSL inspection.

Vault previews and uploads are served from Azure Blob Storage. Two interception behaviors break them:

• DNS interception. The security appliance resolves the storage hostname to a private address in its own range. The browser treats the response as coming from a different origin and fails with a CORS error.
• HTTP interception. The security appliance answers the request with an HTML block or notification page. Azure Blob Storage never returns HTML, so an HTML response to a storage request is a reliable sign that a middlebox intercepted it.

To check for DNS interception on an affected machine:

1. Open the browser's Network tab and read the exact storage hostname from a failing request.
2. Run nslookup <storage-account>.blob.core.windows.net.
3. If the result is in the 100.64.x.x range, the security appliance is intercepting the lookup.

Users may report the following if this item is not configured:

• Document preview errors or file upload failures in Vault, often with a CORS error in the browser console

◻ Harvey for Word and Outlook Add-Ins: Permit Login Domains in Office

This item applies only to the Harvey for Word and Harvey for Outlook add-ins, and is most often needed on Citrix and other VDI deployments of Office, or where your security appliance rewrites authentication traffic through its own gateway hostname.

Microsoft Office restricts which domains an add-in can open in a dialog. When authentication is routed through a gateway hostname that is not on Office's permitted list, Office silently blocks the login popup for Harvey’s add-ins.

Add the following domains to AllowedAppDomains in the Office registry, under HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\WEF\AllowedAppDomains:

1. Your organization's security appliance gateway URL
2. login.microsoftonline.com
3. harvey-ai.us.auth0.com
4. app.harvey.ai

If the add-in fails after this change, clear the Office add-in (WEF) cache on the affected machine and restart Office:

• Windows: %LOCALAPPDATA%\Microsoft\Office\16.0\Wef\
• macOS: ~/Library/Containers/com.microsoft.Word/Data/Library/Caches/

If you are not comfortable editing the registry or clearing these directories, contact Harvey Support rather than proceeding.

Users may report the following if this item is not configured:

• The login popup for the add-in never appears
• The add-in pane is blank or white
• An XSS or CSRF error appears

Verify Your Configuration

Use these two checks after completing the checklist during onboarding.

1. Run the Harvey connectivity check. From a machine on the corporate network, visit ping.harvey.ai (EU workspaces: eu.ping.harvey.ai; AU workspaces: au.ping.harvey.ai) and select Initiate Test. The check tests each Harvey endpoint individually and shows exactly which ones are blocked.
2. Compare on and off the corporate network. Repeat the failing action on a mobile hotspot, or with the security appliance client disabled. If it succeeds off-network, the cause is a network policy rather than Harvey itself.

When every endpoint passes and the behavior matches on and off the network, your configuration is complete.

Troubleshooting

If the checklist above is complete and a problem persists, complete the following steps:

• Turn off any VPN. A VPN layered on top of a security appliance is a common cause of timeouts.
• Try a different browser. Inspection and VPN clients interact with Harvey differently per browser, so a working alternate browser helps narrow the cause.

Then submit a Support Ticket with as much of the following as you can gather:

• A HAR file exported from the browser's Network tab during a failing session. This shows whether requests are being intercepted, redirected, or answered by the security appliance instead of Harvey, and lets our support team analyze the failure directly.
• Error messages or screenshots from the failing action.
• Results from the connectivity check for the affected region.
• Confirmation of whether the issue reproduces off-network.
• The inspection or filtering product in use, and the names of any policies applied to Harvey traffic.
• Browser and operating system versions, and the Office and add-in versions if the issue is in Word or Outlook.
• The affected user's email address and the approximate time of a failed attempt, so we can correlate against our logs.