Web AppSec Foundations (IDOR/BOLA, SSRF, Auth, STRIDE)

When: Week 1, before exposing endpoints or tools; revisit whenever a project adds a new endpoint, data store, integration, or privileged action.

Learn - HTTP request lifecycle, cookies, sessions, CORS, CSRF, same-origin policy, and browser security boundaries. - Authentication versus authorization; object-level authorization; IDOR/BOLA; tenant and ownership checks. - Practical OWASP web application risks: broken access control, injection, security misconfiguration, authentication failures, SSRF, and insecure design. - Input validation, output encoding, SQL parameterization, file-upload validation, path traversal, secrets management, dependency hygiene, and safe error handling. - SSRF: server-side URL fetching, redirects, private/link-local address ranges, cloud metadata endpoints, egress restrictions, and allowlists. - Threat modeling: assets, actors, trust boundaries, entry points, data flows, abuse cases, mitigations, and residual risk. Learn STRIDE as a structured prompt, not paperwork.

Practice - Add owner checks to chat-history endpoints. Verify User A cannot read, update, or delete User B's conversation by changing an ID. - Use a local vulnerable API or authorized training lab to demonstrate IDOR, then fix it with server-side object-level authorization. - If a tool fetches URLs, test rejection of localhost, private IPs, link-local/metadata addresses, unexpected schemes, and redirects to blocked destinations. Prefer allowlists and network egress controls over string checks alone. - Draw one data-flow diagram: browser → API → auth/session → database/vector store → model provider → tools/external services. - Write a one-page threat model for the assistant and update it when adding RAG or agent tools.

Do not do yet - Do not start with a large compliance framework, exploit development, or a commercial-model jailbreak contest. - Do not build a generic security platform. Learn each control in the context of a real endpoint or feature. - Do not assume CORS is authentication, a hidden UI button is authorization, or prompt instructions are a security boundary.

Completion evidence - Tests prove cross-user chat-history access is denied. - SSRF-sensitive features have a strict destination policy and tests, or arbitrary URL fetching is out of scope. - Secrets are outside source control; logs do not expose credentials or sensitive prompts. - You can explain the trust boundaries and authorization decision for one request.

## Historical 350-hour foundation allocation (reference only; superseded by the 555-hour schedule)

This table records the earlier 350-hour curriculum allocation for historical context only. It is not the current schedule or hour accounting. The active plan is the 555-hour, 111-day schedule in Sections 1--3; its 12 original security stages and ten added domains are interleaved across all 19 weeks. Do not use the historical Weeks 1--11 labels below to schedule current work.

------------------------------------------------------------------------------ Workstream Hours What counts ------------------- --------- ------------------------------------------------ Core AI engineering 75 LLM application patterns, structured outputs, tools, streaming, RAG, agents, model behavior, evaluation

Project 95 Build and integrate the three flagship implementation applications

Backend and system 40 HTTP/API design, FastAPI, persistence, SQL, design jobs, queues, Docker, reliability, architecture

Security in the 25 Application security, prompt injection basics, original 11-week tenant isolation, safe tool execution, RAG build access control, privacy-aware logging

Testing, 35 Automated tests, QA dataset, eval runs, evaluation, and benchmarks, documentation, retrospectives review

Original AI 270 Weeks 1--8 engineering plan

AI attack surfaces 6 STRIDE, trust boundaries, confused deputy, and threat email-to-CRM threat model modelling (Stage 1)

Advanced injection 6 Direct/indirect injection, multi-turn attacks, and jailbreak Crescendo, splitting/encoding testing

MCP and agentic 7 JSON-RPC validation, tool poisoning, security authorization, least privilege

RAG poisoning and 5 Poisoned documents, vector access control, provenance citation integrity

PII and privacy 5 Masking/token substitution, privacy tests, engineering differential privacy concepts

Identity and 7 OAuth2, scoped tokens, delegated permissions, delegated access HITL, A2A concepts

Output validation 3 Schema validation, sanitization, grammar and constrained constraints generation

Automated red 6 PyRIT/Garak orientation, attack corpus, teaming and fuzzing CI/nightly tests

Model extraction 4 Threat model and controlled extraction/inference and IP protection simulation

Mechanistic 8 TransformerLens, logit lens, activation interpretability patching, circuits, limitations investigation

Governance, 4 NIST AI RMF, EU AI Act awareness, audit design, auditing, and privacy/retention compliance

CVE research, 8 Vulnerability analysis, authorized teardown, teardown, responsible disclosure workflow, evidence disclosure, portfolio

Integrated 80 Weeks 9--11 security curriculum

Total required 350 Weeks 1--11 plan ------------------------------------------------------------------------------

Historical note: the earlier 350-hour version used a different sequencing model. It is retained here only to preserve the original allocation rationale; it is not additive to, or a replacement for, the active 555-hour plan. The separate 2-hour/day interview block remains outside the 555 hours.

## Three flagship projects --- detailed specifications

### Project 1 --- Local AI Assistant

Start: Weeks 1--2; continue improving later.

A local-model assistant that supports chat, streaming, structured output, tools, conversation history, and eventually selected personal knowledge or calendar features.

Core implementation

• Connect to a local model through Ollama; keep the provider interface simple.

• Add a provider adapter for a hosted API if useful, without coupling business logic to a single provider.

• Build a terminal chat first; add FastAPI endpoints once the core loop works.

• Implement structured output with Pydantic and an invoice/receipt parser.

• Add get_weather, calculate, and search_notes tools. Mock weather/search initially if external integrations distract from tool-calling fundamentals.

• Add streaming, /reset, token counting, message truncation, persistent conversation history, timeouts, retries, and cost/latency logging.

• Validate tool arguments server-side. Tool permissions must be enforced by application code, not trusted to the model.

• Authenticate users and authorize every conversation by owner/tenant. Validate request sizes and content types, protect secrets, and avoid exposing internal errors.

• If a tool accepts URLs, treat it as an SSRF boundary: use a destination allowlist, safe redirect policy, network egress restrictions, and tests for private/link-local destinations. Prefer not to implement arbitrary URL fetching initially.

• Test IDOR/BOLA on conversation IDs and unsafe tool arguments.

Required security work for this project - Threat-model the assistant's complete data flow. - Explore direct/indirect prompt injection, multi-turn context manipulation, and payload encoding/splitting with a local model or controlled harness. Measure unauthorized actions and data access, not just refusal wording. - Prototype PII token substitution with synthetic values; test collisions, output leakage, and session isolation.

### Required topic integrations

