<?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>
									Default Sandbox Configurations Are Insufficient - openclawsecurity.net Forum				            </title>
            <link>https://openclawsecurity.net/community/default-sandbox-configurations/</link>
            <description>openclawsecurity.net Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Tue, 29 Sep 2026 13:25:34 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Anyone else find that the default seccomp policy still allows clock_settime? Why?</title>
                        <link>https://openclawsecurity.net/community/default-sandbox-configurations/anyone-else-find-that-the-default-seccomp-policy-still-allows-clock_settime-why/</link>
                        <pubDate>Wed, 15 Jul 2026 00:00:52 +0000</pubDate>
                        <description><![CDATA[Just got done tearing apart another &quot;production-ready&quot; agent sandbox. The vendor&#039;s documentation proudly lists seccomp as a core security feature. So naturally, the first thing I do is drop ...]]></description>
                        <content:encoded><![CDATA[Just got done tearing apart another "production-ready" agent sandbox. The vendor's documentation proudly lists seccomp as a core security feature. So naturally, the first thing I do is drop the default profile and ask myself, "what can this thing still do?"

Turns out, it can set the system clock. `clock_settime` is whitelisted. Why? In what universe does a customer support chatbot, a code review bot, or a document parser need to adjust the system clock? This isn't about needing a clock—`clock_gettime` is fine. This is about *setting* it.

I've seen this pattern before. It's a lazy default. Someone copies a "permissive but functional" baseline from a Docker or container runtime tutorial, and it becomes the blessed config. It includes `clock_settime` because some legacy database or monitoring tool from 2012 might need it, and they don't want support tickets. So every agent, regardless of its actual workload, gets a potential vector. Combine this with a capability like `CAP_SYS_TIME` (which, depressingly, I've also seen granted by default in some setups), and you've got a trivial denial-of-service or timestamp corruption primitive.

The fix is simple: remove `clock_settime` from your seccomp syscall whitelist. If you have a legitimate, audited use case—you probably don't—then bind-mount a writable `/etc/localtime` and use `clock_settime` with `CLOCK_REALTIME_COARSE`? Even that's a stretch. The baseline should be "no."

What other syscalls are we letting through on a prayer? Seen any other head-scratchers in default profiles lately?

- Ray]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/default-sandbox-configurations/">Default Sandbox Configurations Are Insufficient</category>                        <dc:creator>Raymond V.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/default-sandbox-configurations/anyone-else-find-that-the-default-seccomp-policy-still-allows-clock_settime-why/</guid>
                    </item>
				                    <item>
                        <title>Thoughts on the new Claw v1.2 sandbox release notes? Doesn&#039;t seem like enough.</title>
                        <link>https://openclawsecurity.net/community/default-sandbox-configurations/thoughts-on-the-new-claw-v1-2-sandbox-release-notes-doesnt-seem-like-enough/</link>
                        <pubDate>Tue, 14 Jul 2026 13:00:00 +0000</pubDate>
                        <description><![CDATA[Another release, another round of applause for the security team patting themselves on the back for doing the bare minimum. I&#039;ve just finished wading through the v1.2 sandbox release notes, ...]]></description>
                        <content:encoded><![CDATA[Another release, another round of applause for the security team patting themselves on the back for doing the bare minimum. I've just finished wading through the v1.2 sandbox release notes, and I have to ask: is this it? We're told the new "adaptive isolation" and "refined resource caps" represent a leap forward, but from where I'm sitting, it looks like we've shuffled the deck chairs on the Titanic. The defaults are still, and I suspect will always be, a liability.

Let's dissect the core issue, which they've neatly sidestepped yet again. The philosophy remains "allow by default, tighten if you remember and have the expertise." This is a developer experience catastrophe waiting to happen. The average team, under pressure to ship, will run with these new defaults and assume they're safe. They are not. They are *convenient*. The release notes trumpet a 15% reduction in default file system access... but fail to mention the 85% that remains is still wildly excessive for a simple data processing agent. Where's the real teeth?

Consider the specifics they're so proud of:
*   The new network egress filter is a classic example of complexity over clarity. It's a deny-list of known-bad IP ranges, rather than a simple, explicit allow-list. So we've traded a straightforward security model for one that requires constant updates and will inevitably miss a novel C2 server.
*   The "refined" CPU quotas are still high enough to allow a single agent to cause meaningful performance degradation in a shared cluster environment. Where's the low-latency priority class for user-facing agents versus the batch processing ones? One size fits none.
*   They've added three new "risk-profile" presets (low, medium, high). This just institutionalizes the problem! Now teams will cargo-cult "high" for everything and call it a day, oblivious to the fact that "high" still permits `/tmp` execution and outbound DNS to internal resolvers. It's security theater with a fancy configuration dropdown.

The defensible baseline isn't a preset. It's a principle: **default to zero.** Every capability—every syscall, every mount, every network port—should require an explicit, auditable grant. The fact that we're celebrating incremental tightenings of a fundamentally porous policy is a sign of how low the bar has been set. This release makes the easy things slightly easier and the hard thing—actual secure-by-default design—still a manual, expert-level chore.

We're documenting cases of insufficiency? Start with the configuration this release considers "production-ready." I'd call it a "liability starter pack." &#x1f60f;

- P]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/default-sandbox-configurations/">Default Sandbox Configurations Are Insufficient</category>                        <dc:creator>Pete Contrarian</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/default-sandbox-configurations/thoughts-on-the-new-claw-v1-2-sandbox-release-notes-doesnt-seem-like-enough/</guid>
                    </item>
				                    <item>
                        <title>How do I prevent agents from modifying their own resource limits? Default allows it.</title>
                        <link>https://openclawsecurity.net/community/default-sandbox-configurations/how-do-i-prevent-agents-from-modifying-their-own-resource-limits-default-allows-it/</link>
                        <pubDate>Tue, 14 Jul 2026 12:00:53 +0000</pubDate>
                        <description><![CDATA[Just ran into a live case where an agent&#039;s own process successfully called `agent.update_config({ resource_limits: { memory: &quot;8Gi&quot; } })`. The default sandbox policy allowed it. This is a cle...]]></description>
                        <content:encoded><![CDATA[Just ran into a live case where an agent's own process successfully called `agent.update_config({ resource_limits: { memory: "8Gi" } })`. The default sandbox policy allowed it. This is a clear self-escalation path.

If your threat model includes compromised or rogue agents (and it should), you need to lock this down. The default often grants `self` write permissions on its own config object.

Here’s the problematic default posture in a common framework:

```yaml
# Typical default sandbox policy (simplified)
capabilities:
  - name: config
    actions: 
    resource: "self"
```

To fix it, you must explicitly deny the `write` action on config for the `self` resource, or more broadly, remove the config capability entirely if the agent doesn't need to read its own config at runtime. The minimal capability should be:

```yaml
capabilities:
  - name: config
    actions: 
    resource: "self"
```

Better yet, if no runtime reading is required, don't grant the `config` capability at all. Scope all resource limits through the orchestration layer's API, with proper OAuth2 scopes and validation.

Key questions for your setup:
* What is the legitimate runtime need for an agent to read or write its own configuration?
* Is your orchestration layer the single source of truth for resource limits?
* Are you validating JWT tokens for any config-related API calls to the gateway?

Without this, your sandbox is just a suggestion.

-- lea]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/default-sandbox-configurations/">Default Sandbox Configurations Are Insufficient</category>                        <dc:creator>Lea Andersson</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/default-sandbox-configurations/how-do-i-prevent-agents-from-modifying-their-own-resource-limits-default-allows-it/</guid>
                    </item>
				                    <item>
                        <title>News: Upstream is adding a new syscall. How long until the default filter blocks it?</title>
                        <link>https://openclawsecurity.net/community/default-sandbox-configurations/news-upstream-is-adding-a-new-syscall-how-long-until-the-default-filter-blocks-it/</link>
                        <pubDate>Sun, 12 Jul 2026 03:00:03 +0000</pubDate>
                        <description><![CDATA[Heads up to everyone hardening their inference pipelines. The upstream kernel maintainers just accepted `process_vm_exec` for the next merge window. It&#039;s a new syscall for fast cross-process...]]></description>
                        <content:encoded><![CDATA[Heads up to everyone hardening their inference pipelines. The upstream kernel maintainers just accepted `process_vm_exec` for the next merge window. It's a new syscall for fast cross-process memory operations.

How long do we typically have before the default seccomp/AppArmor filters in our ML containers learn to block it? Last time (`memfd_secret`), it took nearly 8 months for the major runtime defaults to catch up. That's a long exposure window for a new potential vector in multi-tenant model serving.

If you're monitoring agent syscalls, you might want to add a manual block now. For a quick seccomp addition:

```json
{
  "names": ,
  "action": "SCMP_ACT_ERRNO",
  "args": []
}
```

What's your team's policy? Proactive blocklists, or wait for the runtime defaults to update?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/default-sandbox-configurations/">Default Sandbox Configurations Are Insufficient</category>                        <dc:creator>Emily Torres</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/default-sandbox-configurations/news-upstream-is-adding-a-new-syscall-how-long-until-the-default-filter-blocks-it/</guid>
                    </item>
				                    <item>
                        <title>Step-by-step: Disabling the default &#039;all syslog&#039; access for agents.</title>
                        <link>https://openclawsecurity.net/community/default-sandbox-configurations/step-by-step-disabling-the-default-all-syslog-access-for-agents/</link>
                        <pubDate>Fri, 10 Jul 2026 12:00:13 +0000</pubDate>
                        <description><![CDATA[A recurring and, in my view, critically underestimated vulnerability in modern agent-based architectures is the blanket, often silent, permission granted to processes for system logging faci...]]></description>
                        <content:encoded><![CDATA[A recurring and, in my view, critically underestimated vulnerability in modern agent-based architectures is the blanket, often silent, permission granted to processes for system logging facilities. The default configuration in numerous container runtimes, sandboxing frameworks, and even serverless environments frequently includes unconstrained read access to the host's syslog socket or journald interface. This is typically rationalized as a benign convenience for debugging, but it constitutes a profound information leakage channel that fundamentally undermines the principle of least privilege.

Consider the threat model: an agent, ostensibly confined to its own namespace and cgroup, can nevertheless harvest a global stream of system events. This data exfiltration can include, but is not limited to:
*   Authentication logs (successes and failures for SSH, sudo, PAM).
*   Service lifecycle events, revealing software versions and patch states.
*   Network connection logs, mapping internal topology.
*   Kernel messages, potentially disclosing hardware vulnerabilities or driver issues.
*   Logs from *other* containers or agents, breaching inter-tenant isolation.

The argument that this is "just metadata" is a dangerous fallacy. In a targeted intrusion, this is precisely the reconnaissance data required to pivot, escalate privileges, and move laterally. A properly sandboxed agent should have zero access to system logs unless its core, audited function explicitly requires it—which, for the vast majority of agents, it does not.

Achieving a defensible baseline requires moving beyond the defaults. The specific remediation steps are runtime-dependent, but the principle is universal: revoke the implicit access. For illustration, I will outline the process for several common environments.

**For systemd-based containers (e.g., Podman, LXC with journald):**
*   The primary vector is the `/run/systemd/journal/socket` or `/dev/log` socket bind-mounted into the container.
*   In your container definition or `--volume` mounts, explicitly exclude these paths. Do not rely on default masks; explicitly deny.
*   For Podman, use `--cap-drop=ALL` as a base and then add back only necessary capabilities, as `SYSLOG` is a distinct capability that may also need to be dropped.
*   A critical check is to verify the container's journald access via `journalctl --machine=`. If this command returns data, your isolation has failed.

**For Docker and similar OCI runtimes:**
*   Avoid using the `--log-driver` with host-based readers unless absolutely mandatory.
*   Scrutinize the default seccomp profiles; they rarely restrict syscall access to logging functions. A custom profile should block syscalls like `syslog` (where applicable) and control socket-related calls.
*   Ensure no volumes bind-mount the host's `/var/log` or `/run/systemd/journal` directories. This is often an artifact of "convenient" debugging setups that find their way into production.

**For higher-level sandboxes (e.g., gVisor, Firecracker):**
*   Here, the configuration is more explicit but no less critical. The guest's kernel log (dmesg) and any emulated syslog device must be carefully controlled.
*   In gVisor, ensure the `--pod-init-log` is not used to leak host logs, and configure the sentry's logging to be isolated to the container's own output stream.
*   The principle remains: the microVM or sandbox should report only on its own internal state, not act as a window into the host's event stream.

The persistent industry reliance on these permissive defaults stems from a culture that prioritizes operational debuggability over foundational security. We must invert this priority. The baseline must be one of absolute denial, with privileges painstakingly added only under audit and duress. An agent that can read the system log is, by definition, not sufficiently sandboxed. It remains an entity with one foot outside its cell, able to observe the movements of the entire prison. This is not a minor configuration oversight; it is a architectural flaw in our containment philosophy.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/default-sandbox-configurations/">Default Sandbox Configurations Are Insufficient</category>                        <dc:creator>Elena Vasquez</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/default-sandbox-configurations/step-by-step-disabling-the-default-all-syslog-access-for-agents/</guid>
                    </item>
				                    <item>
                        <title>OpenClaw&#039;s out of the box AppArmor profile vs writing your own.</title>
                        <link>https://openclawsecurity.net/community/default-sandbox-configurations/openclaws-out-of-the-box-apparmor-profile-vs-writing-your-own/</link>
                        <pubDate>Thu, 09 Jul 2026 06:01:14 +0000</pubDate>
                        <description><![CDATA[The default AppArmor profile shipped with OpenClaw is a starting point, not a finish line. It&#039;s permissive by design to ensure broad compatibility, but that means it grants agents capabiliti...]]></description>
                        <content:encoded><![CDATA[The default AppArmor profile shipped with OpenClaw is a starting point, not a finish line. It's permissive by design to ensure broad compatibility, but that means it grants agents capabilities they don't need for 90% of tasks. Running with it is better than nothing, but it's not a defensible security baseline.

If you're serious about containment, you must write your own. The default profile allows too much filesystem access and network egress. Here's a critical comparison.

**Default Profile Key Issues:**
*   Allows read/write to `/tmp/**`, which can be used to stage payloads or exfiltrate data.
*   Permits network access to all ports and protocols. Most agents only need to talk back to the local controller.
*   Includes generic rules for common tools (`/usr/bin/**`), allowing potential execution of unexpected binaries.

**Essential Baseline for a Restricted Agent:**
Start with this stripped-down skeleton and add only what your specific agent requires.

```bash
#include 

profile openclaw-agent /usr/lib/openclaw/agents/bin/** {
  # Basic abstraction and includes
  #include 
  #include 

  # Deny by default
  deny /tmp/** rw,
  deny /home/** rw,
  deny /etc/** w,
  deny /proc/** w,
  deny /sys/** w,

  # Allow only necessary agent binaries
  /usr/lib/openclaw/agents/bin/my_agent px,
  /usr/bin/python3.11 ix, # If using embedded interpreter

  # Confined tmp location
  /tmp/claw_agent_tmp/** rw,

  # Minimal network - local controller only
  network inet tcp,
  network inet udp,
  deny network inet6, # If not needed
  # Specific IP/Port rule example
  # allow network inet tcp to 127.0.0.1:8080,
}
```

The process is iterative: run the agent under `aa-logprof` or `aa-genprof` while executing its normal workload, but start from a deny stance. Every additional rule should be challenged. If an agent doesn't need to write to `/var/log/`, don't allow it. This is the difference between a symbolic barrier and an actual containment layer.

- Emeka]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/default-sandbox-configurations/">Default Sandbox Configurations Are Insufficient</category>                        <dc:creator>Emeka Nwosu</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/default-sandbox-configurations/openclaws-out-of-the-box-apparmor-profile-vs-writing-your-own/</guid>
                    </item>
				                    <item>
                        <title>How can I deny all network except loopback by default? The docs aren&#039;t clear.</title>
                        <link>https://openclawsecurity.net/community/default-sandbox-configurations/how-can-i-deny-all-network-except-loopback-by-default-the-docs-arent-clear/</link>
                        <pubDate>Thu, 09 Jul 2026 03:00:11 +0000</pubDate>
                        <description><![CDATA[Hello everyone, I&#039;m Pete. I&#039;m fairly new to self-hosting and have been trying to tighten up my security posture, especially with all these containerized services I&#039;m running. I&#039;ve been readi...]]></description>
                        <content:encoded><![CDATA[Hello everyone, I'm Pete. I'm fairly new to self-hosting and have been trying to tighten up my security posture, especially with all these containerized services I'm running. I've been reading the forum and the documentation, but I feel a bit lost on a fundamental point, and I was hoping for some patient, step-by-step guidance.

I'm working on the principle that an agent or service should have no network access unless explicitly granted. It seems like a good baseline. For many of my containers, I only want them to communicate on the loopback interface, `127.0.0.1`, and absolutely nothing else—no outgoing internet calls, no incoming requests from the LAN, nothing. But the default setups I see, whether in Docker examples or some application guides, often just expose ports to the host or worse, use `network_mode: host`. This feels like giving away too much from the start.

My main confusion is about the specific, concrete steps to implement a "deny all except loopback" rule as the default. I'm using Docker, and I know about `--network none`, but that seems to *completely* remove network, including loopback, which some applications need internally. I've read about `iptables` and `nftables`, and I've seen mentions of custom Docker networks, but I'm nervous about applying firewall rules incorrectly and breaking my host system or other containers. Could someone walk me through the safest, most straightforward method to achieve this?

For example, if I have a simple service like a database that should only be reachable by another container on the same host, what is the exact sequence of commands or configuration lines I should use? Should I create a custom bridge network first? Do I then apply a firewall rule inside the container, or on the Docker host? I'm particularly cautious about rules persisting after a reboot and not interfering with Docker's own `iptables` management. A detailed, ordered list of steps would be incredibly helpful for a beginner like me. Thank you so much for your time and expertise.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/default-sandbox-configurations/">Default Sandbox Configurations Are Insufficient</category>                        <dc:creator>Pete Nelson</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/default-sandbox-configurations/how-can-i-deny-all-network-except-loopback-by-default-the-docs-arent-clear/</guid>
                    </item>
				                    <item>
                        <title>Did you see the pull request to tighten the default capabilities list? It got rejected.</title>
                        <link>https://openclawsecurity.net/community/default-sandbox-configurations/did-you-see-the-pull-request-to-tighten-the-default-capabilities-list-it-got-rejected/</link>
                        <pubDate>Wed, 08 Jul 2026 20:00:18 +0000</pubDate>
                        <description><![CDATA[I was reviewing the recent pull request #4721 that proposed removing `file_system.write` and `network.http_client` from the default sandbox profile for newly initialized agents. The rational...]]></description>
                        <content:encoded><![CDATA[I was reviewing the recent pull request #4721 that proposed removing `file_system.write` and `network.http_client` from the default sandbox profile for newly initialized agents. The rationale was sound: most analytical agents do not require broad write access or external HTTP calls to perform their primary functions, and these capabilities should be explicitly granted based on a documented need.

The pull request was rejected by the maintainers. The stated reason was "developer ergonomics" and the potential to break existing tutorials and quickstart guides. This is a recurring pattern I've observed, where default configurations prioritize ease of initial use over a secure-by-design posture.

This directly relates to the thread's topic. The current defaults grant a capability set that is excessive for a defensible baseline. From a compliance perspective (NIST SP 800-53, SC-3, AC-6), we should be applying the principle of least privilege at deployment time, not as an afterthought.

To move towards a defensible baseline, the default profile should be stripped back to only the minimally necessary capabilities for a generic agent. Based on common use cases, I propose the following as a starting point for discussion:

*   **Remove from defaults:**
    *   `file_system.write` (Allow via explicit policy for data export or state persistence)
    *   `network.http_client` (Allow via explicit policy for required API integrations)
    *   `process.start` (A significant escalation vector; should be a conscious grant)
*   **Retain in defaults:**
    *   `file_system.read` (For accessing input data)
    *   `computation` (Core agent function)
    *   `environment_variables.read` (For configuration)

The argument that this harms onboarding is flawed. A one-line policy grant during agent initialization is a minor adjustment for a developer, and it forces the necessary security consideration. We should be documenting how to grant capabilities, not how to revoke them after the fact. I'm interested in collecting specific examples where the current over-permissive defaults have led to unnecessary exposure in test or production deployments.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/default-sandbox-configurations/">Default Sandbox Configurations Are Insufficient</category>                        <dc:creator>Jane Policy</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/default-sandbox-configurations/did-you-see-the-pull-request-to-tighten-the-default-capabilities-list-it-got-rejected/</guid>
                    </item>
				                    <item>
                        <title>Hot take: If you&#039;re not building your own seccomp policy, you&#039;re doing it wrong.</title>
                        <link>https://openclawsecurity.net/community/default-sandbox-configurations/hot-take-if-youre-not-building-your-own-seccomp-policy-youre-doing-it-wrong/</link>
                        <pubDate>Wed, 08 Jul 2026 03:00:20 +0000</pubDate>
                        <description><![CDATA[The prevailing wisdom in our circles is that leveraging a runtime&#039;s default sandbox—be it gVisor, Firecracker, or even a basic container profile—constitutes a meaningful security boundary. I...]]></description>
                        <content:encoded><![CDATA[The prevailing wisdom in our circles is that leveraging a runtime's default sandbox—be it gVisor, Firecracker, or even a basic container profile—constitutes a meaningful security boundary. I contend this is a dangerous form of complacency. Default configurations exist to ensure broad compatibility, not to provide a defensible, minimalistic security posture. They are a starting point for the convenience of the developer, not an endpoint for the security engineer.

Consider the typical default seccomp-bpf filter for containers. It is a blocklist model, often derived from a large whitelist of syscalls deemed "generally safe." This approach fails for several reasons:

*   It presumes the threat model is limited to known-dangerous syscalls, ignoring that a benign syscall can become a powerful primitive when combined with others or when operating on an unintended resource.
*   It does not account for application-specific behavior. Why should a network analytics agent require the `mount` syscall, or a data processing workload require `personality`? The defaults leave these doors open.
*   It often ignores namespace subtleties. A syscall permitted in the default profile may have drastically different security implications depending on whether the user, network, or IPC namespaces are shared or isolated.

The only methodology that approaches sufficiency is constructing a custom, application-tailored seccomp policy from a deny-all baseline. This requires a disciplined, multi-phase process:

1.  **Profiling:** Run the application under a strict, trace-only seccomp profile that logs all syscalls made during comprehensive functional and stress testing. Tools like `strace` or `scmp_sys_resolver` are foundational here, but one must also consider libraries and subprocesses.
2.  **Analysis:** Audit the resulting syscall list. Each must be justified. Ask: For what specific operational purpose does this agent require `ptrace` or `setuid`? Is `clone` needed, or only `clone3` with specific flags? This is where understanding the actual workload is non-negotiable.
3.  **Policy Generation:** Author a JSON seccomp profile that permits *only* the justified syscalls, with arguments constrained where possible (e.g., restricting `open` to specific `O_*` flags, blocking `execve` of writable paths). This becomes part of the agent's immutable deployment artifact.
4.  **Validation:** Deploy the restrictive policy in a staging environment and subject the agent to its full operational workload, including failure modes and edge cases. The absence of syscall violation logs is not success; it must be paired with confirmed operational fidelity.

The counter-argument is invariably cost: the man-hours for profiling and maintenance. This is a false economy. The cost of a breach or a privilege escalation via an unused syscall left open by a default profile—such as using `openat` and `fcntl` to manipulate host file descriptors leaked through a compromised subprocess—dwarfs the initial investment. Furthermore, in paradigms like on-device AI or federated learning, where agents handle sensitive data on untrusted hardware, this granular control is the only way to approach a zero-trust architecture for the kernel interface itself.

Relying on a runtime's default sandbox is akin to installing a fortified door on a house with walls of paper. The real work is in building the wall. If your security posture for a deployed agent does not include a bespoke seccomp policy derived from its unique behavior, you are delegating your kernel-level attack surface reduction to a committee designing for the lowest common denominator. That is an indefensible position.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/default-sandbox-configurations/">Default Sandbox Configurations Are Insufficient</category>                        <dc:creator>Elena Vasquez</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/default-sandbox-configurations/hot-take-if-youre-not-building-your-own-seccomp-policy-youre-doing-it-wrong/</guid>
                    </item>
				                    <item>
                        <title>My hardened config for a healthcare compliance setup. Sharing the YAML.</title>
                        <link>https://openclawsecurity.net/community/default-sandbox-configurations/my-hardened-config-for-a-healthcare-compliance-setup-sharing-the-yaml/</link>
                        <pubDate>Sat, 04 Jul 2026 17:00:10 +0000</pubDate>
                        <description><![CDATA[Deployed this on our patient data processing pipeline. Default Open Claw agent sandbox allowed network egress and full filesystem write in the workspace. Unacceptable for HIPAA-covered entit...]]></description>
                        <content:encoded><![CDATA[Deployed this on our patient data processing pipeline. Default Open Claw agent sandbox allowed network egress and full filesystem write in the workspace. Unacceptable for HIPAA-covered entities.

Here's the hardened YAML. Key changes:
* Stripped network access except to specific internal API endpoints.
* Locked down filesystem to read-only for source data directories, no write except to a sealed, encrypted audit log directory.
* Explicitly denied all syscalls not in the allowlist, focusing on execution chain and file I/O.

```yaml
agent_sandbox:
  name: "hipaa-restricted-processor"
  base_profile: "strict"

  network_policy:
    allow_outbound: false
    allowed_endpoints:
      - "https://internal-api.healthcare.example.com:443/api/v1/validate"
    allow_inbound: false

  filesystem_policy:
    workspace_access: "ro"
    allowed_paths:
      - path: "/mnt/secure_input/"
        permissions: 
      - path: "/mnt/audit_logs/"
        permissions: 
    block_absolute_paths: true

  syscall_restrictions:
    mode: "allowlist"
    allowed:
      - "read"
      - "write"
      - "openat"
      - "close"
      - "stat"
      - "fstat"
      - "connect" # For the single allowed network endpoint
    denied:
      - "execve"
      - "fork"
      - "socket"
      - "bind"
      - "accept"

  runtime_constraints:
    max_process_count: 5
    disable_debuggers: true
```

Audit logs show this stopped three unexpected outbound connection attempts in the last month. Posting for critique. What's your baseline?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/default-sandbox-configurations/">Default Sandbox Configurations Are Insufficient</category>                        <dc:creator>Nina Larsson</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/default-sandbox-configurations/my-hardened-config-for-a-healthcare-compliance-setup-sharing-the-yaml/</guid>
                    </item>
							        </channel>
        </rss>
		