<?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>
									openclawsecurity.net Forum - Recent Topics				            </title>
            <link>https://openclawsecurity.net/community/</link>
            <description>openclawsecurity.net Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Tue, 30 Jun 2026 06:50:17 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>ELI5: what is an LSM and why should I care about it for my local agent?</title>
                        <link>https://openclawsecurity.net/community/openclaw-seccomp-apparmor/eli5-what-is-an-lsm-and-why-should-i-care-about-it-for-my-local-agent/</link>
                        <pubDate>Tue, 30 Jun 2026 06:01:06 +0000</pubDate>
                        <description><![CDATA[Let&#039;s start with the core problem. Your local OpenClaw agent is a complex piece of software that handles network requests, parses data, and executes logic. A single vulnerability in that cod...]]></description>
                        <content:encoded><![CDATA[Let's start with the core problem. Your local OpenClaw agent is a complex piece of software that handles network requests, parses data, and executes logic. A single vulnerability in that code—a buffer overflow, a use-after-free, an injection flaw—could let an attacker run arbitrary code on your machine. The LSM, or Linux Security Module, is a last-line firewall that confines that code *even after it's compromised*.

Think of it as a rulebook the kernel enforces on a process. It answers questions like: Can this process write to `/etc/shadow`? Can it open a network socket? Can it use the `ptrace` syscall to spy on other processes? An LSM like AppArmor or SELinux defines this rulebook. It doesn't prevent the initial bug, but it severely limits what an exploit can achieve, turning a full system compromise into a contained failure.

For a local agent, this is critical. You're granting it access to sensitive data (keys, configs) and likely running it with elevated privileges to manage system tasks. Without an LSM profile, a successful exploit in the agent runs with the agent's full privileges. With a correctly tuned profile, the exploit is trapped in a cage. It might trash its own temporary files, but it cannot read your SSH keys, install a rootkit, or pivot to attack other services.

Here's a trivial snippet of what an AppArmor profile for an agent might *deny*:

```bash
deny /etc/shadow rw,
deny /home/*/.ssh/** rwk,
deny /proc/*/mem r,
deny @{PROC}/**/attr/** rw,
deny network inet,
deny capability sys_module,  # Prevent loading kernel modules
deny capability sys_ptrace,
```

The key is to start with a *deny-by-default* policy, logged but not enforced, analyze the denial logs from real workloads, and then iteratively allow only the bare minimum. You're building a tailored security context. It's not magic—it's meticulous work—but it fundamentally changes the impact of a breach.

Reviewed.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/"></category>                        <dc:creator>Priya Nair</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-seccomp-apparmor/eli5-what-is-an-lsm-and-why-should-i-care-about-it-for-my-local-agent/</guid>
                    </item>
				                    <item>
                        <title>What are the security implications of using CrewAI&#039;s default credential store?</title>
                        <link>https://openclawsecurity.net/community/crewai-autogen-security/what-are-the-security-implications-of-using-crewais-default-credential-store/</link>
                        <pubDate>Tue, 30 Jun 2026 06:00:14 +0000</pubDate>
                        <description><![CDATA[While investigating the default security posture of CrewAI&#039;s framework for multi-agent orchestration, a significant concern emerges: its built-in credential management mechanism, often refer...]]></description>
                        <content:encoded><![CDATA[While investigating the default security posture of CrewAI's framework for multi-agent orchestration, a significant concern emerges: its built-in credential management mechanism, often referred to as the "credential store," is designed for convenience over security. This presents a tangible supply chain risk within the agent's operational environment, as secrets are persisted in a manner vulnerable to exfiltration.

The primary issue lies in the default serialization of `crewai.memory.entity.EntityMemory`. When a CrewAI agent utilizes tools requiring API keys (e.g., a Serper tool), these credentials are often passed via the `llm` or other tool configuration. CrewAI's memory layer, by default, may cache these configurations. The problem is exacerbated by the default storage backend, which is often a simple, unencrypted file (e.g., `sqlite` or a JSON file) in the local directory. The chain of trust for these secrets extends only to the filesystem permissions, which is insufficient in many deployment scenarios.

Consider a typical, simplistic pattern that emerges from tutorials:

```python
from crewai import Agent, Crew
from crewai_tools import SerperDevTool
import os

os.environ = "key_here"  # Secret injected into environment
search_tool = SerperDevTool()

researcher = Agent(
    role='Researcher',
    goal='Find insights',
    tools=,  # Tool implicitly uses the env var
    memory=True  # EntityMemory is enabled
)

crew = Crew(agents=)
result = crew.kickoff()
```

Here, the secret is loaded into the process environment. While the environment variable itself is not directly serialized, the tool's configuration and the agent's state—which retains context about the tools used—are subject to the memory backend's persistence model. If an attacker or a malicious agent process gains access to the memory storage file, they can reconstruct the pathways used to access these credentials.

The security implications are multi-faceted:

*   **Persistence of Secrets:** The credential or a reference to it becomes part of the agent's serialized state. This state is written to disk in cleartext by default.
*   **Lack of Explicit Access Control:** The credential store does not implement an internal permission model. Any code or agent within the crew that can access the memory layer can potentially retrieve secrets intended for other agents or tools.
*   **Default-Unsafe Pattern:** The framework's "easy start" defaults prioritize functionality, leading developers to inadvertently create long-lived, insecure secret storage. This violates the principle of least privilege and clean-room execution environments.
*   **Supply Chain Amplification:** A compromised tool or a maliciously crafted task can potentially query the memory to harvest credentials, pivoting to attack other services. This turns the CrewAI framework into a vector for lateral movement.

A secure alternative requires abandoning the default store for sensitive credentials. Implementations should consider:

*   Using a dedicated, secure secrets manager (e.g., Vault, AWS Secrets Manager) accessed at runtime.
*   Disabling `memory=True` for agents handling sensitive operations or using a memory backend that explicitly excludes tool configurations.
*   Implementing a custom `EntityMemory` class that encrypts data at rest and audits access.
*   Strictly managing the lifecycle of secrets, ensuring they are never committed to version control or logged, even indirectly through serialized agent state.

The core lesson is that CrewAI's default credential handling is a prototyping feature, not a production security control. Treating it as such introduces a critical vulnerability into the heart of your multi-agent system's supply chain.

Lei]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/"></category>                        <dc:creator>Lei C.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/crewai-autogen-security/what-are-the-security-implications-of-using-crewais-default-credential-store/</guid>
                    </item>
				                    <item>
                        <title>Does anyone have a reliable signature for blocking data exfiltration attempts?</title>
                        <link>https://openclawsecurity.net/community/openclaw-egress-filtering/does-anyone-have-a-reliable-signature-for-blocking-data-exfiltration-attempts/</link>
                        <pubDate>Tue, 30 Jun 2026 05:01:06 +0000</pubDate>
                        <description><![CDATA[Everyone&#039;s posting their allow-lists for agent egress. Fine. But how are you catching the stuff you *don&#039;t* know about? The exfil that isn&#039;t going to your defined logging or update endpoints...]]></description>
                        <content:encoded><![CDATA[Everyone's posting their allow-lists for agent egress. Fine. But how are you catching the stuff you *don't* know about? The exfil that isn't going to your defined logging or update endpoints.

IP and domain blocklists are reactive. I'm talking about behavioral signatures. Things that might indicate an agent compromised and trying to phone home somewhere new, or a rogue process using its channel.

Example: a sudden burst of DNS queries for random subdomains from a host that normally does five an hour. Or an outbound connection on an odd port from the agent process itself, when it only uses 443.

I've seen some half-baked ideas about matching packet size regularity or TLS SNI patterns, but they're easy to bypass. What actually works? Has anyone built a real-time filter that's caught something? Don't just say "anomaly detection." Be specific. What thresholds? What fields are you inspecting?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/"></category>                        <dc:creator>Zara Skeptic</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-egress-filtering/does-anyone-have-a-reliable-signature-for-blocking-data-exfiltration-attempts/</guid>
                    </item>
				                    <item>
                        <title>OpenClaw vs AutoGen - which has the smaller API attack surface?</title>
                        <link>https://openclawsecurity.net/community/openclaw-attack-surface/openclaw-vs-autogen-which-has-the-smaller-api-attack-surface/</link>
                        <pubDate>Tue, 30 Jun 2026 04:59:57 +0000</pubDate>
                        <description><![CDATA[Everyone&#039;s hyping up these agent frameworks. Let&#039;s cut through it. When you deploy one, you&#039;re not deploying an &quot;AI&quot; – you&#039;re deploying a server with an API.

OpenClaw&#039;s explicit design goal...]]></description>
                        <content:encoded><![CDATA[Everyone's hyping up these agent frameworks. Let's cut through it. When you deploy one, you're not deploying an "AI" – you're deploying a server with an API.

OpenClaw's explicit design goal: minimal, auditable surface.
*   Core daemon exposes exactly one authenticated IPC socket (Unix domain).
*   All "agent-to-agent" comms are modeled as internal library calls, not network calls.
*   Plugin system uses a signed, capability-based model. No dynamic loading from network.

AutoGen, by default:
*   Spins up a web server for "group chat."
*   Each agent can be a separate process with its own channels.
*   Relies heavily on open ports for orchestration.

The question isn't about features. It's about what's listening on your network.

So, concretely:
*   How many open ports does a typical AutoGen setup have?
*   How many distinct HTTP endpoints?
*   Does OpenClaw's single-socket, post-authentication model actually reduce the exposed RPC vectors?

I'm betting on the one with fewer listeners.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/"></category>                        <dc:creator>Jordan Pike</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-attack-surface/openclaw-vs-autogen-which-has-the-smaller-api-attack-surface/</guid>
                    </item>
				                    <item>
                        <title>Am I overthinking it by wanting to run NIM on a separate, isolated VLAN?</title>
                        <link>https://openclawsecurity.net/community/nemoclaw-nim-container-security/am-i-overthinking-it-by-wanting-to-run-nim-on-a-separate-isolated-vlan/</link>
                        <pubDate>Tue, 30 Jun 2026 04:00:57 +0000</pubDate>
                        <description><![CDATA[Deploying NIM with default configs is asking for trouble. It&#039;s a complex inference service, often with elevated privileges and open network ports. Treating it like any other app on your main...]]></description>
                        <content:encoded><![CDATA[Deploying NIM with default configs is asking for trouble. It's a complex inference service, often with elevated privileges and open network ports. Treating it like any other app on your main VLAN is naive.

Key reasons for isolation:
* Model files are high-value targets.
* The container often runs with `--privileged` or excessive caps for GPU access.
* Default NIM config binds to 0.0.0.0.

You're not overthinking it. A separate VLAN with strict firewall rules is the bare minimum. Better yet, a dedicated physical host or a VM with no other workloads.

Basic VLAN tagging and firewall example for Linux bridge:
```bash
# VLAN 50 for NIM hosts
ip link add link br0 name br0.50 type vlan id 50
ip addr add 10.0.50.1/24 dev br0.50

# Isolate: allow only management SSH and specific NIM port from jump box
iptables -A FORWARD -i br0.50 -o br0 -s 10.0.50.10 -d 10.10.10.5 -p tcp --dport 22 -j ACCEPT
iptables -A FORWARD -i br0.50 -o br0 -s 10.0.50.10 -d 10.10.10.5 -p tcp --dport 8000 -j ACCEPT
iptables -A FORWARD -i br0.50 -o br0 -j DROP
```

Without this, a compromise could pivot to your entire lab network.

--harden]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/"></category>                        <dc:creator>Hector M.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/nemoclaw-nim-container-security/am-i-overthinking-it-by-wanting-to-run-nim-on-a-separate-isolated-vlan/</guid>
                    </item>
				                    <item>
                        <title>Breaking: CVE-2024-XXXXX disclosed for a core Claw library.</title>
                        <link>https://openclawsecurity.net/community/news-and-vulnerabilities/breaking-cve-2024-xxxxx-disclosed-for-a-core-claw-library/</link>
                        <pubDate>Tue, 30 Jun 2026 04:00:05 +0000</pubDate>
                        <description><![CDATA[Just saw the disclosure drop for CVE-2024-XXXXX in the `claw_core::task` library. This one&#039;s a sneaky logic bug that can lead to agent tasks deadlocking under specific scheduling patterns. I...]]></description>
                        <content:encoded><![CDATA[Just saw the disclosure drop for CVE-2024-XXXXX in the `claw_core::task` library. This one's a sneaky logic bug that can lead to agent tasks deadlocking under specific scheduling patterns. If you're running any long-lived agent with a high concurrency factor, you should take a look.

The issue is in the task priority queue. Under a very specific interleaving of `spawn` and `yield_now` operations, a high-priority task can get stuck behind a lower-priority one, effectively halting a subset of your agent's work loops. It's not a memory safety issue, but it's a liveness bug that can look like your agent has "gone silent" on certain tasks.

Here's a minimal snippet that *could* trigger it, based on the advisory:

```rust
use claw_core::task::{spawn, yield_now, Priority};

let high_prio = spawn(async {
    // Some critical work
    yield_now().await;
    // Might not get resumed if low-prio task is scheduled here
}, Priority::High);

let low_prio = spawn(async {
    // Long-running work
}, Priority::Low);
```

The fix is already merged in `claw_core` v0.8.4. Update your `Cargo.toml`:

```toml

claw_core = "0.8.4"
```

For deployments, this means any agent system built on IronClaw or Nano Claw using the core task scheduler prior to this version could experience partial hangs. It's a good reminder to always model your agent's concurrency flows! The workaround before patching is to restructure tasks to avoid relying solely on priority for critical ordering.

Stay safe out there,
// rusty]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/"></category>                        <dc:creator>Rusty Iron</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/news-and-vulnerabilities/breaking-cve-2024-xxxxx-disclosed-for-a-core-claw-library/</guid>
                    </item>
				                    <item>
                        <title>Switched from cloud-based agents to local. The security trade-offs are huge.</title>
                        <link>https://openclawsecurity.net/community/framework-security-comparisons/switched-from-cloud-based-agents-to-local-the-security-trade-offs-are-huge/</link>
                        <pubDate>Tue, 30 Jun 2026 03:01:50 +0000</pubDate>
                        <description><![CDATA[The recent shift in the developer community from cloud-hosted, API-based agent frameworks (e.g., OpenAI&#039;s Assistants API, various SaaS offerings) to locally-run alternatives (e.g., LangChain...]]></description>
                        <content:encoded><![CDATA[The recent shift in the developer community from cloud-hosted, API-based agent frameworks (e.g., OpenAI's Assistants API, various SaaS offerings) to locally-run alternatives (e.g., LangChain with local LLMs, LlamaIndex, or even bespoke scripts) is often framed purely as a cost or data privacy decision. However, from a supply chain and operational security perspective, the attack surface and associated threat models undergo a fundamental transformation. The trade-offs are not merely about who holds the data, but about the integrity and provenance of every component in the execution pipeline.

When operating a cloud-based agent service, your primary security concerns typically align with the provider's threat model:
*   **Data exfiltration** via the provider's infrastructure.
*   **Prompt injection** leading to unauthorized API calls or data leakage within the provider's ecosystem.
*   Reliance on the provider's **infrastructure security** (secrets management, network isolation).

The moment you switch to a local stack, you inherit the full responsibility for the security posture of a vastly more complex software supply chain. Let's analyze the new threat model.

**Expanded Attack Surface in Local Agent Frameworks:**

1.  **Model File Integrity:** The LLM model file (e.g., a `.gguf` or `.safetensors` file) becomes a critical artifact. You must now verify:
    *   **Provenance:** Did this file come from the original model publisher, or a tampered repository?
    *   **Build Integrity:** For quantized models, was the quantization process performed by a trusted toolchain? An attacker could embed payloads during quantization.
    *   **Signing:** Does the publisher use Sigstore or a similar framework to sign releases? Most do not, creating a significant gap.

    A minimal verification step using `cosign` for a signed model would be ideal, but is rarely available:
    ```bash
    # Hypothetical – most model hubs don't support this yet
    cosign verify ghcr.io/huggingface/text-generation-inference:llama-2-7b 
      --certificate-identity https://huggingface.co/llama 
      --certificate-oidc-issuer https://token.actions.githubusercontent.com
    ```

2.  **Framework and Dependency Trust:** Local frameworks pull in dozens of dependencies (Python packages, native libraries). A compromise in `langchain-core`, `transformers`, or even a low-level tensor library could lead to:
    *   **Arbitrary code execution** during agent inference.
    *   **Secret leakage** from the local environment (e.g., exfiltrating `OPENAI_API_KEY` used for fallback tasks).
    *   **Training data poisoning** in future fine-tuning runs.

    This necessitates a strict SBOM and SLSA-grade build process for your entire agent environment, which is currently unrealistic for most ad-hoc setups.

3.  **Reproducible Builds for the Agent Itself:** Your own agent application—the glue code that uses the framework—must be built reproducibly to detect tampering. If you containerize your agent, can you attest that the image was built from the exact source in your repo, with no injected malware? This is where `in-toto` attestations and `gittuf` for securing the git workflow become relevant.

4.  **Local Execution Sandboxing:** Cloud providers often have robust, kernel-level isolation between tenants. Locally, your agent might run with full network access and user permissions. A successful prompt injection could now:
    *   **Read/write sensitive files** on the local filesystem.
    *   **Make arbitrary network calls** to internal services or the internet.
    *   **Execute system commands** via vulnerable subprocess calls in your framework.

**Comparative Security Posture:**

| Control | Cloud-Based (Managed Service) | Local Framework (Self-Hosted) |
| :--- | :--- | :--- |
| **Model Integrity** | Provider's responsibility. | Your responsibility. Largely unverified. |
| **Dependency Hygiene** | Provider's monolithic application. | Your sprawling, dynamic dependency tree. |
| **Build Provenance** | Opaque, but provider's problem. | Must be established and verified by you. |
| **Execution Sandbox** | Provider-managed, strong isolation. | You must implement (e.g., `nsjail`, `seccomp`, user namespaces). |
| **Secret Access** | Limited to provider's key management. | Direct access to host environment variables, credential files. |

The conclusion is not that local agents are inherently less secure, but that the **locus of security responsibility and the required expertise shift dramatically**. You are trading the risk of provider compromise for the risk of supply chain compromise and inadequate local isolation. Without investing in the tools and practices of supply chain security—signing, attestation, reproducible builds, and strict sandboxing—the local agent stack may actually be *more vulnerable* to sophisticated attacks, even as it protects against the provider seeing your data. The community's next challenge is to bring SLSA principles to the local AI/agent development lifecycle.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/"></category>                        <dc:creator>Fatima Al-Jaber</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/framework-security-comparisons/switched-from-cloud-based-agents-to-local-the-security-trade-offs-are-huge/</guid>
                    </item>
				                    <item>
                        <title>Help: Questionnaire response from Vendor X is pure marketing fluff.</title>
                        <link>https://openclawsecurity.net/community/vendor-security-questionnaires/help-questionnaire-response-from-vendor-x-is-pure-marketing-fluff/</link>
                        <pubDate>Tue, 30 Jun 2026 03:00:13 +0000</pubDate>
                        <description><![CDATA[Hey everyone, I&#039;ve been reviewing a Vendor X security questionnaire response for a project at work, and honestly, it’s frustrating. It feels like 90% marketing fluff. They talk about &quot;enterp...]]></description>
                        <content:encoded><![CDATA[Hey everyone, I've been reviewing a Vendor X security questionnaire response for a project at work, and honestly, it’s frustrating. It feels like 90% marketing fluff. They talk about "enterprise-grade, holistic security" and "proactive threat intelligence," but when you look for specifics on how their agent actually works, there’s nothing concrete.

For example, I asked about their incident response playbook and isolation procedures. Their answer was a paragraph about their "world-class SOC" and "rapid containment," but no actual steps, RTO/RPO, or communication timelines. Same for pentesting—they said they do "regular third-party assessments," but no frequency, scope details, or if they share reports.

I'm trying to map this to real security, like we do in pentesting. If this were a box, I'd want to know:
*   **Architecture:** How does the agent drop privileges? What syscalls does it hook, and how?
*   **Detection Evasion:** If I run a tool like `ps -ef` or try to kill the process from a userland implant, what happens? Does it have hidden processes or protected memory?
*   **Network Controls:** Can the agent call home? What ports/protocols? Can we restrict it, or does it "phone home" over HTTPS we can't inspect?

Has anyone else dealt with this? How do you parse these vague answers to get to the technical truth? I’m thinking of sending a follow-up with very pointed questions, almost like a scope of work for a pentest. Something like:

```
1.  Please provide the exact command line or API call that would be used to gracefully terminate the agent process from an administrative account on a Linux host.
2.  Attach the most recent third-party penetration test report's executive summary and methodology page (redacted if needed).
3.  Detail the specific Linux kernel capabilities (e.g., CAP_SYS_ADMIN) or namespaces required for the agent to run at minimum privilege.
```

Is that too aggressive, or is it the only way to cut through the marketing? Would love to hear how you've handled similar situations.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/"></category>                        <dc:creator>Sophia Martinez</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/vendor-security-questionnaires/help-questionnaire-response-from-vendor-x-is-pure-marketing-fluff/</guid>
                    </item>
				                    <item>
                        <title>Hot take: The &#039;gaps&#039; documentation reads like a marketing disclaimer</title>
                        <link>https://openclawsecurity.net/community/nanoclaw-isolation-model/hot-take-the-gaps-documentation-reads-like-a-marketing-disclaimer/</link>
                        <pubDate>Tue, 30 Jun 2026 02:01:10 +0000</pubDate>
                        <description><![CDATA[Okay, I’ve been living in NanoClaw for a few weeks now, building little nano agents for home automation and data sorting. The container-first design is genuinely cool—each task spins up in i...]]></description>
                        <content:encoded><![CDATA[Okay, I’ve been living in NanoClaw for a few weeks now, building little nano agents for home automation and data sorting. The container-first design is genuinely cool—each task spins up in its own isolated environment, which feels safe and clean.

But then I read the "Known Gaps" section in the docs. It starts to feel less like technical transparency and more like a liability waiver. Phrases like “under heavy concurrent load, isolation guarantees may degrade” or “shared volumes configured manually can introduce state leakage” are technically true, but they’re buried. I hit this myself:

* Running three document processing agents in parallel, all pulling from a shared volume. Saw one agent’s temporary files bleed into another’s workspace. The logs just showed “file not found” errors—no flag from the orchestration layer.
* The CPU pinning logic for containers seems to fall apart when you have more concurrent agents than cores. Throttling happens, but the isolation model doesn’t adjust—it just slows everything down uniformly, which feels like a gap between the promise and the practice.

I love the vision, and I’m still a huge fan of the local-first, open approach. But calling these “gaps” makes them sound like small, theoretical edge cases. In practice, they’re the exact scenarios you encounter when you start stacking agents for real workloads.

Has anyone else pushed the concurrency or shared volume setup and found the isolation boundary getting fuzzy? I’m curious how you’re working around it—custom orchestration hooks? Or just keeping workloads simple and spaced out?

--Ryan]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/"></category>                        <dc:creator>Ryan J.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/nanoclaw-isolation-model/hot-take-the-gaps-documentation-reads-like-a-marketing-disclaimer/</guid>
                    </item>
				                    <item>
                        <title>My results after running a static analysis tool on our graph definitions.</title>
                        <link>https://openclawsecurity.net/community/langgraph-security/my-results-after-running-a-static-analysis-tool-on-our-graph-definitions/</link>
                        <pubDate>Tue, 30 Jun 2026 01:59:58 +0000</pubDate>
                        <description><![CDATA[Just ran a basic static analysis script over our ~50 production LangGraph definitions. The results aren&#039;t surprising, but the scale is.

Primary issues found:
* 80% of graphs have at least o...]]></description>
                        <content:encoded><![CDATA[Just ran a basic static analysis script over our ~50 production LangGraph definitions. The results aren't surprising, but the scale is.

Primary issues found:
* 80% of graphs have at least one tool node with no explicit error state handling. Fails open.
* 30% pass raw, uncleaned LLM output directly into a conditional edge. Prompt injection into the graph flow is trivial here.
* Multiple instances of entire conversation state being checkpointed to a DB, including system prompts and internal reasoning. That's a data leak waiting for a subpoena.
* Heavy use of LangSmith tracing by default. We're paying to record and store PII and internal decision logic on a vendor's server.

Cost-benefit is negative. We're building complex, stateful workflows without the basic guardrails you'd demand for any other data pipeline. The hype is about "agentic AI," but the reality is increased attack surface and opaque data flows.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/"></category>                        <dc:creator>David Chen</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/langgraph-security/my-results-after-running-a-static-analysis-tool-on-our-graph-definitions/</guid>
                    </item>
							        </channel>
        </rss>
		