• Trace one request through the LLM pipeline: text → token IDs → embeddings → transformer/attention (conceptual level) → logits → sampling. Keep this to a small experiment; do not attempt to implement a transformer.

• Compare temperature and top-p on a fixed prompt set; record how output variability changes.

• Generate local embeddings for a small set of notes and compare latency/quality with the embedding option used in Project 2.

• Add explicit long-term memory policies: what may be written, updated, retrieved, or deleted; scope memories to the right user/session and test isolation.

• UI integration (required where the project needs a user-facing demonstration): build a small React streaming chat interface with safe Markdown rendering, cancellation, and protection against stale responses.

• Provider comparison: compare one hosted provider with Ollama. Explore provider-specific prompt caching, batch APIs, PDF input, or extended-thinking features only if they serve a concrete use case.

Backend and system-design concepts

• HTTP methods/status codes, request/response schemas, REST endpoints, dependency injection.

• Sync versus async I/O; timeout and cancellation behavior.

• Stateless API processes versus persisted conversation state.

• Database transactions and session ownership.

• Configuration, environment variables, secret handling, and provider abstraction.

Definition of done

• A user can chat, reset a session, call allowed tools, and receive structured output.

• Conversation state behaves predictably across requests/restarts if persistence is implemented.

• Tests cover schema failures, tool arguments, provider errors, retry limits, and conversation truncation.

• README explains setup, API routes, architecture, limitations, and how to run tests.

### Project 2 --- Secure Production AI Platform

Start: Weeks 3--4; prioritize production hardening in Weeks 7--8.

A document Q&A/RAG service with ingestion, retrieval, reranking, citations, evaluation, access controls, and deployment.

Core implementation

• Begin with 50--100 pages of safe sample documents.

• Compare chunking strategies and record chunk size/overlap choices.

• Implement embeddings and nearest-neighbor search; start with Chroma or another simple local option.

• Add metadata filtering, top-k tuning, reranking, grounded responses, and citations.

• Expose upload/ingestion status and query endpoints with FastAPI.

• Create 30 representative question-answer evaluation cases.

• Separate retrieval metrics from answer-quality metrics. Record a baseline before changing one variable at a time.

• Add document-level authorization and tenant-aware retrieval filters.

• Add durable ingestion jobs only when the synchronous prototype is too slow or unreliable.

• Add PostgreSQL/pgvector or retain a separate vector store based on an explicit trade-off. Use Redis only for a clear need such as cache or rate-limit counters.

### Required topic integrations

• Harden PDF/Markdown/HTML parsing with representative fixtures and tests for malformed files, empty documents, tables, headings, and source metadata.

• Run one structure-aware/vectorless retrieval experiment: create an outline, hierarchical index, or LLM-generated document map, then compare it with vector retrieval and (if useful) a hybrid approach.

• Compare retrieval methods using the same evaluation questions. Record retrieval recall/precision where practical, answer quality, citation support, latency, and cost; change one variable at a time.

• Conditional on the project requirement ecosystem practice: try Qdrant if the core implementation uses another store, or build a NotebookLM-style multi-document interface on top of the existing RAG service. Do not build a second RAG system.

Backend and system-design concepts

• SQL schema, migrations, indexes, transactions, and connection pooling.

• Relational metadata versus object storage versus vector index.

• Separate ingestion and query-serving paths.

• Job states, retries, idempotency, re-indexing, and partial failures.

• Pagination, upload limits, error contracts, cache invalidation, and tenant-safe cache keys.

Security requirements

• Enforce authorization on the server and at retrieval time---not only in the UI.

• Test that one tenant cannot retrieve another tenant's documents or cached responses.

• Treat document text and retrieved content as untrusted input.

• Avoid leaking sensitive document content through logs, citations, errors, or evaluation traces.

• Enforce authorization and tenant filters before retrieval; never rely on the model or UI to enforce document access.

• Test indirect prompt injection and poisoned-document behavior in a controlled corpus. Retrieved content is untrusted data, not an instruction source.

• Protect ingestion against oversized files, unsupported types, path traversal, unsafe remote URLs, and parser failures.

• Generate citations from trusted document/chunk identifiers and server-side metadata, not arbitrary model-provided URLs.

Required security work for this project - Add a clearly labeled malicious test document to a disposable corpus. Measure whether retrieval/generation follows its instruction or emits an attacker-controlled URL; test provenance, trust labels, source filters, and instruction/data separation. - Prototype PII masking/token substitution with synthetic identifiers. Test partial matches, collisions, output leakage, and failure paths.

Definition of done

• Document ingestion and cited Q&A work end to end.

• A 30-question evaluation dataset is repeatable and reports a baseline.

• Authorization and cross-tenant tests pass.

• The app runs reproducibly through Docker Compose (API, database/vector store, and Redis only if needed).

• README includes architecture, API examples, evaluation results, security boundaries, and known limitations.

### Project 3 --- Secure Agent and Workflow System

Start: Weeks 5--6; continue hardening in Weeks 7--8 and beyond.

A bounded tool-using agent plus a deterministic workflow, with explicit state, authorization, traceability, and human approval for consequential actions.

Core implementation

• Build a from-scratch agent with three tools and a maximum-step limit before adopting a framework.

• Write clear tool descriptions and validate every tool input.

• Implement a three-step pipeline: extract facts → generate outputs in parallel → score/select the best output.

• Compare a single LLM call, deterministic workflow, and agent; document why each is appropriate.

• Add explicit state schemas and, when needed, LangGraph checkpointing/resume.

• Add retries, timeouts, bounded concurrency, cancellation, and execution traces.

• Add role-based tool authorization, audit logs, and human approval before high-impact or irreversible actions.

• Evaluate task success, tool selection, invalid actions, latency, cost, and prompt-injection resistance.

• Treat a coding-agent sandbox as an advanced required module. Never provide unrestricted host access; apply filesystem, network, time, memory, and process limits.

• Model the agent as a confused deputy risk: it may possess legitimate credentials but must not use them beyond the requesting user's authority.

• Separate tool discovery from authorization. The model may request a tool; application code decides whether the authenticated principal may invoke it and with which arguments.

• Treat tool descriptions, MCP metadata, tool output, retrieved content, and agent-to-agent messages as untrusted.

• If exposing MCP, authenticate callers, authorize each tool, validate parameters, scope credentials, and log security events. Never expose an unauthenticated MCP server publicly.

