Learning outcomes
- Place clients, gateways, portals, enclaves, and application sandboxes in the request path.
- Compare protocol coverage, client requirements, bypass, identity, and failure behavior.
- Select a model for a named resource rather than for the whole network by default.
- Combine models without creating parallel implicit-trust paths.
System and boundaries
In a device agent and gateway model, endpoint software steers traffic to a gateway. In an enclave gateway model, gateways protect communication between defined network or service enclaves. In a resource portal model, a client reaches resources through a browser or application portal without a general endpoint tunnel. Application sandboxing isolates selected application traffic and state on the device. These are placement patterns, not complete policy models.
Request and decision flow
For each model, trace client selection, endpoint identity, traffic steering, gateway or portal, policy decision, protected resource, application authorization, evidence, and recovery. State which protocols and applications the path supports and whether the client can reach the resource another way.
Failure domains
Device agents can be disabled or compromised. Enclave gateways can preserve broad trust inside the enclave. Portals can cover only compatible application traffic and can become credential or content intermediaries. Sandboxes can share host, browser, network, or identity state. Mixed models can create an unreviewed fallback path.
Design tradeoffs and residual risk
Endpoint clients cover more protocols and increase deployment and device trust. Clientless portals reduce endpoint work and limit protocol and application compatibility. Enclave gateways ease migration and retain internal implicit trust. Sandboxing improves separation and adds platform dependence.
Residual risk includes direct origins, unmanaged devices, unsupported protocols, compromised clients, broad enclave access, portal application defects, and incomplete evidence across models.
Pomerium boundary
Pomerium provides clientless HTTP access and documented client or native patterns for selected non-HTTP protocols. It can serve as a resource-facing gateway or portal component. Operators choose topology, client coverage, upstream isolation, endpoint controls, network boundaries, and application authorization.
Exercise
Apply all four models to one administration service with browser, API, and SSH access. For each, draw client, enforcement, identity, protocol, direct path, failure, evidence, and recovery. Select the smallest model set that covers the required paths.
Evaluation checklist
- Which named resources and protocols does each model cover?
- Where are client, gateway, portal, enclave, and application trust boundaries?
- Can the client or another workload bypass the selected path?
- What happens when the agent, gateway, portal, or sandbox fails?
- Does combining models preserve one explicit policy and evidence chain?
Next learning unit
Zero Trust
Zero trust does not assume that every user or device is malicious.
