Skip to main content
>_ supraj.dev

Module 7: Enterprise Production & Capstone · 4h

01 · UNDERSTAND

Day 43 Theory — Adversarial Security and Data-Protection Day

Security review begins by assuming misuse

A normal functional test asks whether an expected user can complete a task.

An adversarial test asks what happens when a caller, document, tool result or remote agent tries to violate the system's assumptions.

Today we intentionally attack the capstone.

Build a threat model

List:

  • valuable assets,
  • trust boundaries,
  • attacker capabilities,
  • entry points,
  • dangerous side effects.

For the Service Desk, assets include credentials, employee PII, internal documents, privileged actions and tenant data.

Attack classes to test

Examples:

  • direct prompt injection,
  • indirect injection through RAG/tool content,
  • cross-tenant retrieval,
  • privilege escalation,
  • malicious tool arguments,
  • duplicate side-effect replay,
  • secret/log leakage,
  • forged approval events,
  • untrusted remote agent metadata.

Defense in depth

No single model prompt should be responsible for security.

Security layers may include:

authentication
  ↓
authorization
  ↓
retrieval/data filtering
  ↓
tool allowlist/policy
  ↓
human approval
  ↓
audit + detection

If one layer fails, another should still limit impact.

Data minimization

Inspect every place sensitive data can travel:

  • prompt/context,
  • tool arguments,
  • checkpoints,
  • vector store metadata,
  • traces/logs,
  • error messages.

Remove fields that are unnecessary for the task.

Red-team evidence

For every attack, record:

  • payload,
  • expected safe behavior,
  • observed result,
  • control that stopped it,
  • regression test added.

The goal is not a dramatic demo. It is durable engineering evidence.

Service Desk connection

Today we try to make our own system violate policy so those failures are discovered before users or attackers do.

The principle is:

Assume model inputs and external content can be malicious, keep security in deterministic layers, minimize sensitive data, and convert every discovered weakness into a repeatable regression test.

02 · APPLY

Lesson Overview

This is the applied companion for Day 43. Read DAY_43_THEORY.md first for the beginner-first teaching of Adversarial Security and Data-Protection Day. Then use the real service-desk-day-43/ project to trace, run, debug, and explain the concept.

Service Desk Alignment

Day 43 adds Adversarial Security and Data-Protection Day to the running Service Desk. Start with security/shield.py, models/models.py, agent/hardened_agent.py, then follow imports and tests to identify the actual runtime path.

Why This Topic Matters

The theory chapter explains why Adversarial Security and Data-Protection Day is needed. Here the goal is evidence: identify where the capability is implemented, what observable behavior changes, and how the repository proves both success and failure behavior.

System Architecture

The implementation boundary for Adversarial Security and Data-Protection Day is the service-desk-day-43/ project. Use its README and tests as the executable architecture map.

Repository Implementation Map

Use the real Day 43 repository, not a fabricated sample, to connect theory to implementation.

Theory concepts to locate:

  • Security review begins by assuming misuse
  • Build a threat model
  • Attack classes to test
  • Defense in depth

Most relevant implementation modules first:

  • service_desk/security/shield.py
  • service_desk/models/models.py
  • service_desk/agent/hardened_agent.py

Follow imports/calls from the relevant module and confirm behavior in tests. Record input → mechanism → observable output/state → failure evidence.

Code Walkthrough & Mechanics

Read security/shield.py, models/models.py, agent/hardened_agent.py with these theory sections beside you:

  • Security review begins by assuming misuse — locate its implementation and evidence.
  • Build a threat model — locate its implementation and evidence.
  • Attack classes to test — locate its implementation and evidence.
  • Defense in depth — locate its implementation and evidence.
  • Data minimization — locate its implementation and evidence.

For each concept identify the real function/class/protocol boundary, its input/state, its observable result, and the assertion in tests/test_adversarial_suite.py that proves the behavior. If a concept has no implementation or evidence, record that as a gap rather than inventing one.

Common Mistakes & Debugging Guidance

Use the theory—not generic timeout or .env advice—to decide what can fail today.

Failure lens: revisit Defense in depth, Data minimization.

  • Reproduce the smallest case that violates one of those expectations.
  • Trace the real Day 43 modules until you find the first incorrect state/output/decision.
  • Use tests/test_adversarial_suite.py as executable evidence.
  • Add a regression test if the failure is not already represented.
  • Fix the smallest responsible boundary and rerun the relevant test before the full suite.

Your debugging explanation must name the topic-specific invariant that failed, not merely say “an exception occurred.”

Practical Lab Instructions

  1. Summarize these theory ideas before opening the implementation:
    • Security review begins by assuming misuse
    • Build a threat model
    • Attack classes to test
    • Defense in depth
  2. Inspect the most relevant real Day 43 modules first:
    • service_desk/security/shield.py
    • service_desk/models/models.py
    • service_desk/agent/hardened_agent.py
  3. Inspect the automated evidence:
    • tests/test_adversarial_suite.py
  4. Establish the baseline:
    cd service-desk-day-43
PYTHONPATH=. pytest tests/test_adversarial_suite.py -q
  5. Trace one theory concept through the actual nested modules and tests.
  6. Run one success case and record input → mechanism → observable result.
  7. Exercise one topic-specific failure/boundary case and name the invariant that protects the system.
  8. Re-run the relevant tests and explain theory → implementation → evidence.

Done when: another student can reproduce your trace without relying on an invented sample.

Key Takeaways

  1. Be able to explain Security review begins by assuming misuse and point to its implementation/evidence in Day 43.
  2. Be able to explain Build a threat model and point to its implementation/evidence in Day 43.
  3. Be able to explain Attack classes to test and point to its implementation/evidence in Day 43.

Knowledge Check & Scenario Questions

  1. Concept: Using Security review begins by assuming misuse, explain the engineering problem Day 43 is solving without naming a framework as the answer.
  2. Mechanism: How does Build a threat model appear in the real project? Start from service_desk/security/shield.py and name the observable state/output/event that changes.
  3. Failure: For Attack classes to test, describe one incorrect implementation or boundary condition and the evidence you would expect in tests/test_adversarial_suite.py.
  4. Design review: Which assumption in today's design would you verify before reusing this implementation in a different production system?

Official References

03 · EXPLAIN

Interview checkpoint

Explain one design decision from this lesson, the alternative you rejected, and the failure mode or evidence that justified your choice.