Required security work for this project - Build a local MCP server with one or two safe tools. Validate with Pydantic, authenticate the client, enforce per-user tool permissions, and test confused-deputy attempts. - Explore tool poisoning/shadow-tool cases in a controlled setup: misleading descriptions, conflicting names, unexpected metadata, and output that redirects the agent. - Prototype short-lived, narrowly scoped delegated tokens. Never give an agent a user's raw password or a long-lived unrestricted token. - Add agent-to-agent trust boundaries only if multiple agents are actually implemented.

### Required topic integrations

• Implement a small MCP server exposing one or two safe tools. Practise schemas, authorization, errors, and cancellation; do not make MCP a prerequisite for the agent milestone.

• Add a repository exploration/documentation workflow: safe file-tree walk, search for files/functions/classes, source-grounded summaries, and Markdown documentation export.

• Test hard limits for step count, token/cost budget, tool allowlists, approval gates, audit events, and retry idempotency.

• Conditional on the project requirement SDK comparison: reproduce one small workflow using either the OpenAI Agents SDK or Claude Agent SDK and compare the abstraction with your from-scratch implementation. Choose one, not both.

• Conditional on the project requirement ecosystem exploration: look at Skills or managed tools (such as web/file search or code execution) only after the core agent is bounded and tested.

Backend and system-design concepts

• State machines, terminal states, checkpoint storage, and resumability.

• Sequential versus parallel tasks and dependency graphs.

• Idempotency keys and safe retries for side-effecting tools.

• Duplicate jobs, worker crashes, durable execution, and approval pauses.

• Bounded concurrency and recovery after partial failure.

Definition of done

• Agent execution is bounded and traceable.

• Workflow state can be validated and failures have predictable behavior.

• Authorization is checked by the tool/service itself.

• Approval and audit records exist for selected consequential actions.

• Tests cover retries, limits, unauthorized tools, untrusted input, and failure recovery.

------------------------------------------------------------------------

## 3A. Integrated flagship-project architecture: the 12 security deliverables

This section is part of the three-project specification, not a fourth project or a detached collection of mini-projects. Build three coherent products with shared security components where reuse is architecturally justified. The 12 deliverables are capabilities inside those products; do not create 12 unrelated repositories or duplicate the same control three times.

### Ownership map --- exactly where each deliverable belongs

---------------------------------------------------------------------------------------------- ID Deliverable Primary home Shared use Why it belongs there ---- --------------- ------------- --------------------- ------------------------------------- 1 Crescendo Project 1 Project 3 attack The assistant gives you a controlled Attack Fuzzer --- Local AI scenarios; all conversational target for multi-turn Assistant projects' regression escalation, context manipulation, corpus payload splitting, and unauthorized-action testing.

2 Sandboxed MCP Project 3 Project 1 only if it MCP is a tool-protocol trust Proxy --- Secure later exposes tools boundary. The agent/workflow product Agent and through MCP is the natural place to demonstrate Workflow protocol validation, identity, System per-tool authorization, and constrained execution.

3 Inter-Agent Project 3 None unless you Agent-to-agent communication belongs Sanitization --- Secure actually introduce in the workflow system. Implement it Bus Agent and multiple agents as a trusted typed-message boundary, Workflow elsewhere not a text-cleaning filter. System

4 PII Project 1 Reuse the same The assistant provides a clear UUID-Swapping --- Local AI service/library in request/response path for Gateway Assistant Project 2 tokenization and controlled restoration; Project 2 then proves the gateway works for document ingestion and retrieved answers too.

5 RAG Citation & Project 2 None; Project 1's Source provenance, chunk identity, Poison Detector --- Secure notes search may citation support, and Production AI reuse citation poisoned-document evaluation are core Platform primitives, not the RAG responsibilities. full detector

6 CFG Output Project 2 Reuse The platform has the richest Caging Layer --- Secure schema/rendering downstream output path. Demonstrate Production AI contracts in Projects structured generation, schema Platform 1 and 3 validation, safe rendering, and sink-specific validation there; share schemas where useful.

7 Delegated Agent Project 3 Project 1 may consume Delegation, short-lived credentials, OAuth Broker --- Secure scoped identity if it scopes, audiences, revocation, and Agent and calls delegated tools human approval are agent workflow Workflow concerns. System

8 PyRIT CI/CD Shared All three This is not a product feature. It is Security Gate engineering a common security-testing pipeline control that runs a deterministic PR suite across all 3 and broader scheduled/pre-release projects suites against each project's versioned attack corpus.

9 Computer-Use Project 3 None unless Project 1 Screenshot/OCR and visual-target Pixel Auditor --- Secure later gains verification are specific to Agent and computer-use browser/computer-use actions and Workflow capabilities should sit beside the agent's action System executor and approval gates.

10 Vector DB Project 2 Project 1 only if it Vector memory is a retrieval and Sleeper-Agent --- Secure adopts persistent data-governance concern. Build Scrubber Production AI vector memory provenance/trust classification, Platform quarantine, re-evaluation, and memory-write authorization---not a detector that claims to find every semantic backdoor.

11 Cryptographic Project 3 Project 1 reuses the The workflow has the richest sequence Trajectory --- Secure event contract; of decisions and side effects. Ledger Agent and Project 2 emits Establish a tamper-evident event Workflow ingestion/retrieval chain and then reuse its event schema System events into the same across the other products. format

12 AI Supply-Chain Shared All three Dependencies, containers, SBOM Scanner engineering model/tokenizer artifacts, datasets, control MCP servers, and build provenance across all 3 span all products. One scanner/policy projects with per-project manifests avoids duplicated, inconsistent inventories. ----------------------------------------------------------------------------------------------

Counting rule: 12 deliverables means 12 distinct capabilities. Shared use does not create additional projects. The primary home owns implementation and acceptance; other projects consume a stable interface or shared pipeline rather than rebuilding it.

### Project 1 --- Local AI Assistant: secure personal assistant and privacy boundary

Purpose: demonstrate that a local/hosted LLM assistant can safely manage conversation, memory, tools, and sensitive user data. This is your focused application-security and privacy engineering showcase.

Add these deliverables:

• Crescendo Attack Fuzzer (primary). Build a stateful multi-turn harness that stores conversation state, attack stages, model/provider/prompt versions, tool-call outcomes, and expected security properties. Include direct and indirect injection, gradual escalation, payload splitting/encoding, and attempts to access another user's data or invoke an unauthorized tool. Run only against your own application, local models, or explicitly authorized environments. Save reproducible transcripts and turn each confirmed failure into a regression case.

• PII UUID-Swapping Gateway (primary implementation; shared with Project 2). Add a pre-model and post-model boundary: detect candidate PII, validate the detection, replace values with scoped opaque tokens, keep the mapping in a protected vault, and restore only for the authorized caller and permitted output fields. Include tenant/session separation, collision handling, retention/deletion, access logging, and tests for partial matches, false negatives, token guessing, and leakage. UUID-shaped tokens alone do not provide privacy.

