What if the network was the sandbox? — Remy Guercio, Tailscale (Рубрика AI4SDLC)
Посмотрел этот доклад Remy Guercio из Tailscale с конфы AI Engineer, 1 июня 2026, где разговор шел про то, как запускать AI агентовв организацию, если им нужны ключи, доступы, MCP tools и иногда production-данные. Сам Remy Guercio занимается стратегическими проектам в Tailscale, который многие знают как "удобный VPN на WireGuard". Но сама компания давно позиционирует себя шире - как платформа для связи с нулевым доверием (zero trust) и основанная на identity. То есть сеть, где устройство, пользователь, workload или CI job подключаются не как безымянный IP, а как сущность с identity, группами, тегами и политиками доступа.
На этом фоне Tailscale теперь заходит в AI governance через Aperture. Это продукт, сейчас в beta, который работает как AI gateway: стоит между вашими агентами/LLM-клиентами и провайдерами моделей вроде OpenAI, Anthropic, Google или самостоятельно развернутых OpenAI-совместимых решений. И главная идея доклада такая: если сеть на базе WireGuard уже умеет надёжно понимать, кто именно делает запрос, зачем класть настоящий API key внутрь sandbox'а с агентом?
Обычная модель выглядит так. Мы запускаем агента в контейнере, VM, GitHub Actions runner или другом sandbox. Вроде бы он изолирован. Но чтобы он был полезным, мы кладем внутрь разрешения: API key к Anthropic/OpenAI, OAuth token, доступ к tool'ам, иногда секреты к внутренним сервисам. Получается странная конструкция: sandbox ограничивает среду исполнения кода, но access control живет внутри этой же среды. Если агент работает долго, утащит ключ, обойдет обертку или начнет ходить напрямую, sandbox уже мало помогает.
Guercio предлагает инверсию: вынести AuthN/AuthZ на сетевой слой. Агенту не дают настоящий ключ. Ему дают только base_url на Aperture и, по сути, пустую заглушку вместо provider API key, чтобы существующий LLM-клиент продолжил работать. Сам Aperture живет в tailnet (Tailscale network), хранит ключи провайдерову себя, видит identity входящего соединения и решает: этому пользователю, устройству, CI job или tagged agent можно идти к такой модели, с таким лимитом и такими правилами. Если доступ запрещен или quota исчерпана, агенту нечего "попробовать в другом месте": ключа у него никогда не было.
Это и есть "network as sandbox" в практическом смысле. Не "контейнеры больше не нужны", конечно. Контейнер или VM все еще нужны для filesystem, process isolation и выполнения кода. Но сетевой слой становится границей разрешений: кто может вызвать модель, какой агент может ходить к какому endpoint'у, сколько он может потратить, какие tool calls видны в аудите.
Что Tailscale предлагает из коробки.
1️⃣ Aperture как продукт: единый AI gateway для организации. Он убирает раздачу API keys по ноутбукам, devcontainer'ам и CI; маршрутизирует запросы к разным провайдерам по model name; логирует запросы, ответы, tool use, bash-команды, MCP-вызовы, токены и стоимость; позволяет задавать budgets, quotas, ограничения по пользователям, группам, агентам и моделям; умеет отправлять события во внешние системы через webhooks для security, audit и compliance.
2️⃣ Aperture CLI как open source tooling: launcher для coding agents, который конфигурирует Claude Code, Codex, Gemini CLI, OpenCode, GitHub Copilot CLI и другие инструменты на работу через Aperture. Важная деталь: это не новый coding agent, а слой настройки и подключения к gateway. Репозиторий открыт, но сам проект помечен как alpha.
3️⃣ tsnet как open source библиотека: Go-библиотека, позволяющая встроить Tailscale прямо в программу. То есть ваш внутренний MCP server, proxy, admin endpoint или собственный agent gateway может сам стать node'ой в tailnet и читать identity вызывающего клиента без отдельной OAuth-интеграции. Это сильная часть истории: Aperture — продукт, но underlying pattern можно повторять внутри своих платформенных сервисов.
Плюс у Tailscale открыт значительный кусок клиентского кода: tailscaled и tailscale CLI живут в GitHub-репозитории. Это не значит, что весь Tailscale как SaaS лежит open source, но для платформенных команд важно другое: примитивы вокруг клиента и tsnet можно изучать, расширять и использовать в своей инфраструктуре.
Почему это важно для production AI.
- Это убирает проблему утекания ключей. Пока AI в компании живет как набор личных токенов в IDE, CI secrets и локальных конфигов, никакого production governance нет.
- Это дает нормальную атрибуцию и наблюдаемость без переписывания агента. Для production мало знать, что "Claude что-то сделал". Нужно знать, какой пользователь, какой agent, какой CI workflow, какая модель, какой function call, какой MCP-запрос, какая bash-команда, сколько токенов, какая стоимость и какой результат.
- Это делает AI rollout управляемым для security, platform и finance. Можно разрешить дешевую модель всем, дорогую — отдельным группам, background agents — с жесткими лимитами, PR review bot — только в конкретном repo scope, а подозрительные tool calls отправлять webhook'ом в security-систему.
- Это показывает, куда движется инфраструктура агентов. Production AI — это не только evals, prompts и RAG. Это еще и identity, policy, audit, cost control, routing, secrets management и observability.
Главный вывод для меня: sandbox для агента — это не только место, где он запускается. Это еще и место, где живут его разрешения. Если разрешения лежат внутри sandbox'а, агент потенциально владеет собственными ключами. Если разрешения вынесены в identity-aware network и gateway, агент становится гораздо менее опасным: он может действовать, но не может унести с собой право действовать.
#AI #AI4SDLC #Security #PlatformEngineering #DevOps #Architecture