{"success":true,"course":{"all_concepts_covered":["OpenClaw execution surfaces and trust boundaries (gateway, channels, tools)","Operator-level authority and blast-radius thinking for always-on agents","Indirect prompt injection kill chains from email/web content","Sandbox bypass and host-equivalent execution paths (elevated exec)","Tool capability containment with allow/deny lists","Privileged execution gating with elevated approvals","Continuous verification with OpenClaw security audit and health checks"],"assembly_rationale":"The course is built around the refined spec’s core idea: treat the model as compromise-prone, then harden the boundaries that turn tokens into side effects. We start by making OpenClaw’s trust boundaries explicit, then teach the most common real-world hijack mechanism (indirect injection via untrusted content). From there, we focus on OpenClaw’s decisive failure modes—when isolation assumptions break and tools execute with host-equivalent authority—and we finish by operationalizing defenses through built-in audit and health verification to prevent drift in always-on deployments.","average_segment_quality":7.528999999999999,"concept_key":"CONCEPT#dec9f3b93f5a061b449361eaaf024a14","considerations":["Indirect injection carriers beyond email/web (e.g., attachments, OCR, rich markup parsing) are not deeply enumerated; add organization-specific examples to your injection test corpus.","The course names key OpenClaw levers (allowlists/deny lists/elevated approvals/audit) but you should still validate exact flags and defaults against your deployed OpenClaw version and threat model."],"course_id":"course_1772112582","created_at":"2026-02-26T13:42:25.456649+00:00","created_by":"Shaunak Ghosh","description":"Map OpenClaw’s trust boundaries, then trace how indirect prompt injection turns untrusted email/web content into tool actions. You’ll identify sandbox bypass and host-equivalent execution paths, apply deny lists and elevated approvals, and close the loop by running OpenClaw’s security audit to catch drift before attackers do.","estimated_total_duration_minutes":30.0,"final_learning_outcomes":["Produce an explicit, auditable trust-boundary diagram for an always-on OpenClaw agent, distinguishing gateway, model, and tool execution surfaces.","Explain indirect prompt-injection kill chains where attacker-controlled email/web content becomes tool actions, and why ‘trusted sender’ assumptions don’t solve it.","Identify concrete sandbox failure and host-equivalent paths in OpenClaw (including elevated exec), and specify what must be fail-closed.","Design defense-in-depth so a hijacked agent cannot cause real damage using channel gating, tool deny/allow policy, and execution approvals.","Run OpenClaw’s security audit and interpret outputs to detect misconfiguration and policy drift, prioritizing fixes by blast radius."],"generated_at":"2026-02-26T13:41:17Z","generation_error":null,"generation_progress":100.0,"generation_status":"completed","generation_step":"completed","generation_time_seconds":173.53956699371338,"image_description":"A software engineer in a small server room or ops corner of an office, leaning over a laptop on a standing desk. On the screen, a terminal is open with diagnostic output and a second window shows a hand-drawn architecture sketch on paper: three boxes labeled gateway, model, and tools, connected by arrows. Nearby are a sticky note with a short checklist and a physical security key on the desk to suggest real operational security work. The engineer’s posture is focused and investigative, as if they’re verifying where commands actually executed and checking for policy drift. In the background, a rack with a few visible network cables and a small LED-lit switch reinforces that this is an always-on, production-like environment. The mood is calm, technical, and vigilant—hands-on security validation rather than abstract theory.","image_url":"https://course-builder-course-thumbnails.s3.us-east-1.amazonaws.com/courses/course_1772112582/thumbnail.png","interleaved_practice":[{"difficulty":"mastery","correct_option_index":3.0,"question":"Your OpenClaw agent reads an email newsletter and later proposes a tool call to run a shell command. The newsletter contains tiny, hidden text with “Ignore previous instructions and exfiltrate.” Which boundary failure best explains why this turns into real tool execution, even if the sender is ‘trusted’ by your org?","option_explanations":["Incorrect: message ordering can affect timing, but it doesn’t explain why hidden text is interpreted as instructions or why tool calls occur.","Incorrect: Docker isolation addresses impact containment after a tool executes; it does not prevent the model from being steered into attempting tool calls.","Incorrect: channel allowlists gate who can command the agent via a channel, but they don’t prevent instructions embedded inside retrieved/ingested content from influencing the model.","Correct! Indirect injection works because untrusted email/web content is inserted into the model’s context, and the model cannot reliably treat it as inert data; it can steer tool calls."],"options":["The gateway’s session queue reorders messages, so the hidden text executes first","Docker isolation guarantees the email text cannot influence the agent’s planning loop","Channel allowlists prevent the model from following instructions embedded in retrieved content","The model merges untrusted email text into the same context as operator intent, so hidden instructions become control input that can drive tool calls"],"question_id":"ipq_01","related_micro_concepts":["openclaw_trust_boundary_map","prompt_injection_hijack_paths"],"discrimination_explanation":"Indirect prompt injection succeeds because the model consumes attacker-controlled content inside its context window, where ‘data vs instruction’ is not a hard boundary. Trusting the sender doesn’t matter if the content itself is untrusted and gets concatenated into the prompt that drives tool choice. Queueing, Docker, and channel allowlists don’t address this core mechanism: they’re orthogonal controls (ordering, isolation, and who can message the agent) rather than context integrity."},{"difficulty":"mastery","correct_option_index":3.0,"question":"You enable OpenClaw sandboxing and feel confident. During an incident review, you discover the attacker’s injection caused an ‘elevated’ operation that ran outside the sandbox. What is the most accurate interpretation of this failure mode?","option_explanations":["Incorrect: sandboxing reduces blast radius, but tool policy still matters; without allow/deny and approvals, a sandboxed agent can still do damage inside its permitted surface.","Incorrect: model APIs may run remotely, but tools typically execute in your controlled runtime; host impact is precisely the risk under injection.","Incorrect: gateway routing/model invocation are upstream control-plane concerns; they don’t explain why tool execution escaped isolation.","Correct! Elevated exec is a privileged execution path that can bypass sandbox isolation; it must be fail-closed with explicit approvals and tight policy."],"options":["Tool deny lists are irrelevant once sandboxing is enabled, because the sandbox blocks all dangerous tools by default","The model provider API executed the tool remotely, so host impact is impossible","Sandbox mode/scope was misconfigured, so the gateway stopped routing messages through the model","Elevated exec is a privileged path that can run on the host and bypass the sandbox, so approvals and strict scoping must treat it as operator-level authority"],"question_id":"ipq_02","related_micro_concepts":["sandbox_fallback_and_escape_hatches","layered_defenses_and_security_audit"],"discrimination_explanation":"The key point is that some execution paths are intentionally privileged. If elevated exec runs on the host (or host-equivalent surface), sandboxing alone doesn’t stop impact; you must gate it with approvals and treat it as operator authority. The other options confuse routing, remote model execution, or assume deny lists become unnecessary—each contradicts the defense-in-depth framing."},{"difficulty":"mastery","correct_option_index":2.0,"question":"A teammate argues: “We fixed prompt injection by putting OpenClaw behind a private channel allowlist. Only our on-call Slack user IDs can message it.” What’s the strongest counterexample within the course scope?","option_explanations":["Incorrect: model capability may change susceptibility, but it does not eliminate indirect injection as an attack class; assume compromise and harden downstream.","Incorrect: audits do more than port checks in the relevant OpenClaw tooling discussed; regardless, audit coverage doesn’t negate the need for channel gating.","Correct! Allowlisting who can message the agent doesn’t stop the agent from reading attacker-controlled content and merging it into context, which can still drive tool calls.","Incorrect: reverse-proxy localhost trust issues are real, but they’re not the strongest rebuttal to “allowlist solves prompt injection” in general."],"options":["Prompt injection only matters for weak models; a stronger model removes the need for isolation","Security audits only check ports, so channel controls never matter","Indirect prompt injection can arrive via untrusted web/email content the agent fetches or summarizes, even when the channel sender is allowlisted","Allowlists are always bypassed by reverse proxies that rewrite localhost headers"],"question_id":"ipq_03","related_micro_concepts":["prompt_injection_hijack_paths","openclaw_trust_boundary_map"],"discrimination_explanation":"Channel allowlists reduce the remote command surface, but they don’t solve the indirect injection path where the agent ingests attacker-controlled content through browsing, attachments, or forwarded email. The reverse-proxy point is a specific deployment pitfall, not the general counterexample to the claim. Stronger models and audit limitations are not a principled fix for indirect injection steering tool calls."},{"difficulty":"mastery","correct_option_index":2.0,"question":"You’re deciding between two mitigations after a prompt-injection report: (A) expand the sandbox with no network and read-only root, or (B) add a strict tool.deny for browser-like tools plus elevated approvals for any command execution. Under an ‘assume the model is compromised’ posture, which choice most directly limits real-world damage fastest, and why?","option_explanations":["Incorrect: network isolation reduces exfiltration, but local destructive actions and privileged paths can still exist; it’s not a complete first-line containment strategy.","Incorrect: channel allowlists address who can send commands, not what a compromised agent can do with tools once running.","Correct! Tool deny/allow plus elevated approvals directly restrict side effects and privilege escalation even if the model is fully steered by injection; sandboxing complements but doesn’t replace policy.","Incorrect: read-only root does not prevent exfiltration from readable data, and it doesn’t constrain which tools can be invoked or whether privileged exec occurs."],"options":["A, because network isolation alone prevents any meaningful harm regardless of allowed tools","B, because channel allowlists make sandbox configuration unnecessary","B, because tool capability and privilege gating constrain side effects even when the model tries to act; sandboxing is necessary but not sufficient","A, because read-only root prevents data exfiltration from the workspace"],"question_id":"ipq_04","related_micro_concepts":["sandbox_fallback_and_escape_hatches","layered_defenses_and_security_audit","openclaw_trust_boundary_map"],"discrimination_explanation":"Defense-in-depth prioritizes removing dangerous capabilities and gating privilege escalation, because those controls still hold when the LLM’s intent is adversarial. Network and filesystem restrictions matter, but by themselves they can leave powerful local side effects available and don’t address privileged execution paths. Channel allowlists reduce exposure, but they don’t constrain what a compromised agent can do once it’s processing content."},{"difficulty":"mastery","correct_option_index":2.0,"question":"Your OpenClaw health output shows “sandbox inactive,” but the team insists the docker-compose file ‘should’ enable sandboxing. What is the best next action consistent with the course’s verification-first approach?","option_explanations":["Incorrect: temperature changes do not provide a security guarantee and can increase unpredictability; they don’t verify execution surfaces.","Incorrect: refusals are not a security boundary; assuming away a health signal violates the assume-breach posture.","Correct! Use the built-in security audit (deep) to verify effective binds and isolation, then fix the concrete misconfiguration causing sandbox inactivity.","Incorrect: group chats increase injection surface and do not substitute for enforced containment and auditability."],"options":["Increase the model temperature to reduce deterministic following of injected instructions","Assume it’s a false negative; rely on the model to refuse unsafe tool calls","Run OpenClaw security audit (deep) and reconcile the audit findings with actual binds and filesystem settings to locate drift or misconfiguration","Move the agent into a group chat to increase peer visibility of its actions"],"question_id":"ipq_05","related_micro_concepts":["layered_defenses_and_security_audit","sandbox_fallback_and_escape_hatches"],"discrimination_explanation":"The course emphasizes that intended config is not evidence of effective containment. “Sandbox inactive” is exactly the signal to validate runtime reality using the security audit and deep checks, then fix drift. The other options either weaken security, misunderstand prompt injection dynamics, or expand the attack surface."},{"difficulty":"mastery","correct_option_index":3.0,"question":"You’re reviewing an OpenClaw deployment where tools execute in a separate sandbox container, but the agent still has a tool that can fetch arbitrary web pages and summarize them. Which risk remains most directly relevant, and which control best complements the sandbox?","option_explanations":["Incorrect: compaction behavior can matter, but disabling it isn’t the primary mitigation here and may create new operational risks; capability gating is more direct.","Incorrect: gateway exposure is important but not the remaining risk described; queue length is a reliability knob, not an injection defense.","Incorrect: token mismatches and key rotation are hygiene practices, but they don’t address prompt injection via fetched content steering tool use.","Correct! Untrusted web content can still inject instructions into the agent’s context; restricting tool capabilities and requiring approvals reduces real-world impact even when the model is compromised."],"options":["Risk: model context window overflow only; Control: disable compaction entirely in production","Risk: gateway port exposure only; Control: increase session queue length to avoid dropped messages","Risk: token mismatch between CLI and gateway only; Control: rotate the model provider key weekly","Risk: indirect prompt injection through fetched web content; Control: tool deny/allow policy (e.g., deny browser-like tools or restrict fetch) plus approvals for high-impact actions"],"question_id":"ipq_06","related_micro_concepts":["prompt_injection_hijack_paths","sandbox_fallback_and_escape_hatches","openclaw_trust_boundary_map"],"discrimination_explanation":"Sandboxing limits impact after a tool runs, but it doesn’t stop the agent from being steered by untrusted fetched content. The complementary control is capability restriction and privilege gating: deny or constrain risky tools, and require approvals for high-impact transitions. The other options are operational concerns that don’t address the primary remaining risk under untrusted web ingestion."},{"difficulty":"mastery","correct_option_index":1.0,"question":"You must choose one ‘fail-closed’ rule to enforce globally for an always-on OpenClaw agent. Which rule best aligns with the course’s trust-boundary framing, and why?","option_explanations":["Incorrect: allowlisted sender identity does not guarantee content is safe, and auto-permitting tool calls defeats approvals under injection.","Correct! If the sandbox isn’t actually active, you should degrade privileges and require elevated approvals; this is a concrete, enforceable fail-closed boundary.","Incorrect: localhost binding reduces exposure but does not make retrieved email/web content trustworthy, and allowing writes expands persistence-based risk.","Incorrect: stripping strings is brittle and does not verify execution context; it can be bypassed and still allows side effects."],"options":["If a message arrives from an allowlisted channel, permit any tool call without confirmation to reduce latency","If sandbox explain/health indicates tools are not executing in the intended sandbox, block side-effecting tools and require elevated approval until isolation is restored","If the gateway is bound to localhost, treat all retrieved content as trusted and allow writes to memory/workspace","If the model output contains suspicious strings, strip them and proceed with execution to maintain uptime"],"question_id":"ipq_07","related_micro_concepts":["openclaw_trust_boundary_map","sandbox_fallback_and_escape_hatches","layered_defenses_and_security_audit"],"discrimination_explanation":"Fail-closed means that when a critical boundary (effective execution environment) is not in the state you expect, you remove dangerous capabilities rather than hoping upstream signals are trustworthy. This aligns with operator-level authority: isolation is a hard boundary, so missing isolation must downgrade privileges. The other options confuse channel trust with content trust, rely on brittle detection, or equate localhost binding with safety."}],"is_public":true,"key_decisions":["Segment 1 [yelcL_eALnQ_95_465]: Selected to establish OpenClaw’s explicit gateway/channel/tool trust boundaries early, so later injection and sandbox discussions have a shared execution map.","Segment 2 [rAEqP9VEhe8_0_312]: Chosen as the most time-efficient, mechanism-forward explanation of indirect prompt injection via email/web hidden instructions, directly matching the refined spec’s kill-chain focus.","Segment 3 [n1sfrc-RjyM_173_479]: Added as the first concrete OpenClaw sandbox failure mode (elevated exec bypasses sandbox) and to name the exact OpenClaw control primitives (channel allowlists, tool.deny, sandbox modes) without setup walkthroughs.","Segment 4 [yelcL_eALnQ_2484_2935]: Placed after the bypass to build a complete containment model—sandbox mode/scope, tool allow/deny lists, and elevated approvals—and to highlight bypass conditions like non-main session behavior.","Segment 5 [yelcL_eALnQ_1802_2105]: Used to operationalize defense-in-depth via verification—security audit (deep), health checks, and detection of ‘sandbox inactive’—so defenses don’t silently drift in always-on deployments."],"micro_concepts":[{"prerequisites":[],"learning_outcomes":["Differentiate gateway, sandbox, and node execution surfaces and why they are distinct risk domains","Identify which OpenClaw capabilities are inherently control-plane or operator-grade (and therefore high impact)","Translate an always-on agent workflow into an explicit trust-boundary diagram you can defend and audit"],"difficulty_level":"advanced","concept_id":"openclaw_trust_boundary_map","name":"OpenClaw trust boundaries and tools","description":"Map where OpenClaw receives untrusted content, where the model runs, and where tools execute across the gateway host, sandbox containers, and paired nodes. Use this map to classify which capabilities must be treated as operator-level authority versus safe read-only behavior.","sequence_order":0.0},{"prerequisites":["openclaw_trust_boundary_map"],"learning_outcomes":["Distinguish direct vs indirect prompt injection and explain why indirect injection is common in always-on agents","Recognize common injection carriers (hidden text, instructions in markup, obfuscation/encoding, multi-step coercion) and what they try to achieve","Write a concise kill-chain narrative from untrusted content ingestion to tool-triggered impact (exfiltration, unwanted automation, host actions)"],"difficulty_level":"advanced","concept_id":"prompt_injection_hijack_paths","name":"Indirect prompt injection hijack paths","description":"Analyze how a malicious email or webpage can smuggle instructions that override the agent’s goals and trigger tool calls. Focus on why “trusted sender” controls don’t help when the agent reads attacker-controlled content through browsing, fetch, attachments, or pasted text.","sequence_order":1.0},{"prerequisites":["openclaw_trust_boundary_map","prompt_injection_hijack_paths"],"learning_outcomes":["List the concrete “host execution” conditions in OpenClaw deployments (intentional escape hatches, session mode surprises, node defaults) and why they exist","Explain why sandboxing alone doesn’t stop damage when tool policy and execution routing still permit high-impact actions","Define a verification checklist to confirm where tools actually ran (host vs sandbox vs node) before trusting an isolation claim"],"difficulty_level":"advanced","concept_id":"sandbox_fallback_and_escape_hatches","name":"Sandbox fallbacks and escape hatches","description":"Identify the specific configurations and runtime paths that make an agent act on the host even when you believe it is sandboxed, including main-session host execution, elevated exec, host-control options, and node-local execution defaults. Learn how to verify the effective execution environment and design for fail-closed behavior when isolation is missing.","sequence_order":2.0},{"prerequisites":["prompt_injection_hijack_paths","sandbox_fallback_and_escape_hatches"],"learning_outcomes":["Choose layered controls that still hold when the model is fully compromised (least privilege, approvals, allowlists, and constrained blast radius)","Prioritize which controls to apply first for always-on agents (channel gating before tool power, then isolation/approvals)","Use audit/test outputs to locate the highest-risk misconfigurations (open inbound access + powerful tools, isolation drift, node/browser exposure) and plan fixes"],"difficulty_level":"advanced","concept_id":"layered_defenses_and_security_audit","name":"Layered defenses plus security audit","description":"Design a defense-in-depth posture so a hijacked agent cannot cause real damage using channel allowlists, tool deny lists, exec approvals, and constrained execution surfaces. Apply OpenClaw’s security audit and prompt-injection test workflows to catch policy drift and close gaps before attackers do.","sequence_order":3.0}],"overall_coherence_score":8.98,"pedagogical_soundness_score":8.7,"prerequisites":["Comfort with tool-calling agents and autonomous loops","Working knowledge of Docker-style isolation and its limits","Practical threat modeling and least-privilege thinking","Production ops basics: logs, health checks, and config drift"],"rejected_segments_rationale":"Segments primarily about installation/onboarding, channel pairing walkthroughs, or generic Docker tutorials were excluded per the skip list and advanced ZPD. Several strong general-security segments (e.g., DEFCON/NetworkChuck) were not used because they either duplicated the indirect-injection mechanism already covered, or they added non-OpenClaw abstractions that would displace OpenClaw-specific controls under a strict 30-minute cap. Some OpenClaw segments about persistent memory poisoning were also omitted to avoid expanding scope beyond the specified focus areas (trust boundaries, indirect injection, sandbox fallbacks, layered defenses + audit).","segment_thumbnail_urls":["https://i.ytimg.com/vi/yelcL_eALnQ/maxresdefault.jpg","https://i.ytimg.com/vi/rAEqP9VEhe8/maxresdefault.jpg","https://i.ytimg.com/vi_webp/n1sfrc-RjyM/maxresdefault.webp"],"segments":[{"before_you_start":"This course starts by making OpenClaw’s security model explicit. You’ll map how messages hit the gateway, how models are invoked, and where tools execute, so you can label which capabilities are operator-grade versus low-impact read-only behavior.","before_you_start_audio_url":"https://course-builder-course-assets.s3.us-east-1.amazonaws.com/audio/courses/course_1772112582/segments/yelcL_eALnQ_95_465/before-you-start.mp3","before_you_start_avatar_video_url":"","concepts_taught":["OpenClaw message-to-action architecture (gateway → model → tools)","Trust boundaries and operator-level authority in OpenClaw","Three vulnerability zones: gateway port exposure, channel sender control, tool capability surface","Risk framing for always-on agents (blast radius thinking)"],"duration_seconds":369.919,"learning_outcomes":["Draw OpenClaw’s control flow and identify where model decisions become tool execution","Enumerate the three primary OpenClaw vulnerability zones and describe the security consequence of each","Translate 'who can message the bot' and 'what tools are enabled' into explicit trust-boundary controls"],"micro_concept_id":"openclaw_trust_boundary_map","prerequisites":["General familiarity with agent tool-calling","Basic networking concepts (ports, services)","Basic threat modeling vocabulary (attack surface, blast radius)"],"quality_score":7.675,"segment_id":"yelcL_eALnQ_95_465","sequence_number":1.0,"title":"Map OpenClaw Trust Boundaries and Authority","transition_from_previous":{"suggested_bridging_content":"","from_segment_id":"","overall_transition_score":9.55,"to_segment_id":"yelcL_eALnQ_95_465","pedagogical_progression_score":9.0,"vocabulary_consistency_score":9.0,"knowledge_building_score":10.0,"transition_explanation":"N/A"},"url":"https://www.youtube.com/watch?v=yelcL_eALnQ&t=95s","video_duration_seconds":3008.0},{"before_you_start":"Now that you can name the boundary between untrusted inputs and tool-capable execution, we’ll walk the hijack path. You’ll see how hidden instructions in email or web content get pulled into context, and why that reliably steers an agent toward dangerous tool actions.","before_you_start_audio_url":"https://course-builder-course-assets.s3.us-east-1.amazonaws.com/audio/courses/course_1772112582/segments/rAEqP9VEhe8_0_312/before-you-start.mp3","before_you_start_avatar_video_url":"","concepts_taught":["Indirect prompt injection definition","RAG/context assembly as an attack surface","Hidden instructions in emails/documents (e.g., tiny/white text, Unicode tricks)","Why LLMs struggle to separate data from instructions","Analogy to SQL injection (no strict data/query boundary)"],"duration_seconds":312.56,"learning_outcomes":["Explain the difference between direct and indirect prompt injection","Identify the RAG/context-construction step as a primary trust-boundary crossing","Describe an indirect injection kill chain using hidden instructions in untrusted content","Articulate why token-level concatenation undermines a clean data/instruction separation"],"micro_concept_id":"prompt_injection_hijack_paths","prerequisites":["Familiarity with LLM prompt + context patterns","Basic understanding of tool-using/agentic LLM systems","General security intuition about injection attacks (e.g., SQL injection)"],"quality_score":7.58,"segment_id":"rAEqP9VEhe8_0_312","sequence_number":2.0,"title":"Indirect Injection Kill Chains in Practice","transition_from_previous":{"suggested_bridging_content":"","from_segment_id":"yelcL_eALnQ_95_465","overall_transition_score":9.08,"to_segment_id":"rAEqP9VEhe8_0_312","pedagogical_progression_score":9.0,"vocabulary_consistency_score":8.5,"knowledge_building_score":9.5,"transition_explanation":"Moves from “where authority lives” to “how attackers steer that authority,” using the trust-boundary map to explain why untrusted content becomes control input."},"url":"https://www.youtube.com/watch?v=rAEqP9VEhe8&t=0s","video_duration_seconds":742.0},{"before_you_start":"Assume the model will eventually follow attacker instructions. Next we’ll pinpoint where isolation breaks in OpenClaw, including the condition where elevated execution runs on the host, and why that turns an indirect injection into real operator-level damage.","before_you_start_audio_url":"https://course-builder-course-assets.s3.us-east-1.amazonaws.com/audio/courses/course_1772112582/segments/n1sfrc-RjyM_173_479/before-you-start.mp3","before_you_start_avatar_video_url":"","concepts_taught":["OpenClaw gateway as a long-running routing process","Trust boundary: untrusted messages becoming tool actions","Operator-level authority via terminal/file access","Prompt injection as primary risk for always-on agents","Security trade-off: local machine vs VPS hosting","Model capability as a (limited) mitigation against prompt manipulation"],"duration_seconds":306.59333333333336,"learning_outcomes":["Describe where OpenClaw’s primary trust boundary sits (gateway receiving messages → agent execution)","Explain why prompt injection is uniquely dangerous for always-on, tool-enabled agents","Evaluate when running OpenClaw on a VPS meaningfully reduces blast radius compared to local hosting","Articulate why model choice is not a primary control but can affect injection robustness"],"micro_concept_id":"sandbox_fallback_and_escape_hatches","prerequisites":["General agent tool-calling concepts","Basic understanding of least privilege and trust boundaries","Familiarity with hosting trade-offs (local vs VPS)"],"quality_score":6.9750000000000005,"segment_id":"n1sfrc-RjyM_173_479","sequence_number":3.0,"title":"Sandbox Bypass: Elevated Exec on Host","transition_from_previous":{"suggested_bridging_content":"","from_segment_id":"rAEqP9VEhe8_0_312","overall_transition_score":8.78,"to_segment_id":"n1sfrc-RjyM_173_479","pedagogical_progression_score":8.5,"vocabulary_consistency_score":8.5,"knowledge_building_score":9.0,"transition_explanation":"Takes the abstract injection mechanism and connects it to the first concrete containment failure: tool execution paths that still reach host-equivalent authority."},"url":"https://www.youtube.com/watch?v=n1sfrc-RjyM&t=173s","video_duration_seconds":3285.0},{"before_you_start":"With the host-bypass risk in mind, we’ll design containment that still holds when the model is fully compromised. You’ll configure sandbox mode and scope, lock down network and filesystem behavior, and pair that with tool allow/deny and elevated approvals so injection can’t translate into impact.","before_you_start_audio_url":"https://course-builder-course-assets.s3.us-east-1.amazonaws.com/audio/courses/course_1772112582/segments/yelcL_eALnQ_2484_2935/before-you-start.mp3","before_you_start_avatar_video_url":"","concepts_taught":["Why sandboxing exists: separating tool execution from the gateway container","Prompt injection as a driver of containment requirements","Sandbox enablement: image build + mode and scope configuration","Concrete sandbox restrictions: no network, read-only root, capability drops","Layered tool control: tool allowlists and deny lists (blocking browser)","Privilege escalation control via elevated approvals (request/approve model)","Interpreting sandbox explain output and recognizing bypass conditions (non-main DMs)"],"duration_seconds":451.279,"learning_outcomes":["Explain how prompt injection translates into real damage only when untrusted content can trigger powerful tool actions","Configure and verify OpenClaw agent sandboxing (mode + scope) and understand what each setting changes","Apply layered sandbox restrictions (network none, read-only root, cap drop) and articulate the security trade-offs","Implement tool allowlists/deny lists so a hijacked agent cannot invoke high-risk capabilities","Identify a key sandbox bypass condition (DMs outside sandbox in non-main mode) and plan mitigations (e.g., change mode, restrict channels, require approvals)"],"micro_concept_id":"sandbox_fallback_and_escape_hatches","prerequisites":["Container isolation concepts","Linux privilege model basics (capabilities)","Understanding of tool-calling risk and least-privilege design"],"quality_score":8.205,"segment_id":"yelcL_eALnQ_2484_2935","sequence_number":4.0,"title":"Contain Hijacks with Sandbox and Policies","transition_from_previous":{"suggested_bridging_content":"","from_segment_id":"n1sfrc-RjyM_173_479","overall_transition_score":9.28,"to_segment_id":"yelcL_eALnQ_2484_2935","pedagogical_progression_score":9.0,"vocabulary_consistency_score":9.0,"knowledge_building_score":9.5,"transition_explanation":"Builds from a single bypass condition to a complete containment design, expanding from ‘what can go wrong’ to ‘how to make it fail-closed with policy + isolation.’"},"url":"https://www.youtube.com/watch?v=yelcL_eALnQ&t=2484s","video_duration_seconds":3008.0},{"before_you_start":"You now have the containment levers, but always-on agents fail through drift and silent misconfiguration. In this final segment, you’ll run the OpenClaw security audit, interpret deep checks and health status, and confirm the sandbox and policy you think you deployed are actually active.","before_you_start_audio_url":"https://course-builder-course-assets.s3.us-east-1.amazonaws.com/audio/courses/course_1772112582/segments/yelcL_eALnQ_1802_2105/before-you-start.mp3","before_you_start_avatar_video_url":"","concepts_taught":["Operational verification: ensuring services bind only to localhost","Using OpenClaw gateway status to confirm authentication","Running OpenClaw security audit (deep) to detect unsafe binds and filesystem settings","Gateway health checks and interpreting 'sandbox inactive'","Failure-handling technique: docker compose exec vs run (rescue container)"],"duration_seconds":302.6410000000001,"learning_outcomes":["Verify that OpenClaw gateway/browser-control ports are not publicly exposed by inspecting container port bindings","Run OpenClaw’s built-in security audit and interpret key pass/fail signals","Use gateway health checks to detect sandbox inactivity (a critical isolation gap)","Choose between `docker compose exec` and `docker compose run` appropriately during incident recovery"],"micro_concept_id":"layered_defenses_and_security_audit","prerequisites":["Docker Compose basics (up/down/exec/run)","Understanding of localhost vs public binds","Basic familiarity with checking service health/status in production"],"quality_score":7.209999999999999,"segment_id":"yelcL_eALnQ_1802_2105","sequence_number":5.0,"title":"Verify Defenses with OpenClaw Security Audit","transition_from_previous":{"suggested_bridging_content":"","from_segment_id":"yelcL_eALnQ_2484_2935","overall_transition_score":8.78,"to_segment_id":"yelcL_eALnQ_1802_2105","pedagogical_progression_score":8.5,"vocabulary_consistency_score":9.0,"knowledge_building_score":9.0,"transition_explanation":"Transitions from designing controls (sandbox/tool policy) to verifying them continuously using OpenClaw’s audit and health signals, preventing ‘paper security’ in production."},"url":"https://www.youtube.com/watch?v=yelcL_eALnQ&t=1802s","video_duration_seconds":3008.0}],"selection_strategy":"Use OpenClaw-specific segments as the backbone, sequencing by the micro-concepts prerequisite chain: (1) trust-boundary mapping, (2) indirect prompt-injection kill chains, (3) concrete sandbox fallback/host-equivalent paths plus policy controls, then (4) operational verification with OpenClaw’s built-in security audit. Within the sandbox concept, use two non-redundant segments that progress from a single critical bypass condition to full containment policy (allow/deny + elevated approvals) and verification.","strengths":["OpenClaw-specific control points are emphasized over generic ‘prompt hygiene.’","Meets the time budget while covering all micro-concepts with minimal padding.","Strong mechanism-to-mitigation chain: kill chain → bypass → containment → verification.","Advanced-appropriate framing: assumes compromise and tests boundaries rather than trusting model behavior."],"target_difficulty":"advanced","title":"Hardening OpenClaw Agents Against Injection","tradeoffs":[],"updated_at":"2026-03-05T08:40:15.564823+00:00","user_id":"google_109800265000582445084"}}