• Cryptographic Trajectory Ledger (consumer/reference implementation). Emit assistant events using the shared ledger contract: request ID, actor, session/tenant, model and prompt version, tool request, authorization decision, approval, state mutation, result, and timestamp. Avoid storing raw prompts by default; store redacted metadata, hashes, and access-controlled payload references with retention limits.

• AI Supply-Chain SBOM Scanner (shared pipeline consumer). Produce a project manifest covering application dependencies, lockfiles, container image, model/runtime, tokenizer/config, and downloaded artifacts. The shared scanner checks known vulnerabilities, suspicious/misspelled packages, pinning, hashes, provenance, and license/policy metadata.

• PyRIT CI/CD Security Gate (shared pipeline consumer). Run the assistant's small deterministic prompt-injection and unauthorized-tool corpus on pull requests; run broader multi-turn fuzzing nightly or before release. Gate on severity and reproducibility, not a universal jailbreak percentage.

Project 1 architecture boundaries: - assistant-api owns authentication, conversation ownership, rate/cost budgets, and request lifecycle. - privacy-gateway owns PII tokenization/restoration and mapping-vault access. It must not trust model output to decide what can be restored. - tool-runtime owns tool allowlists, argument validation, authorization, timeouts, and egress policy. - attack-harness drives test conversations but has no production credentials or unrestricted network access. - audit-client emits normalized events to the trajectory ledger; the ledger is not the source of authorization truth.

Acceptance evidence: multi-turn attack corpus with replayable transcripts; negative tool-authorization tests; PII leakage and cross-session isolation tests; verifiable event-chain test; SBOM and provenance report; CI run showing a seeded regression blocks the build.

#### Capability integrations within Project 1

These are bounded extensions of the assistant, not separate applications.

• Autonomous task execution with human approval (high priority). Extend the existing tool runtime and approval flow so the assistant can interpret a request, select only an authorized tool, produce a parameter-bound action preview, obtain approval for sensitive actions, execute, and record the outcome. Enforce authorization in application code; approval must be bound to the exact action, target, and parameters. Reuse the existing trajectory-ledger event contract.

• Adaptive memory and personalized state (partially covered). Extend the existing persistent-memory work with explicit user preferences, task state, retrieval, correction, expiry, and deletion. Preserve owner/tenant scope, source provenance, trust labels, and poisoning protections. This is an extension of the memory lifecycle in Weeks 3 and 14, not a second memory subsystem.

• Incident diagnosis and recovery recommendations (high priority). Let the assistant inspect a restricted, read-only set of application logs, traces, health signals, and diagnostic outputs. It may classify a failure, explain evidence and uncertainty, and recommend a recovery step. Any action that changes state must pass the existing authorization and human-approval path; destructive recovery is never autonomous.

Acceptance evidence: unauthorized-tool attempts are rejected; approval replay or parameter changes invalidate approval; memory correction/deletion and cross-user isolation are tested; incident diagnoses cite the relevant diagnostic evidence; recovery recommendations are tested without granting unrestricted write or shell access.

### Project 2 --- Secure Production AI Platform: trusted document intelligence and retrieval

Purpose: demonstrate production-minded RAG: ingestion provenance, tenant-safe retrieval, supported citations, privacy controls, and robust output contracts. This is your data security, retrieval integrity, and production platform showcase.

Add these deliverables:

• RAG Citation & Poison Detector (primary). Assign immutable source/document IDs, chunk IDs, content hashes, ingestion versions, tenant/ACL metadata, and parser versions. Track retrieval provenance through reranking and answer generation. Verify that each citation resolves to a trusted stored chunk and that claims are supported by the cited evidence. Maintain a controlled poisoned-document corpus and test instruction/data separation, source trust, suspicious URLs, and retrieval manipulation. A hash proves identity/integrity of bytes, not that a claim is semantically supported.

• Vector DB Sleeper-Agent Scrubber (primary). Treat this as a memory/index hygiene and quarantine workflow: classify source trust, preserve provenance, flag suspicious or anomalous records for review, run trigger-oriented retrieval tests, re-evaluate aged content, enforce write authorization, and support quarantine/deletion/reindexing. Add retrieval ACLs and tenant isolation. Do not claim anomaly detection can reliably find every semantic backdoor; do not use embedding similarity as the security boundary.

• CFG Output Caging Layer (primary). Define output contracts for answer types and downstream consumers. Use constrained decoding only when supported, then always validate server-side with JSON Schema/Pydantic, enforce ranges/enums/lengths, reject unexpected fields, and safely render Markdown/HTML. Validate again at the sink (browser, API, export); schema-valid output can still contain unsafe semantics or malicious URLs.

• PII UUID-Swapping Gateway (shared consumer). Reuse Project 1's gateway contract for uploaded documents, chunks, retrieval context, and generated answers. Preserve source references and ensure token mappings cannot cross tenants. Document how masking affects citations and search quality.

• AI Supply-Chain SBOM Scanner (shared pipeline consumer). Include parser libraries, embedding/reranking models, vector database clients, ingestion workers, container images, datasets, and model artifacts in the inventory.

• PyRIT CI/CD Security Gate (shared pipeline consumer). Run the RAG-specific corpus: indirect injection, poisoned documents, citation fabrication, tenant-crossing retrieval, prompt/context manipulation, and unsafe output. Include retrieval and citation assertions, not only refusal checks.

Project 2 architecture boundaries: - ingestion-service validates file type/size, parses in isolation, stamps provenance, and writes versioned chunks. - provenance-registry is the source of truth for document/chunk identity, tenant, ACL, parser/model versions, and content hashes. - retrieval-service enforces authorization before and during retrieval; the model never decides access. - citation-verifier checks source IDs and claim/evidence support independently of model-generated citation text. - index-hygiene-worker re-evaluates, quarantines, deletes, or reindexes suspicious/stale vector records under an auditable policy. - output-contract validates structured output and applies sink-specific rendering/escaping.

Acceptance evidence: reproducible retrieval/citation benchmark; poisoned corpus with expected detections and documented misses; cross-tenant retrieval tests; deletion propagation across source store/vector index/cache; PII leakage tests; output-schema and rendering tests; SBOM; CI security gate report.

#### Capability integrations within Project 2

