> ## Documentation Index
> Fetch the complete documentation index at: https://docs.beyondguard.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# ICAP and Proxy Deployment for Inline Inspection
> Deploy BeyondGuard inline as a proxy using ICAP — traffic flow, proxy egress options, internal connectivity, port summary, and mail interception.
Beyond the [Guard Gateway API](/api-reference/guard-gateway), BeyondGuard can inspect traffic **inline as a proxy** using ICAP (Internet Content Adaptation Protocol). In this mode, client traffic flows through a proxy that hands each request to BeyondGuard for inspection before allowed traffic is forwarded to its destination.
```text theme={null}
Client → Proxy Server → BeyondGuard → (allowed) → Destination
```
## Core services
| Service | Port(s) | HA | Exposure |
| - | - | - | - |
| `bg-proxy-server` | 8080 | Yes | Client-facing; intercepts traffic and relays approved traffic outbound |
| `bg-icap-server` | 1344, 8080 | — | Internal (reachable from the proxy server) |
| `bg-service-engine` | 8080 | — | Internal |
| `bg-log-writer` | — | — | Internal background consumer (no listening port) |
| `bg-management-panel-be` | 8000 | — | Internal / behind reverse proxy |
| `bg-management-panel-ui` | 3000 | — | Internal / behind reverse proxy |
| Guard microservices | 8080 | — | Internal only |
Backing services for this module are **PostgreSQL 15+** (primary datastore) and **Kafka 3.x** (event bus for the audit-log pipeline consumed by `bg-log-writer`). Each can be containerized or an existing external instance.
## Proxy network position
Because the proxy is what ultimately relays approved traffic to external destinations, its **outbound reachability is the critical networking decision** for this module. There are two supported positions:
Position `bg-proxy-server` on a network segment with outbound internet access (directly or via NAT / egress gateway). Outbound access is required to the destinations being inspected — external web endpoints and/or LLM provider endpoints — typically on TCP 80 and 443. No additional proxy configuration is required.
If the proxy host cannot reach the internet directly (segmented, restricted, or air-gapped-with-egress-broker environments), configure an **upstream proxy**. `bg-proxy-server` forwards all outbound traffic to a designated corporate egress proxy that holds internet access:
```text theme={null}
bg-proxy-server → Upstream Proxy (with internet egress) → Destination
```
Provide the upstream proxy host, port, and credentials (if it requires authentication). If the upstream proxy performs TLS interception, supply its CA certificate so it can be trusted by the proxy server.
## Internal connectivity
* All guard microservices and the Service Engine are **internal-only** and require no outbound internet access.
* `bg-icap-server` must be reachable from `bg-proxy-server` on the ICAP port (**1344**) and HTTP port (**8080**).
* `bg-management-panel-be` requires connectivity to PostgreSQL and Kafka.
* During installation, outbound access to the image repository (and Helm repository for Helm deployments) is required to pull artifacts — mirrorable to an internal registry in restricted environments.
`bg-proxy-server` is the only traffic-facing service and should run in **HA** so that interception is not a single point of failure.
## Mail interception
In addition to HTTP/proxy traffic, BeyondGuard can monitor email via **IMAP**, **Microsoft Exchange**, and **POP** connectors, bringing mail-borne content under the same policy engine as the rest of your AI traffic.
## Related
Where the proxy and ICAP layers sit in the stack.
Backing services and network prerequisites.
The API-based integration path.
Deploy the proxy and ICAP services.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.