Coverage
Network & Gateways
Use the gateway you already own
You do not need another inline proxy to see AI traffic. If you run a secure web gateway, it is already watching every AI request that leaves your network. SAF3AI ingests that feed from ten vendors, maps each vendor's own log format, and turns it into AI-specific risk.
What you see
The telemetry we pull
Who called which model
Every AI request crossing your gateway, resolved to a user, a device and a destination model provider — without terminating TLS yourself.
Sanctioned versus unsanctioned
Traffic to approved providers separated from traffic to the long tail of consumer AI tools, which is where shadow AI actually shows up in the network.
Prompt and payload metadata
Request size, token counts and, where your gateway captures it, the payload itself — enough to run data-loss detection on what left the building.
Blocked and allowed verdicts
What your existing gateway policy already stopped, so SAF3AI complements it rather than duplicating decisions it has already made.
Per-user AI footprint
The set of AI destinations each person reaches, aggregated over time — the evidence behind a shadow-AI conversation with a business unit.
Volume and cost signal
Request volume by destination, which surfaces both runaway automation and a team quietly running production traffic through a personal API key.
How it connects
From zero to first signal
- 1
Pick your existing gateway
If you already run Zscaler, Netskope, Palo Alto or one of eight other supported vendors, SAF3AI reads its AI traffic feed. No new inline hop, no new point of failure.
- 2
Point the feed at the ingest endpoint
Configure your gateway to stream logs to the SAF3AI webhook or bucket. Each vendor has its own log format and SAF3AI maps it — there is no normalisation work on your side.
- 3
Or route through the AI Gateway
Where you want inline enforcement rather than telemetry, SAF3AI can sit as a trusted upstream behind your existing proxy, or issue scoped API keys for specific teams and contractors.
- 4
Traffic becomes graph edges
Network observations resolve to the same users, agents and models as every other connector, so a gateway signal and a Copilot signal about one person are one story.
Payload-level detection depends on what your gateway captures. In metadata-only mode SAF3AI still resolves destination, user, device and volume — enough for shadow-AI discovery and exfiltration signal, but not for prompt content inspection.
What it catches
Risks specific to this surface
Shadow AI at network scale
The tools nobody declared, ranked by how many people use them and how much data they receive — the inventory that makes an AI policy enforceable.
Data exfiltration to consumer AI
Large payloads heading to unapproved AI destinations, correlated with the user and device that sent them.
Personal API keys in production paths
Application traffic authenticating with an individual's key, which fails audit and disappears the day that person leaves.
Policy gaps between gateways
Traffic that one gateway blocks and another allows, visible only when both feeds land in the same place.
Off-network AI use
The traffic that never crosses the gateway at all, which is exactly why network coverage pairs with endpoint and browser visibility.
Model provider concentration
Dependence on a single provider that nobody has quantified, which is a resilience and a commercial question as much as a security one.
Supported feeds
Ten vendors, each parsed natively
Every gateway logs AI traffic in its own shape. SAF3AI maps each one, so you configure a feed rather than building a normalisation pipeline.
See Network & Gateways in your own tenant
Connect this surface in a pilot and get a mapped inventory, a scored risk list and the attack paths that actually reach your data.