• Multi-hop research and citation provenance (high priority). Extend the existing retrieval and citation-verification path into a bounded research workflow: decompose a research question into sub-queries, retrieve evidence for each, preserve source identity and retrieval history, map claims to supporting passages, detect contradictions, and verify citations before returning a synthesis. Keep source authorization and citation verification outside model judgment.

• Schema drift detection and pipeline recovery (high priority). Add versioned schema expectations to ingestion and background jobs. Detect missing, added, or type-changed fields; classify the failure; propose a transformation or mapping; validate it against fixtures and tests; then retry or roll back through a controlled workflow. A model may propose a repair but must not write arbitrary transformations directly into production data.

• Structured extraction and business-rule reconciliation (high priority). Use the existing document ingestion and output-contract layers to extract fields into validated schemas, match records across related documents, apply explicit business rules, and surface mismatches as exceptions. Keep uncertain or high-impact decisions in a human review queue. Do not authorize payments or financial transfers.

• Multi-agent coordination and conflict resolution (high priority). Demonstrate a small, bounded collaboration workflow---for example, an extraction/research agent, an independent evidence reviewer, and a policy/security reviewer. Give each role a narrow contract and shared task state; preserve provenance; identify conflicting findings; and use a deterministic adjudication step or human review. Do not treat majority agreement as proof of correctness. Reuse the typed message, identity, audit, and evaluation contracts already defined in the roadmap rather than building a general-purpose multi-agent platform.

Acceptance evidence: research claims resolve to authorized source passages; citation and contradiction checks have measurable test cases; schema changes are detected against versioned fixtures; proposed repairs pass validation before retry; extracted fields meet schema and business-rule tests; multi-agent conflicts are surfaced and resolved with recorded evidence.

### Project 3 --- Secure Agent and Workflow System: bounded, delegated, auditable automation

Purpose: demonstrate secure autonomous workflows with protocol-level tool controls, delegated identity, safe inter-agent communication, computer-use safeguards, and verifiable execution history. This is your distributed systems, identity, and agent-security showcase.

Add these deliverables:

• Sandboxed MCP Proxy (primary). Put the proxy between the agent and MCP servers. Validate JSON-RPC envelopes and tool schemas; authenticate callers; bind user/workflow identity; authorize each tool and resource; enforce allowlists, argument constraints, timeouts, output-size limits, concurrency limits, and egress policy; preserve trusted server metadata; and emit audit events. Schema validation (including Pydantic) is not authorization. Test confused-deputy attempts, tool shadowing, malformed metadata, replay, and unauthorized resource access.

• Inter-Agent Sanitization Bus (primary). Implement a typed message envelope with sender/recipient identity, workflow ID, provenance, trust label, schema/version, content type, and correlation ID. Validate the envelope, distinguish data from instructions, constrain capabilities at the receiving agent, enforce recipient authorization and size limits, and audit delivery. Do not rely on stripping hidden Markdown or suspicious strings: semantic prompt injection can survive text sanitization. Start with two agents only if a real workflow needs them.

• Delegated Agent OAuth Broker (primary). Implement OAuth2 delegated authorization with short-lived, narrowly scoped credentials, audience/resource binding, expiry, refresh/revocation, and explicit mapping from user permission to agent action. Bind approvals to exact action parameters and target. Consider workload identity and sender-constrained tokens where feasible; a signed JWT by itself does not prove the caller is entitled to use a resource.

• Computer-Use Pixel Auditor (primary). Before high-impact UI actions, capture a fresh screenshot, inspect OCR/visual targets and overlays, compare coordinates with DOM/accessibility metadata where available, and verify that the intended target still matches. Flag suspicious overlays, spoofed controls, stale screenshots, and coordinate drift. Require approval for sensitive actions and record what was observed. This is a detection/verification layer, not a guarantee that every hidden or deceptive element is detected.

• Cryptographic Trajectory Ledger (primary). Record ordered execution events: agent/workflow identity, state transitions, model/tool versions, MCP request, delegated authorization result, approval decision, external side effect, retries, and outcome. Use sequence numbers and a hash chain or equivalent tamper-evident structure. Verify chain integrity and access controls. A chain proves tamper evidence for recorded events---not that events are complete or truthful---so define trusted event producers and retention/redaction rules.

• Crescendo Attack Fuzzer (shared consumer). Reuse Project 1's harness to test multi-turn attempts to escalate privileges, trick an agent into using tools, override approval, or manipulate workflow state. Add workflow-specific state and tool-call assertions.

• PyRIT CI/CD Security Gate and AI Supply-Chain SBOM Scanner (shared controls). Run the workflow's deterministic MCP, delegation, message-boundary, approval-replay, and computer-use test corpus. Inventory agent frameworks, MCP servers/clients, tool packages, browser automation dependencies, containers, model artifacts, and build provenance.

Project 3 architecture boundaries: - workflow-orchestrator owns state transitions, budgets, retries, cancellation, and approval pauses. - mcp-proxy is the only route from the agent runtime to MCP tools; direct network/tool access is denied. - identity-broker issues or exchanges scoped credentials and checks audience/resource/action constraints. - message-bus validates agent envelopes and trust metadata; it does not make arbitrary message text safe. - computer-use-adapter owns browser session isolation, screenshot freshness, target verification, download/file/network restrictions, and approval hooks. - trajectory-ledger receives events from trusted components and supports integrity verification and audit export.

Acceptance evidence: per-tool authorization matrix and negative tests; MCP protocol fuzz cases; delegated-token expiry/revocation/audience tests; message spoofing and cross-workflow isolation tests; approval replay/parameter-change tests; screenshot freshness/overlay/target mismatch tests; ledger tamper-evidence verification; CI and SBOM reports.

#### Capability integrations within Project 3

• Automated code diagnosis and PR generation (medium priority). As a bounded workflow, ingest CI failure summaries, classify likely causes, reproduce failures in an isolated workspace, propose a patch, and run the relevant tests and security checks. The agent may prepare a branch or pull-request proposal, but it must not merge its own changes. Require human review and retain the test output, diff, and execution trace.

• Computer-use automation and human takeover (already covered). Keep the existing Week 10 Computer-Use Pixel Auditor, browser isolation, screenshot/target verification, approval, and takeover design. The back-office automation idea is an application scenario for this existing capability, not a new deliverable.

• Agent trajectory evaluation and regression testing (already covered). Reuse the existing PyRIT CI/CD Security Gate, trajectory ledger, deterministic test corpus, and final cross-project regression work. Add task-level measures where useful---tool-call correctness, completion, policy compliance, and failure category---but do not create a duplicate evaluation platform.

