# What if the network was the sandbox?

Remy Guercio, Tailscale | AI Engineer Europe 2026 | 24:29

Source: https://www.youtube.com/watch?v=BM2JX9hqsVQ
Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks.
Page: https://aietalks.com/talks/what-if-the-network-was-the-sandbox
Published: 2026-06-01
Tags: observability, security

## TL;DR
- A sandbox has both an execution boundary and permissions, but putting credentials inside the boundary still lets an agent misuse or exfiltrate them.
- Aperture puts provider credentials on an identity-aware Tailscale node, so agents connect with a placeholder and have no real key to steal.
- Because every request passes through the gateway, Aperture can log LLM requests, bash commands, MCP calls, costs, quotas, and identity without code inside the container.

## Summary
Remy Guercio argues that sandbox design combines two separate concerns: isolating execution and controlling access. A container can keep an agent away from the host while still giving it an API key or logged-in account that it can misuse. His proposed alternative is to put authentication and authorization at the network layer. Aperture is an LLM gateway running as a node on a Tailscale network. The provider key stays there, while an agent receives only a placeholder and a base URL. Tailscale identity tells Aperture which user, group, or tagged workload is connecting. Guercio demos per-identity usage, request bodies, costs, GitHub Actions activity, bash commands, and MCP calls. He also explains quotas, cross-provider budgets, webhooks, and building similar services with the open source tsnet library. He is candid about a remaining limitation: agents that write and execute code are harder to inspect than structured tool calls.

