<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									Threat Model Templates and Examples - openclawsecurity.net Forum				            </title>
            <link>https://openclawsecurity.net/community/openclaw-threat-model-templates/</link>
            <description>openclawsecurity.net Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Tue, 30 Jun 2026 13:14:04 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Has anyone tried applying the SAFECode practices to OpenClaw deployments?</title>
                        <link>https://openclawsecurity.net/community/openclaw-threat-model-templates/has-anyone-tried-applying-the-safecode-practices-to-openclaw-deployments/</link>
                        <pubDate>Tue, 30 Jun 2026 08:00:07 +0000</pubDate>
                        <description><![CDATA[Hey everyone! I&#039;ve been digging into the SAFECode &quot;Practical Security Stories and Security Tasks for Agile Development&quot; paper, trying to see how it could map onto our local OpenClaw setups. ...]]></description>
                        <content:encoded><![CDATA[Hey everyone! I've been digging into the SAFECode "Practical Security Stories and Security Tasks for Agile Development" paper, trying to see how it could map onto our local OpenClaw setups. It's all about weaving security into the dev lifecycle with user stories and concrete tasks, which feels like a great fit for avoiding the "security as an afterthought" trap I keep falling into &#x1f605;

Most of the examples in the paper are for traditional web apps, so I'm trying to translate. For instance, one of their core stories is "As a developer, I want to ensure that user-supplied data cannot be interpreted as code by the system." For us, that's not just about web forms—it's **prompt injection** against the LLM, **malicious model files** in Hugging Face, or even unsafe instructions in a Docker Compose build context. The "security task" would be to implement input validation and sanitization for prompts and to verify model hashes.

Here's a super basic example of how I'm starting to think about it for my `docker-compose.yml`:

```yaml
# Security Task: Isolate the inference service from host and other services
services:
  openclaw-nano:
    image: openclaw/nano_claw:latest
    container_name: nano-inference
    # Use a read-only root filesystem where possible
    read_only: true
    # Limit capabilities
    cap_drop:
      - ALL
    networks:
      - internal-ai-net
    # Don't mount the model volume as read-write unless absolutely necessary
    volumes:
      - ./models:/app/models:ro
```

My question is: has anyone else tried applying this SAFECode story/task framework? I'm particularly stuck on how to write a good "security story" for the **supply chain risk** of pulling down a fine-tuned model from Hugging Face. The paper talks about third-party components, but a model isn't a library. What are the concrete, actionable "tasks" for that in a local deployment context?

I feel like if we could build a small library of these stories and tasks tailored for local AI, it would be a huge help for newcomers like me trying to do things right from the start.

- ella]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-threat-model-templates/">Threat Model Templates and Examples</category>                        <dc:creator>Ella Local</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-threat-model-templates/has-anyone-tried-applying-the-safecode-practices-to-openclaw-deployments/</guid>
                    </item>
				                    <item>
                        <title>Help: how to model threats from other agents in a shared workspace?</title>
                        <link>https://openclawsecurity.net/community/openclaw-threat-model-templates/help-how-to-model-threats-from-other-agents-in-a-shared-workspace/</link>
                        <pubDate>Sun, 28 Jun 2026 10:00:14 +0000</pubDate>
                        <description><![CDATA[I&#039;m setting up a multi-agent system for a customer support pipeline. All agents live in the same environment and can access a shared workspace for documents and task status.

I&#039;m trying to d...]]></description>
                        <content:encoded><![CDATA[I'm setting up a multi-agent system for a customer support pipeline. All agents live in the same environment and can access a shared workspace for documents and task status.

I'm trying to do a threat model for this, but the templates I find mostly focus on external users attacking the system. My worry is internal: what can a compromised or malicious agent do to the other agents?

*   Can one agent poison the data another agent uses?
*   Could a prompt injection against Agent A make it attack Agent B's process?
*   How do you even draw the trust boundaries in a data-flow diagram for this?

I'm specifically thinking about shell_injection risks and how an agent with tool access could escalate. Are there example STRIDE diagrams for inter-agent threats?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-threat-model-templates/">Threat Model Templates and Examples</category>                        <dc:creator>Ivy N.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-threat-model-templates/help-how-to-model-threats-from-other-agents-in-a-shared-workspace/</guid>
                    </item>
				                    <item>
                        <title>Breaking: new release of OpenClaw has a &#039;security context&#039; feature. Implications?</title>
                        <link>https://openclawsecurity.net/community/openclaw-threat-model-templates/breaking-new-release-of-openclaw-has-a-security-context-feature-implications/</link>
                        <pubDate>Sat, 27 Jun 2026 19:01:16 +0000</pubDate>
                        <description><![CDATA[Hey everyone, just saw the announcement for the new OpenClaw release. That &#039;security context&#039; feature has me both excited and a bit lost, honestly.

I&#039;ve been running OpenClaw locally for my...]]></description>
                        <content:encoded><![CDATA[Hey everyone, just saw the announcement for the new OpenClaw release. That 'security context' feature has me both excited and a bit lost, honestly.

I've been running OpenClaw locally for my LLM projects using Docker Compose, mostly following the basic guides. I get the general idea of isolation, but the new docs mention "defining trust boundaries" and "resource constraints per component" and my head starts spinning. &#x1f605;

Could someone walk through what this actually means for a simple, self-hosted setup? Like, if I have the main app, the Nemoclaw inference backend, and a database all in separate containers, how would I start applying these security contexts? Are we talking about a new config section in the `docker-compose.yml`, or is it more about the internal OpenClaw policy files?

Mainly, I'm trying to figure out if this is a must-use feature right away for privacy, or more of an advanced thing. Does it change the basic threat model templates you have here in this subforum? Thanks for any guidance.

thanks, Tom]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-threat-model-templates/">Threat Model Templates and Examples</category>                        <dc:creator>Tom Hardy</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-threat-model-templates/breaking-new-release-of-openclaw-has-a-security-context-feature-implications/</guid>
                    </item>
				                    <item>
                        <title>TIL: you can use MITRE ATT&amp;CK techniques to map post-exploitation for agents.</title>
                        <link>https://openclawsecurity.net/community/openclaw-threat-model-templates/til-you-can-use-mitre-attck-techniques-to-map-post-exploitation-for-agents/</link>
                        <pubDate>Fri, 26 Jun 2026 23:02:02 +0000</pubDate>
                        <description><![CDATA[A common oversight in our threat modeling for agent-based systems is an over-focus on initial compromise vectors (e.g., prompt injection, malformed plugin input) and a comparative neglect of...]]></description>
                        <content:encoded><![CDATA[A common oversight in our threat modeling for agent-based systems is an over-focus on initial compromise vectors (e.g., prompt injection, malformed plugin input) and a comparative neglect of the post-exploitation landscape. Once an adversary has established a foothold within an agent, either by compromising the agent process itself or by coercing it into performing malicious actions, their subsequent techniques can be systematically mapped using the MITRE ATT&amp;CK® framework. This provides a structured methodology for hardening our runtime environments and communication channels.

Consider a scenario where an attacker has achieved code execution within an agent's container. The subsequent tactics and techniques are highly relevant to our architectures:

*   **Persistence (TA0003):** An adversary may attempt to maintain their foothold across agent restarts or scaling events.
    *   **Technique T1543.003 (Create or Modify System Process: Windows Service)** is less likely, but **T1543 (Create or Modify System Process)** could manifest as modifying the agent's startup script or leveraging a compromised plugin to re-infect upon load.
    *   **Technique T1053.003 (Scheduled Task/Job: Cron)** could be used to install a cron job within the agent's container for callback or data exfiltration.

*   **Discovery (TA0007) &amp; Collection (TA0009):** The compromised agent will likely perform reconnaissance.
    *   **Technique T1613 (Container and Resource Discovery)** is critical: querying the Kubernetes API from within the pod to map the service mesh, identifying other agents, backend services, and data stores.
    *   **Technique T1552 (Unsecured Credentials):** Searching the filesystem for mounted Kubernetes service account tokens, secrets, or credentials in environment variables (a common pattern for database connections).

*   **Lateral Movement (TA0008):** Within a service mesh like Istio or Linkerd, this is a primary concern.
    *   **Technique T1570 (Lateral Tool Transfer):** Using the compromised agent as a hop point to transfer tools or payloads to other pods.
    *   **Technique T1210 (Exploitation of Remote Services):** The agent may be used to exploit vulnerabilities in adjacent gRPC services, leveraging the inherent mTLS trust. The agent's identity, if overly permissive, could grant access to sensitive APIs.

*   **Command and Control (TA0011):** Communication patterns are key.
    *   **Technique T1071 (Application Layer Protocol):** C2 traffic may blend with normal gRPC or HTTP/2 traffic to external plugin endpoints, attempting to evade simple rate-limiting or egress filters that are not application-aware.
    *   **Technique T1095 (Non-Application Layer Protocol)** could use raw sockets, but is more easily detected.

A practical application of this mapping is to inform our **Runtime Agent Hardening** checklist and **Service Mesh Authorization Policies**. For instance, knowing that `T1613` and `T1210` are viable post-exploitation paths, we must enforce strict Kubernetes RBAC on our agent service accounts and implement explicit `AuthorizationPolicy` rules in Istio to restrict agent-to-service communication to the minimal necessary set of gRPC methods.

```yaml
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: agent-to-backend-restrict
  namespace: agent-namespace
spec:
  selector:
    matchLabels:
      app: vulnerable-backend-service
  action: ALLOW
  rules:
  - from:
    - source:
        principals: 
    to:
    - operation:
        methods: 
        paths: 
```

This approach moves us beyond simplistic "prevent initial access" models and forces us to consider the kill chain *after* a breach. Our threat models should explicitly include a post-exploitation phase annotated with likely ATT&amp;CK techniques, which directly translates to more robust detective controls (e.g., logging agent calls to the Kubernetes API) and restrictive policies (network, identity, filesystem).

- Lei]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-threat-model-templates/">Threat Model Templates and Examples</category>                        <dc:creator>Lei Zhang</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-threat-model-templates/til-you-can-use-mitre-attck-techniques-to-map-post-exploitation-for-agents/</guid>
                    </item>
				                    <item>
                        <title>Just built a template for a financial analysis agent (high integrity needs).</title>
                        <link>https://openclawsecurity.net/community/openclaw-threat-model-templates/just-built-a-template-for-a-financial-analysis-agent-high-integrity-needs/</link>
                        <pubDate>Fri, 26 Jun 2026 15:00:07 +0000</pubDate>
                        <description><![CDATA[Built a template because I keep seeing the same mistakes with these &quot;high-integrity&quot; financial agents. Everyone focuses on the model, then slaps a basic auth on a Flask app and calls it secu...]]></description>
                        <content:encoded><![CDATA[Built a template because I keep seeing the same mistakes with these "high-integrity" financial agents. Everyone focuses on the model, then slaps a basic auth on a Flask app and calls it secure. That's not a threat model.

This template assumes:
* Agent ingests sensitive financial documents (PDFs, spreadsheets).
* Makes investment recommendations via an LLM.
* Output must be tamper-proof and non-repudiable.
* Deployed in a container, but with elevated privileges to access host data (that's the failure).

Key failure modes most templates ignore:
* **Data exfiltration via indirect prompt injection:** Attacker embeds malicious instructions in a source document. Template forces data flow diagrams to track untrusted data.
* **Container escape via mounted volumes:** The deployment pattern requires host mounts. Template includes seccomp/AppArmor rules that are actually restrictive.
* **Integrity of outputs:** No signing of recommendations. Template adds a mandatory signing step with a protected key.

Core of the template is the mitigation table for STRIDE per data flow element. Example for the "Document Parser" component:

```
Component: Document Parser (Processes uploaded files)
- Spoofing: Service account with defined roles only. No interactive logins.
- Tampering: Files processed in a tempfs mount, read-only after upload.
- Repudiation: All parsing actions logged to a secured, append-only audit trail.
- Information Disclosure: Parser runs with seccomp filter blocking network syscalls.
- Denial of Service: Memory limits (cgroups) and input file size caps.
- Elevation of Privilege: No SETUID binaries. Capabilities dropped: `docker run --cap-drop=ALL --cap-add=DAC_OVERRIDE` (minimum needed for file access).
```

The template is empty without your specific data flows. Fill it in, then we can tear it apart. The assumptions section is the most important part. If you assume the kernel is patched, write it down. If you assume the internal network is trusted, write it down so we can call you out on it later.

--segfault]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-threat-model-templates/">Threat Model Templates and Examples</category>                        <dc:creator>Sam &#039;Segfault&#039; Torres</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-threat-model-templates/just-built-a-template-for-a-financial-analysis-agent-high-integrity-needs/</guid>
                    </item>
				                    <item>
                        <title>Opinion: we should have a shared repo of vetted threat model templates.</title>
                        <link>https://openclawsecurity.net/community/openclaw-threat-model-templates/opinion-we-should-have-a-shared-repo-of-vetted-threat-model-templates/</link>
                        <pubDate>Fri, 26 Jun 2026 09:01:04 +0000</pubDate>
                        <description><![CDATA[The current proliferation of individual, ad-hoc threat models for similar OpenClaw deployment patterns is inefficient and introduces significant risk of oversight. While the principle of con...]]></description>
                        <content:encoded><![CDATA[The current proliferation of individual, ad-hoc threat models for similar OpenClaw deployment patterns is inefficient and introduces significant risk of oversight. While the principle of context-specific modeling is sound, the foundational components—trust boundaries, data flow diagrams, and standard STRIDE per-element analyses—are often reinvented with varying degrees of rigor. I propose we establish a shared, version-controlled repository of vetted threat model templates.

A template in this context would not be a mere blank diagram. It should be a fully realized example for a common scenario, such as "OpenClaw Scanner with CI/CD Integration" or "Central Policy Manager with Multiple Remote Agents." Each template must include, at minimum:

*   **Explicit Assumptions:** The security guarantees and trust relationships the model is built upon (e.g., "The build pipeline is treated as a trusted compute base," "All inter-service communication occurs over mutually authenticated TLS").
*   **Complete Data Flow Diagrams (DFDs):** Level 0 and Level 1 diagrams with clearly labeled processes, data stores, data flows, and trust boundaries.
*   **Structured Threat Analysis:** A STRIDE breakdown applied to each DFD element, with:
    *   Credible threat scenarios for each relevant STRIDE category.
    *   Documented mitigations corresponding to OpenClaw's control set.
    *   **Crucially, a list of known failure modes** for the depicted architecture (e.g., "If the SBOM cache is poisoned, policy decisions will be made on invalid data," "If the agent's pull interval is too long, vulnerability state may be stale").
*   **Justification for Out-of-Scope Items:** A clear rationale for elements explicitly excluded from the model.

This approach yields several concrete benefits:
*   **Consistency:** Provides a baseline for quality and completeness, making reviews more efficient.
*   **Onboarding:** Accelerates understanding of security considerations for new team members or adopters.
*   **Collective Improvement:** Templates become living documents; as new attack vectors or deployment variants are discovered, the community can update the canonical template via pull request, benefiting all downstream users.

For illustration, consider the skeleton of a template entry for a common component:

```yaml
template_id: oc_central_manager_v1.0
deployment_pattern: Centralized policy management with lightweight remote agents
assumptions:
  - Agent registration uses pre-shared credentials rotated via secure channel.
  - The central manager's database stores only policy metadata, not vulnerability data.
key_failure_modes:
  - AgentManager Heartbeat Loss: Agent may operate on cached, stale policy if channel is disrupted.
  - Manager DB Compromise: Attacker could disable or modify policy enforcement across all agents.
dfd_elements:
  - element: Agent Policy Cache (Data Store)
    stride_analysis:
      - spoofing: Mitigated by mutual TLS for cache refresh.
      - tampering: Cache integrity validated via signed manifests from manager.
      - information_disclosure: Cache holds only policy IDs, not sensitive data.
      - denial_of-service: Local cache prevents DoS from manager outage.
```

The next step would be to define a schema for these templates and establish a review process. I am prepared to contribute an initial set derived from our internal documentation. Thoughts on the required schema fields and governance model?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-threat-model-templates/">Threat Model Templates and Examples</category>                        <dc:creator>Nina Johansson</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-threat-model-templates/opinion-we-should-have-a-shared-repo-of-vetted-threat-model-templates/</guid>
                    </item>
				                    <item>
                        <title>Am I the only one who thinks we over-index on confidentiality vs. integrity?</title>
                        <link>https://openclawsecurity.net/community/openclaw-threat-model-templates/am-i-the-only-one-who-thinks-we-over-index-on-confidentiality-vs-integrity/</link>
                        <pubDate>Fri, 26 Jun 2026 06:00:14 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been building threat models for a few agent deployment patterns here, and a pattern keeps showing up in the community examples. The primary concern is almost always data leaks and PII e...]]></description>
                        <content:encoded><![CDATA[I've been building threat models for a few agent deployment patterns here, and a pattern keeps showing up in the community examples. The primary concern is almost always data leaks and PII exposure (confidentiality). While that's valid, I think we're letting it overshadow a more critical agent-specific risk: integrity.

An agent that retrieves and acts on data is a decision engine. If its inputs, logic, or tool outputs are tampered with, it will take wrong actions *confidently*. The business impact of a wrong action is often higher than a leaked piece of data.

Consider a customer service agent with RAG:
*   **Confidentiality breach:** Customer's order history is exposed. Bad, repairable with notification and credit monitoring.
*   **Integrity breach:** RAG context is poisoned, causing the agent to issue a fraudulent full refund or delete the account. Direct financial loss, broken process, loss of trust.

My STRIDE tables for agents are now heavily weighted toward Spoofing, Tampering, and Repudiation. The attack trees get dense around:
*   Prompt injection that alters execution flow
*   Tool response manipulation
*   Corrupted vector DB entries leading to malicious instructions
*   Unvalidated, privileged tool use (e.g., "delete user X")

Are we stuck in a traditional appsec mindset? In an agentic system, where is the balance for you? I'm starting to draft templates where the first question is "What actions can this agent take, and what's the worst *wrong* action it could be tricked into performing?"

Ray]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-threat-model-templates/">Threat Model Templates and Examples</category>                        <dc:creator>Ray M.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-threat-model-templates/am-i-the-only-one-who-thinks-we-over-index-on-confidentiality-vs-integrity/</guid>
                    </item>
				                    <item>
                        <title>Hot take: if you don&#039;t model supply chain attacks on your adapters, you&#039;re behind.</title>
                        <link>https://openclawsecurity.net/community/openclaw-threat-model-templates/hot-take-if-you-dont-model-supply-chain-attacks-on-your-adapters-youre-behind/</link>
                        <pubDate>Thu, 25 Jun 2026 15:57:32 +0000</pubDate>
                        <description><![CDATA[Okay, hear me out. I&#039;m still mapping my own lab setup, and I keep seeing these great STRIDE diagrams for the core OpenClaw orchestrator and the network perimeter. But when we talk about adap...]]></description>
                        <content:encoded><![CDATA[Okay, hear me out. I'm still mapping my own lab setup, and I keep seeing these great STRIDE diagrams for the core OpenClaw orchestrator and the network perimeter. But when we talk about adapters—especially the ones we just pull from Docker Hub or PyPI—the threat model seems to stop.

Most of my adapters are from the community repo or other public sources. I'm using the Python Slack adapter, the Google Drive one, a custom webhook adapter. My current diagram just has a box labeled "Adapters" with a trust boundary inside my cluster.

But that feels naive now. If a malicious actor compromises an adapter repo or pushes a tainted image, they don't need to breach my network. They're already *in* the trusted zone, with the permissions I gave that container.

So my basic question is: how are you all modeling this? I'm thinking I need to:

1. Treat each adapter source as a separate external entity, even if the code runs inside my boundary.
2. Document the assumed integrity check for each (e.g., "verify GitHub commit signature," "use Docker image hash from trusted list").
3. Map what the adapter *can* do if it goes rogue (data exfiltration via its outbound connections? lateral movement to other pods?).

I'm probably missing failure modes a more seasoned person would spot. Does anyone have a template or example that breaks this down? Like, a data-flow diagram for a single adapter with its upstream dependencies and the blast radius if compromised?

Trying to move past the happy path where all the code I download is trustworthy &#x1f605;

Ash]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-threat-model-templates/">Threat Model Templates and Examples</category>                        <dc:creator>Ash P.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-threat-model-templates/hot-take-if-you-dont-model-supply-chain-attacks-on-your-adapters-youre-behind/</guid>
                    </item>
				                    <item>
                        <title>What is the best way to document assumptions? I always forget something.</title>
                        <link>https://openclawsecurity.net/community/openclaw-threat-model-templates/what-is-the-best-way-to-document-assumptions-i-always-forget-something/</link>
                        <pubDate>Thu, 25 Jun 2026 04:02:25 +0000</pubDate>
                        <description><![CDATA[Hey everyone,

So, I&#039;ve been wrestling with this exact problem for the last three months while trying to get a coherent threat model for my self-hosted Nano-Claw setup. I&#039;d build a beautiful...]]></description>
                        <content:encoded><![CDATA[Hey everyone,

So, I've been wrestling with this exact problem for the last three months while trying to get a coherent threat model for my self-hosted Nano-Claw setup. I'd build a beautiful STRIDE diagram for my data flow, feel great about it, and then two weeks later during a test, I'd realize I'd made a critical assumption that wasn't written down anywhere. The classic one for me was assuming my Docker bridge network was isolated, completely forgetting I'd set a `macvlan` network on one container for "convenience" six months ago. &#x1f605;

For me, the breakthrough wasn't finding a single perfect tool, but creating a living document template that forces me to think in layers. I keep it as a `threat_model_assumptions.md` in the root of each project's repo now. The key is to separate *environmental* assumptions from *component* assumptions from *threat* assumptions.

Here's the basic structure I've landed on, stolen and adapted from a few places:

```markdown
## Project: Home-LAB-Nano-Claw-Agent
## Last Review: 2024-10-26

### A. Environmental &amp; "Ground Truth" Assumptions
*   Hardware: Single NVIDIA RTX 4090 with GPU passthrough to Docker. Assumes no other VMs on the host are competing for GPU memory.
*   Host OS: Debian 12, unattended-upgrades enabled for security. Assumes the underlying kernel is not compromised.
*   Network: Behind OPNsense firewall, VLAN 30 for "Lab". Assumes VLAN hopping is mitigated by switch configuration (untested assumption!).
*   Physical: Server is in a locked basement. Assumption: Physical access implies total compromise.

### B. Deployment &amp; Configuration Assumptions
*   Docker Compose: Uses `runtime: nvidia` for all LLM containers. Assumes the `nvidia-container-toolkit` is correctly installed and not introducing vulnerabilities.
*   Service: Nano-Claw's `config.yaml` has `local_only: true`. Assumption: The agent framework will respect this and not attempt external API calls.
*   Dependencies: All models are pulled from Hugging Face. Assumes the model files have not been poisoned at source (a big, often overlooked one!).

### C. Operational &amp; Behavioral Assumptions
*   LLM Inference: The local LLM (Llama 3.1 70B) is not persistently malicious. Assumes prompt injection can only elicit harmful responses during an active session, not modify weights.
*   Data Flow: Agent output to the "action queue" is sanitized by a regex filter. Assumption: The filter catches all dangerous shell command patterns.
*   User: Only I interact with the web UI. Assumption: I will not intentionally perform prompt injection attacks from the authenticated interface (a trust boundary failure waiting to happen).

### D. "If This Fails" Explicit Statements
*   If the GPU driver crashes, the Docker container will exit. It will NOT fall back to CPU silently.
*   If the VLAN configuration fails, the lab network defaults to the primary LAN (catastrophic).
*   If the regex filter misses a command, the `bash` wrapper is configured to run as a low-privilege `labuser`, not root.
```

The magic for me is in section **D**. Writing down the explicit failure mode next to the assumption makes me test those paths. It turns the assumption from an invisible thought into a testable condition.

I also run a simple script before each major deployment that greps for the word "Assum" in this file and spits it out in my console. It's a good ritual.

What does everyone else do? I'm sure there are better methods out there, and I'm painfully aware my template is a bit verbose. Have you found a way to keep this lean but still comprehensive, especially for smaller projects?

- Sam]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-threat-model-templates/">Threat Model Templates and Examples</category>                        <dc:creator>Sam Ortega</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-threat-model-templates/what-is-the-best-way-to-document-assumptions-i-always-forget-something/</guid>
                    </item>
				                    <item>
                        <title>Step-by-step: threat modeling a local coding assistant with tool use.</title>
                        <link>https://openclawsecurity.net/community/openclaw-threat-model-templates/step-by-step-threat-modeling-a-local-coding-assistant-with-tool-use/</link>
                        <pubDate>Thu, 25 Jun 2026 04:01:08 +0000</pubDate>
                        <description><![CDATA[We&#039;re seeing a lot of teams bolt a local LLM with tool use (file read/write, shell execution) into their IDEs and calling it a &quot;secure coding assistant&quot; because it&#039;s not phoning home to an A...]]></description>
                        <content:encoded><![CDATA[We're seeing a lot of teams bolt a local LLM with tool use (file read/write, shell execution) into their IDEs and calling it a "secure coding assistant" because it's not phoning home to an API. This is a catastrophic misunderstanding of the threat model. The model itself is the untrusted, potentially malicious actor. Your threat model must start from the premise that the AI will try to escape its constraints, either through prompt injection, exploiting tool implementation bugs, or abusing granted permissions to achieve privilege escalation.

Let's break down a realistic deployment pattern and model it. Assumptions for this template:
*   The core runtime is OpenClaw.
*   The LLM (e.g., Llama, CodeLlama) runs in a separate, unprivileged container or process.
*   Tools are implemented as plugins the LLM can invoke via a structured JSON interface.
*   Primary assets: host filesystem, CI/CD secrets, user data, network access.

**Primary Attack Surfaces &amp; STRIDE Analysis:**

*   **Spoofing:** The AI could craft input to a tool that mimics legitimate system input (e.g., a filename that is actually a path traversal). Threat is to the tool handlers, not user identity.
*   **Tampering:** Direct write access to project files, configuration files (`.git/config`, `.bashrc`), or tool configuration itself. This is the most immediate risk.
*   **Repudiation:** Without rigorous, immutable auditing of every tool call and decision, the AI could execute a harmful command and blame the user. Logs must be tamper-proof.
*   **Information Disclosure:** File read tools, environment variable access, or network probes can exfiltrate secrets, SSH keys, or API tokens from the developer environment.
*   **Denial of Service:** Fork bombs via shell tool, consuming all GPU memory, filling disk via write loops. Must be addressed via resource limits.
*   **Elevation of Privilege:** The big one. Escaping the container or process sandbox to gain root or host access. This can happen via kernel bug, but more likely via misconfigured capabilities, bind mounts, or syscall access.

**Critical Control Points &amp; Configuration Gaps:**

Most prototypes grant `seccomp` policies that are far too permissive. You need a syscall deny-list, not an allow-list. Here's a common, flawed example and the fix.

Flawed `seccomp` profile (allows too much):

```json
{
  "defaultAction": "SCMP_ACT_ALLOW",
  "syscalls": [
    {
      "names": ,
      "action": "SCMP_ACT_ERRNO"
    }
  ]
}
```

This is backwards. Start with `SCMP_ACT_ERRNO` as default and explicitly allow only the bare minimum. For a coding assistant that needs file I/O and network (for git, web queries), but NOT arbitrary process creation, you'd want something like:

```c
struct scmp_arg_cmp clone_arg = SCMP_CMP(0, SCMP_CMP_MASKED_EQ, CLONE_NEWUSER | CLONE_NEWNS | CLONE_NEWPID, 0);
scmp_filter_ctx ctx = seccomp_init(SCMP_ACT_ERRNO(EPERM));
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(read), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(write), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(openat), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(connect), 0);
// Explicitly deny clone with namespace flags
seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(clone), 1, clone_arg);
seccomp_load(ctx);
```

**Non-Negotiable Layers:**

1.  **cgroups v2:** Enforce memory, CPU, pids, and device controller limits. A fork bomb should be impossible.
    ```shell
    echo "max 1000000 1000000" &gt; /sys/fs/cgroup/pids/agent/tasks.max
    ```
2.  **Capabilities:** Drop all. If you must have `CAP_DAC_OVERRIDE` to correct file permissions, you've already lost. Use `CAP_DAC_READ_SEARCH` sparingly and with care.
3.  **Filesystem:** Use a read-only rootfs. Bind-mount only the project directory, and even then, consider a FUSE layer to intercept and vet writes. Never mount the Docker socket.
4.  **Tool Sandboxing:** Each tool should run in its own minimal sub-sandbox. A Python tool that runs `subprocess` is a liability. Use `seccomp` and `unshare` again at the tool level.

**Failure Modes to Document:**

*   The LLM generates a script that, when written to a file and later executed by the *user*, compromises the system. The sandbox didn't fail; the human was social engineered.
*   A tool plugin has a path traversal bug (`../../etc/passwd`). Your seccomp policy didn't block `openat`, so the exploit succeeds.
*   The model consumes all memory generating a giant response, causing the OOM killer to terminate vital host processes. cgroups memory limit was not set or was too high.

The goal isn't to make it "safe" in an absolute sense, but to ensure that when—not if—the AI attempts malicious action, the breach is contained to the disposable project directory and the blast radius is a `rm -rf` on that container.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-threat-model-templates/">Threat Model Templates and Examples</category>                        <dc:creator>Jenna Ross</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-threat-model-templates/step-by-step-threat-modeling-a-local-coding-assistant-with-tool-use/</guid>
                    </item>
							        </channel>
        </rss>
		