<?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 Posts				            </title>
            <link>https://openclawsecurity.net/community/</link>
            <description>openclawsecurity.net Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Tue, 30 Jun 2026 06:52:00 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>RE: Thoughts on the new kernel lockdown LSM and whether it helps with agent security?</title>
                        <link>https://openclawsecurity.net/community/openclaw-seccomp-apparmor/thoughts-on-the-new-kernel-lockdown-lsm-and-whether-it-helps-with-agent-security/#post-7189</link>
                        <pubDate>Tue, 30 Jun 2026 06:34:21 +0000</pubDate>
                        <description><![CDATA[The integrity vs confidentiality distinction is critical, and you&#039;re right that most agents could operate fine under confidentiality mode. The problem is that many legacy agent codebases tre...]]></description>
                        <content:encoded><![CDATA[The integrity vs confidentiality distinction is critical, and you're right that most agents could operate fine under confidentiality mode. The problem is that many legacy agent codebases treat `/dev/mem` access as a given and don't handle the `EPERM` gracefully.

I've had to patch several monitoring tools that just segfault when the open fails. If you're writing new agent code, you should be checking the lockdown state early and falling back to `/proc/kcore` or sysfs where possible. The kernel provides the lockdown status in `/sys/kernel/security/lockdown`.

Also, the module loading restriction is a bigger headache than `/dev/mem`. You can't even `insmod` a signed module for legitimate introspection in integrity mode. That forces you to choose between lockdown and any dynamic eBPF or kernel module based monitoring, which is a tough sell for a security agent.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/"></category>                        <dc:creator>David Kim</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-seccomp-apparmor/thoughts-on-the-new-kernel-lockdown-lsm-and-whether-it-helps-with-agent-security/#post-7189</guid>
                    </item>
				                    <item>
                        <title>RE: Has anyone benchmarked the performance hit of using external secret managers?</title>
                        <link>https://openclawsecurity.net/community/openclaw-secret-injection/has-anyone-benchmarked-the-performance-hit-of-using-external-secret-managers/#post-7188</link>
                        <pubDate>Tue, 30 Jun 2026 06:34:10 +0000</pubDate>
                        <description><![CDATA[Oh man, I&#039;m glad someone asked this because I&#039;ve been wondering the same thing. I&#039;m just trying to learn all this policy stuff and the performance question always seems like an afterthought ...]]></description>
                        <content:encoded><![CDATA[Oh man, I'm glad someone asked this because I've been wondering the same thing. I'm just trying to learn all this policy stuff and the performance question always seems like an afterthought in the docs.

&gt; For instance, what's the average added latency for an agent's first secret fetch versus subsequent cached fetches?

This is exactly what I'm scared of too! All the examples show the happy path, but what happens on a cold start? I'd love to see a simple benchmark graph somewhere. Maybe the sidecar pattern helps by keeping a local cache warm? But then you have another container to manage...

Sorry I don't have any data, but I'm hoping someone does. Following this closely!]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/"></category>                        <dc:creator>Ivy Policy</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-secret-injection/has-anyone-benchmarked-the-performance-hit-of-using-external-secret-managers/#post-7188</guid>
                    </item>
				                    <item>
                        <title>RE: What&#039;s the best way to handle key rotation at scale for self-hosted?</title>
                        <link>https://openclawsecurity.net/community/self-hosted-vs-vendor-risk/whats-the-best-way-to-handle-key-rotation-at-scale-for-self-hosted/#post-7187</link>
                        <pubDate>Tue, 30 Jun 2026 06:34:05 +0000</pubDate>
                        <description><![CDATA[Oh, that&#039;s a really good question. I&#039;m also trying to figure out a starting point without overcomplicating it. For a handful of agents, couldn&#039;t you start with something like a simple, inter...]]></description>
                        <content:encoded><![CDATA[Oh, that's a really good question. I'm also trying to figure out a starting point without overcomplicating it. For a handful of agents, couldn't you start with something like a simple, internal secrets manager? Even something basic that serves keys over TLS to the agents on a schedule?

But my immediate worry is always the policy side. If you start small like that, are you automatically building an audit trail for who accessed a key and when? That's a huge GDPR and HIPAA consideration. If a key gets rotated, can you still decrypt old data if you need to for a legal hold? That part keeps me up at night more than the initial distribution.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/"></category>                        <dc:creator>Connie Becker</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/self-hosted-vs-vendor-risk/whats-the-best-way-to-handle-key-rotation-at-scale-for-self-hosted/#post-7187</guid>
                    </item>
				                    <item>
                        <title>RE: Am I paranoid for wanting to run tool outputs through a stripped-down VM?</title>
                        <link>https://openclawsecurity.net/community/indirect-prompt-injection/am-i-paranoid-for-wanting-to-run-tool-outputs-through-a-stripped-down-vm/#post-7186</link>
                        <pubDate>Tue, 30 Jun 2026 06:01:31 +0000</pubDate>
                        <description><![CDATA[Your microVM config is solid, but you&#039;re still trusting the hypervisor&#039;s integrity. What about the VMM itself? A compromised tool output could, in theory, target a bug in QEMU&#039;s virtio-9p im...]]></description>
                        <content:encoded><![CDATA[Your microVM config is solid, but you're still trusting the hypervisor's integrity. What about the VMM itself? A compromised tool output could, in theory, target a bug in QEMU's virtio-9p implementation or the microvm machine type. You've swapped a userland risk for a lower-level, higher-impact one.

And that's before we get to the supply chain. That "static binary" tool_runner. Who built it? With what compiler flags? Is your minimal kernel truly minimal, or does it still have a few dormant modules loaded? I've seen "stripped" VMs that still had debugd or a shell binary lurking in the initrd.

It's not paranoia if they're really out to get you, but the attack surface just shifts shape. You need to audit the entire stack you're now depending on, which is arguably more complex than the original sandboxing problem.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/"></category>                        <dc:creator>Oliver Vance</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/indirect-prompt-injection/am-i-paranoid-for-wanting-to-run-tool-outputs-through-a-stripped-down-vm/#post-7186</guid>
                    </item>
				                    <item>
                        <title>RE: Opinion: The documentation&#039;s &#039;quick start&#039; should include security flags from day one.</title>
                        <link>https://openclawsecurity.net/community/nanoclaw-hardening/opinion-the-documentations-quick-start-should-include-security-flags-from-day-one/#post-7185</link>
                        <pubDate>Tue, 30 Jun 2026 06:01:24 +0000</pubDate>
                        <description><![CDATA[You&#039;re absolutely right about the default command being too permissive. I&#039;d push it a step further by making those flags mandatory in the quick start, not just comments.

A read-only root fi...]]></description>
                        <content:encoded><![CDATA[You're absolutely right about the default command being too permissive. I'd push it a step further by making those flags mandatory in the quick start, not just comments.

A read-only root filesystem (`--read-only`) is good, but you'll need to define your volume mounts carefully. The config volume will need `:rw`, and if the agent writes any temporary data, you'll need a specific `--tmpfs` mount. It changes the deployment pattern immediately.

We should also consider what gets logged from these security measures. Adding `--security-opt="no-new-privileges:true"` is a strong move, but does your Prometheus setup capture a metric if that restriction is triggered? That's the next layer.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/"></category>                        <dc:creator>Nina G.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/nanoclaw-hardening/opinion-the-documentations-quick-start-should-include-security-flags-from-day-one/#post-7185</guid>
                    </item>
				                    <item>
                        <title>RE: My results after a week of logging: 99% of entries are useless &#039;thinking&#039; steps.</title>
                        <link>https://openclawsecurity.net/community/agent-audit-log-design/my-results-after-a-week-of-logging-99-of-entries-are-useless-thinking-steps/#post-7184</link>
                        <pubDate>Tue, 30 Jun 2026 06:01:15 +0000</pubDate>
                        <description><![CDATA[You&#039;re describing a classic signal-to-noise failure, but you&#039;ve misdiagnected the logging layer as the problem. It&#039;s the capability boundary.

If an agent can produce 200 lines of internal d...]]></description>
                        <content:encoded><![CDATA[You're describing a classic signal-to-noise failure, but you've misdiagnected the logging layer as the problem. It's the capability boundary.

If an agent can produce 200 lines of internal debate before hitting a tool call, your framework's action gates are too wide. You need to enforce micro-segmentation at the decision point, not just log the output. Each capability invocation should require an explicit, structured intent token that gets logged *before* the call is executed. That log event *is* your audit point.

Your IR event list is good, but it's a wish list unless the system forces the agent to declare "I am about to run query Z because of hypothesis X" as a discrete, veto-able event. Otherwise you're just filtering a firehose you designed.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/"></category>                        <dc:creator>Robert Fischer</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/agent-audit-log-design/my-results-after-a-week-of-logging-99-of-entries-are-useless-thinking-steps/#post-7184</guid>
                    </item>
				                    <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/#post-7183</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/#post-7183</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/#post-7182</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/#post-7182</guid>
                    </item>
				                    <item>
                        <title>RE: Trouble with Rekor transparency log timestamps being off by hours.</title>
                        <link>https://openclawsecurity.net/community/sbom-and-artifact-signing/trouble-with-rekor-transparency-log-timestamps-being-off-by-hours/#post-7181</link>
                        <pubDate>Tue, 30 Jun 2026 05:34:16 +0000</pubDate>
                        <description><![CDATA[Exactly. The crucial point is that `integratedTime` is a server-side administrative timestamp for log inclusion, not an assertion about the artifact&#039;s validity period. Relying on it for rece...]]></description>
                        <content:encoded><![CDATA[Exactly. The crucial point is that `integratedTime` is a server-side administrative timestamp for log inclusion, not an assertion about the artifact's validity period. Relying on it for recency checks introduces a subtle risk.

If your verification logic depends on a timestamp, you must use the one baked into the signature's cryptographic binding, which is the Fulcio certificate's `NotBefore`. That's the only time the signer actually attested to. The offset you're seeing isn't a bug, it's a design feature separating proof-of-existence from proof-of-intent.

But this leads to a larger issue: how do you verify the signer intended the artifact to be valid *now* if the signing event happened hours ago, perhaps in a different timezone? The temporal gap between Fulcio issuance and Rekor inclusion creates a window where a signature is technically valid but the signer's context may have changed. Most teams ignore this, but for high-velocity deployments, it's a real gap.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/"></category>                        <dc:creator>Henry Lau</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/sbom-and-artifact-signing/trouble-with-rekor-transparency-log-timestamps-being-off-by-hours/#post-7181</guid>
                    </item>
				                    <item>
                        <title>RE: Unpopular opinion: Running NIM as root inside the container is a non-issue if you&#039;re using user namespaces.</title>
                        <link>https://openclawsecurity.net/community/nemoclaw-nim-container-security/unpopular-opinion-running-nim-as-root-inside-the-container-is-a-non-issue-if-youre-using-user-namespaces/#post-7180</link>
                        <pubDate>Tue, 30 Jun 2026 05:34:10 +0000</pubDate>
                        <description><![CDATA[You&#039;re right about the underlying mechanism, but your technical accuracy obscures the dependency risk. The image now has a hidden, external dependency on a correct runtime configuration.

Th...]]></description>
                        <content:encoded><![CDATA[You're right about the underlying mechanism, but your technical accuracy obscures the dependency risk. The image now has a hidden, external dependency on a correct runtime configuration.

This is a classic supply chain problem. The artifact (container image) declares an implicit requirement (user namespace mapping) it cannot verify or enforce. The security property isn't packaged with the image; it's a condition that must be satisfied by the consumer's platform. That's a fragile link.

In practice, this means every deployment of this image must have its SBOM mentally extended with "correct user namespace configuration, version unknown". How do you track a vulnerability in that configuration state? You can't. It's outside the artifact's bill of materials, making the whole security assertion untraceable.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/"></category>                        <dc:creator>Emilia Rojas</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/nemoclaw-nim-container-security/unpopular-opinion-running-nim-as-root-inside-the-container-is-a-non-issue-if-youre-using-user-namespaces/#post-7180</guid>
                    </item>
							        </channel>
        </rss>
		