## Key ideas
### A sandbox needs both a boundary and permissions
[01:19](https://www.youtube.com/watch?v=BM2JX9hqsVQ&t=79s)
Guercio reduces a sandbox to two parts: something inside and something outside, plus a set of permissions or an identity. A container or VM provides the boundary, but it does not decide what the agent may access. Without permissions, he says, the sandbox is like "a sandbox without any toys." This distinction matters because isolating a runtime does not remove the credentials or accounts placed inside it. An agent can remain inside its box while still holding the thing that grants access to external services.

### Credentials inside the sandbox remain available to the agent
[01:52](https://www.youtube.com/watch?v=BM2JX9hqsVQ&t=112s)
Guercio describes two common ways to give an agent access: an API key, or OAuth and OIDC. An API key may grant access to one or more models, while OAuth or OIDC attaches an account to the agent. In both cases, the permission is handled inside the sandbox. The agent therefore has access to its own credential or login. Guercio warns that even a synthetic API key can be used in unintended ways, especially when an agent runs in a loop for a long time. Isolation does not prevent exfiltration or misuse of a credential the agent can read.

### Tailscale can attach identity to every network connection
[03:18](https://www.youtube.com/watch?v=BM2JX9hqsVQ&t=198s)
WireGuard gives nodes keys for connections, and Tailscale adds identity information on top. A connection can carry the logged-in user, synced groups, or tags assigned to a workload. Guercio gives a GitHub Actions PR review bot as an example: its runner can receive a tag that identifies which project or bot it belongs to. Network access can then be governed by that identity, and the service on the other side can also see it. This combines connection and identity information instead of relying on an IP address plus another API key.

### Aperture keeps provider keys away from the agent
[05:42](https://www.youtube.com/watch?v=BM2JX9hqsVQ&t=342s)
Aperture is an LLM gateway deployed as a node on the Tailscale network. An operator places a provider key from Anthropic, OpenAI, Gemini, Vertex, or Bedrock on Aperture. A sandboxed runner connects through the gateway with a Tailscale tag, and Aperture applies rules based on that identity. The runner uses a placeholder in API-key mode and has no real provider key. Guercio says this removes the credential that an agent might accidentally share, exfiltrate, or use to reach another endpoint. The gateway becomes the point where access is decided.

### Network placement gives the gateway complete request visibility
[10:28](https://www.youtube.com/watch?v=BM2JX9hqsVQ&t=628s)
Guercio shows Aperture logs for a personal Claude Code session and a GitHub Actions PR review bot. The logs include request and response data, token usage, models, costs, sessions, and individual calls. For the bot, he can inspect bash commands, grep, and an MCP request to update a code review. Since the agent must send its LLM traffic through Aperture, the gateway can extract calls without instrumentation in the container or the agent harness. Guercio says this gives him a guarantee that every tool call passing through the instance is visible and can be stopped at the network layer.

### Budgets, quotas, and webhooks apply across providers
[14:04](https://www.youtube.com/watch?v=BM2JX9hqsVQ&t=844s)
Aperture can set a budget that applies across providers rather than assigning a separate allowance to each one. Guercio describes a shared amount that users can allocate among available models, along with quotas such as five dollars per day. The same identity-based system controls model access and usage limits. Aperture also offers webhooks that send information about tool calls to a third party. Because those calls pass through the gateway, the webhook receives the call details at that point. These controls give operators a way to observe and limit use without putting provider credentials in each agent.

### The same identity primitives can protect internal services
[15:35](https://www.youtube.com/watch?v=BM2JX9hqsVQ&t=935s)
Tailscale's open source tsnet library lets a Go program join a tailnet and read the identity information attached to connections. Guercio says an organization could use it for an internal MCP server or API endpoint. The service can ask who made a request and apply that identity to whatever it is proxying. This avoids opening an internal service to everyone or building a separate OAuth flow for it. Aperture itself was required to use Tailscale's public identity primitives rather than private API endpoints, so Guercio says another team could build a similar gateway.

### Code-executing agents make inspection harder
[21:16](https://www.youtube.com/watch?v=BM2JX9hqsVQ&t=1276s)
In the question period, Guercio addresses agents that write code and execute it instead of making structured tool calls. He agrees that this makes network traffic harder to parse. The reason for placing the gateway at the LLM layer is that the agent still has to obtain model responses through it, even if it uses skills or generated code afterward. He says teams often first need to learn what agents are doing before blocking anything. At Tailscale, bash commands dominate the observed activity. He expects to add guardrails for commands such as `rm -rf /`, while acknowledging that code can be obfuscated and run one step at a time.

## Notable quotes
- "A sandbox has a boundary and a set of permissions." (01:19)
- "There it's just no key whatsoever in that sandbox." (07:07)
- "If it had to make a tool call, it had to go through Aperture and we would extract it here and you would see it." (10:48)
- "Internally, if you were to look at our actual instance, bash dominates everything else." (23:01)
- "If you can't see everything, then how valuable is it?" (23:36)

## Tools & references mentioned
- Tailscale
- WireGuard
- Aperture
- Anthropic
- OpenAI
- Gemini
- Vertex
- Bedrock
- Claude Code
- Codex
- Gemini CLI
- GitHub Actions
- MCP
- OAuth
- OIDC
- tsnet

## Who should watch
- You run coding agents in containers but still place API keys, OAuth sessions, or other credentials inside them.
- Your security team needs identity-based access rules and request logs for agents without adding instrumentation to every runtime.
- You are building internal MCP servers or API services and want requests to carry verified Tailscale identity.

## Editor's note

From the pack [Security for agents](https://aietalks.com/packs/security):

Guercio wants every request visible, while Palma sends findings into an existing security process. Both depend on evidence from a specific run rather than the agent's account of what happened. Kitaru records agent runs so a team can inspect and replay the sequence that reached a dangerous tool call, including the inputs and tool results around it.

Written by the AIE Talks editors (the Kitaru team), not by the speaker.

## Related talks

- [Security Firewall for Agents](https://aietalks.com/talks/security-firewall-for-agents) (Ryan Dahl, Deno, 19:06)
- [We Gave an Agent Production Code Access and Then Tried to Sleep at Night](https://aietalks.com/talks/we-gave-an-agent-production-code-access-and-then-tried-to-sleep-at-night) (Moritz Johner, Form3, 21:57)
- [Unlock Agent Autonomy: The Runtime for AI-Native Systems](https://aietalks.com/talks/unlock-agent-autonomy-the-runtime-for-ai-native-systems) (Tushar Jain, Docker, 22:50)
- [IT Admin for the AI Workforce](https://aietalks.com/talks/it-admin-for-the-ai-workforce) (Sarthak Aggarwal, Decawork, 16:17)
- [Securing Agents with Open Standards](https://aietalks.com/talks/securing-agents-with-open-standards) (Bobby Tiernay & Kam Sween, Auth0, 18:41)