Acceptance evidence: CI failures can be reproduced only inside the sandbox; proposed patches are tested and reviewed before merge; computer-use actions retain existing authorization and takeover guarantees; trajectory tests cover tool-call correctness and regression across model/prompt/tool changes.

### Shared contracts and integration rules

To make the three projects feel like one serious engineering portfolio rather than three disconnected demos, define a small set of versioned shared contracts:

• Identity context: principalId, tenantId, workflowId, scopes, audience, and correlation/request IDs. Each service still validates the context and authorization locally; do not blindly trust caller-supplied claims.

• Security event envelope: event ID, sequence, timestamp, actor, action, resource, decision, component version, model/tool version where applicable, outcome, and redacted metadata. Project 3 owns the first ledger implementation; Projects 1 and 2 emit compatible events.

• Provenance reference: immutable source/artifact ID, version, hash, origin, owner/tenant, trust label, and ingestion/build metadata. Project 2 uses it for documents/chunks; the SBOM scanner uses it for software/model artifacts.

• Test case format: threat category, preconditions, input/steps, expected security invariant, observed result, severity, reproducibility metadata, and regression status. The shared CI gate consumes this format.

• PII token contract: opaque token, tenant/session scope, mapping reference, permitted restoration context, expiry, and deletion state. Only the privacy gateway can access the mapping vault.

Prefer a monorepo or a small shared package only if it reduces duplicated contracts without creating tight runtime coupling. The three applications must remain independently runnable and independently enforce security. Shared libraries are convenience, not a shared trust boundary.

### Continuous 19-week integration map

The existing 111-day schedule remains 111 × 5 hours = 555 hours. These are the implementation homes and sequencing anchors for the 12 deliverables; use the named day/week tasks in Section 3 as the study schedule and treat the following as project acceptance milestones within those blocks---not extra hours or a separate phase.

----------------------------------------------------------------------------- Schedule Project work to complete or advance point ---------- ------------------------------------------------------------------ Weeks 1--1 Project 1: tool authorization foundations; start Crescendo corpus and stateful multi-turn harness (Deliverable 1).

Week 2 Project 1: define security-event envelope and memory provenance; establish trajectory-ledger event contract (Deliverable 11), initially without claiming cryptographic completeness.

Week 3 All projects: generate initial dependency/model-artifact manifests; start shared SBOM scanner (Deliverable 12).

Weeks 4--4 Project 2: build source/chunk provenance, citation verifier, and poisoned-document test corpus (Deliverable 5). Integrate Project 1's PII gateway into document ingestion (Deliverable 4).

Weeks 5--6 Project 3: implement MCP proxy (Deliverable 2), then delegated OAuth broker (Deliverable 7); add typed inter-agent bus only for the two-agent workflow (Deliverable 3).

Weeks Project 3: make trajectory ledger tamper-evident and add event 9--10 verification (Deliverable 11). Add per-tenant cost and resource controls across the three applications.

Week 8 All projects: implement shared PyRIT CI/CD gate (Deliverable 8), deterministic pull-request subset, and scheduled/nightly or pre-release extended runs.

Week 9 Project 2: add CFG output caging (Deliverable 6); test constrained generation plus mandatory server-side validation. Add controlled model-extraction-abuse signals only as layered defenses, not a semantic-only rate limiter.

Week 10 Project 3: implement computer-use pixel auditor (Deliverable 9) beside browser isolation, target verification, and human approval.

Week 11 Project 2: implement vector index hygiene, quarantine, provenance rechecks, and trigger tests (Deliverable 10). Complete PII deletion and privacy tests.

Weeks Keep interpretability as bounded research; complete three public 15--16 exploit/CVE teardowns under the existing security-teardown work. Do not add a claimed sycophancy-neutralization feature.

Weeks Harden the primary homes and integrate bounded capability 17--19 extensions: Project 1 autonomous approved tasks, memory lifecycle, and incident diagnosis; Project 2 multi-hop research, schema recovery, structured extraction, and bounded multi-agent review; Project 3 sandboxed code diagnosis/PR proposals plus existing computer-use controls. Verify shared contracts across all three.

Weeks Run cross-project attack chains, reliability tests, incident 20--21 drills, and ledger/CI evidence checks. Validate approval boundaries, recovery/rollback behavior, code-agent sandboxing, research provenance, and capability regressions. Fix findings and add tests.

Weeks Finish governance mapping, SBOM/provenance evidence, security 22--24 reports, reproducible demos, architecture diagrams, and portfolio documentation. Include evidence for the capability extensions that were implemented; document deferred or incomplete capabilities honestly. -----------------------------------------------------------------------------

### Definition of a strong portfolio outcome

Each flagship project should be independently runnable, have an architecture/threat-model diagram, a concise README, reproducible tests, a demo, an evaluation/security report, and a limitations section. The shared controls should have versioned contracts and evidence that each project actually consumes them.

Do not describe these as production-certified security products. In a 555-hour learning roadmap, the realistic outcome is credible, tested portfolio-grade prototypes with clearly documented assurance limits. Production deployment would additionally require independent review, operational monitoring, key management, incident response ownership, load testing, and ongoing vulnerability management.

------------------------------------------------------------------------

## Backend, API, distributed systems, and system design sequence

Learn these as the projects require them. The target is practical competence: implement the pattern, explain why it exists, and describe its trade-offs.

When --- Learn --- Demonstrate in code - Weeks 1--2: HTTP, REST, status codes, FastAPI, validation, async I/O --- Well-defined endpoints, validation, timeouts, error contracts - Weeks 1--2: Configuration, secrets, state, persistence, transactions --- Persistent conversations and safe configuration - Weeks 3--4: SQL schemas, migrations, indexes, transactions, connection pooling --- Document/tenant metadata and consistent ingestion state - Weeks 3--4: Vector retrieval, filtering, object storage, cache keys --- Secure retrieval and source citations - Weeks 3--4: Jobs, retries, idempotency, partial failure --- Reliable ingestion where asynchronous processing is needed - Weeks 5--6: State machines, workflows, concurrency, checkpoints --- Bounded agent execution and resumable workflows - Weeks 7--8: Docker, health checks, graceful shutdown, CI --- Reproducible deployment - Weeks 7--8: Queues, at-least-once delivery, backpressure, dead letters --- Reliable background processing where justified - Weeks 7--8: Authentication, authorization, rate limiting, observability --- Protected, traceable endpoints - After this plan: Load testing, capacity planning, replicas, autoscaling, disaster recovery --- Measure bottlenecks before scaling architecture

### Five design questions to

ask for every feature

• Boundary: Which component owns this responsibility, and what API does it expose?

