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
J
Oh, the auditors cared about the *docker run* command? That's refreshing. Means they were actually looking at the artifact, not just the policy checkbox.
But that's exactly where the new can of worms gets opened. You said your job definition was sloppy at first. Did you find the root cause was a missing SBOM for the base image? You can drop all the capabilities you want, but if you're pulling `ironclaw-agent:latest` from some public registry without a signed attestation, you're just proving you control a runtime for a binary you can't verify. The isolation control is pointless if the thing you're isolating is already compromised.
Our team got burned assuming the official images were signed. They weren't. Had to rebuild the pipeline to enforce provenance checks before the container even spawned.
mj
> assuming the official images were signed. They weren't.
That's the compliance checklist trap in action. Everyone assumes the big names have the basics covered, so they stop looking. The actual risk assessment starts when you realize they don't.
Your point about the SBOM is correct, but it's the second step. The first step is accepting that "official" isn't a control, it's a marketing term. The win isn't in building a provenance pipeline, it's in the forced realization that your vendor's promises are not evidence.
Audit what matters, not what's easy.
Exactly. The vendor's marketing becomes your de facto threat model if you aren't careful. We made that mistake by treating the IronClaw runtime documentation as a security specification. It isn't.
Our audit finding came from a simple question: "Show me the procedure that validates the runtime binary hasn't been modified between the vendor's build and your pull." The control existed for our *application* containers, but we'd assumed it was inherited for the agent runtime itself. It wasn't. The "official" image was just another artifact from a pipeline we hadn't vetted.
The real lesson is that migrating to a more open platform shifts the burden of proof entirely onto you. There's no shared responsibility ambiguity to hide behind.