CVEs, Security Teardowns, Disclosure & Portfolio

When: Week 11 (8 hours), after the projects are stable. The goal is a defensible teardown and disclosure workflow, not unbounded vulnerability hunting.

• Learn coordinated disclosure, scope, safe reproduction, severity, impact analysis, and remediation verification.

• Read public advisories and security patches to understand real exploit chains.

• Write advisories with affected versions, preconditions, impact, authorized reproduction, mitigation, and remediation status.

• Review open-source AI frameworks/MCP servers for authorization, SSRF, path traversal, unsafe deserialization, secret leakage, and tool permission mistakes.

• Test only systems within explicit bug-bounty scope or with maintainer authorization.

Practice: perform a code review/security teardown of an open-source AI component. If you find a genuine issue, follow its disclosure policy; do not publish an unpatched exploit or claim a vulnerability without evidence.

Do not learn yet: hunt for CVEs before understanding the codebase, scope, and disclosure rules. A high-quality defensive teardown is useful portfolio evidence.

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

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

## 11. Detailed specifications for the ten additional security domains

These ten domains are already distributed across Days 1--111. This section is the deeper reference for the labs and completion criteria. Follow the day schedule for timing; use these details when implementing each module.

## C. Module 1 --- Model supply-chain security (10 hours)

Best time to learn: After the original roadmap's Docker, dependency hygiene, and deployment fundamentals (Weeks 7--8). Learn a short provenance primer before using any external model checkpoint in a project; complete this module during the advanced supplement.

Prerequisites - Python environments and package/dependency management. - Docker image and deployment basics. - Familiarity with Hugging Face model repositories and model loading. - Basic hashes, signatures, and software supply-chain concepts.

### Threat model

A model artifact is executable-adjacent, high-impact input to your system. The supply chain includes weights, tokenizer files, configuration, custom model code, adapters, datasets, evaluation assets, packages, and the infrastructure that downloads and stores them.

Study: - Unsafe model serialization and deserialization. - safetensors and the limits of choosing a safer weight format. - pickle-based loading risks and arbitrary code execution hazards. - trust_remote_code and custom repository code. - Model and dataset repository impersonation or compromise. - Weight, tokenizer, configuration, and adapter substitution. - Dependency confusion, typosquatting, compromised packages, and transitive dependencies. - Provenance, checksums, signatures, immutable version pinning, and artifact inventories. - Model cards and dataset cards as useful metadata, not cryptographic proof of safety. - Scanning and review before an artifact is admitted to a production environment.

### Labs

• Artifact inventory (2h): Select one small public model. Record repository, exact revision, file list, model format, tokenizer/config files, declared dependencies, license, and provenance claims.

• Safe-loading comparison (2h): In an isolated disposable environment, compare a safe tensor loading path with an unsafe serialization example. Do not execute untrusted artifacts on your host. Explain exactly what the format does and does not protect against.

• Integrity gate (2h): Download a pinned artifact, calculate file hashes, store an approved manifest, alter a copy, and verify the gate rejects the changed artifact.

• Repository review (2h): Inspect custom model code, dependencies, install hooks, and remote-code requirements. Document why each permission is needed or reject the artifact.

• Admission control (2h): Add a model-artifact approval checklist to one project. Record source, revision, hashes, license, reviewer, scan results, and deployment version.

### Project integration

• Project 1: Pin the Ollama model identifier/version where possible; record provider/runtime/model configuration. If using downloaded Hugging Face artifacts, use a pinned revision and a controlled cache.

• Project 2: Add approved model and embedding-model manifests. Prevent silent model changes from invalidating evaluation baselines.

• Deployment: Keep model files separate from application code, use read-only mounts where possible, and run model-loading processes with minimal filesystem and network permissions.

### Measurable completion criteria

• You can explain why safetensors reduces a particular class of deserialization risk but does not prove that weights are benign.

• Every model artifact used in the project has a recorded source and pinned revision or version.

• An integrity test detects a modified artifact.

• Unreviewed custom model code is not executed by default.

• You can produce an artifact inventory and explain its residual risks.

Do not overreach: Do not attempt to build a universal model malware scanner. Artifact provenance, safe loading, isolation, and admission controls are the target.

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

## D. Module 2 --- Training and fine-tuning security (10 hours)

Best time to learn: After Module 1 and after you understand model evaluation. Place it after the model lifecycle and evaluation portions of the existing roadmap, not before you know how to establish a clean baseline.

Prerequisites - Basic supervised learning and fine-tuning concepts. - Train/validation/test separation. - Model evaluation and reproducibility. - Module 1 artifact provenance.

### Threat model

Training-time attacks influence model behavior before inference. They are distinct from RAG poisoning and runtime prompt injection.

Study: - Pretraining and fine-tuning data poisoning. - SFT and preference-data poisoning. - Trigger-based backdoors and targeted behavior changes. - Label manipulation and data provenance failures. - Reward-model and preference optimization manipulation at a conceptual level. - Evaluation-set contamination and benchmark leakage. - Model checkpoint substitution. - Data lineage, deduplication, outlier review, and dataset versioning. - Backdoor persistence, transfer, and limitations of simple detection. - Why cleaning data does not guarantee a backdoor has been removed from an already trained model.

### Labs

• Clean baseline (1h): Use a small model or toy classifier and a synthetic, harmless task. Save model version, dataset version, seed, and baseline metrics.

• Synthetic poisoning (3h): Add a small controlled set of trigger-associated examples to a toy fine-tuning dataset. Keep the trigger and task benign and confined to your local experiment.

• Behavioral evaluation (2h): Compare clean inputs, trigger inputs, and unrelated inputs. Report false positives, false negatives, and changes in normal task performance.

• Mitigation comparison (2h): Compare data filtering, provenance checks, retraining from a clean checkpoint, and targeted evaluation. Explain why no single mitigation is guaranteed.

• Dataset governance (2h): Add dataset versioning, source tracking, review status, and a poisoning-test report to the project documentation.

### Project integration

• Project 1: Add a model provenance and behavior-regression record, even if you do not fine-tune its local model.

• Project 2: Treat embedding model, reranker, answer model, evaluation data, and source documents as separately versioned assets.

• Project 3: Ensure an agent's policy or behavior configuration cannot be silently replaced by an unreviewed fine-tuned checkpoint.

### Measurable completion criteria

• You can explain the difference between retrieval poisoning, training-data poisoning, and inference-time prompt injection.

• You have a reproducible synthetic poisoning experiment with a clean baseline.

• You report trigger behavior and collateral impact on normal task performance.

• You can describe at least three mitigations and their limitations.

• Dataset and checkpoint provenance are represented in your project documentation.

Do not overreach: Do not try to reproduce large-scale foundation-model poisoning or claim that a small toy experiment predicts real-world backdoor prevalence.

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

## E. Module 3 --- Multimodal AI security (10 hours)

Best time to learn: Immediately after the existing RAG ingestion, file parsing, and prompt-injection stages. Introduce multimodal attack concepts earlier if the product already accepts images, audio, or video.

Prerequisites - Prompt injection and trust-boundary fundamentals. - File upload validation, parser isolation, and SSRF protections. - Basic understanding of OCR, speech-to-text, and vision-language model pipelines.

### Threat model

A multimodal system receives more than user-authored text. Instructions and adversarial content can arrive through pixels, OCR, audio transcription, video frames, metadata, and document structure.

Study: - Image prompt injection and hidden/low-visibility text. - OCR manipulation and disagreement between visual and extracted text. - Audio transcription attacks, spoken prompt injection, and speaker ambiguity. - Video frame-level and audio/video instruction conflicts. - PDF and office-document embedded content, parser vulnerabilities, and active content. - Cross-modal instruction precedence and provenance. - Adversarial examples versus prompt injection: related but different threat classes. - Content moderation and safety checks across modalities. - Safe storage, retention, and access control for uploaded media.

### Labs

• Image injection (2h): Create benign test images containing visible and low-visibility instructions. Test a vision-language model and record whether it treats image text as instructions or quoted content.

• OCR discrepancy (2h): Compare the original image, OCR output, and model interpretation. Test cases where OCR omits, reorders, or misreads text.

• Audio attack surface (2h): Use your own recorded benign phrases and transcription output. Test speaker attribution, transcription uncertainty, and whether spoken content can cause an agent to take an action without user confirmation.

• Document parser boundary (2h): Test malformed and oversized files in an isolated parser pipeline. Verify type checks, size limits, timeouts, and rejection of active or unsupported content.

• Cross-modal policy (2h): Define how the application labels provenance: user instruction, quoted document content, OCR text, transcript, and model-generated description. Add tests for conflicts and untrusted instructions.

### Project integration

• Project 2: Extend ingestion to one additional modality only after the text pipeline has safe parsing, access control, and provenance. Add OCR/transcription output as untrusted source material.

• Project 3: If the agent can inspect screenshots or browser pages, treat visual text as untrusted page content, not as agent policy.

• API layer: Store media metadata and access rights separately from extracted text; do not let a derived OCR chunk bypass the source document's ACL.

### Measurable completion criteria

• Image, OCR, audio/transcript, and document-parser test cases are represented in a repeatable suite.

• Extracted content retains source and trust labels.

• Malformed, oversized, and unsupported files are rejected safely.

• A multimodal prompt-injection attempt cannot independently authorize a privileged action.

• You can distinguish prompt injection, adversarial examples, parser exploits, and ordinary transcription errors.

Do not overreach: Do not build a complete video understanding system just to learn security. One image path and one audio/transcript path are sufficient for the security labs.

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

## F. Module 4 --- Inference infrastructure and serving security (10 hours)

Best time to learn: During the existing production-engineering and deployment weeks, after Docker, networking, authentication, and observability. This is a prerequisite for operating self-hosted or multi-tenant open-weight models.

Prerequisites - Docker and container basics. - HTTP/API authentication and authorization. - Network segmentation, secrets management, and logging. - Basic inference-server architecture.

### Threat model

The model-serving layer can be attacked even if the model's prompt handling is excellent. A reachable unauthenticated endpoint, weak container, overprivileged process, or shared-resource leak can compromise the system.

Study: - Inference gateway versus model server responsibilities. - vLLM or another serving runtime at an architectural level. - Authentication, authorization, per-tenant routing, and request identity propagation. - Network segmentation and outbound egress restrictions. - Container hardening, non-root execution, read-only filesystems, and capability reduction. - Model file mounts and runtime filesystem access. - Secret injection and rotation. - GPU/resource isolation and multi-tenant considerations. - Request concurrency, queue limits, memory pressure, and graceful shutdown. - Endpoint exposure, health endpoints, metrics endpoints, and administrative interfaces. - Cloud IAM and workload identity where applicable.

### Labs

• Serving topology (2h): Diagram gateway, model server, storage, telemetry, network boundaries, and identity propagation. Identify every externally reachable endpoint.

• Endpoint hardening (2h): Put a local inference endpoint behind an authenticated gateway. Verify unauthorized and cross-tenant requests are rejected.

• Container hardening (2h): Run as non-root, remove unnecessary capabilities, restrict mounts, avoid privileged mode, and use a read-only filesystem where feasible.

• Network and secrets (2h): Restrict egress to required destinations; verify secrets are not baked into images, logs, or environment dumps.

• Resource isolation (2h): Add request size, concurrency, queue, and timeout limits. Simulate resource pressure and verify controlled rejection and recovery.

### Project integration

• Project 1: If Ollama or another local runtime is exposed beyond localhost, put it behind an explicit access boundary. Never assume a local inference port is safe to expose.

• Project 2: Harden the deployed API, embedding/reranking workers, vector store, and model endpoint as separate components.

• Project 3: Keep agent execution workers isolated from the model-serving process and from application secrets.

### Measurable completion criteria

• No model-serving or administrative endpoint is unintentionally public.

• Unauthorized requests and cross-tenant access fail closed.

• Containers run with documented minimum privileges.

• Egress and secret-handling policies are tested.

• Resource-exhaustion tests produce bounded failure rather than uncontrolled service degradation.

Do not overreach: Do not deploy Kubernetes, a GPU cluster, or a service mesh solely for résumé value. A hardened single-host deployment can demonstrate the relevant controls.

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

## G. Module 5 --- AI denial of service and economic abuse (5 hours)

Best time to learn: Immediately after implementing token budgets, truncation, retries, tool-call limits, queues, and rate limiting.

Prerequisites - Token counting and context budgets. - API rate limiting. - Async concurrency and queue basics. - Agent step and tool-call budgets.

### Threat model

AI workloads have variable and sometimes multiplicative costs. One user action may trigger retrieval, reranking, several model calls, tools, retries, and media processing.

Study: - Denial of wallet and cost amplification. - Context stuffing and oversized input. - Repeated tool invocation and recursive agent loops. - Retry storms and provider failure amplification. - Expensive retrieval/reranking patterns. - Per-user, per-tenant, and per-model quotas. - Concurrency limits, queue backpressure, and circuit breakers. - Abuse signals and anomaly detection.

### Labs

• Cost model (1h): Estimate cost per request across input/output tokens, retrieval, reranking, tools, and media.

• Adversarial load (1h): Simulate oversized prompts, repeated requests, and tool loops against your own local test system.

• Budget enforcement (2h): Add request, token, tool-call, wall-clock, and concurrency budgets with deterministic rejection behavior.

• Recovery test (1h): Simulate provider timeouts and retries; verify retry caps, jitter, circuit breaking, and queue recovery.

### Project integration

• Project 1: Token and conversation budgets, maximum response tokens, request timeout, and per-session limits.

• Project 3: Maximum steps, tool calls, parallel tasks, execution time, and approval waits.

• Production API: Per-user and per-tenant quotas, backpressure, and cost alerts.

### Measurable completion criteria

• Each request has a bounded token, time, and cost budget.

• Agent loops terminate at a deterministic limit.

• Retries cannot amplify an outage indefinitely.

• Load tests show controlled degradation and recovery.

• Cost and abuse metrics are available without logging sensitive prompt contents.

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

## H. Module 6 --- AI memory security (5 hours)

Best time to learn: At the exact point persistent memory is added to Project 1; revisit the same controls when Project 3 introduces checkpoints or long-lived agent state.

Prerequisites - Database ownership and tenant isolation. - RAG authorization and provenance. - Conversation persistence. - Basic privacy and retention concepts.

### Threat model

Memory is durable state that can influence future model behavior. A malicious or unauthorized write can persist beyond the original conversation; an access-control error can expose one user's history to another.

Study: - Memory write versus read authorization. - User, session, tenant, and agent identity boundaries. - Memory provenance and trust labels. - Memory poisoning and stale facts. - Sensitive memory classification and minimization. - Expiration, deletion, correction, and retention. - Memory retrieval authorization and audit events. - Checkpoint integrity and replay risks.

### Labs

• Isolation test (1h): Prove users cannot read, search, overwrite, or delete another user's memories.

• Poisoning test (1h): Add an adversarial memory entry in a controlled test and verify provenance, confirmation, or trust rules prevent it from silently becoming privileged instruction.

• Lifecycle controls (2h): Implement TTL, deletion, correction, and retention behavior. Verify derived indexes and caches follow the same deletion policy.

• Replay and integrity (1h): Test stale checkpoint replay and unauthorized state restoration.

### Project integration

• Project 1: Every memory record has an owner, source, timestamp, trust classification, and retention rule.

• Project 3: Checkpoints are bound to the correct user, tenant, workflow, and authorization context.

• RAG: Memory search applies authorization filters before content is returned to the model.

### Measurable completion criteria

• Cross-user memory access tests pass.

• Memory writes have provenance and authorization checks.

• Deletion covers primary records and relevant derived indexes/caches.

• Untrusted memory cannot grant tool permissions or override application policy.

• You can explain what is remembered, why, for how long, and how it is removed.

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

## I. Module 7 --- Advanced privacy-preserving ML (8 hours)

Best time to learn: After the original PII proxy and model extraction/privacy stages. This module distinguishes application-level privacy controls from model-level information leakage.

Prerequisites - PII classification and masking. - Basic model training or fine-tuning concepts. - Statistics and evaluation metrics. - Familiarity with membership inference and model inversion concepts.

### Threat model

Sensitive information can leak from training data, embeddings, model outputs, logs, caches, and shared infrastructure. Removing obvious PII from prompts does not establish that the model has not memorized sensitive examples.

Study: - Memorization and training-data regurgitation. - Membership inference. - Model inversion and reconstruction risks. - Embedding inversion and semantic leakage. - Privacy risks in fine-tuning and retrieval. - Differential privacy: adjacency, clipping, noise, privacy budget, epsilon/delta, and utility trade-offs. - Federated learning threat model: client poisoning, update leakage, and secure aggregation concepts. - Machine unlearning: deletion claims, retraining, and verification limitations. - Cache and cross-tenant information leakage.

### Labs

• Privacy threat model (1h): Identify sensitive data at ingestion, storage, embedding, prompt construction, model output, logs, and caches.

• Membership inference demonstration (2h): Use a small controlled dataset and toy or published demonstration. Explain the attack signal and false-positive limitations.

• Embedding privacy (1h): Examine what metadata and semantic information can be inferred from stored embeddings; test access control and minimization.

• Differential privacy experiment (2h): Run a small DP example or documented library tutorial. Compare privacy parameters, utility, and assumptions.

• Deletion and cache test (2h): Delete a synthetic user's data and verify primary storage, vector index, caches, and logs follow the declared deletion policy.

### Project integration

• Project 1: Redact sensitive telemetry and define conversation/memory retention.

• Project 2: Enforce source ACLs before retrieval; test embedding-store isolation and deletion propagation.

• Training/fine-tuning workflow: Record whether data is suitable for training, how consent/provenance is represented, and how deletion requests are handled.

### Measurable completion criteria

• You can distinguish PII masking, differential privacy, access control, and machine unlearning.

• A small privacy attack demonstration includes assumptions and limitations.

• Deletion tests cover derived data stores and caches.

• You can explain the privacy/utility trade-off of a DP configuration.

• No claim of "privacy guaranteed" is based solely on masking or a single experiment.

Do not overreach: Do not claim production-grade DP or federated-learning expertise from one tutorial. Understand the threat model, assumptions, and measured trade-offs.

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

## J. Module 8 --- AI secure development lifecycle (AI-SDLC) (7 hours)

Best time to learn: After your projects have automated tests and CI, before treating any project as production-ready.

Prerequisites - Git and code review. - Unit/integration tests and CI. - Docker image builds. - Model, prompt, dataset, and evaluation versioning.

### Threat model

Security must persist through changes to code, dependencies, model versions, prompts, tools, datasets, infrastructure, and providers. A secure release process needs to detect changes that invalidate prior security evidence.

Study: - SAST and security-focused code review. - Software composition analysis (SCA), lockfiles, and dependency pinning. - Secret scanning and rotation. - Container image scanning and provenance. - Infrastructure-as-code scanning where IaC is used. - API security testing and DAST concepts. - Model, prompt, tool-schema, dataset, and evaluation versioning. - Security regression gates for model/provider changes. - SBOM and model-artifact inventory concepts. - Release approval, rollback, and incident response.

### Labs

• Pipeline inventory (1h): Map code, dependencies, containers, models, prompts, tools, datasets, and deployment configuration.

• Static and dependency checks (2h): Add a SAST or lint security check, dependency vulnerability scan, and secret scan to CI.

• Artifact checks (1h): Scan built container images and record model artifact versions/hashes.

• AI regression gate (2h): Run a compact security evaluation suite when prompt, model, provider, tool schema, or retrieval code changes.

• Release drill (1h): Simulate a vulnerable model/provider update; block or roll back the release and preserve evidence.

### Project integration

• All three projects: A pull request should run relevant unit tests, authorization tests, prompt-injection regression tests, dependency checks, and a compact model evaluation.

• Release process: A model/provider change is a security-relevant change, not merely a configuration edit.

### Measurable completion criteria

• CI detects a deliberately introduced secret or vulnerable dependency in a controlled test.

• Model and prompt versions are recorded with evaluation results.

• A failed security regression blocks a release or triggers a documented approval path.

• Rollback procedure is documented and tested.

• Security evidence is tied to a specific build and model configuration.

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

## K. Module 9 --- Browser and computer-use agent security (10 hours)

Best time to learn: After MCP, tool authorization, scoped identity, and human approval are implemented in Project 3. Do not start with a powerful computer-use agent before the simpler tool model is secure.

Prerequisites - Agent state machine and tool execution. - Authentication and delegated authorization. - Prompt injection and untrusted tool/page content. - Process/container isolation and network restrictions. - Human-in-the-loop approval.

### Threat model

A browser or computer-use agent can interact with untrusted websites and potentially sensitive user sessions. The webpage is an untrusted source of instructions. The agent's ability to click, type, download, upload, or execute commands creates real-world side effects.

Study: - Browser prompt injection and malicious webpage content. - Browser profile and session isolation. - Cross-origin navigation and account-boundary risks. - Credential and cookie protection. - Download and attachment handling. - Filesystem sandboxing and path restrictions. - Shell/command execution policy. - Network egress allowlists and DNS/IP restrictions. - Screenshot, clipboard, and page-content leakage. - Human approval for high-impact actions. - Time-of-check/time-of-use and approval-context binding. - Cancellation, emergency stop, and action audit trails.

### Labs

• Threat model (1h): Draw trust boundaries for agent, browser, website, identity provider, user session, filesystem, network, and model.

