diff --git a/docs/property-assessor.md b/docs/property-assessor.md
index 3f9678c..b5d428d 100644
--- a/docs/property-assessor.md
+++ b/docs/property-assessor.md
@@ -220,11 +220,21 @@ Good:
 - `node har-photos.js "<url>"`
 - `scripts/property-assessor locate-public-records --address "..."`
 - `scripts/property-assessor render-report --input ... --output ...`
+- `web_fetch` to read an official CAD / assessor page when the TypeScript helper needs a plain page fetch
 
 Avoid when possible:
 
 - `node -e "..."`
 - `node --input-type=module -e "..."`
+- `python3 - <<'PY' ... PY`
+- `python -c "..."`
+- raw `bash -lc '...'` or `zsh -lc '...'` probes for CAD / public-record lookup
+
+Reason:
+
+- OpenClaw exec approvals are path-based, and inline shell / interpreter forms are treated conservatively in allowlist mode.
+- For `property-assessor`, CAD and public-record lookup should stay on the skill’s file-based TypeScript helper path or use `web_fetch`.
+- If the workflow drifts into an ad hoc shell snippet, that is not the approved skill path and can still trigger Control UI approval prompts.
 
 ## PDF report template
 
diff --git a/skills/property-assessor/SKILL.md b/skills/property-assessor/SKILL.md
index 1cd8bf1..1f3ce13 100644
--- a/skills/property-assessor/SKILL.md
+++ b/skills/property-assessor/SKILL.md
@@ -46,6 +46,8 @@ Rules:
 - Avoid fragile interactive gallery flows if they are likely to require approval or bounce the user into Control UI.
 - If a richer photo pass would require approval, do not silently force that path first. Continue with the best approval-free workflow available and clearly lower confidence if needed.
 - Only escalate to approval-heavy browser interaction when there is no reasonable alternative and the extra fidelity materially changes the assessment.
+- Do **not** use ad hoc shell snippets, heredocs, or inline interpreter eval for public-record or CAD lookup from chat. Avoid forms like `python3 - <<'PY'`, `python -c`, `node -e`, `node --input-type=module -e`, or raw `bash -lc '...'` probes.
+- For public-record enrichment, use `scripts/property-assessor locate-public-records`, `scripts/property-assessor assess`, or `web_fetch`. If a one-off fetch helper is truly needed, add a file-based helper under the skill tree first and run that file-based entrypoint instead of inline code.
 
 ## Source order
 
@@ -106,6 +108,12 @@ Default approach:
 4. use the official public-record site as a primary-source check against listing data
 5. link the official jurisdiction page and any direct property page used in the final result
 
+Approval-safe rule:
+- do not perform CAD/public-record discovery with inline shell or interpreter snippets
+- use the built-in TypeScript helper path first
+- if the official site needs a plain page fetch, prefer `web_fetch`
+- if rendered interaction is unavoidable, use a file-based `web-automation` helper rather than ad hoc shell text
+
 Use the helper CLI first:
 
 ```bash
@@ -141,6 +149,7 @@ Important rules:
 - parcel/APN/account identifiers from Zillow/HAR/Redfin are much stronger keys than listing geo IDs
 - if a direct public-record property page is available, use its data in the assessment and link it explicitly
 - if the jurisdiction can be identified but the property detail page is not directly retrievable, still link the official jurisdiction page and say what could not be confirmed
+- a host approval prompt triggered by an ad hoc shell snippet is workflow drift; return to `locate-public-records`, `assess`, `web_fetch`, or a file-based helper instead of approving the inline probe by default
 
 ### Texas rule