• State: Where is the source of truth? What happens if a process restarts?

• Failure: What if the provider, database, worker, or external tool times out or fails?

• Security: Who is authorized to perform this action, and where is that enforced?

• Measurement: What test or metric would show that this design works?

Do not introduce microservices just to demonstrate distributed systems. Start with a modular application and split components only when the separation has a clear benefit.

## Definition of done for the flagship projects

Use this checklist for each meaningful feature.

• [ ] Works end to end through a documented API or interface.

• [ ] Validates inputs and has predictable error behavior.

• [ ] Has automated tests for the happy path and important failures.

• [ ] Has appropriate authorization and security checks.

• [ ] Logs useful diagnostics without leaking secrets or sensitive content.

• [ ] Documents important design decisions and trade-offs.

• [ ] Has reproducible setup and run instructions.

• [ ] Has a measured result when quality, latency, or cost matters.

For Projects 2 and 3, also test cross-tenant access, unauthorized tools, prompt injection, and sensitive-data exposure. Do not claim a security property merely because you added a security library; verify it with tests.

## Required depth and scope

Aim for working knowledge with implementation evidence, not mastery of every framework or specialty.

Area --- Target depth by the end - LLM application engineering: Implement prompts, structured outputs, tool calling, streaming, state, retries, and cost tracking; explain the major failure modes - RAG: Build ingestion/retrieval/citations, tune chunking/top-k/reranking, evaluate quality, enforce document authorization - Agents/workflows: Build a bounded agent and deterministic workflow; understand state, retries, checkpoints, tool permissions, and evaluation - Backend/API: Design and test FastAPI endpoints, validation, persistence, auth boundaries, and error contracts - Databases: Model data, use transactions/indexes/migrations, and explain consistency trade-offs - Distributed systems: Understand jobs, retries, idempotency, duplicate delivery, backpressure, and worker failure; implement a relevant subset - AI security: Recognize and test prompt injection, retrieval leakage, unauthorized tools, and tenant isolation - Observability/evaluation: Produce useful logs/traces and repeatable quality/cost/latency measurements - Frameworks: Use a small selected set; understand concepts well enough to evaluate alternatives - Inference engineering: Learn introductory benchmarking concepts now; continue advanced GPU/runtime optimization after this plan

## Interview preparation --- separate from roadmap hours

You already spend 2 hours/day on interview preparation. Keep that separate from the 5-hour AI block, but let your project work supply examples and practical understanding. Avoid studying the same topic twice from scratch.

### Daily two-hour interview block

Time --- Activity --- Method - 60 min: Existing interview syllabus --- Continue planned coding, Python, database, backend, and other interview topics - 30 min: AI/system-design interview topic --- Cover the topic relevant to the current project stage - 20 min: Explain your implementation --- Answer aloud without notes; draw the architecture or trace a request - 10 min: Recall and gap log --- Write what you missed and schedule only the gaps that matter If your existing interview plan already assigns the same backend/database topic that day, use the 30-minute AI/system-design segment for a different gap or for an AI-specific advanced required module. Do not duplicate the same lesson.

### Interview topics by project stage

#### Weeks 1--2: LLM applications

• How do tool calls differ from ordinary text generation?

• How do you validate structured model output and handle invalid responses?

• How do streaming and SSE work at a high level? What happens when a client disconnects?

• How do timeouts, bounded retries, and 429 handling work?

• How would you manage conversation history and token budgets?

• How would you prevent prompt injection from triggering an unauthorized tool?

• Design an LLM API with provider failure, latency, and cost constraints.

Practical evidence: draw the request lifecycle and explain one failure you tested.

#### Weeks 3--4: RAG and databases

• Walk through ingestion, chunking, embedding, retrieval, reranking, and generation.

• How would you diagnose poor retrieval? Which metrics or examples would you inspect?

• How do chunk size, overlap, top-k, and reranking affect the trade-off?

• How do citations and abstention reduce unsupported answers?

• How would you enforce document-level permissions and tenant isolation?

• What consistency problems occur when document metadata and vector records change separately?

• When would you use a background job, a relational database, a vector store, or Redis?

Practical evidence: explain your 30-question evaluation dataset, baseline, and one measured improvement.

#### Weeks 5--6: Agents and workflows

• When should you use a single LLM call, a deterministic workflow, or an agent?

• How do you bound agent execution and tool permissions?

• How do checkpoints and resumability work?

• Why can retries duplicate side effects, and how does idempotency help?

• How do you evaluate task success versus intermediate process behavior?

• How do you handle untrusted tool output and human approval?

Practical evidence: draw the workflow state machine and explain its failure-recovery behavior.

#### Weeks 7--8: Production and distributed systems

• How would you containerize and deploy the RAG API?

• When are in-process background tasks insufficient?

• Explain at-least-once delivery, idempotency, retries, and dead-letter handling.

• How would you handle queue backlogs, worker saturation, and provider rate limits?

• How do authentication and authorization differ?

• Which metrics would you use for API reliability, retrieval quality, model cost, and workflow success?

• How would you design for tenant isolation, graceful shutdown, and safe rollback?

• What would you measure before scaling or splitting a service?

Practical evidence: draw the deployed architecture, identify bottlenecks, and explain what you would measure before optimizing.

### Interview answer format

For a project/system-design question, practice answering in this order:

• Requirements and constraints.

• API and component boundaries.

• Data model and source of truth.

• Main request/data flow.

• Failure handling and consistency.

• Security and authorization.

• Observability and evaluation.

• Trade-offs and future improvements.

For behavioral or project-deep-dive questions, use: problem → decision → implementation → evidence/result → trade-off → what you would change. Do not invent performance improvements; measure them or state that they are hypotheses.

### Build a reusable interview evidence log

After each substantial feature, record:

• Problem and requirement.

• Architecture decision and alternatives considered.

• Important implementation details.

• One failure mode and how you tested it.

• One security consideration.

• One metric, test result, or evaluation result.

• One trade-off and one follow-up improvement.

This converts roadmap work into interview examples and reduces the need to reconstruct your reasoning months later.

## Daily operating checklist

Use this at the end of each day.

• [ ] Learned or experimentally verified one current concept.

• [ ] Implemented a concrete project increment.

• [ ] Added or ran tests.

• [ ] Considered a relevant security boundary.

• [ ] Recorded a decision, result, or unresolved question.

• [ ] Practiced one interview explanation when it overlaps with today's work.

• [ ] Selected the next smallest useful task.

### Weekly review

Every Sunday, answer:

• What actually works end to end?

• What did I measure, rather than assume?

• What failed, and why?

