System Boundaries: Security, Data Sensitivity & Topology · the finale
You've designed a system, audited its honesty, its provenance, and its evaluation. This last one asks you to draw its boundaries — and then to name the single instinct that has run through the entire course. The grade is in the reasoning, not in finding a flawless system.
Time: ~45–60 min · Due: before the wrap session · Submit: post your write-up in the cohort channel.
Pick one system or proposed AI feature that touches sensitive data — or a component you'd be tempted to put inline.
⚠️ The smart-home camera audited below is off-limits as your submission — it's the worked demo. Pick something else.
In a ~300–400 word audit, walk the five boundary decisions:
- Classify. What's the data's sensitivity tier, and what does that label force (where it can live, which providers, who sees it)? Does the label travel with the data?
- Minimize. Does it need a durable store? Which copies, caches, or logs could you eliminate? Preserve the one source — minimize its shadows.
- Egress & fail-closed. What may cross the perimeter, and to where? Does the control fail closed when it can't run — and is it usable enough that nobody routes around it?
- Inline or beside. Must it enforce on every request (inline), or does it reflect / advise (beside)? What does inline cost you — and is it worth it here?
- Blast radius. If it fails — and if it's AI, it can be confidently wrong — what's the damage? What's the fallback that doesn't depend on it?
- Name a security control you've seen that was so strict people routed around it. More secure, or less — and what does that say about "usefulness is a security property"?
- Take a component you'd be tempted to put inline. What does it cost to depend on it, would it be safer beside, and when is inline actually worth it?
- Minimize vs preserve: when does minimization threaten Module 3's preserved source — and how do you honour both at once?
- The synthesis. Looking back across all five modules, what single instinct shows up in every one? Point to where you saw it in each — your own homework counts.
Reply to one classmate's audit. Find where they put something inline that should be beside (a needless dependency, chokepoint, or blast radius), or where restricted data could cross a boundary it shouldn't — and propose the fix.
Everything below is just these, applied to one component. Keep them in front of you:
- Classify, and let the label drive. Restricted data gets the strongest controls — and the label has to travel with the data, because a boundary can only protect what it recognizes.
- Minimize. You can't leak what you don't store. Preserve the one authoritative source; minimize its copies — caches, logs, shadow stores.
- Control egress, fail closed — stay usable. Restricted data may be processed inside but never sent out; when the control can't run, deny. A control everyone routes around protects nothing.
- Inline to enforce, beside to reflect. Inline can enforce but is a dependency and a chokepoint; beside can advise but can't enforce.
- Contain blast radius by placement. Keep the confidently-wrong-prone component off the irreversible path, with a fallback that doesn't depend on it.
Let's run the audit on something that is not your assignment: a smart-home security camera + hub with an on-device AI that recognizes people and can trigger actions (notify you, or unlock the door for a recognized face). Watch the moves, then make them on your own system.
1 · Classify. The camera and audio feed is highly sensitive personal data — top tier. That label forces decisions immediately: raw footage should stay on-device or in a tightly controlled zone, and "send it to a clever cloud model" is constrained before you even weigh how good that model is. Capability doesn't override classification.
2 · Minimize. Does the hub need a durable archive of every second of video? No. Process the stream on-device, keep only short event clips for as long as they're useful, and don't ship raw frames anywhere. You can't leak footage you never stored. If there's a "preserved source" worth keeping (a flagged-event clip), preserve that one copy and starve the rest — no scattered caches, no full-history cloud reservoir.
3 · Egress & fail-closed. If person-recognition uses a cloud model, restricted raw video must not cross the perimeter — send only minimal derived features, or keep recognition on-device. And fail closed: if the egress/privacy control can't run, the hub does not upload — it degrades to local-only, it doesn't quietly stream footage out. The control also has to be usable, or people disable the whole privacy mode to make the app work — which protects nothing.
4 · Inline or beside? Here's the decision that defines the system. Does the AI sit inline — it decides whether to unlock the door — or beside — it notifies you and you decide? For a consequential, hard-to-reverse action like unlocking a door, the AI belongs beside: it advises, the human decides, and the normal key/PIN works regardless. Inline would buy convenience at the cost of putting a fallible component in the path of an irreversible action.
5 · Blast radius. The AI is confidently-wrong-prone. Inline, a confident misidentification unlocks the door to a stranger — an uncontained, irreversible failure. Beside, the same misidentification is a spurious notification — annoying, contained, recoverable. The fallback (the physical key / PIN) doesn't depend on the AI at all, so when the model is wrong or down, the security of the door is unaffected.
Notice what just happened: I let the label drive everything, minimized to no raw-video reservoir, controlled egress with fail-closed, placed the AI beside the consequential action, and contained its blast radius with a non-AI fallback. That's the whole of Part A. Your job is to make those five moves on your system.
Two contrasts to look for: an inline control that enforces (and fails closed), and a risky component placed beside the consequential path. Your audit asks, for each piece: does it need to be inline — and does restricted data have any arrow across the perimeter it shouldn't?
flowchart TD
DATA([Camera feed<br/>restricted data])
GATE["Egress gateway<br/>INLINE · enforces · fails closed<br/>restricted data never leaves"]
DET["AI detector<br/>BESIDE · advises only"]
OWNER["Owner decides<br/>+ key/PIN fallback"]
LOCK([Door lock<br/>consequential])
CLOUD([Outside perimeter])
DATA --> GATE
GATE -- minimal derived features only --> CLOUD
DATA --> DET
DET -. advisory notify .-> OWNER
OWNER == decides ==> LOCK
style GATE stroke:#F5A623,stroke-width:2px
style DET stroke:#C97E12,stroke-width:1.5px
Copy this into your doc and replace each blank. Keep it tight — most of the marks are in points 4 and 5.
COMPONENT (one line): _______________________________________
1. CLASSIFY
Data sensitivity tier: _____________________________
What the label forces: _____________________________
2. MINIMIZE
Durable store needed? ______________________________
Copies / caches / logs to eliminate: _______________
3. EGRESS & FAIL-CLOSED
What may cross the perimeter (and to where): _______
Does it fail closed? Is it usable? _________________
4. INLINE or BESIDE
Must it enforce (inline) or advise (beside)? _______
What inline costs here: ____________________________
5. BLAST RADIUS
If it fails confidently, the damage is: ____________
Fallback that does NOT depend on it: _______________
If you want a diagram, copy the Mermaid block above and relabel it for your system — it renders as a flowchart in your Gist.
Part B — starter prompts (answer in your own words; don't just restate these):
- Ask whether the strict control made more people comply or more people bypass. The security lives in the compliance, not the strictness — that's the whole point.
- Ask what every request now waits on, and what breaks when that component breaks. Inline earns its place only when it must enforce on every single request.
- Separate "the one authoritative source" from "its copies." Minimize the second relentlessly; never the first. Name which is which in your system.
- Re-read your five take-homes. In each, what did you do when the system was uncertain about something consequential? The answer is the same word every time — find it.
- Putting a component inline when it only advises. That's a needless dependency, chokepoint, and blast radius — beside is almost always right for advisory AI.
- Letting restricted data cross a boundary because the tool is "capable." Classification beats capability, every time.
- A control so strict it gets bypassed. Usefulness is a security property — a bypassed control protects nothing.
- Forgetting the fallback. If the consequential path depends on the risky component, you haven't contained anything.
- Minimizing the source itself. Don't delete the preserved truth — delete its shadows.
- Lets the data label drive placement — classifies first, and the label travels.
- Minimizes copies while preserving the source (reconciles with Module 3).
- Controls egress, fails closed, and stays usable.
- Places by enforcement-need (inline to enforce, beside to reflect) and contains blast radius with a non-AI fallback.
- Part B names the through-line: conservative action under uncertainty, answerable to a human.
That's the course. Five problems, one instinct — bring the boundary you'd defend on the day the clever component you trusted turns out to be confidently wrong.