Guided defense lab

Network / Egress Restrictions

A guided exercise on one question: may this workload establish this network path to this resolved destination under application-owned egress policy? Service IDs, canonical destinations, redirect hops, internal destinations and why reachability is not permission.

Conceptual simulationAdvanced15 minutes2026-09-27

Conceptual simulation

This exercise uses authored, deterministic examples with fictional workloads, services and .example.test names. It makes no network connections or DNS lookups, calls no tools, APIs or models, and does not predict how any real system behaves.

Step 3 of 63/6

Learning objectives

Decide egress from the workload egress class, service ID or destination class, canonical destination, resolved network class and policy version.
Treat every redirect hop as a fresh egress decision.
Recognize that a schema-valid URL or a hostname string is not an allowed, currently resolved destination.
Explain why internal destinations are not automatically reachable and why reachability is not trust.
Keep egress separate from Agent Authorization, Information Flow Control, Least Privilege and Output Validation.
Explain why a model cannot mint an exception, service ID or allowlist entry, and why a blocked path is not proof of an attack.

Prerequisites

Network / Egress Restrictions defense article (recommended)
Agent Authorization lab (recommended)

Choose a scenario

Each fictional scenario shows task and model text and, separately, the application-owned network facts: egress class, service mapping, resolved attributes, redirect hop and policy version. You decide only whether the network path may exist - not whether the action may run or data may move.

Approved service ID, approved endpointAn inventory read uses the application-owned service ID inventory-read, which the workload's egress class maps to one internal API endpoint.Model-supplied external upload URLThe task needs no external upload, but model output proposes a structurally valid HTTPS upload destination at a partner host.Redirect leaves the approved boundaryA request to an approved internal documentation service receives a redirect to an external host that has no allowed destination identity for this workload.Internal management destinationA proposed destination is a fictional internal management-plane service, but the workload has no management network or service class.Bounded approved external docs readA documentation task uses the configured service ID vendor-docs-read, mapped by the application to one external documentation host.

Egress path

The application assigns the workload an egress class, canonicalizes and resolves any proposed destination, records resolved attributes and redirect hops, decides under egress policy and enforces at a network point. Proposed destination values stay variable. Remote content and claims are never application-owned just because a destination is reachable.

Workload / task egress classApplication-owned->
Proposed destination valueVariable content->
Canonicalization + service / destination resolutionApplication-owned->
Resolved network attributes / redirect hopApplication-owned->
Egress policy decisionApplication-owned->
Network enforcement pointApplication-owned

Task and model text

What the user asks and what a model proposes or claims. It cannot create a service ID, exception or allowlist entry.

User task
How many units of item K-12 are in stock?
Model proposal
call service inventory-read: GET stock for K-12

Application-owned network facts

Workload egress class, service mapping, canonical destination, resolved network class, TLS identity, redirect hops and policy version as recorded by the application.

Workload egress class: inventory-assistant: service inventory-read only
Service mapping: inventory-read -> https://inventory-api.internal.example.test:443
Resolved attributes: current resolution in approved service network class svc-inventory; TLS/service identity matches inventory-api
Redirect / policy: no redirect; policy egress-v3