goodra7174

How do you handle the placeholder to real credential swap on the network side, is the isolated VM's egress forced through the gateway as a transparent proxy, or does the agent have to make an explicit call back to the gateway for each action?

Asking because that decision changes your failure mode a lot. If egress is forced through the gateway, a slow or down gateway just breaks connectivity and the agent fails closed by construction, which is a nice property. If the agent calls back explicitly, you're relying on the agent to actually make that call correctly every time, and now you need to check that no tool has a code path that reaches the real network directly and bypasses the swap.

clawdlinux.org building the Kubernetes-native runtime that AI agents call to provision their own secure execution environments — the missing infrastructure layer for every enterprise that can’t send agent data to the cloud

#Ycombinator #buildinpublic #startups

clawdlinux.org building the Kubernetes-native runtime that AI agents call to provision their own secure execution environments — the missing infrastructure layer for every enterprise that can’t send agent data to the cloud

#Ycombinator #buildinpublic #startups

How does it know its ai generated ? How does it validate that ?

The tmpfs overlay approach is smart — writes never touch the host. We've been solving a related but different problem: running AI agent workloads (not just coding agents) in production Kubernetes clusters where the agents can't make outbound calls at all. Air-gapped environments where the LLM inference runs on-cluster via Ollama or vLLM.

The isolation model is different — instead of protecting the developer's machine, we're protecting the enterprise's network from the agent. NetworkPolicies + FQDN egress control per agent namespace.

Question: how do you handle persistent state across sessions? If the agent needs to remember what it learned from a previous run, does the tmpfs model break that?

The HTTPS_PROXY approach is clever — interface-agnostic credential brokering without modifying the agent itself.

We ran into the same problem from the infrastructure side. When you're running agent workloads on Kubernetes, the blast radius of a leaked credential scales with whatever the pod's ServiceAccount can reach. We ended up combining Cilium FQDN egress policies (agents can only call approved endpoints) with per-workload tool allowlists enforced at the CRD level. The network-level lockdown means even if the agent is prompt-injected, it physically cannot exfiltrate to an unauthorized domain.

Curious: have you tested AV with agents that make tool calls through MCP servers? The proxy would need to handle the MCP server's outbound requests too, not just the agent's direct calls.

Great curious to try it out. Have you posted on Linkedkin as well ?

I was looking for something similar to try out. Cool!