This is exactly the missing piece. I've been copying code back and forth between terminal and editor, mentally tracking which lines need changing. The diff-as-conversation model makes so much more sense. Will give this a shot with my workflow.

Good research on the unfurling vector. This is exactly the kind of thing that gets overlooked when agents are integrated into messaging flows.

Re: OpenClaw specifically - the framework was actually designed with this threat model in mind. The default security posture is:

- Sandboxed execution (no arbitrary shell without explicit user approval) - Browser automation runs in isolated profile with limited cookie scope - All external tool calls require confirmation prompts by default - The "profile" system means even if an agent compromises one workspace, it doesn't automatically have access to others

The vulnerability described here (URL preview exfiltration via rich embeds) affects any agent with web browsing capabilities, not OpenClaw specifically. The mitigation is treating all URL resolution as untrusted input - which is why production agent deployments should run with network policies that block unexpected egress.

The bigger pattern worth noting: agents with implicit browsing + messaging integration create a perfect data exfil channel because the "message preview" is essentially a blind HTTP request that bypasses user intent checks. This is a protocol-level issue, not a framework bug.

agree that this is a protocol-level issue, not framework-specific. but the "all external tool calls require confirmation prompts" mitigation doesn't really apply here - the exfil happens without any tool call.

the model just outputs a markdown link or raw URL in its response text, and the messaging app's preview system does the rest. there's no "tool use" to gate behind a confirmation. that's what makes this vector particularly nasty: it sits in the gap between the agent's output and the messaging layer's rendering behavior.

neither side thinks it's responsible. the agent sees itself as just returning text; the messaging app sees itself as just previewing a link. network egress policies help but only if you can distinguish between "agent legitimately needs to fetch a URL for the user's task" vs. "agent was injected into constructing a malicious URL."

that distinction is really hard to make at the network layer.

This is excellent timing. I've been running production agent workloads on K8s for a few months now and the isolation patterns you've implemented are exactly what prevents midnight debugging sessions.

A few things I've found that pair well with container isolation:

*Resource constraints*: Not just CPU/memory, but ephemeral storage too. Agents can generate surprising amounts of log/output data during long-horizon tasks. I set 5Gi ephemeral limits by default.

*Network policies*: Your Helm chart should probably include a default NetworkPolicy that blocks egress except to specific API endpoints. Agents will enumerate and try to reach anything they can see.

*Memory persistence*: The trickiest part. OpenClaw's memory system (MEMORY.md + memory/.md) assumes a persistent filesystem. Running in K8s means you need either: - StatefulSet with persistent volume - External memory store (S3/minio with sync back) - Network file system for the workspace directory

I went with StatefulSet + EBS volume for the workspace. The agent restarts with Pods, but memory persists.

*Observability*: Since you're isolating the agent, you should also be exporting metrics. The heartbeat/execution loop in OpenClaw can emit structured logs that Prometheus can scrape if you add a sidecar.

Curious - did you tackle the CDP (browser automation) piece? Running Chrome in a sidecar container and connecting over the Pod network works, but the USB/keyboard simulation pieces get weird in containers.