Lesson map
Lesson 02 published. Map, example, EX004.
flowchart TD
N0["Learning outcomes"]
N1["2.1 The request path"]
N2["2.2 Protocol roles"]
N3["2.3 Gateway controls"]
N4["2.4 Network abuse"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX004"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["2.1 The request path"]
N2["2.2 Protocol roles"]
N3["2.3 Gateway controls"]
N4["2.4 Network abuse"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX004"]
[Learning outcomes]
|
v
[2.1 The request path]
|
v
[2.2 Protocol roles]
|
v
[2.3 Gateway controls]
|
v
[2.4 Network abuse]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX004]
Learning outcomes
You will (1) trace an AI request across networks and protocols; (2) explain TLS, DNS and HTTP roles in AI services; (3) configure gateway controls such as rate limiting; and (4) recognise network-level abuse of AI endpoints.
2.1 The request path
A customer's browser resolves the shop's domain through DNS, opens a TLS connection, and sends an HTTP request. The web app calls internal services over the private network and calls the model vendor's API over the internet, again with TLS and an API key. Every hop is a place to authenticate, encrypt and log. For Ask Brightwell, the internal hop from orchestrator to order tool and the external hop to the vendor API both carry customer data, so both need TLS and logging. The vendor key in that external call is a credential like any other and must stay on the server.
2.2 Protocol roles
DNS maps names to addresses; if it is hijacked, users can be sent to a fake assistant. TLS protects confidentiality and integrity in transit and authenticates servers through certificates. HTTP carries requests and responses; streaming responses (server-sent events or WebSockets) are common for chat and need timeouts so idle connections do not pile up. Ask Brightwell streams answers to the browser, so an attacker who opens many streams and never reads them can tie up server connections. Timeouts on idle streams close them, and the gateway counts open streams per session as one of its limits. Certificate checks on the call to the vendor matter too, because the API key travels in it.
2.3 Gateway controls
An API gateway or reverse proxy sits in front of AI endpoints. It authenticates callers, enforces maximum request size, and applies rate limits. A token bucket allows a steady rate with short bursts: well-behaved users are served while floods are cut back.
"""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
Jonas's lab tests exactly this design, with a rate of 2 requests per second and a burst of 10, against a flood and a set of normal users. The gateway also rejects messages above a set length before they reach the orchestrator, so a single enormous request cannot consume a session's whole token budget.
2.4 Network abuse
Abuse patterns include floods to raise cost, scraping many answers to copy a model's behaviour (model extraction), and stolen API keys used from unexpected networks. Signals: request rates per key, unusual geographies, many distinct queries from one client. For Ask Brightwell, the useful signals are per-session request rates, token usage per account and how many distinct questions one client asks. A partner key that suddenly sends thousands of varied scoring calls to ReturnGuard is the pattern that later turned out to be extraction.
2.5 Worked example (synthetic Brightwell case)
Ask Brightwell's endpoint had no rate limit. Jonas runs the lab on a copy: at 2 requests per second with burst 10, all 90 normal requests are served while only 129 of 3,000 flood requests get through. At 1 per second, normal users start failing (62/90). He proposes 2/s burst 10 per session plus a daily token budget per account. The lab's numbers make the trade-off concrete. A limit loose enough to serve every normal request still cuts the flood to a small fraction, while halving the rate starts failing real users. Limiting by session rather than by address also avoids blocking customers who share a network.
2.6 Errors and limits
- Rate limiting by IP only (shared networks, botnets).
- Limits so tight they block real users.
- Vendor API keys in front-end code.
Jonas's proposal answers each. It limits by session and account rather than by address, it was chosen from the lab's measurements so that all 90 normal requests were still served, and it keeps the vendor key on the server. A limit that blocks real users would push the business to remove it, so measuring both sides matters more than choosing a strict number.
Exercises
- EX004 — Path. List each protocol hop for an Ask Brightwell request and one control per hop. Rubric: 3 = DNS, TLS, HTTP, internal, vendor API with controls; 2 = three or four; 1 = one or two; 0 = none.
- EX005 — Lab. Using the lab, justify the chosen limit. Rubric: 3 = normal served fully, flood reduced, tighter limit hurts users; 2 = two; 1 = one; 0 = wrong.
- EX006 — Key leak. A vendor API key appears in browser JavaScript. What happens and what is the fix? Rubric: 3 = anyone can use it, cost and abuse; rotate, move server-side, scope; 2 = partial; 1 = vague; 0 = none.
Synthesis
AI endpoints are internet services: secure DNS, TLS and HTTP, put a gateway in front, and tune rate limits so users are served while abuse is curbed.
Continue studying — chapter 02 of 30
← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →