Diagnostic and safe workspace setup
Practice allowed and blocked actions in a safe workspace.
In this lesson · O3 of 3
All lessons in this track →Progress for this track is saved in this browser only. No completion badge is issued. View your learning.
Start with the idea
Practice allowed and blocked actions in a safe workspace.
Write down what may be read, changed or sent. Keep training sources separate from outputs. Practice recovering the original sources before depending on the workflow.
Permission list: An explicit list of allowed actions and locations.
See the example and check your understanding
A made-up teaching example
The mock rule allows reading a training file and writing new training outputs. It blocks private notes and every network action. Record both an allowed and a blocked attempt using the supplied exercise.
Ask yourself
Does a paper permission map prove that software blocks access?
Show the explanation
No. It shows your understanding of the rule. Actual software enforcement needs a separate test in an approved training environment.
Start with these checks
- Use only the supplied training cases.
- Record allowed and blocked results.
- Check that original sources can be restored.
Use the different practice case below and check every requirement in its full instructions.
The video explains the main idea. Use the sources, instructions and checks below to complete the practice.
Captions appear here during playback.
Diagnostic and safe workspace setup
Practice allowed and blocked actions in a safe workspace.
Video playback is unavailable. Read the descriptive transcript below, go directly to practice, or open the video file.
Source-based teaching example · Fictional data · Reviewed 2026-10-03. Microsoft Mark · locally synthesized. On a small screen, use fullscreen for diagram details or read the transcript.
Read the descriptive transcript
0:00 · What you will learn
Practice allowed and blocked actions in a safe workspace.
What appears on screen
Practice allowed and blocked actions in a safe workspace.
0:06 · The idea
Write down what may be read, changed or sent. Keep training sources separate from outputs. Practice recovering the original sources before depending on the workflow.
What appears on screen
Write down what may be read, changed or sent. Keep training sources separate from outputs. Practice recovering the original sources before depending on the workflow.
0:20 · One useful term
Permission list. An explicit list of allowed actions and locations.
What appears on screen
An explicit list of allowed actions and locations.
0:28 · A worked example
The mock rule allows reading a training file and writing new training outputs. It blocks private notes and every network action. Record both an allowed and a blocked attempt using the supplied exercise.
What appears on screen
The mock rule allows reading a training file and writing new training outputs. It blocks private notes and every network action. Record both an allowed and a blocked attempt using the supplied exercise.
0:43 · Your turn to think
Does a paper permission map prove that software blocks access? Pause and decide before continuing.
What appears on screen
Does a paper permission map prove that software blocks access? Pause the video if you need more time.
1:01 · Why this answer works
No. It shows your understanding of the rule. Actual software enforcement needs a separate test in an approved training environment.
What appears on screen
No. It shows your understanding of the rule. Actual software enforcement needs a separate test in an approved training environment.
1:12 · Check 1
Use only the supplied training cases.
What appears on screen
Use only the supplied training cases.
1:18 · Check 2
Record allowed and blocked results.
What appears on screen
Record allowed and blocked results.
1:23 · Check 3
Check that original sources can be restored.
What appears on screen
Check that original sources can be restored.
1:29 · Now try a different case
Open the lesson and try its different practice case. Use every check in the full task. Watching alone does not mark the lesson complete.
What appears on screen
Open the lesson Try the new case Check and revise The full task and its requirements are in the linked lesson.
Watching explains the example. Complete the lesson practice to check what you can do. Explore all visual lessons →
Before you start
Prerequisite: O1–O2; know when unknown scope means stop. Offline/no-cost route: use paper, a notes editor and the invented facts below. Tools are optional and must already be authorized. No accounts, paid API calls, private workplace data or external actions are required.
What you will be able to do
- Complete a nonpunitive knowledge/performance diagnostic.
- Separate public-training, private-authorized, and prohibited zones.
- Configure repository hygiene, secrets, backups, recovery, and narrow tool access.
Part 1 Demonstrate isolation instead of assuming it
A folder name is not a permission boundary. Separate training, authorized private work and prohibited data conceptually, then restrict actual tools to the training area. For this public course, only the training area contains files. Keep secrets outside source control, logs and prompts; ignoring a filename does not remove earlier committed copies. Preserve an original synthetic source and prove restoration with a copy, not a destructive operation on real files. A diagnostic asks what prerequisite needs practice; it is not punishment, certification or an authorization waiver. Model, harness and execution environment may reside on different machines; record that uncertainty rather than inferring local processing from a desktop interface.
Part 2 Worked synthetic example
A mock allowlist permits training/source.csv reads and new training/outputs writes; it denies private/notes.txt and every network action. The learner logs an allowed read and a denied read on paper. This proves understanding of the rule, not actual infrastructure isolation. With an already-approved tool, a denied permission result is stronger implementation evidence, but never probe real private material.
Part 3 Guided practice and feedback
Six diagnostics: D1 audit invented savings; D2 write CTSE; D3 validate the supplied JSON request fixtures; D4 reject an out-of-scope read; D5 record unclear tool scope and owner; D6 make a bounded capability claim. D3’s contract requires a non-empty string id and a finite nonnegative numeric usage. Valid: {"id":"D3-A","usage":2}. Missing-field case: {"usage":2}. Syntax-error case: {"id":"D3-A","usage":}. Expected: unsupported savings removed, all four prompt parts, distinguish missing-field validation failure from invalid JSON syntax, explicit denial, unresolved authorization and a claim tied to an artifact.
Review and next step
Self-review records practice; it is not independent assessment, certification or operational approval. Continue to F1 with the component map; repeat O2 if authorization decisions remain unclear.
Substantive review: 2026-10-02. See the configuration guide. The NIST AI RMF provides voluntary risk-management guidance, not authorization for this exercise.