---
title: Network Requirements
description: Every hostname and port 1Security needs, in one table - plus copy-paste unblock steps for FortiGate, Zscaler, Netskope, Palo Alto and Cisco Umbrella when a web filter classifies 1Security as an AI site.
icon: Network
---
# Network requirements
Everything your network team needs to let 1Security through: the exact hostnames, ports and directions, what happens if each one is blocked, and vendor-by-vendor instructions for the one thing that actually trips deployments - a category-based web filter that reads `1security.ai` as an AI site and blocks it.
The headline: **1Security is a browser-only SaaS product.** No inbound rules, no VPN, no tunnel, no collector, no agent on endpoints. Your users' browsers make ordinary outbound HTTPS connections, and that is the whole footprint.
## What has to be reachable
All entries are **TCP 443, outbound only**, from your users' browsers.
| Hostname | Purpose | If it's blocked |
| :--- | :--- | :--- |
| `app.1security.ai` | The dashboard itself | Nothing loads. |
| `api.1security.ai` | GraphQL API and [public REST API](/en/docs/reference/api) - every screen's data, plus SIEM polling | The dashboard shell loads and then stays empty or spins forever. **This is the most common half-configured state:** the apex domain gets allowlisted, the API subdomain doesn't. |
| `1security.ai` | Public site, documentation, sign-in entry point | Users can't reach sign-in or these docs. |
| `login.microsoftonline.com` | Microsoft sign-in and admin consent | Nobody can authenticate. Almost always already allowed in a Microsoft 365 tenant. |
| `*.sharepoint.com`, `*-my.sharepoint.com` | "Open in SharePoint" deep links from findings | The product works; the jump-to-file links fail. Also normally already allowed. |
Optional, and safe to leave blocked - none of these affect functionality:
| Hostname | Purpose |
| :--- | :--- |
| `posthog.1security.ai`, `eu.i.posthog.com` | Product analytics |
| `o4509649988026368.ingest.de.sentry.io` | Browser error reporting |
**Nothing else.** No inbound firewall rules. No source-IP allowlist on your
side. No ports other than 443. No software to install - no browser extension,
no desktop agent, no endpoint software, no log forwarder.
### Which way the traffic goes
- **1Security never connects into your network.** It calls Microsoft Graph on your tenant's behalf, from our cloud to Microsoft's - your perimeter isn't in that path at all.
- **SIEM integration is pull-based.** Your SIEM calls `api.1security.ai` on a schedule; we never call it. See [SIEM Integration](/en/docs/guides/siem-integration).
- **Plain HTTPS request/response.** No WebSockets, no long-polling, no streaming connections to keep open through a proxy.
## When a web filter blocks 1Security
The symptom is unmistakable: instead of the dashboard, users get **your own vendor's block page** - FortiGuard, Zscaler, Umbrella and the rest all serve a branded page naming the category they blocked.
The cause is almost always the same. Every major web filter added a dedicated AI category in 2024-2025 (FortiGuard's **Artificial Intelligence Technology**, Palo Alto's **artificial-intelligence**, Umbrella's **Generative AI**), and many organizations block that whole category by default. A domain that ends in `.ai` and has a product name containing "Security" for an AI-adjacent product gets swept up by automated classification - even though 1Security is a Microsoft 365 security dashboard, not a generative-AI service, and users neither upload nor paste data into a model through it.
There are two fixes and you want both:
1. **Unblock locally** using your vendor's instructions below. Takes minutes, works immediately, done by whoever administers your web filter.
2. **Tell us**, so we file a recategorization request with the vendor. That fixes it globally for every customer on that vendor - see [Getting the rating fixed at source](#getting-the-rating-fixed-at-source).
Prefer a **domain-specific override** over disabling the AI category. Every
option below unblocks 1Security alone and leaves the rest of your AI policy
exactly as it is. Nobody should have to weaken a working control to run a
security tool.
## FortiGate
Locally re-rates the domain into a category you already permit. The AI
category block stays fully intact for every other site, no policy is edited,
and all remaining UTM inspection (antivirus, DLP, content filter) still
applies to 1Security traffic. This is the cleanest option.
**GUI:** Security Profiles → Web Rating Overrides → Create New. For each
hostname, set **Category** to `General Interest - Business` and
**Sub-Category** to `Information Technology`.
**CLI:**
```
config webfilter ftgd-local-rating
edit "1security.ai"
set status enable
set rating 52
next
edit "app.1security.ai"
set status enable
set rating 52
next
edit "api.1security.ai"
set status enable
set rating 52
next
end
```
Rating `52` is **Information Technology** in the current FortiGuard
category set - confirm against the dropdown in your own build if you
prefer. Add an entry per hostname as shown: an override matches the
hostname you enter, so a single `1security.ai` entry is not guaranteed to
cover `app.` and `api.`, and those two are exactly the ones that must
work.
Works, but it is the blunt instrument - reach for it only if your change
process rules out rating overrides.
Security Profiles → Web Filter → your profile → **Static URL Filter** →
Create New. Add each hostname with Type `Simple` and action **Exempt**.
**The action must be `Exempt`, not `Allow`.** This is the single most
common mistake here. In FortiOS, `Allow` means "passed by the URL filter,
now continue to the remaining inspections" - including the FortiGuard
category filter, which is the thing doing the blocking. The site stays
blocked and the change looks like it silently did nothing. Only `Exempt`
bypasses the category lookup. See Fortinet's own
[Allow vs Exempt](https://community.fortinet.com/t5/FortiGate/Technical-Tip-The-difference-between-Allow-and-Exempt-in-the-web/ta-p/261349)
note.
The trade-off: `Exempt` bypasses **all** remaining scanning for that
destination - antivirus, DLP, web content filter, everything - not just the
category check. A rating override doesn't.
A **separate axis** from the category block, and usually not what you need.
Only relevant if 1Security loads but behaves erratically - certificate
warnings, truncated responses, requests failing under deep inspection.
Security Profiles → SSL/SSH Inspection → your deep-inspection profile →
**Exempt from SSL Inspection** → Addresses / Web categories.
If users are seeing a FortiGuard block page naming a category, this is not
the fix - use a rating override instead. Exempting from SSL inspection does
not lift a category block.
## Zscaler
Two places may need attention, because Zscaler filters URLs and cloud apps separately.
### Create a custom URL category
Administration → URL Categories → Add. Include `1security.ai`,
`app.1security.ai` and `api.1security.ai`. Custom categories take precedence
over Zscaler's own categorization.
### Allow it in URL Filtering
Policy → URL & Cloud App Control → URL Filtering. Add a rule with action
**Allow** for that custom category, ordered **above** any rule blocking the
AI-related categories.
### Check Cloud App Control
If your tenant blocks the **AI & ML Applications** cloud-app category, add an
allow rule for 1Security there too. A URL Filtering allow does not override
a Cloud App Control block - deployments that fix only the first one still
fail.
## Netskope
### Add a URL list
Policies → Profiles → URL Lists → New URL List. Add the three hostnames.
### Wrap it in a custom category
Policies → Profiles → Custom Categories. Netskope applies URL lists to
policies through a custom category, not directly.
### Allow it ahead of the Gen-AI rule
Policies → Real-time Protection. Add an **Allow** policy for that category
and order it **above** any Generative AI blocking policy. Netskope evaluates
top-down and stops at the first match.
## Palo Alto Networks
Objects → Custom Objects → **URL Category**. Create a category containing
`1security.ai`, `app.1security.ai` and `api.1security.ai`, then set that custom
category to **allow** in the URL Filtering profile attached to your outbound
policy. Custom categories are evaluated before PAN-DB, so this holds regardless
of how PAN-DB rates the domain - including the granular AI categories introduced
in Advanced URL Filtering.
## Cisco Umbrella
Policies → Policy Components → **Destination Lists**. Create an *Allow* list
with the three hostnames and apply it to the policy covering your users.
Umbrella evaluates allow lists before content categories, so this takes effect
without touching your Generative AI category setting.
Note that Umbrella's DNS-layer enforcement resolves on the domain only - one
allow list entry per hostname is still the safe shape.
## Getting the rating fixed at source
Local overrides fix one organization. A recategorization request fixes everyone
on that vendor, usually within 24-48 hours, and it is free. If you have hit this
block, **tell your 1Security contact which vendor and which category the block
page named** - we file the request. You are welcome to file one in parallel;
a report from an affected customer often carries more weight than one from the
site owner.
| Vendor | Where to submit |
| :--- | :--- |
| Fortinet / FortiGuard | [fortiguard.com/faq/wfratingsubmit](https://www.fortiguard.com/faq/wfratingsubmit) - reviews generally processed within 24 hours |
| Zscaler | [sitereview.zscaler.com](https://sitereview.zscaler.com/) |
| Netskope | Skope IT → Tools → **URL Lookup** → *Report Miscategorization* |
| Palo Alto Networks | [urlfiltering.paloaltonetworks.com](https://urlfiltering.paloaltonetworks.com/) → *Request a Change* |
| Cisco Umbrella | [Dispute a categorization](https://docs.umbrella.com/umbrella-user-guide/docs/dispute-a-categorization), or submit directly through Cisco Talos |
The category to request is **Information Technology** (or your vendor's nearest
equivalent - Business, Computers and Internet, Software as a Service).
## Self-hosted deployments
The table at the top covers Cloud (SaaS), where 1Security calls Microsoft and
your network is not involved. **BYOC and On-Premise** deployments make those
Microsoft calls from inside your environment, so the deployment itself needs
outbound HTTPS (443) to `login.microsoftonline.com`, `graph.microsoft.com`,
`manage.office.com`, `.sharepoint.com`, `-my.sharepoint.com`,
plus `outlook.office365.com` and `*.compliance.protection.outlook.com` for the
audit and Purview modules. Sizing and deployment models are in
[Installation](/en/docs/installation).
## Troubleshooting
A category-based web filter. Read the category off the block page itself -
it will name one - and apply the matching vendor section above. Then send us
the vendor and category so we can file the recategorization.
`app.1security.ai` is allowed but `api.1security.ai` is not. The page is
static assets, so it loads; every piece of data on it comes from the API
host. Allowlist both. This accounts for most "it half works" reports.
The action is almost certainly `Allow`. It has to be `Exempt` - `Allow`
passes the request on to the FortiGuard category filter, which blocks it
again. Or switch to a web rating override, which is the better fix anyway.
TLS deep inspection, not category filtering. Add 1Security's hostnames to
your inspection exemption list and retest. If the error is a block page
rather than a certificate warning, this is not the cause.
Server egress usually runs through a different policy than user browsing.
The API host `api.1security.ai` needs to be reachable on 443 from whichever
host runs the poller - see [SIEM Integration](/en/docs/guides/siem-integration).
Next: the tenant-side prerequisites - licenses, admin roles and permissions -
are in [Requirements](/en/docs/requirements).