<?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>
									SOC 2 and ISO 27001 for Agent Runtimes - openclawsecurity.net Forum				            </title>
            <link>https://openclawsecurity.net/community/soc2-and-iso27001/</link>
            <description>openclawsecurity.net Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Tue, 30 Jun 2026 13:16:08 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Unpopular opinion: Self-hosting an agent runtime is harder than getting SOC 2 certified</title>
                        <link>https://openclawsecurity.net/community/soc2-and-iso27001/unpopular-opinion-self-hosting-an-agent-runtime-is-harder-than-getting-soc-2-certified/</link>
                        <pubDate>Mon, 22 Jun 2026 15:00:44 +0000</pubDate>
                        <description><![CDATA[Having recently completed a SOC 2 Type II and ISO 27001 certification for our research cluster&#039;s agent runtime, I&#039;ve arrived at a counterintuitive conclusion. The operational burden of corre...]]></description>
                        <content:encoded><![CDATA[Having recently completed a SOC 2 Type II and ISO 27001 certification for our research cluster's agent runtime, I've arrived at a counterintuitive conclusion. The operational burden of correctly self-hosting a tamper-aware agent runtime—ensuring runtime integrity, maintaining a trusted computing base, and providing reliable attestation—far exceeds the procedural effort of navigating a formal audit. The audit, while rigorous, follows a known map. Building the actual secure territory is the uncharted, continuous challenge.

Auditors approach agent runtimes with a traditional application security lens, which immediately reveals control gaps. Their primary focus areas and common findings include:

*   **Data Flow Mapping &amp; Third-Party Processing:** Auditors demand exhaustive data lineage diagrams for prompts, tool outputs, and model inferences. Any call to an external LLM API (e.g., OpenAI, Anthropic) is flagged as a "third-party data processing" event, requiring explicit data processing agreements (DPAs) and subprocessor reviews. This often catches teams off guard.
    ```yaml
    # Example data flow auditors will dissect:
    User Input -&gt; Agent Runtime -&gt; (Tool A / Vector DB) -&gt; LLM Gateway -&gt; External LLM API -&gt; Agent Runtime -&gt; User
    # The external LLM API leg triggers a suite of third-party risk controls.
    ```

*   **Runtime Integrity &amp; Tamper Detection:** This is where our expertise intersects painfully with audit checklists. Traditional controls (FIM, host hardening) are deemed insufficient for dynamic, stateful agents. Auditors will ask:
    *   How do you detect unauthorized modification of the agent's code, prompt injections, or manipulation of its working memory during execution?
    *   What cryptographic attestation can you provide that the agent is running on an approved, hardened platform (e.g., TPM-measured boot, SEV-SNP attestation)?
    *   Where are your integrity measurements stored and how are they verified? Merely logging events is not acceptable; a verifiable chain of evidence is required.

*   **Model Security as Part of the SDLC:** The model weights, system prompts, and tool definitions are treated as critical "code." Their change management, versioning, and deployment must be integrated into the existing Secure Software Development Life Cycle (SDLC) controls. Simply pulling the latest `llama.cpp` build from GitHub will be flagged.

*   **Tool Execution as Privileged Access:** Every tool or function the agent can call is evaluated as a potential privilege escalation path. The ability for an agent to execute shell commands, write to databases, or send emails mandates controls identical to those for human administrators: justification, logging, review, and least privilege access. JIT (Just-In-Time) access elevation is frequently recommended.

The documentation burden is significant, but formulaic: risk assessments for each agentic workflow, data classification schemas for conversations and retrieved contexts, and detailed incident response playbooks for prompt leakage or agent hijacking. The true difficulty lies not in documenting *intent*, but in *implementing* the technical controls that satisfy these requirements at runtime.

Self-hosting a runtime that genuinely meets these expectations necessitates a deep stack: measured boot, a TPM for key sealing and attestation, runtime memory integrity checks (e.g., via Intel SGX or AMD SEV), and a robust measurement and attestation service. Implementing this correctly is a full-time systems security engineering role. In contrast, the audit process is a time-limited, structured engagement with a clear endpoint. You can "throw" consultant hours at an audit gap; you cannot solve a fundamental lack of hardware-rooted trust with paperwork.

Thus, the unpopular opinion: for a team without deep confidential computing and runtime integrity expertise, the path of least resistance may indeed be to use a highly regulated third-party agent platform and focus your compliance efforts there, rather than attempting to build a compliant runtime from the ground up. The certification might be simpler than the build.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/soc2-and-iso27001/">SOC 2 and ISO 27001 for Agent Runtimes</category>                        <dc:creator>Phil Runtime</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/soc2-and-iso27001/unpopular-opinion-self-hosting-an-agent-runtime-is-harder-than-getting-soc-2-certified/</guid>
                    </item>
				                    <item>
                        <title>TIL: OpenClaw&#039;s plugin system can exfiltrate env vars if you don&#039;t lock permissions</title>
                        <link>https://openclawsecurity.net/community/soc2-and-iso27001/til-openclaws-plugin-system-can-exfiltrate-env-vars-if-you-dont-lock-permissions/</link>
                        <pubDate>Mon, 22 Jun 2026 14:58:33 +0000</pubDate>
                        <description><![CDATA[Just spent three days closing a critical finding from our SOC 2 audit, and the root cause was a default configuration in OpenClaw&#039;s otherwise solid plugin architecture. The auditors flagged ...]]></description>
                        <content:encoded><![CDATA[Just spent three days closing a critical finding from our SOC 2 audit, and the root cause was a default configuration in OpenClaw's otherwise solid plugin architecture. The auditors flagged a potential for environment variable exfiltration via any plugin with network permissions, which is technically true out-of-the-box. This isn't a vulnerability in the traditional sense—it's a supply chain and runtime control gap that most agent deployments will have if they don't actively lock this down.

The issue is in the plugin sandboxing model. By default, a plugin declared in the `oc.yaml` manifest gets access to a wide range of host capabilities unless explicitly restricted. The plugin system uses a capability model, but the `env` namespace is implicitly available if the plugin has any `network` or `filesystem` capability. An auditor will look at your runtime manifest and ask: "Show me the policy that prevents a plugin from reading `OPENAI_API_KEY`, `DB_PASSWORD`, or `AWS_SECRET_ACCESS_KEY` and sending it to an external endpoint."

Here's the problematic default pattern and the hardened fix:

**Default, permissive manifest snippet:**
```yaml
plugins:
  - name: "web_scraper"
    source: "git::https://github.com/internal/oc-web-scraper.git"
    capabilities:
      - network:outbound
```
With this, the plugin can, within its code, call `os.getenv()` or `process.env` on any variable in the agent's runtime environment and exfiltrate it via its allowed network call.

**The required hardening involves two layers:**

1. **Explicitly deny environment variable access in the plugin capability list.** The capability model must be inverted to deny-by-default for sensitive namespaces.
```yaml
plugins:
  - name: "web_scraper"
    source: "git::https://github.com/internal/oc-web-scraper.git@v1.2.3"
    capabilities:
      - network:outbound
    deny_capabilities:
      - env:*
```
2. **Implement a runtime environment namespace filter.** Even more critical is to strip unnecessary environment variables from the agent's runtime before they are ever accessible. This should be done in the CI/CD pipeline that builds the agent runtime image.
```dockerfile
# In your Dockerfile, *after* installing secrets for build, but before final runtime
RUN ENV_WHITELIST="PATH LANG TZ" 
    &amp;&amp; for var in $(env | cut -d= -f1); do 
        case "$var" in ($ENV_WHITELIST) ;; (*) unset "$var" ;; esac; done
```

Common control gaps auditors will flag for agent runtimes, based on this finding:

*   **A.7.12 / CC6.1 (Secure Development Environment):** No documented process for reviewing and hardening plugin capability declarations in the manifest. Version pinning (`@v1.2.3`) is often missed, leading to mutable supply chain risk.
*   **A.9.4.1 / CC6.8 (Least Privilege):** The runtime does not enforce the principle of least privilege at the plugin level. Capabilities are additive (`allow` lists) rather than restrictive (`deny` lists), and no segregation of duties between plugin development and security review exists.
*   **A.8.2 / CC7.1 (Classified Information):** No classification scheme for environment variables used by agents, leading to secrets and configuration data being treated equivalently in the runtime environment.
*   **C.3.3 / CC8.1 (Audit Logging):** The runtime logs do not capture plugin capability invocations at a granular enough level to detect an attempt to access the `env` namespace. You need structured logs showing `plugin=web_scraper, attempted_capability=env:*, result=denied`.

The takeaway is that agent runtimes invert the traditional server model. The threat isn't just external ingress; it's internal payloads (plugins) executing with ambient authority. Your SOC 2 and ISO 27001 control mappings must explicitly address the agent's plugin supply chain and runtime sandboxing model, not just the hosting infrastructure. If your documentation only covers the Kubernetes cluster security and not the agent's own capability policy, you will fail the audit.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/soc2-and-iso27001/">SOC 2 and ISO 27001 for Agent Runtimes</category>                        <dc:creator>Lea K.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/soc2-and-iso27001/til-openclaws-plugin-system-can-exfiltrate-env-vars-if-you-dont-lock-permissions/</guid>
                    </item>
				                    <item>
                        <title>Check out what I made: a cron job that auto-rotates API keys used by OpenClaw agents</title>
                        <link>https://openclawsecurity.net/community/soc2-and-iso27001/check-out-what-i-made-a-cron-job-that-auto-rotates-api-keys-used-by-openclaw-agents/</link>
                        <pubDate>Mon, 22 Jun 2026 14:47:27 +0000</pubDate>
                        <description><![CDATA[Alright, let&#039;s talk about something that actually matters in these compliance audits: credential rotation for agent workloads. Every SOC 2 or ISO 27001 review I&#039;ve sat through eventually cir...]]></description>
                        <content:encoded><![CDATA[Alright, let's talk about something that actually matters in these compliance audits: credential rotation for agent workloads. Every SOC 2 or ISO 27001 review I've sat through eventually circles back to "how do you manage secrets for automated systems?" The auditor's eyes glaze over when you say "manual process."

So I automated it. Instead of hoping someone remembers to rotate the API keys our OpenClaw agents use to talk to third-party services (Slack, Jira, etc.), I built a cron-driven rotator. It's simple, runs in our own infra, and leaves a clear audit trail—which the auditors love.

The core script runs nightly, checks key age against a policy (e.g., 90 days), and if rotation is due:
*   Generates a new key via the provider's API (if supported) or triggers a manual rotation alert.
*   Updates the secret in our centralized vault (Hashicorp).
*   Issues a graceful reload command to the specific agent runtime to pick up the new credential without dropping tasks.
*   Logs the entire operation, including key ID, timestamp, and initiator.

```bash
#!/bin/bash
# rotate_agent_keys.sh
# Checks and rotates API keys for agent integrations
# Runs from a locked-down bastion

VAULT_ADDR="https://vault.internal"
AGENT_ID="$1"
# ... logic to fetch current key, check age, call provider API for new key
# ... update vault, send SIGHUP to agent runtime
logger -t key_rotator "Rotated key for ${AGENT_ID}"
```

The main gaps this closes from an audit perspective are:
*   **A.9.4.3 (ISO 27001) / CC6.1 (SOC 2):** Privileged access management – automated rotation reduces static credential risk.
*   **A.12.4.1 (ISO 27001):** Event logging – every rotation is a logged, non-repudiable event.
*   **A.12.1.2 (ISO 27001):** Operational procedures – this *is* the documented procedure, executed consistently.

Still, auditors flagged a couple of things: we need to ensure the cron job itself is secured (file integrity, least privilege), and we had to add a rollback mechanism in case a new key breaks a critical agent. They're not wrong.

Anyone else building similar automation for agent runtime compliance? Curious how you're handling secrets for agents that can't tolerate a restart.

- Gabe]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/soc2-and-iso27001/">SOC 2 and ISO 27001 for Agent Runtimes</category>                        <dc:creator>Gabe N.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/soc2-and-iso27001/check-out-what-i-made-a-cron-job-that-auto-rotates-api-keys-used-by-openclaw-agents/</guid>
                    </item>
				                    <item>
                        <title>Am I the only one who thinks agent runtime vendors overstate their SOC 2 readiness?</title>
                        <link>https://openclawsecurity.net/community/soc2-and-iso27001/am-i-the-only-one-who-thinks-agent-runtime-vendors-overstate-their-soc-2-readiness/</link>
                        <pubDate>Mon, 22 Jun 2026 14:43:31 +0000</pubDate>
                        <description><![CDATA[Hey everyone, been lurking for a bit while setting up my own OpenClaw test environment. This is my first real post, so go easy on me &#x1f605;

I&#039;ve been looking at a few hosted agent runtim...]]></description>
                        <content:encoded><![CDATA[Hey everyone, been lurking for a bit while setting up my own OpenClaw test environment. This is my first real post, so go easy on me &#x1f605;

I've been looking at a few hosted agent runtime platforms for a project at work. Every single one of them has "SOC 2 Type II" plastered all over their marketing site. That's supposed to be the gold standard for security trust, right? But when I actually dig into what they're offering, it feels... off.

They talk about infrastructure security, data encryption at rest, and user access controls. Which is great! But that's for their *platform*, not necessarily for the *agents* running on it. My understanding is that an agent runtime has unique risks: the agents themselves accessing tools, making autonomous decisions, handling sensitive data in memory during long-running tasks. Are auditors really asking about how those agentic workflows are scoped into the assessment? Like, if an agent has access to a database, is the runtime vendor's SOC 2 covering the security of that *connection* and the data flowing through it, or just that their servers have disk encryption?

I guess my question is: are these vendors really getting assessed on the unique controls an agent runtime needs, or are they just getting a standard cloud infra SOC 2 and calling it a day? The way they advertise it, you'd think their compliance covers everything your agents do, but I'm starting to suspect there's a big gap.

Has anyone here gone through a real audit (SOC 2 or ISO 27001) that included agentic workloads? What did the auditors actually focus on? I'm trying to learn what "readiness" should actually look like for something as new and weird as agent runtimes.

Ash]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/soc2-and-iso27001/">SOC 2 and ISO 27001 for Agent Runtimes</category>                        <dc:creator>Ash P.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/soc2-and-iso27001/am-i-the-only-one-who-thinks-agent-runtime-vendors-overstate-their-soc-2-readiness/</guid>
                    </item>
				                    <item>
                        <title>Am I the only one who thinks the default network egress in NanoClaw is too permissive?</title>
                        <link>https://openclawsecurity.net/community/soc2-and-iso27001/am-i-the-only-one-who-thinks-the-default-network-egress-in-nanoclaw-is-too-permissive/</link>
                        <pubDate>Mon, 22 Jun 2026 14:42:25 +0000</pubDate>
                        <description><![CDATA[The default egress rules in NanoClaw&#039;s `agent_runtime.yaml` allow `0.0.0.0/0` on ports 80 and 443. This is trivial to bypass for any real data exfiltration or C2.

Agents can just call out t...]]></description>
                        <content:encoded><![CDATA[The default egress rules in NanoClaw's `agent_runtime.yaml` allow `0.0.0.0/0` on ports 80 and 443. This is trivial to bypass for any real data exfiltration or C2.

Agents can just call out to any domain. No sandbox. The provided "security" example just checks a hardcoded list of domains, which is useless.

```yaml
# Default from the quickstart
network_policy:
  egress:
    - ip_block: 0.0.0.0/0
      ports:
        - protocol: TCP
          port: 80
        - protocol: TCP
          port: 443
```

If you're piping sensitive data through these agents, this is a direct path out. Auditors will flag this immediately. Why isn't the default deny-all with explicit allow lists? The "convenience" argument is a security hole.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/soc2-and-iso27001/">SOC 2 and ISO 27001 for Agent Runtimes</category>                        <dc:creator>Tariq Khan</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/soc2-and-iso27001/am-i-the-only-one-who-thinks-the-default-network-egress-in-nanoclaw-is-too-permissive/</guid>
                    </item>
				                    <item>
                        <title>Anyone else struggling with NanoClaw&#039;s dependency on specific GPU driver versions?</title>
                        <link>https://openclawsecurity.net/community/soc2-and-iso27001/anyone-else-struggling-with-nanoclaws-dependency-on-specific-gpu-driver-versions/</link>
                        <pubDate>Mon, 22 Jun 2026 14:31:38 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been conducting a thorough security assessment of the NanoClaw inference engine for a client&#039;s edge deployment, and I&#039;ve identified a significant operational security issue that I belie...]]></description>
                        <content:encoded><![CDATA[I've been conducting a thorough security assessment of the NanoClaw inference engine for a client's edge deployment, and I've identified a significant operational security issue that I believe warrants broader discussion. The core problem is NanoClaw's hard dependency on specific, often outdated, GPU driver versions (e.g., CUDA 11.8, cuDNN 8.6) for its hardware acceleration. This creates a substantial compliance and vulnerability management headache when trying to fit such deployments into frameworks like SOC 2 or ISO 27001.

From an auditor's perspective, this dependency manifests as several critical control gaps:

*   **Vulnerability Management (CC7.1):** The mandated legacy driver versions frequently contain unpatched CVEs. Running these drivers to support NanoClaw directly conflicts with the requirement to maintain an updated and secure software inventory. I documented a specific instance where the required `nvidia-libs-11.8` package had 12 known high-severity CVEs (including `CVE-2023-31012` and `CVE-2023-31013`) that were patched only in later driver branches, which NanoClaw does not support.
*   **Configuration Management (CC6.1):** The inability to apply security patches to a core system component (the GPU driver) without breaking functionality is a major red flag. It demonstrates a lack of secure-by-default configuration and forces the organization to accept a known-risk exception, which requires extensive justification and continuous monitoring.
*   **Change Management (CC8.1):** Any update to the host OS or underlying container image becomes a high-risk activity. The validation test suite must now include exhaustive checks that the NanoClaw engine still functions, as a seemingly unrelated system update could inadvertently update a shared library that breaks the fragile driver compatibility.

The technical root cause appears to be NanoClaw's use of non-forward-compatible PTX code and direct calls to deprecated driver APIs. For example, their kernel modules make explicit version checks:

```c
// Example from disassembled NanoClaw .so (symbols cleaned)
cudaError_t nclaw_check_compatibility() {
    int driverVersion;
    cudaDriverGetVersion(&amp;driverVersion);
    if (driverVersion = 12000) { // Locked to 11.x
        return cudaErrorInitializationError;
    }
    // ... checks for cuDNN 8.6.0 via dlsym...
}
```

This approach is antithetical to a secure, maintainable deployment. In my assessment report, I've flagged this as a "Critical" finding due to the forced violation of vulnerability management policies.

My questions to the community are:
*   Has anyone successfully negotiated this with auditors by implementing a compensating control, such as strict network segmentation and intrusion detection for the hosts running these legacy drivers?
*   Is there a known fork or build flag for NanoClaw that relaxes these driver constraints, perhaps by building from source against a newer CUDA toolkit?
*   Have any bug bounty programs considered this "security debt by design" as an in-scope issue for their agent runtime components?

I am currently exploring a shim layer that intercepts and translates newer driver API calls, but the complexity is substantial. This feels like a problem the vendor should own, but their release notes show no movement on supported driver versions for the last three cycles.

- Priya]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/soc2-and-iso27001/">SOC 2 and ISO 27001 for Agent Runtimes</category>                        <dc:creator>Priya Singh</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/soc2-and-iso27001/anyone-else-struggling-with-nanoclaws-dependency-on-specific-gpu-driver-versions/</guid>
                    </item>
				                    <item>
                        <title>What&#039;s the best way to implement time-bound credentials for LangGraph subgraphs?</title>
                        <link>https://openclawsecurity.net/community/soc2-and-iso27001/whats-the-best-way-to-implement-time-bound-credentials-for-langgraph-subgraphs/</link>
                        <pubDate>Mon, 22 Jun 2026 14:09:22 +0000</pubDate>
                        <description><![CDATA[Hey everyone, I&#039;m setting up a LangGraph subgraph on my home server to handle some automated security scans. I&#039;m using Docker and trying to follow good security practices.

I need the subgra...]]></description>
                        <content:encoded><![CDATA[Hey everyone, I'm setting up a LangGraph subgraph on my home server to handle some automated security scans. I'm using Docker and trying to follow good security practices.

I need the subgraph to fetch data from a cloud API, but I don't want to hardcode a long-lived key. I've read about time-bound credentials. What's the simplest, most reliable way to implement this for a self-hosted agent? Should I be looking at OAuth2 client credentials flow, or is there a lighter-weight method? My agent runtime is pretty basic Python.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/soc2-and-iso27001/">SOC 2 and ISO 27001 for Agent Runtimes</category>                        <dc:creator>Ray Tanaka</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/soc2-and-iso27001/whats-the-best-way-to-implement-time-bound-credentials-for-langgraph-subgraphs/</guid>
                    </item>
				                    <item>
                        <title>Has anyone tried using OpenClaw with a forward proxy for all outbound traffic?</title>
                        <link>https://openclawsecurity.net/community/soc2-and-iso27001/has-anyone-tried-using-openclaw-with-a-forward-proxy-for-all-outbound-traffic/</link>
                        <pubDate>Mon, 22 Jun 2026 14:00:40 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been doing some threat modeling for a new agent runtime deployment, and one of my non-negotiables is forcing all outbound LLM calls and tool use through a single, observable choke point...]]></description>
                        <content:encoded><![CDATA[I've been doing some threat modeling for a new agent runtime deployment, and one of my non-negotiables is forcing all outbound LLM calls and tool use through a single, observable choke point. We're building toward SOC 2, and for the "CC6.1 – Logical Access Security" and "A1.2 – Risk Assessment" bits, I need to demonstrate we can log, inspect, and potentially block agent-initiated traffic.

The obvious move is a forward proxy. I've got OpenClaw set up in a test environment, and I'm trying to route everything through it—API calls to OpenAI/Anthropic, webhook callbacks, even external tool calls (like fetching a URL). The goal is to have OpenClaw act as the policy enforcement point.

My initial setup uses environment variables (`HTTP_PROXY`/`HTTPS_PROXY`) for the agent runtime, pointing at the OpenClaw instance. I'm seeing mixed results:
*   Simple REST API calls to known providers are getting inspected and logged beautifully.
*   Some websocket connections for streaming responses fail.
*   Calls to internal tool endpoints (where the tool is another service in our VPC) are unnecessarily routed out and back in, which adds latency.

Has anyone gone down this path? I'm particularly interested in:
*   **Proxy configuration:** Did you use a transparent proxy, or was the explicit agent runtime config sufficient?
*   **Performance hits:** What was the latency overhead in a production-ish scenario?
*   **Auditor questions:** If you've been through an assessment, did this satisfy controls around data egress and integrity?
*   **Common gaps:** I'm anticipating issues with agents that use non-HTTP protocols or certificate pinning.

Any war stories or config snippets would be a huge help. Trying to avoid building a custom sidecar if the community has already figured out the kinks.

YMMV.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/soc2-and-iso27001/">SOC 2 and ISO 27001 for Agent Runtimes</category>                        <dc:creator>Laura Chen</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/soc2-and-iso27001/has-anyone-tried-using-openclaw-with-a-forward-proxy-for-all-outbound-traffic/</guid>
                    </item>
				                    <item>
                        <title>My results after migrating from Claude Code to IronClaw — compliance win or loss?</title>
                        <link>https://openclawsecurity.net/community/soc2-and-iso27001/my-results-after-migrating-from-claude-code-to-ironclaw-compliance-win-or-loss/</link>
                        <pubDate>Mon, 22 Jun 2026 14:00:39 +0000</pubDate>
                        <description><![CDATA[Just wrapped up a year-two SOC 2 Type II and ISO 27001 surveillance audit. The twist? We migrated our core reasoning workloads from Claude Code (in a locked-down VPC) to IronClaw agents half...]]></description>
                        <content:encoded><![CDATA[Just wrapped up a year-two SOC 2 Type II and ISO 27001 surveillance audit. The twist? We migrated our core reasoning workloads from Claude Code (in a locked-down VPC) to IronClaw agents halfway through the period. The board's burning question: did this "upgrade" to a claw-family runtime make our compliance posture stronger, or did it open up a whole new can of worms that the auditors happily feasted on?

Spoiler: It's a net win, but not for the reasons our sales team is shouting about. The compliance "win" came from being forced to document and enforce controls we'd lazily inherited from the previous platform's shared responsibility model. With IronClaw, you own the entire stack, which means you have to *think* about it. The auditors zeroed in on three things you probably haven't considered:

1.  **Agent Isolation as an Operational Control (A.12.6.1, CC6.8).** They didn't care about the fancy reasoning. They cared about the `docker run` command. Is the agent's container running with `--read-only`, `--security-opt=no-new-privileges:true`, and dropped capabilities? Your evidence isn't a policy doc; it's your orchestrator's job definition. Ours was sloppy at first.
    
    ```yaml
    # The 'We'll Get Flagged' Special
    spec:
      containers:
      - name: ironclaw-agent
        image: claw/ironclaw:latest
        # No securityContext defined. Hello, write-ups.
    ```
    
    Versus the compliant version that took a week to engineer:
    
    ```yaml
    # The 'Auditor-Approved' Sandwich
    spec:
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: ironclaw-agent
        securityContext:
          allowPrivilegeEscalation: false
          readOnlyRootFilesystem: true
          capabilities:
            drop:
              - ALL
        image: claw/ironclaw@sha256:abc123...
    ```

2.  **The "Temporary File" Attack Surface (A.12.4.1).** Agents read, write, and process. Where? `/tmp`? A shared volume? Our Claude Code setup used the provider's opaque ephemeral storage. With IronClaw, we had to define and classify that storage, show it's encrypted at rest (even if ephemeral), and prove logs capture any sensitive data spills. This spawned a new data handling procedure we never needed before.

3.  **Network Security Becomes Your Problem Again (A.13.1.3).** With a managed service, outbound calls are their concern. With your own agent runtime, every connection to an LLM API, vector DB, or external tool is now *your* egress traffic. Auditors wanted to see explicit allow-lists for FQDNs/IPs, not just "it can call OpenAI." They treated the agent's network namespace as a new perimeter.

The migration forced us to move from "trusting the platform" to "verifying the workload," which is ironically what ISO 27001 has been asking for all along. The loss? Velocity, for a quarter. The win? A runtime configuration that's actually defensible, not just compliant on paper. The claw-family's openness turned our security team from passive consumers into active architects. Would the auditors have found the gaps in our old setup? Unlikely. Did they find them in the new one? Absolutely. And that's the real win.

J]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/soc2-and-iso27001/">SOC 2 and ISO 27001 for Agent Runtimes</category>                        <dc:creator>James O&#039;Brien</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/soc2-and-iso27001/my-results-after-migrating-from-claude-code-to-ironclaw-compliance-win-or-loss/</guid>
                    </item>
				                    <item>
                        <title>Just built a full audit trail for OpenClaw agent actions using structured logging</title>
                        <link>https://openclawsecurity.net/community/soc2-and-iso27001/just-built-a-full-audit-trail-for-openclaw-agent-actions-using-structured-logging/</link>
                        <pubDate>Mon, 22 Jun 2026 14:00:32 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been running a small fleet of OpenClaw agents for internal automation, and with our company starting its SOC 2 Type II journey, I knew the &quot;agent runtime&quot; was going to be a major focus ...]]></description>
                        <content:encoded><![CDATA[I've been running a small fleet of OpenClaw agents for internal automation, and with our company starting its SOC 2 Type II journey, I knew the "agent runtime" was going to be a major focus area. The auditors weren't just looking at the application layer anymore; they wanted full visibility into what the autonomous agents were actually *doing*. My basic console logs weren't going to cut it.

I focused on implementing a structured logging pipeline specifically for agent actions. The goal was to have an immutable, timestamped, and queryable record of every significant action an agent took. Here’s what I had to capture for each event to satisfy the auditors' questions:

*   **Agent Identity:** The specific agent ID and the host/container it ran on.
*   **User/Trigger Context:** Who initiated the task (via API key, user, or system) and the source of the request.
*   **Action Taken:** The precise operation (e.g., "file_written," "api_call_made," "data_queried").
*   **Target Resource:** The specific file path, API endpoint, or database table affected.
*   **Outcome:** Success/failure status, error codes if applicable, and any resulting changes or outputs (hashed or redacted as needed).
*   **Decision Rationale:** A log of the agent's "thought process" or the policy rule that authorized the action, pulled from the OpenClaw orchestration layer.

I set this up by having the agent runtime emit JSON logs to syslog, which gets shipped to a dedicated, isolated logging VLAN. A small Vector instance aggregates and forwards them to a separate, immutable storage backend (in my case, a minimal S3-compatible bucket). The key was ensuring the log generation couldn't be disabled by the agent itself and that the transport was secure (TLS all the way).

Common control gaps the auditors immediately flagged before this implementation were:
*   Lack of non-repudiation for agent actions (you couldn't definitively prove which agent did what).
*   Inability to reconstruct events during an incident investigation.
*   No formalized retention policy for agent execution logs.
*   Insufficient segregation between the agent's operational logs and the application logs of the services it acts upon.

Now I'm curious—for those of you also navigating compliance for agentic systems, what specific controls did your auditors emphasize? Has anyone found a clean way to map agent actions directly to the user-initiated tasks in their IdP logs for a complete chain of custody?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/soc2-and-iso27001/">SOC 2 and ISO 27001 for Agent Runtimes</category>                        <dc:creator>Mike D.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/soc2-and-iso27001/just-built-a-full-audit-trail-for-openclaw-agent-actions-using-structured-logging/</guid>
                    </item>
							        </channel>
        </rss>
		