• What security boundary did I test?

• Which interview question can I now answer with implementation evidence?

• What is the one primary deliverable for next week?

• What should I explicitly defer?

## End-of-plan outcomes

By the end of the 555-hour roadmap, aim to have:

• Project 1: a tested LLM assistant with structured outputs, tools, streaming, state, and failure handling.

• Project 2: a RAG platform with ingestion, citations, evaluation, document permissions, and a reproducible deployment.

• Project 3: a bounded agent/workflow system with explicit state, tool authorization, traceability, and evaluation.

• Engineering evidence: API contracts, data models, tests, Docker setup, architecture notes, and measured results.

• Interview evidence: concise explanations of design choices, trade-offs, failures, security decisions, and evaluation results.

### After the 555 hours

Continue with inference engineering---benchmarking, TTFT/ITL, throughput, KV cache, prefill/decode, GPU architecture, runtimes, and optimization---and deeper AI security as continuing tracks. Expand the projects when a specific learning goal justifies it, not simply to make them larger.

Success criterion: you can build, debug, evaluate, secure, and explain the systems you implemented, while clearly identifying what you have not yet explored.

## AI engineering topics integrated into the required path

This section deliberately sits outside the critical path. The 11-week plan and its core milestones remain unchanged. These topics are added at the places where they naturally fit, but you should study them only in allocated roadmap time, after the core task for that week is complete, or after the main roadmap. Never postpone a core milestone to finish an advanced required module.

### Required AI engineering topics

Best fit --- Extra topic --- Small, bounded proof of learning - Project 1 / Weeks 1--2: Transformer and generation internals --- Explain tokenization, token IDs, embeddings, attention, logits, and sampling at a conceptual level; run a temperature/top-p experiment. - Project 1 / Weeks 1--2: Local embeddings --- Embed a small set of notes and compare similarity results and latency with the embedding approach used in Project 2. - Project 1 / after core assistant: Persistent assistant memory --- Implement write/retrieve/update/delete rules and test session/user isolation. - Project 1 / conditional on the project requirement frontend: React streaming chat --- Show streamed output, safe Markdown, cancel a response, and prevent an older response overwriting a newer one. - Project 2 / Weeks 3--4: Robust PDF, Markdown, and HTML parsing --- Add a small fixture-based test set for headings, tables, malformed/empty files, metadata, and citations. - Project 2 / after baseline evaluation: Vectorless or structure-aware retrieval --- Compare a document outline/hierarchical index/LLM-generated map against vector retrieval on the same QA set; report what changed. - Project 3 / after agent basics: MCP server --- Expose one or two safe tools with validated schemas, server-side authorization, and predictable error handling. - Project 3 / after agent basics: Repository exploration and documentation --- Search a repository safely, find functions/classes, create source-grounded summaries, and export Markdown docs. - Project 3 / after core security tests: Agent SDK comparison --- Rebuild one small workflow with either OpenAI Agents SDK or Claude Agent SDK and write a short comparison.

### Required ecosystem literacy

(bounded)

• Compare OpenAI, Anthropic, Gemini, and Ollama only on the same small task set and only after the provider-neutral core works.

• Explore prompt caching, batch APIs, long-context/PDF input, or extended-thinking features only when there is a concrete workload that benefits.

• Try Qdrant if the main RAG project uses a different vector store; do not maintain multiple vector databases without a reason.

• Build a NotebookLM-style multi-document experience as a thin advanced required module of Project 2, not as a separate project.

• Explore managed tools, Skills, and distribution/publishing after the core agent and permissions are secure.

• Voice agents, a separate pitch-deck generator, and deep Mem0/Neo4j/knowledge-graph work are conditional on the project requirement future explorations, not requirements for this plan.

### How to sequence this work

• Finish the day's core deliverable and its tests first.

• If additional time remains, select one advanced required module that fits the current project.

• Time-box the first attempt to 30--60 minutes. Produce a tiny experiment, test, or comparison---not a new large feature.

• If it needs more time, put it in the backlog and return to the core roadmap next session.

• Keep advanced required module results separate from the core milestone checklist. A project milestone can be complete even if every advanced required module remains unchecked.

Rule: Core schedule first; advanced required modules second. These additions broaden coverage without making the existing plan slower or harder to finish.

## Original 12-stage AI security curriculum --- detailed reference

The following stages map the supplied security curriculum into the existing projects. They are not twelve equal courses. The first eight are practical product-security capabilities; Stages 9--10 and parts of 11--12 are specialist or post-core work.

### Twelve-stage security map

-------------------------------------------------------------------------------- Stage Topic When Priority ------- --------------------------------- -------------------- ----------------- 0 Web application security and Week 1, then Core threat modeling: IDOR/BOLA, SSRF, continuously auth, trust boundaries, STRIDE

1 AI attack surfaces: OWASP Top 10 Weeks 1--2; revisit Core concepts for LLMs, confused deputy, Weeks 4--6 data-flow mapping

2 Prompt injection/jailbreak Weeks 1--2 and 6--8 Basic defenses resilience: direct/indirect, core; harness multi-turn, encoding/splitting additional

3 Agentic security/MCP: tool Weeks 5--6 Authorization poisoning, JSON-RPC validation, core; MCP server least privilege additional

4 RAG security/data poisoning: Weeks 3--4 Access control vector access, citation spoofing, core; advanced poisoned corpus experiment additional

5 PII/privacy: masking, token Weeks 1--2 basics; Privacy hygiene substitution, differential Weeks 7--8 review core; proxy privacy concepts additional

6 Identity/delegated access: OAuth2 Weeks 7--8; Auth/approval scopes, short-lived tokens, HITL, approvals in Weeks core; broker A2A 7--8 additional

7 Output validation/constrained Weeks 1--2; deeper Schema validation generation: schemas, work after core core; constrained sanitization, grammar constraints decoding additional

8 Automated red teaming/fuzzing: Weeks 4--6; CI in Small test suite PyRIT, Garak, adversarial Week 8 core; large datasets, CI gates campaigns additional

9 Model extraction/IP protection: After Week 8, if Specialist abuse detection, rate limits, relevant membership inference, watermarking

10 Mechanistic interpretability: After core, Defer activation patching, logit lens, conditional on the circuits, TransformerLens project requirement research track

11 Compliance/auditing/governance: Basic auditability Audit basics NIST AI RMF, EU AI Act awareness, Weeks 7--8; deeper core; formal work SOC 2 controls later additional

12 CVEs/teardowns/responsible After a stable Career advanced disclosure/portfolio project required module --------------------------------------------------------------------------------