> ## Documentation Index
> Fetch the complete documentation index at: https://docs.inviolet.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Network enforcement overview

> How Inviolet integrates with SWG / CASB vendors to stop and measure LLM bypass — the two integration directions and which vendor does what.

Agents and users can bypass Inviolet by calling an LLM **directly** instead of
through the governed path. Inviolet closes that gap at the network layer by
integrating with your existing Secure Web Gateway (SWG) / CASB — in **two
directions**:

* **Enforce (SWG — write):** push a rule into the vendor that **blocks** direct
  LLM access, forcing traffic through Inviolet.
* **Observe (CASB — read):** pull or receive the vendor's egress logs so Inviolet
  **sees** bypass volume and attributes it to a user.

## Read vs write

The same vendor appliance can be integrated either way, with very different
cost and blast radius:

|                       | CASB — observe (read)     | SWG — enforce (write)        |
| --------------------- | ------------------------- | ---------------------------- |
| What it does          | Detects "bypass happened" | Blocks it in real time       |
| In the traffic path?  | No (passive)              | Yes (inline)                 |
| Latency to signal     | Minutes (log lag)         | Real time                    |
| Risk if misconfigured | None                      | Can block legitimate traffic |
| Setup                 | An API token / log stream | A policy + device enrollment |

Most teams start with **observe** (low risk, quick visibility) and add **enforce**
where they want a hard block.

## Vendor support

| Vendor                                                       | Observe (CASB) | Enforce (SWG)               |
| ------------------------------------------------------------ | -------------- | --------------------------- |
| **[Cloudflare](/integrations/network/cloudflare)**           | ✅ Logpush      | ✅ Gateway (fully validated) |
| **[Zscaler](/integrations/network/zscaler)**                 | ✅ connector    | On request                  |
| **[Netskope](/integrations/network/netskope)**               | ✅ connector    | On request                  |
| **[Palo Alto Prisma](/integrations/network/prisma)**         | ✅ connector    | On request                  |
| **[Cisco Umbrella](/integrations/network/umbrella)**         | ✅ connector    | On request                  |
| **[MS Defender for Cloud Apps](/integrations/network/mcas)** | ✅ connector    | On request                  |

**Cloudflare** is the reference implementation, validated end to end (see its
page for the full setup, including everything we learned). For the other vendors,
the **observe** side connects via an API token today; **enforce** packs are
delivered per engagement — [contact us](mailto:support@inviolet.ai) to scope one.

## What you don't need

You don't have to route *all* traffic through Inviolet to prevent API bypass —
the strongest control is **credential isolation** (agents never hold the LLM API
key; they can only call via Inviolet). The SWG layer is complementary: it catches
the human/browser case and enforces at the network for teams that want it.