◇ OpenCyber Academy
Engineering · Chapter 11 · English

Chapter 11 — Networks and protocols

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 11 — Networks and protocols

Lesson map

Lesson 11 published. Map, example, EX031.

flowchart TD
  N0["Learning outcomes"]
  N1["11.1 The request path"]
  N2["11.2 Threats specific to AI APIs"]
  N3["11.3 Segmentation"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX031"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["11.1 The request path"]
  N2["11.2 Threats specific to AI APIs"]
  N3["11.3 Segmentation"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX031"]

[Learning outcomes]
    |
    v
[11.1 The request path]
    |
    v
[11.2 Threats specific to AI APIs]
    |
    v
[11.3 Segmentation]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX031]

Learning outcomes

You will (1) explain the network path of a model-serving request (DNS, TCP, TLS, HTTP); (2) identify network-level threats to AI services (interception, denial of service, abuse of APIs); (3) design network segmentation for training, serving and tool back-ends; and (4) interpret API rate limits and quotas as security controls.

11.1 The request path

A client resolves the service name with DNS, opens a TCP connection, negotiates TLS (which authenticates the server and encrypts traffic) and sends an HTTP request — typically JSON containing a prompt or features. The server returns a response, perhaps streamed token by token. Each layer has its own failure modes: DNS spoofing, TLS misconfiguration, HTTP request smuggling, oversized bodies.

Engineers review each layer separately. DNS records are protected and monitored, TLS settings are checked against current guidance, and the HTTP layer enforces maximum body size and request time before the model sees anything. A request rejected at the edge costs almost nothing; the same request reaching the model can cost seconds of accelerator time.

11.2 Threats specific to AI APIs

Beyond classic network attacks, AI APIs face model extraction by systematic querying (Tramèr et al., arXiv:1609.02943), membership inference through confidence outputs, and unbounded consumption (OWASP LLM10): long prompts and outputs that exhaust compute or budget. Because each request is expensive, ordinary request-per-second limits are not enough; quotas should account for tokens and compute.

"""Lab R: token-bucket limits against unbounded consumption (synthetic).
Simulates 60 seconds of requests from a normal client and a flooding client
against a model endpoint with a per-client token bucket."""
import random
rng = random.Random(4)
def simulate(rate_per_s, burst, reqs):
    tokens, last, ok = burst, 0.0, 0
    for t in reqs:
        tokens = min(burst, tokens + (t - last) * rate_per_s); last = t
        if tokens >= 1: tokens -= 1; ok += 1
    return ok
normal = sorted(rng.uniform(0, 60) for _ in range(90))
flood = sorted(rng.uniform(0, 60) for _ in range(3000))
for rate, burst in ((5, 20), (2, 10), (1, 5)):
    print(f"limit={rate}/s burst={burst:2d} normal_served={simulate(rate, burst, normal):3d}/90 "
          f"flood_served={simulate(rate, burst, flood):4d}/3000")

Expected output:

limit=5/s burst=20 normal_served= 90/90 flood_served= 319/3000
limit=2/s burst=10 normal_served= 90/90 flood_served= 129/3000
limit=1/s burst= 5 normal_served= 62/90 flood_served=  64/3000

The lab shows a token bucket that serves a normal client fully while limiting a flooding client. Too strict a limit (1/s, burst 5) starts refusing legitimate traffic — limits are a trade-off to tune with real usage data.

11.3 Segmentation

Place training clusters, model registries, serving endpoints and tool back-ends in separate network zones. Serving should not reach training data stores; an LLM agent's tool back-end (for example a work-order system) should accept calls only from the policy service, not directly from the model host. Egress filtering prevents a compromised or manipulated component from sending data to arbitrary destinations — a direct mitigation for exfiltration through injected tool calls.

Zones are enforced by firewall rules and checked by testing: from the model host, a connection to the work-order system or an outside address should fail. Recording these tests means segmentation stays verified after network changes rather than assumed.

11.4 Worked example (synthetic NRS case)

Wrench's model host could reach the internet to fetch supplier bulletins and could also call the work-order API directly. Sam moved bulletin fetching into a separate ingestion service that stores sanitised copies, removed internet egress from the model host, and made the work-order API accept requests only from the policy service with mutual TLS.

The changes cut both untrusted-to-privileged paths at the network level. Even if a bulletin manipulates the model, the model host cannot send data out or reach the work-order system without passing the policy service. Sam verifies each change by attempting the blocked connections from the model host and recording the refusals as evidence.

11.5 Errors and limits

Counting requests alone lets one client send a few huge prompts that cost as much as thousands of small ones. Flat networks mean that one manipulated component can reach every system. Unrestricted egress gives injected instructions a way to send data out. The lab's third setting adds a further lesson: limits tuned without usage data can refuse a third of legitimate requests, so quotas need measurement as well as security reasoning.

Exercises

Synthesis

AI services are network services with expensive requests. TLS, segmentation, egress control and compute-aware quotas reduce interception, abuse and the impact of manipulated components.

Continue studying — chapter 11 of 50

← Chapter 10 (draft) · Course chapter index · Chapter 12 (draft) →