What you’ll be able to do
- Pick the right Claude surface for a stated requirement
- Draw and enforce the content boundary between instructions and data
- Keep one user’s session state out of another’s context
- Design schemas that survive imperfect model output
What you need to know
Surfaces are not interchangeable
Claude reads instructions differently depending on where you're working: the API, the SDKs, Claude Code, the desktop app, claude.ai. A requirement usually implies one of them.
- Programmatic integration inside your product → API / SDK
- Repository-aware development work, CI automation → Claude Code
- Individual knowledge work without engineering effort → claude.ai / Projects
The tested version of this is usually a team reaching for the wrong one — scripting the consumer surface for what should be an API integration, or standing up a service for what a Project would have handled.
The content boundary
This is the concept doing the most work in the sub-skill. Everything reaching the model falls on one side of a line: instructions you author and trust, or data you received and don't.
Retrieved documents, uploaded files, scraped pages, API responses, and user-supplied text are all data. They belong tagged, delimited, and clearly marked as content to be processed — never concatenated into the instruction space where they read as though you wrote them.
messages = [{“role”:“user”,“content”: f”<document>{retrieved_doc}</document>\n\n{question}”}]
Worth being precise: the boundary is a design control that makes injection detectable and containable. It is not by itself a security guarantee — that needs the permission boundary covered in Domain 7.
Session hygiene
In a multi-tenant assistant, conversation state must be scoped per user and per session. When caches are keyed loosely, or a "shared context" optimization is introduced to save tokens, fragments of one user's conversation can surface in another's.
For a healthcare or financial product that isn't a bug, it's a disclosure. The exam frames it as a design failure rather than a security one, because the cause is how state was scoped, not a credential leak.
Schemas that expect imperfection
Design output schemas to fail loudly rather than silently. Prefer required fields with explicit enums over free-form strings, so a deviation is a validation error instead of a plausible-looking wrong value that flows downstream.
A field typed as status: string will happily accept "probably active". The same field as an enum of three values rejects it, and you find out immediately.
Key concept
Choose the surface the requirement implies, keep untrusted data out of instruction space and clearly tagged, scope session state per user, and design schemas so deviations surface as errors rather than plausible values.
Practice scenario
Work it through, then open this
This is a session hygiene failure waiting to happen, and in healthcare or finance a disclosure rather than a bug. Conversation state is scoped per user and per session. The token saving is real and not worth it; compaction and pruning cut the same cost without crossing tenant boundaries.
Build exercise — Draw your content boundary
Intermediate · 30 min
What you’ll learn
- Separating authored instructions from received data
- Making schema deviations loud instead of plausible
-
List everything that reaches your model and mark each as either instructions you authored or data that arrived from outside — retrieved docs, uploads, tool results, user text.
- Why: The content boundary only works if you know which side everything is on.
- You should see: The data column is usually longer than people expect.
-
Check whether any of that data is concatenated into your system prompt. If so, move it into the user turn inside explicit tags, with a system-prompt line stating that tagged content is untrusted material to process.
- Why: Data in instruction space reads to the model as though you wrote it, which is the precondition for indirect injection.
- You should see: A clean split: your instructions in system, everything received in a delimited block.
-
Open your output schema and find every field typed as a free-form string that actually has a fixed set of valid values.
- Why: A status field typed as string accepts ‘probably active’ and passes it downstream. An enum rejects it at the boundary.
- You should see: At least one field that should be an enum. Change it and see what your validation catches.
Exam traps
Concatenating retrieved content directly into the system prompt
It erases the line between what you authored and what arrived from outside, which is the precondition for indirect injection.
Treating the content boundary as a security control on its own
It makes injection containable and detectable. Stopping the action needs a permission boundary as well.
Sharing conversation context across users to save tokens
Cross-tenant state bleed is a disclosure, and in regulated domains a reportable one.
Typing constrained fields as free-form strings
A plausible wrong value passes validation and propagates. An enum turns the same deviation into an immediate error.