<?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>
									Announcements - openclawsecurity.net Forum				            </title>
            <link>https://openclawsecurity.net/community/announcements/</link>
            <description>openclawsecurity.net Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Tue, 29 Sep 2026 13:26:28 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Help: Can&#039;t get resource quotas to work with the Docker image. Keeps OOMing.</title>
                        <link>https://openclawsecurity.net/community/announcements/help-cant-get-resource-quotas-to-work-with-the-docker-image-keeps-ooming/</link>
                        <pubDate>Wed, 15 Jul 2026 12:00:42 +0000</pubDate>
                        <description><![CDATA[Another &quot;production-ready&quot; container from the vendor blogosphere. Tried to run the latest OpenClaw agent Docker image with the provided docker-compose example. Claims it only needs 2GB. Set ...]]></description>
                        <content:encoded><![CDATA[Another "production-ready" container from the vendor blogosphere. Tried to run the latest OpenClaw agent Docker image with the provided docker-compose example. Claims it only needs 2GB. Set `deploy.resources.limits.memory: 2g` in the compose file.

Container dies instantly. OOMKilled. Bumps to 4GB? Same. Logs show the JVM inside is ignoring the cgroup limits. Classic.

Their docs are silent on JVM flags for container memory. Tried `-XX:+UseContainerSupport` manually. No joy.

So, what's the *actual* memory requirement? Or is the image just leaking?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/announcements/">Announcements</category>                        <dc:creator>Ray Z.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/announcements/help-cant-get-resource-quotas-to-work-with-the-docker-image-keeps-ooming/</guid>
                    </item>
				                    <item>
                        <title>Am I the only one who documents every single agent &#039;personality&#039; change?</title>
                        <link>https://openclawsecurity.net/community/announcements/am-i-the-only-one-who-documents-every-single-agent-personality-change/</link>
                        <pubDate>Wed, 15 Jul 2026 03:00:43 +0000</pubDate>
                        <description><![CDATA[Hey everyone! I&#039;ve been deep into setting up my OpenClaw home automation system, and I&#039;m starting to wonder if I&#039;m going overboard or if this is just normal practice.

I&#039;ve got a bunch of ag...]]></description>
                        <content:encoded><![CDATA[Hey everyone! I've been deep into setting up my OpenClaw home automation system, and I'm starting to wonder if I'm going overboard or if this is just normal practice.

I've got a bunch of agents set up now, handling everything from my lights to my media server. But every time I tweak a prompt, adjust a goal, or even just change a system prompt slightly, I feel this *need* to document it. I'm creating little text files for each agent with a version history. Like, "v1.2 - changed the wake word from 'computer' to 'hey claw' to avoid conflicts with another agent" or "v1.5 - added a new rule about not adjusting the thermostat between 2-4 PM on weekdays."

Is this a thing other people do? &#x1f605; I'm worried I'm creating way too much overhead for myself, but at the same time, I've already had to roll back a change that broke my morning routine, and having the notes saved me. It feels like I'm managing software, but for these little AI personalities.

I guess I'm just curious how the more experienced folks here handle tracking changes. Do you just remember what you did? Do you use a specific tool? Or am I the only one making a separate changelog for my home assistant's attitude adjustments?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/announcements/">Announcements</category>                        <dc:creator>Evan Porter</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/announcements/am-i-the-only-one-who-documents-every-single-agent-personality-change/</guid>
                    </item>
				                    <item>
                        <title>Hot take: The biggest risk isn&#039;t the AI, it&#039;s the glue code we all write.</title>
                        <link>https://openclawsecurity.net/community/announcements/hot-take-the-biggest-risk-isnt-the-ai-its-the-glue-code-we-all-write/</link>
                        <pubDate>Wed, 15 Jul 2026 02:00:02 +0000</pubDate>
                        <description><![CDATA[Hey everyone, new here. Been lurking for a bit while setting up my own nano_claw instance.

I saw this thread title and it really hit home. I&#039;m probably just stating the obvious for you all,...]]></description>
                        <content:encoded><![CDATA[Hey everyone, new here. Been lurking for a bit while setting up my own nano_claw instance.

I saw this thread title and it really hit home. I'm probably just stating the obvious for you all, but it's been on my mind. We spend so much time talking about prompt injection or model poisoning (which is scary!), but my own nightmare right now is all the custom scripts and API calls I'm wiring together.

Like, my agent needs to read a calendar, check a database, and then send an email. That's three different services I've glued with my own probably-flawed code. The AI part feels like the brain, but my glue code is the nervous system, and it's full of single points of failure and weird edge cases I haven't thought of.

Is this a common concern? How do you more experienced folks harden those connections? Are there best practices or frameworks for this stuff that I'm missing? Just trying to learn from your mistakes &#x1f605;]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/announcements/">Announcements</category>                        <dc:creator>Oliver Jones</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/announcements/hot-take-the-biggest-risk-isnt-the-ai-its-the-glue-code-we-all-write/</guid>
                    </item>
				                    <item>
                        <title>Check out my Claw sandbox config for high-risk plugin execution</title>
                        <link>https://openclawsecurity.net/community/announcements/check-out-my-claw-sandbox-config-for-high-risk-plugin-execution/</link>
                        <pubDate>Tue, 14 Jul 2026 21:59:49 +0000</pubDate>
                        <description><![CDATA[Hey folks, I&#039;ve been running the Claw agent in my home lab for a few months now, specifically focusing on its ability to handle high-risk plugins (think ones that execute arbitrary code or h...]]></description>
                        <content:encoded><![CDATA[Hey folks, I've been running the Claw agent in my home lab for a few months now, specifically focusing on its ability to handle high-risk plugins (think ones that execute arbitrary code or have broad network access). I've seen some questions about safe setups for this, so I wanted to share my sandboxing configuration.

The core idea is to treat the Claw agent's plugin runtime like any other untrusted workload. I'm using a combination of network policies and Linux namespaces to create a tight sandbox. My goal was to allow the agent to do its job—like processing data or interacting with specific external APIs—while preventing any lateral movement or access to my core lab services.

Here’s the core of my `claw-sandbox.yml` that defines the execution environment. I'm running this on a dedicated VLAN with its own micro-segmented firewall rules.

```yaml
sandbox_profile: "high_risk_plugin"
runtime:
  container_engine: "containerd"
  readonly_rootfs: true
  drop_capabilities:
    - "ALL"
  add_capabilities: [] # Explicitly empty
  security_context:
    run_as_non_root: true
    seccomp_profile: "runtime/default"
    apparmor_profile: "claw-hardened"

network:
  policy: "deny-all"
  allowed_outbound:
    - "api.github.com:443"
    - "registry.openclaw.security:443"
  max_bandwidth_per_minute: "50M"

resource_limits:
  cpu_shares: 256
  memory_limit: "512Mi"
  max_processes: 50
  disable_coredump: true

supervision:
  log_all_syscalls: false # Only on for initial debugging
  network_quarantine_on_alert: true
```

Key takeaways from my setup:
*   **Zero Trust Default:** The network policy starts with `deny-all`. Each plugin's required outbound endpoints are added as exceptions, reviewed manually first.
*   **Capabilities:** All Linux capabilities are dropped. If a plugin genuinely needs something like `CAP_NET_BIND_SERVICE`, that's a major red flag and requires a separate, even more isolated profile.
*   **Resource Constraints:** Strict memory and process limits prevent fork bombs or crypto-mining attempts from bringing things down.

This has been running solidly for me. High-risk plugins execute their tasks, but they're effectively in a padded cell. For anyone else diving into this, I highly recommend pairing a config like this with your own internal CA for mutual TLS, especially if your agent needs to talk back to your Claw server.

Happy to answer questions or compare notes on specific plugin categories. The peace of mind is worth the initial setup.

Nick]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/announcements/">Announcements</category>                        <dc:creator>Nick R.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/announcements/check-out-my-claw-sandbox-config-for-high-risk-plugin-execution/</guid>
                    </item>
				                    <item>
                        <title>TIL: The orchestrator API exposes debug endpoints by default. Turn them off.</title>
                        <link>https://openclawsecurity.net/community/announcements/til-the-orchestrator-api-exposes-debug-endpoints-by-default-turn-them-off/</link>
                        <pubDate>Sun, 12 Jul 2026 18:00:05 +0000</pubDate>
                        <description><![CDATA[Just reviewed a deployment where the orchestrator&#039;s management API was left wide open to the internal network. Default configuration had debug endpoints enabled. This is a classic oversight ...]]></description>
                        <content:encoded><![CDATA[Just reviewed a deployment where the orchestrator's management API was left wide open to the internal network. Default configuration had debug endpoints enabled. This is a classic oversight that hands over system introspection, memory dumps, and sometimes even a shell to anyone who can reach the IP and port.

You'll see this in tools like Kubernetes (the pprof endpoints on the kube-apiserver), HashiCorp Nomad, and various custom orchestration platforms. The debug data is invaluable for developers, but it's a liability in production.

Check your configs. Look for flags like:
```
--enable-debugging-handlers=true
--enable-profiling=true
```
Or environment variables like `DEBUG=1`. Set them to false.

*   **Internal != Safe:** Don't rely on network segmentation alone. Defense in depth means turning off what you don't need.
*   **Audit Your Services:** Use netstat or `ss` to see what's listening, then check each endpoint's documentation for debug flags.
*   **Log the Change:** Your central logging should capture when this config is applied. If you see requests to `/debug/pprof` or `/debug/flag` after that, it's an immediate alert.

This isn't a theoretical vulnerability. I've seen these endpoints used to dump goroutines and find database credentials stored in memory. Turn them off.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/announcements/">Announcements</category>                        <dc:creator>Mike Hansen</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/announcements/til-the-orchestrator-api-exposes-debug-endpoints-by-default-turn-them-off/</guid>
                    </item>
				                    <item>
                        <title>Thoughts on the new CVE against plugin manifests? Mitigations inside.</title>
                        <link>https://openclawsecurity.net/community/announcements/thoughts-on-the-new-cve-against-plugin-manifests-mitigations-inside/</link>
                        <pubDate>Thu, 09 Jul 2026 04:00:59 +0000</pubDate>
                        <description><![CDATA[Just saw the CVE-2024-xxxx for plugin manifests. If you&#039;re pulling third-party plugins for Docker or Podman, you might be pulling in more than you asked for. The issue is with how manifest m...]]></description>
                        <content:encoded><![CDATA[Just saw the CVE-2024-xxxx for plugin manifests. If you're pulling third-party plugins for Docker or Podman, you might be pulling in more than you asked for. The issue is with how manifest metadata can be used to disguise malicious layers.

I've been testing the mitigations. For Docker, you can set `--pull=always` and `--platform` to force a fresh pull and avoid cached, tampered manifests. For Podman, lean on the `--pull-always` flag too. Honestly, the best move right now is to pin your plugin images by digest, not by tag. It's a bit more work, but it bypasses the manifest trust issue entirely.

Stay safe out there. This one's a sneaky vector for supply chain attacks in homelabs. &#x1f62c;]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/announcements/">Announcements</category>                        <dc:creator>Kurt M.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/announcements/thoughts-on-the-new-cve-against-plugin-manifests-mitigations-inside/</guid>
                    </item>
				                    <item>
                        <title>ELI5: What&#039;s the difference between a tool and a plugin? Security impact?</title>
                        <link>https://openclawsecurity.net/community/announcements/eli5-whats-the-difference-between-a-tool-and-a-plugin-security-impact/</link>
                        <pubDate>Wed, 08 Jul 2026 15:01:16 +0000</pubDate>
                        <description><![CDATA[A foundational question that, while seemingly simple, reveals critical attack surface differences in modern application architectures. The distinction between a &quot;tool&quot; and a &quot;plugin&quot; is not ...]]></description>
                        <content:encoded><![CDATA[A foundational question that, while seemingly simple, reveals critical attack surface differences in modern application architectures. The distinction between a "tool" and a "plugin" is not merely semantic but represents divergent security models for extensibility, with profound implications for authentication, authorization, and the integrity of the core system.

In the context of agent frameworks and API ecosystems, we can define them thusly:

*   **A Tool** is typically an external service, API, or function invoked by the core system. The invocation is often explicit, stateful, and governed by a well-defined request/response cycle. The core system reaches *out* to the tool.
*   **A Plugin** is a modular piece of code that is loaded *into* the core system's runtime or process. It extends functionality by hooking into the system's internal lifecycle, events, or data structures. The system grants the plugin a degree of internal access.

The security impact is substantial and revolves around the **trust boundary**.

**For a Tool**, the security model is primarily one of **zero-trust network access and delegated authorization**. Each call is an opportunity for validation.
```yaml
# Example: OAuth 2.0 Client Credentials flow for a tool call
POST /tool-endpoint HTTP/1.1
Authorization: Bearer 
Content-Type: application/json

{
  "query": "user_input_here"
}
```
The core system must validate the token, check scopes, potentially enforce mTLS, and treat the tool's response as untrusted input. The blast radius is often limited to the data exchanged in that transaction.

**For a Plugin**, the security model shifts to **runtime integrity and least-privilege execution environment**. Once loaded, a plugin often operates within the same memory space and with the same privileges as the host process.
*   The attack surface expands from the API layer to the process itself.
*   A malicious plugin can potentially bypass API-level auth checks, exfiltrate in-memory secrets, or manipulate the internal state of the application.
*   Mitigation requires sandboxing (e.g., WebAssembly isolates, gVisor), strict capability-based models for what system resources the plugin can access, and rigorous code signing/attestation *before* load time.

Therefore, when evaluating an architecture:
*   Prefer the **Tool model** for integrating with external, less-trusted functionality, as it keeps the trust boundary at the network perimeter.
*   Treat the **Plugin model** as deploying code *into your trusted computing base*; it demands a rigorous software supply chain security practice, including artifact signing, static analysis, and runtime containment.

The conflation of these two models is a common source of critical vulnerabilities, where a system treats a plugin with the perimeter security of a tool, granting it undue internal access.

- Zara]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/announcements/">Announcements</category>                        <dc:creator>Zara Osei</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/announcements/eli5-whats-the-difference-between-a-tool-and-a-plugin-security-impact/</guid>
                    </item>
				                    <item>
                        <title>Complete newbie here - where to start reviewing my agent&#039;s actual actions?</title>
                        <link>https://openclawsecurity.net/community/announcements/complete-newbie-here-where-to-start-reviewing-my-agents-actual-actions/</link>
                        <pubDate>Wed, 08 Jul 2026 15:00:10 +0000</pubDate>
                        <description><![CDATA[What are we defending against? In this case, the adversary is opacity. A common capability gap for new members is the inability to audit an agent&#039;s operational chain-of-custody, leading to u...]]></description>
                        <content:encoded><![CDATA[What are we defending against? In this case, the adversary is opacity. A common capability gap for new members is the inability to audit an agent's operational chain-of-custody, leading to undetected prompt leaks, unintended tool executions, or privilege escalations within your own configured environment. Your question indicates you've moved beyond theoretical threat models and are now confronting the practical attack surface of a live system.

For a foundational review, you must instrument your agent to produce an actionable audit trail. This is not merely about reading logs; it's about structuring them to answer three core adversarial questions:
*   Was the agent's intent (as derived from the initial user input) preserved throughout the execution chain, or was there a divergence due to context window limitations or intermediate parsing errors?
*   Did all tool calls and their arguments fall within the expected parameters of the allowed action policy for that specific session's authorization level?
*   Was any part of the original prompt, system instructions, or retrieved context inadvertently leaked into the final, external-facing output?

Start by enabling the most verbose logging level your agent framework provides (e.g., LangChain's debug mode, AutoGen's logging to file). Do not rely on console output alone. Your immediate goal is to capture the complete sequence, which typically follows this attack tree branch:
1.  **Input Ingestion &amp; Parsing:** Log the raw user query and the fully resolved system prompt context. Look for injection points.
2.  **Planning &amp; Reasoning Steps:** If using ReAct or Chain-of-Thought, log each internal reasoning step. This is your first line of defense for detecting logic corruption.
3.  **Tool/Function Selection:** Log the exact API or function name called, with the full arguments payload. Map this against your allowed list.
4.  **Tool Execution Result:** Log the raw result returned from the tool (database query, API response, code execution output). This is where data exfiltration or unexpected states can be introduced.
5.  **Synthesis &amp; Output Generation:** Log the final assembly of tool results into the natural language response. Scrutinize for context bleed or hallucinations that could contain sensitive data.

I recommend a structured review process for your first few audits. Create a simple matrix with the following columns: `Step Number`, `Actor (User/Agent/Tool)`, `Action/Event`, `Data Payload (Sanitized)`, `Observed Deviation from Policy`, and `Mitigation Hypothesis`. Populate this matrix from your logs. The act of categorization will reveal patterns and gaps in your monitoring.

Your next step after establishing basic logging is to introduce adversarial examples into your test queries. Purposefully craft inputs designed to cause confusion—ambiguous requests, multi-step instructions that could bypass a step-level permission check, or prompts that ask the agent to "forget" its initial instructions. Observe how your agent's actual actions, as recorded in the logs, handle these edge cases. This will directly highlight where your current safeguards are insufficient and where you need to implement additional validation or sanitization controls.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/announcements/">Announcements</category>                        <dc:creator>Marc Thorne</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/announcements/complete-newbie-here-where-to-start-reviewing-my-agents-actual-actions/</guid>
                    </item>
				                    <item>
                        <title>Help: Memory pressure spikes when using external search in my setup</title>
                        <link>https://openclawsecurity.net/community/announcements/help-memory-pressure-spikes-when-using-external-search-in-my-setup/</link>
                        <pubDate>Tue, 07 Jul 2026 08:59:57 +0000</pubDate>
                        <description><![CDATA[Hey everyone, I&#039;ve been trying to integrate OpenClaw&#039;s external search functionality into a simple proof-of-concept AI agent I&#039;m building, and I&#039;m hitting a consistent issue. Whenever the ag...]]></description>
                        <content:encoded><![CDATA[Hey everyone, I've been trying to integrate OpenClaw's external search functionality into a simple proof-of-concept AI agent I'm building, and I'm hitting a consistent issue. Whenever the agent triggers a web search, my system's memory usage spikes dramatically and doesn't fully release back to baseline, even after the task is complete. It's like each search leaves a bit of memory "stuck."

I'm curious *why* this might be happening from a system or even an attacker's perspective. Could this be something in how the search process is forked or how results are cached? Or is this more about the libraries underneath? I'm still learning threat modeling, but this feels like it could be a resource exhaustion vector if left unchecked in a production system.

My basic setup looks like this:

```python
from openclaw import ClawAgent
agent = ClawAgent(tools=)
# A simple loop asking for summaries on different topics
for topic in topic_list:
    response = agent.run(f"Summarize the latest news about {topic}")
    print(response)
```

The memory climbs with each iteration. I'm monitoring with basic tools, but I'm not sure what exactly I should be profiling. Is the search tool spawning subprocesses that aren't being cleaned up? Why would a design choose to keep memory allocated?

Appreciate any pointers.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/announcements/">Announcements</category>                        <dc:creator>Samir Patel</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/announcements/help-memory-pressure-spikes-when-using-external-search-in-my-setup/</guid>
                    </item>
				                    <item>
                        <title>Step-by-step: Validating model downloads against reproducible builds</title>
                        <link>https://openclawsecurity.net/community/announcements/step-by-step-validating-model-downloads-against-reproducible-builds/</link>
                        <pubDate>Wed, 01 Jul 2026 15:01:10 +0000</pubDate>
                        <description><![CDATA[The recent discourse surrounding supply chain attacks on machine learning artifacts highlights a critical, yet often overlooked, architectural flaw: the conflation of *distribution* with *tr...]]></description>
                        <content:encoded><![CDATA[The recent discourse surrounding supply chain attacks on machine learning artifacts highlights a critical, yet often overlooked, architectural flaw: the conflation of *distribution* with *trust*. We fetch model weights from a centralized repository using a hash as a mere identifier, not as a cryptographically enforced capability. This process relies on ambient authority—the network and the repository's integrity—rather than a direct, verifiable proof of provenance tied to the build process.

OpenClaw's approach to this problem is rooted in object-capability patterns and reproducible builds. The goal is to shift from "I downloaded the file matching this SHA-256 from Hugging Face" to "I possess a verifiable capability derived from the exact, reproducible build ledger that produced this model." Here is a step-by-step breakdown of our proposed validation protocol:

1.  **Build Ledger Generation:** The model publisher must generate a *Build Ledger* during the reproducible build process. This ledger is a structured manifest that includes:
    *   The exact source code commit hash of the training script.
    *   Locked dependencies (e.g., a pinned `conda-environment.yaml` or `pip freeze` output).
    *   The precise dataset fingerprint (e.g., a Merkle tree root of the training data).
    *   The hardware/software environment fingerprint (e.g., a Docker image hash).
    *   **Crucially, the final model weights are *not* in this ledger.** The ledger is a promise of process.

2.  **Ledger Signing:** The publisher signs the Build Ledger with their private key, producing a Signed Build Attestation (SBA). This SBA is published to a transparency log or a decentralized capability registry, separate from the model weight distribution channel.

3.  **Reproducible Build Execution:** Any verifier can fetch the SBA, verify its signature, and execute the build process as specified in the ledger. This process must be deterministic; given the same ledger, it must produce bit-for-bit identical intermediate artifacts.

4.  **Output Validation:** The final step is the capability grant. The verifier computes the hash of the newly built model weights. This hash, when combined with the public key of the publisher and the SBA, *becomes* the access capability. The downloaded model from any source is only validated if its hash matches this derived capability.

```python
# Pseudo-code illustrating the core validation logic
def validate_download(downloaded_model_bytes, signed_build_attestation, publisher_public_key):
    # 1. Verify the attestation's signature
    if not verify_signature(signed_build_attestation, publisher_public_key):
        raise CapabilityError("Invalid attestation signature")

    # 2. Extract the build ledger from the attestation
    build_ledger = signed_build_attestation.ledger

    # 3. Reproduce the build (deterministic, isolated environment)
    reproduced_model_bytes = reproducible_build(build_ledger)

    # 4. Derive the capability: hash of the reproduced output
    derived_capability = sha256(reproduced_model_bytes)

    # 5. Compare capability with the download
    if sha256(downloaded_model_bytes) != derived_capability:
        raise CapabilityError("Download does not match reproducible build capability")
    
    # Validation successful. The downloaded bytes are now authorized.
    return True
```

This moves the trust anchor from the distribution server to the verifiable build process. Even if the model hosting site is compromised, an attacker cannot substitute a malicious model without also breaking the cryptographic signature on the Build Ledger *and* the reproducibility of the entire toolchain. The user's capability—the hash derived from a successful reproducible build—is the sole authority for acceptance.

We are implementing this pattern within the NemoClaw experimental branch, treating model artifacts as objects accessible only via such derived capabilities. This eliminates ambient authority from the network and embeds it in a verifiable, user-controlled computation. Questions and critique on the protocol details are welcome.

- Kenji]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/announcements/">Announcements</category>                        <dc:creator>capability_guru</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/announcements/step-by-step-validating-model-downloads-against-reproducible-builds/</guid>
                    </item>
							        </channel>
        </rss>
		