What if the network was the sandbox? — Remy Guercio, Tailscale (Category AI4SDLC)

I saw it. report Remy Guercio from Tailscale from AI Engineer Confa, 1 June 2026It’s about how to run AI agents into an organization if they need keys, accesses, MCP tools, and sometimes production data. Remy Guercio himself is engaged in strategic projects at Tailscale, which many people know as the “convenient VPN on WireGuard”. But the company has long positioned itself more broadly as a platform to connect with zero trust. (zero trust) It's based on identity. A network where a device, user, workload, or CI job is connected not as an unnamed IP, but as an entity with identity, groups, tags, and access policies.

On this background, Tailscale now enters AI governance through Aperture. It’s a product, now in beta, that works like an AI gateway: between your agents/LLM clients and model providers like OpenAI, Anthropic, Google or self-deployed OpenAI-compatible solutions. The main message of the report is: If a WireGuard-based network already knows who is querying, why put a real API key inside a sandbox with an agent?

The normal model looks like this. We run the agent in a container, VM, GitHub Actions runner or another sandbox. He seems isolated. But to make it useful, we put in the permissions: API key to Anthropic/OpenAI, OAuth token, access to tools, sometimes secrets to internal services. The result is a strange design: sandbox limits the execution environment, but access control lives inside the same environment. If the agent works long hours, pulls the key, bypasses the wrapper, or starts walking straight, the sandbox doesn’t help much.

Guercio offers an inversion: bring AuthN/AuthZ to the network layer. The agent is not given the real key. They only give it to him. base_url Aperture and essentially a blank plug instead of the provider API key to keep the existing LLM client running. Aperture itself lives in tailnet (Tailscale network)It stores the keys to the provider itself, sees the identity of the incoming connection and decides: this user, device, CI job or tagged agent can go to such a model, with such a limit and such rules. If access is denied or quota is exhausted, the agent has nothing to "try elsewhere": he never had the key.

This is “network as sandbox” in a practical sense. Not "containers are no longer needed," of course. A container or VM is still needed for filesystem, process isolation, and code execution. But the network layer becomes the permission boundary: who can call the model, which agent can go to which endpoint, how much it can spend, what tool calls are visible in the audit.

What Tailscale offers out of the box.

1Aperture as a product: a single AI gateway for an organization. It removes the distribution of API keys to laptops, devcontainers and CI; routes requests to different providers by model name; logs requests, answers, tool use, bash commands, MCP calls, tokens and cost; allows you to set budgets, quotas, restrictions on users, groups, agents and models; can send events to external systems through webhooks for security, audit compliance and compliance. 2Aperture CLI as an open source tooling: launcher for coding agents that configures Claude Code, Codex, Gemini CLI, OpenCode, GitHub Copilot CLI and other tools to work through Aperture. Important detail: this is not a new coding agent, but a layer of configuration and connection to the gateway. The repository is open, but the project itself is labeled alpha. 3️⃣ tsnet how open source libraryGo-library that allows you to embed Tailscale directly into the program. That is, your internal MCP server, proxy, admin endpoint, or proprietary agent gateway can become a node in the tailnet and read the identity of the calling client without separate OAuth integration. This is a strong part of the story: Aperture is a product, but the underlying pattern can be replicated within your platform services.

Plus, Tailscale has a significant piece of client code: tailscaled and tailscale CLI live in GitHub repositories. This is not to say that all of Tailscale as SaaS is open source, but for platform teams, something else is important: primitives around the client and the client. tsnet You can explore, expand and use it in your infrastructure.

Why is this important for production AI?

1. This eliminates the problem of leaking keys. As long as AI in a company lives as a set of personal tokens in IDE, CI secrets and local configs, there is no production governance.
2. This gives normal attribution and observability without rewriting the agent. For production, it's not enough to know that "Claude did something." You need to know which user, which agent, which CI workflow, which model, which function call, which MCP request, which bash command, how many tokens, what cost and what result.
3. This makes AI rollout manageable for security, platform and finance. You can allow a cheap model to everyone, an expensive one to individual groups, background agents with strict limits, PR review bot only in a specific repo scope, and suspicious tool calls to send webhook to a security system.
4. It shows where the agent infrastructure is going. Production AI is not just about evals, prompts and RAG. These include identity, policy, audit, cost control, routing, secrets management and observability.

The main takeaway for me is that an agent’s sandbox isn’t just where it launches. This is also where his permissions live. If the permissions are inside a sandbox, the agent potentially owns its own keys. If permissions are made to the identity-aware network and gateway, the agent becomes much less dangerous: he can act, but can not take with him the right to act.

#AI #AI4SDLC #Security #PlatformEngineering #DevOps #Architecture