Lesson 1 of 7 · 0%Threat-model the deployment you actually runNext
Course map

Security Hardening and Threat Boundaries

0 of 7 complete0 of 7

Lesson 1.1 · 45 minutes

Threat-model the deployment you actually run

Turn an OpenClaw deployment into an accountable boundary map before choosing controls.

Skip course map
Current lessonThreat-model the deployment you actually run0% complete · 0/7 lessons

Security Hardening and Threat Boundaries

0% complete · Current: Threat-model the deployment you actually run

Verifiedon 2026.7.1

Action boundary

Before you act

Expected result
A reviewed one-page boundary map names assets, identities, ingress paths, and control owners.
Failure mode
A generic threat list omits the actual channel, host, tools, or credential stores.
Rollback
Make no runtime change; mark uncertain facts for verification with the deployment owner.

Start with a boundary map, not a checklist

An agent deployment joins identities, message sources, model context, tools, files, network services, and credentials. Treat each crossing as a decision point. The OpenClaw security and network-model docs are the product receipts for the current gateway boundary; this lesson turns them into a local review record rather than assuming a default is safe.

Learner artifact

Draw five boxes: people and channels, gateway, agent workspace, tools/services, and secret stores. Add arrows for every inbound message, approval, tool request, outbound action, and log export. Label each arrow with identity, data class, and enforcement point. Annotate unknown arrows in amber; they are findings, not blanks to ignore.

Lab — build the canvas

  1. List assets worth protecting: channel accounts, credentials, private files, host access, recipient trust, and audit records.
  2. Name actors: administrator, operator, trusted sender, untrusted sender, model provider, plugin author, and host attacker.
  3. For each arrow, ask: who can initiate it, what input is untrusted, what authority is available, and what happens if it is wrong?
  4. Record the three highest-impact paths. For each, assign one preventive control, one detection signal, an owner, and a review date.

Do not score a path “low risk” merely because a sender is familiar. A compromised trusted account and a poisoned document can enter through trusted-looking routes.

Checkpoint

Which is the strongest finding?

  • A. “Prompt injection exists.”
  • B. “The gateway is important.”
  • C. “A message from the support channel can reach a file-writing tool with the operator’s credential and no approval.”

Answer: C. It names a reachable path, an authority, and a missing boundary that can be tested.

Evidence to retain

Save the canvas, a table of assumptions, and screenshots only of redacted configuration or topology. Never paste credentials into the dossier. Stop the lab if you cannot identify an owner for an exposed path; escalation is the correct result.

Source provenanceVerification and sources

Review receipt rr_security_threat_model

Outcome
approved
Method
source-review
Reviewer
academy-security-source-review
Reviewed

Evidence

Limitations

  • Approval covers the bounded 2026.7.1 learning exercises and cited security guidance; operators must validate controls against their own deployment and use disposable credentials in labs.

Open the public evidence snapshot

Lesson checkpoint

Ready to move on?

Mark this lesson complete when you can apply its outcome without relying on the examples above.