Architecture

Forge discovers AI use and applies policy through configured gateways, supported network integrations, and managed devices. The traffic path determines which content, identity, and activity Forge can inspect. The same policy and evidence model also covers native network controls, explicitly configured gateways, and Forge on managed devices. You can use one deployment model or combine them to match how your organization works.

​

Choose a deployment model

Use only the routing capabilities available for your connection and client. Network integration setup, certificate trust, identity, and live traffic checks must complete before activation. Explicit gateways can be configured independently of device enrollment or network steering. Device routing also requires a qualified release for the selected platform. Windows full-profile rollout requires the exact Microsoft-signed WFP driver and retail-device acceptance; a development test-signed package or a signed endpoint operation helper does not satisfy that gate. Verify the selected Device Agent release and its installed-device evidence before a customer rollout. macOS signing and notarization are separate from enrollment, permissions, and actual routing qualification.

​

Agentless network routing

Forge works with a supported network platform to identify selected AI destinations and route their traffic to Forge. Users continue to access ChatGPT, Claude, Gemini, coding agents, model APIs, and MCP tools through their usual interfaces. Forge recognizes the destination and supported protocol, evaluates the request with the available identity and policies, and forwards allowed traffic. Native web and desktop inspection preserves the provider login. An explicit model API connection uses gateway credentials and model routes. Steering Claude web traffic does not turn that browser into a Claude Desktop gateway client. The organization chooses the destinations and establishes certificate trust. The provider guide defines whether its TLS inspection must bypass Forge-selected traffic or participate in the authenticated forwarding path. This provides content-aware enforcement without installing Forge on each endpoint or asking teams to replace their existing AI tools.

​

Provider network controls

Your network platform can enforce its own rules independently of Forge. Forge-managed forwarding rules select traffic for inspection. They do not replace Forge content, model, or MCP tool policy with provider-native rules. Cloudflare’s optional background discovery imports network metadata beyond the inline routing set. Metadata can reveal destinations and activity, but cannot establish inspected prompts, responses, tool calls, or Forge policy decisions. See Cloudflare WARP for the two data paths. Availability differs by integration. Review Palo Alto Networks, Zscaler, and Cato Networks before planning a rollout. A documented intended traffic path does not mean the integration is available for customer activation.

​

Forge on managed devices

Forge on devices extends governed routing to enrolled Windows and macOS endpoints, including devices away from the corporate network. It also connects traffic to the initiating device and process, discovers local AI products and configuration, and supports health and lifecycle operations through Devices. Administrators choose which devices use managed routing. Supported desktop, browser, developer API, and MCP traffic is sent to the same LLM and MCP Gateways used by agentless network routing. Administrators can also enable automatic routing for configured HTTP, HTTPS, PostgreSQL, MySQL, and Redis Resources. Those connections reach the assigned Resource Gateway and enter the same Resource policy and protocol engine used by direct access. Forge resolves identity, matches the bounded process ancestry to the existing product catalog, brokers the destination credential, applies Resource Policies, transforms supported HTTP, PostgreSQL, or MySQL data before delivery, and records Resource Activity. Approval also uses the same exact-retry workflow on both paths; Forge does not hold a device connection while a person responds. Other traffic keeps its normal route. The device agent does not expose a local Resource listener. See Forge for devices for setup and Resource Policies for supported protocols.

​

Explicit gateways

Applications and workloads can connect directly to the LLM Gateway or MCP Gateway. This model is useful for developer APIs, shared services, and MCP clients whose endpoints are centrally configured. The LLM Gateway manages provider access, models, budgets, and content policy. The MCP Gateway controls which servers and tools each user or workload can access. Both produce a consistent session and audit trail alongside traffic routed from network and device control points. Supported interactive clients authenticate each person through organization sign-in. Forge resolves their current directory identity and managed-access assignment. Applications and unattended services can use scoped gateway keys. See Gateway authentication for token and access requirements. Resource Gateways are customer-deployed. They provide a stable direct endpoint for HTTP, HTTPS, PostgreSQL, MySQL, and Redis clients and make outbound connections to private destinations. Each runtime needs outbound HTTPS to Forge for configuration and must be able to reach its assigned Resources; it does not require inbound control-plane access. See Resource Gateways.

​

Endpoint collection and operations

Forge can use an existing CrowdStrike, Defender, SentinelOne, or LimaCharlie agent to collect supported inventory and run approved endpoint operations. These connections are separate from network steering and explicit gateway authentication. An imported endpoint does not automatically provide inspected web traffic or gateway model access. Each operation targets a verified provider device and records its execution and verification results. Local collection can use a provider-backed helper. Passive LimaCharlie Output observations do not grant remote execution. See Endpoint operations for setup and pilot checks.

​

Shared policy and evidence

Every deployment model connects to the same Forge control plane. Forge combines identity, application, device, and configuration context from connected enterprise systems, then uses that context across policy, investigations, and operations. Source records retain their origin and observation time as Forge correlates identities, devices, applications, workloads, and sessions. Sensitive session content and Resource Activity details follow the organization’s evidence-detail retention period. Resource Activity records follow the security-record retention period, and preservation holds pause both cleanup stages. Secrets are resolved only by authorized collectors and runtime components. Resource approval requests, decisions, grants, grant use, and revocations are recorded in the existing organization audit log. The audit trail includes the resource and requested operation without storing destination credentials or raw secret values. Requester contact and justification details follow the evidence-detail retention period; the resulting audit events follow the security-record retention period. Preservation holds pause both cleanup paths. Review Gateway, MCP Gateway, Resource Policies, Privacy, and Audit Log for the controls that apply across these deployment models.