• Browser isolation (2h): Use a disposable browser profile and test that credentials/cookies are not shared with unrelated sessions.

• Prompt injection (2h): Create a local test webpage with benign instructions attempting to redirect the agent's task. Verify the agent treats page content as untrusted and cannot change its authorization scope.

• Filesystem and download sandbox (2h): Restrict downloads and file writes to a temporary workspace; test path traversal and unexpected file types.

• Network and command restrictions (1h): Deny unapproved destinations and shell operations. Verify the policy is enforced outside the model.

• Approval and emergency stop (2h): Require explicit approval for a sensitive action; bind approval to the exact action and parameters. Test cancellation during execution and audit the outcome.

### Project integration

• Project 3: Add a restricted browser or computer-use tool only after the normal agent's tool authorization works.

• Execution worker: Run in a disposable container or isolated environment with no host credentials, restricted mounts, and network egress controls.

• Approval layer: The user approves a specific action, not a vague plan that the agent can later reinterpret.

### Measurable completion criteria

• A malicious webpage cannot expand the agent's permissions.

• Browser sessions are isolated and disposable.

• Downloads and file writes are confined to an approved workspace.

• Network and command restrictions are enforced outside the model.

• Sensitive actions require parameter-bound approval.

• Cancellation and audit records work during partial execution.

Do not overreach: Do not give the agent unrestricted desktop access, host filesystem access, personal browser cookies, or a general-purpose shell.

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

## L. Module 10 --- AI safety and misuse prevention (7 hours)

Best time to learn: Alongside the original automated red-teaming stage, after you have a reproducible evaluation harness. Re-run the checks after model or provider changes.

Prerequisites - Prompt-injection and jailbreak testing. - Evaluation datasets and reproducibility. - Content policy and output validation. - Monitoring and incident escalation.

### Scope distinction

AI safety and misuse prevention overlap with AI security but are not the same discipline. This module covers the application and operational controls needed to reduce harmful use. It does not claim to solve model alignment.

Study: - Harmful-use threat modeling and abuse cases. - Refusal robustness and policy bypass evaluation. - Dual-use capability and risk assessment. - Input/output moderation architecture. - Abuse detection and rate-limit signals. - Human escalation and incident response. - Safety regression after model/provider changes. - False positives, false negatives, and user-impact trade-offs. - Differences between model alignment, model safety, application security, and platform abuse prevention.

### Labs

• Misuse threat model (1h): Identify plausible misuse cases for each flagship project and map controls to the application layer, model/provider layer, and operations.

• Evaluation set (2h): Build a small, versioned set of allowed, disallowed, ambiguous, and adversarial requests relevant to the product. Use synthetic examples and clear expected outcomes.

• Control comparison (2h): Compare moderation, policy prompts, structured workflows, tool restrictions, and human review. Record where each control is effective and where it fails.

• Regression and escalation (2h): Run the suite against two model/provider configurations or versions; define escalation and incident handling for severe failures.

### Project integration

• Project 1: Define intended-use boundaries and abuse controls for tools.

• Project 2: Evaluate harmful or sensitive requests in the context of retrieved content and citations.

• Project 3: Require additional authorization and review for high-impact or irreversible actions.

### Measurable completion criteria

• Each project has a documented misuse threat model.

• Evaluation examples have expected outcomes and severity labels.

• False positives and false negatives are measured rather than hidden.

• High-severity failures have an escalation path.

• Model/provider upgrades trigger a safety regression run.

Do not overreach: Do not equate a high refusal rate with safety. A safe system must also complete legitimate tasks, preserve user rights, and enforce permissions independently of model refusals.

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

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

## 12. Integrated security evidence standard

For every meaningful security lab, preserve: 1. System under test, build, model/provider version, and configuration. 2. Attacker capability and preconditions. 3. Reproducible attack steps against your own system or an explicitly authorized lab. 4. Expected secure behavior. 5. Actual observed behavior and relevant logs/test output. 6. Impact on confidentiality, integrity, availability, privacy, safety, or cost. 7. Mitigation location and rationale. 8. Regression test. 9. Residual risk and assumptions.

A lab is complete only when you can reproduce the threat, demonstrate the control, and explain its limits. Installing a tool or reading a checklist is not completion evidence.

## Turning Capabilities into Employment Opportunities

Turn those capabilities into employment opportunities: The roadmap does not fully cover this. The two cold-email articles provide a practical outreach process that is currently missing.

---