Кейс · Безопасность AI-агентов
Sallyport CloudДва человека сделали работу отдела безопасности: AI-агенты делают 100 000+ вызовов в день без единого ключа
Sallyport Cloud хранит API-ключи в зашифрованном хранилище, подставляет их в вызовы агента и делает эти вызовы сам: по MCP, HTTP, SSH и через подключения к базам данных. Ключа у агента нет, поэтому ни утёкший промпт, ни перехваченный агент отдать его не могут. Сейчас через шлюз идёт больше 100 000 вызовов агентов в день, к каждому он добавляет меньше 20 мс, и ни один ключ не утёк. Я спроектировал архитектуру, отвечал за соответствие шифрования требованиям и проверил всю систему на уязвимости, в том числе через проект Daybreak от OpenAI: проверка нашла больше 30 проблем, и все они закрыты. Собрала продукт команда из двух человек вместе с AI-агентами, хотя продукту безопасности обычно нужен целый отдел и соответствующий бюджет.
- Клиент
- Sallyport Cloud
- Продукт
- Шлюз ключей для AI-агентов (MCP proxy)
- Нагрузка
- 100 000+ вызовов агентов в день, меньше 20 мс на вызов
- Каналы
- MCP, HTTP, SSH и базы данных: 4 канала, один шлюз
- Агентские клиенты
- 9 на одном адресе, от Claude Code до ChatGPT и Cursor
- Моя роль
- CTO по подписке, по сей день
- Команда
- 2 человека, AI-native, без отдельного отдела безопасности
- Сайт
- sallyport.cloud

В цифрах
- вызовов агентов в день через шлюз, и ни один ключ не утёк
- 100 000+
- добавляет шлюз к вызову, и безопасность не тормозит агентов
- <20 мс
- находок проверки OpenAI Daybreak, и каждая закрыта навсегда
- 30+
- сервисов доступны агентам без ключа, каждый вызов размечен по риску
- 120
- способов прочитать сохранённый ключ, даже для нашей команды
- 0
- человека делают работу целой команды безопасности
- 2
Продукт
Публичный сайт: шлюз, каталог рецептов и схемы архитектуры и журнала со страницы о безопасности.
С чего начинали
AI-агенту, который делает настоящую работу, нужны ключи к GitHub, Stripe, облаку и базе данных, и любой ключ, отданный агенту, рано или поздно может утечь. Sallyport Cloud даёт агенту действие, а ключ оставляет у себя: агент называет вызов, шлюз берёт ключ из зашифрованного хранилища, сам делает вызов и возвращает результат.
Сервис хранит production-ключи своих клиентов, поэтому планку для всего остального задавала безопасность. Я работаю в нём CTO по подписке и выстроил продукт так, чтобы команда из двух человек, полностью AI-native, взяла эту планку без отдела безопасности, который для таких продуктов обычно нанимают.
Что мы сделали
Один процесс: ключу некуда утечь, а вызов остаётся быстрым
Я спроектировал шлюз как один процесс на Go: он держит подключение к базе, хранилище ключей и журнал и сам делает исходящий вызов. Внутри платформы нет второго звена, которому можно передать ключ: ключ выходит из хранилища один раз на вызов и только для вызова, который уже разрешён. Без второго звена шлюз ещё и работает быстро: к вызову он добавляет меньше 20 мс. Так исчезает целый класс утечек, с которым большинство многосервисных платформ живёт годами. Хранилище и шлюз работают в США.
Корневой ключ, который не может использовать или потерять один человек
За соответствие шифрования требованиям отвечал я. Ключи хранятся с envelope-шифрованием: корневой ключ открывает ключ арендатора, тот открывает ключ домена данных, а каждая запись запечатана своим подключом (HKDF-SHA256, ChaCha20-Poly1305). Корневой ключ разделён на три доли, и любые две его восстанавливают, поэтому потерянная доля ничего не стоит, а украденная ничего не открывает. Ни один маршрут не возвращает сохранённый ключ, а тест роняет сборку, если ключ где-то превращается в строку Go: такую строку нельзя стереть из памяти. Большинство команд приходит к такой тщательности только после инцидента.
Один клиент никогда не доберётся до данных другого
Шлюз ходит в PostgreSQL под ролью, которая ничем не владеет и не может обойти row-level security, и каждая транзакция ограничена одним арендатором и его пространствами. У каждого арендатора свой пул HTTP-соединений, поэтому запрос одного клиента никогда не идёт по соединению другого. Список запретов, вкомпилированный в бинарник, отказывает частным адресам, метаданным облака и собственным хостам шлюза, а имя хоста резолвится заново в момент вызова, и подменить разрешённое имя внутренним адресом не выйдет.
Рискованный вызов ждёт человека, и каждый вызов оставляет доказательство
Человек может одобрить вызов в консоли или в Telegram до того, как он уйдёт, или разрешить набор действий на выбранный срок и с лимитом вызовов. Каждый вызов записывается в журнал арендатора до исполнения, и каждая запись связана хешем с предыдущей и подписана Ed25519. Изменённую или удалённую строку видно сразу, а цепочку можно проверить без наших ключей, так что аудитору клиента не приходится верить нам на слово.
Один адрес для 9 агентских клиентов и 100 000+ вызовов в день
Claude Code, claude.ai, ChatGPT, Cursor, Codex, Gemini CLI, VS Code и API Claude и OpenAI подключаются к одному MCP-адресу. Кроме MCP, агенты вызывают сервисы через HTTP proxy, выполняют команды по SSH и делают запросы к PostgreSQL, MySQL, SQL Server, ClickHouse, MongoDB и Redis. Каталог описывает 120 сервисов и относит каждый вызов к read, write или destructive, поэтому клиент подключает каждого агента один раз, а не настраивает и защищает каждого по отдельности. Вместе агенты делают через шлюз больше 100 000 вызовов в день.
Проверено сертифицированным этичным хакером, 30+ находок закрыты навсегда
Я Certified Ethical Hacker (CEH), у меня также есть сертификаты CompTIA Security+ и CCNP Security, так что продукт получил проверку безопасности того уровня, который компании обычно заказывают у внешней фирмы. Я проверил всю систему на уязвимости, в том числе через проект Daybreak от OpenAI, к которому у меня есть доступ, и проверка нашла больше 30 проблем. Каждую сначала воспроизводил тест, падавший на старом коде, потом её исправляли, и тест остаётся в наборе, поэтому закрытая дыра не откроется снова. Закрыты все, и ни один ключ клиента не утёк. Хранилище ключей, egress-фильтр и журнал покрыты тестами на 95% и больше.
Два человека и AI-агенты вместо целого отдела
Код и тесты пишут AI-агенты по спецификации и файлу правил, где названо каждое правило безопасности, которое код обязан соблюдать. Тесты сервера идут на настоящем PostgreSQL. Этот способ работы выстроил я, и он позволяет двум людям выпускать и вести продукт безопасности в темпе и за деньги, недоступные штатной команде обычного размера.
Результат
Sallyport Cloud работает: через него идёт больше 100 000 вызовов агентов в день, к каждому шлюз добавляет меньше 20 мс, и ни один ключ не утёк. Бесплатный план рассчитан на 10 000 вызовов в месяц, платные стоят от $19 за агента в месяц. Продукт безопасности, для которого обычно держат отдел, строит и ведёт команда из двух человек, и ни один агент в нём не держит ключа.
Стек
- Go
- PostgreSQL
- React
- Next.js
- MCP
- OAuth 2.1
- ChaCha20-Poly1305
- Ed25519
- AWS
- Cloudflare
- Docker
- GitLab CI
- Sentry
- Claude Code
Полный кейс · PDF
Sallyport Cloud
Два человека сделали работу отдела безопасности: AI-агенты делают 100 000+ вызовов в день без единого ключа
- 01Архитектура со схемами: один процесс, хранилище ключей и журнал
- 02Схема шифрования и доли корневого ключа для восстановления
- 03Изоляция арендаторов: роли базы, row-level security, пулы соединений
- 04Как проводилась проверка на уязвимости, что она нашла и как закреплено каждое исправление
- 05Одобрение вызовов и подписанный журнал, который аудитор проверит сам
- 06Как команда из двух человек строит продукт безопасности, для которого обычно держат отдел
Полный кейс Sallyport Cloud
Открытая часть истории на этом заканчивается. Остальное в PDF: архитектура до и после, план переезда, как команда работает с AI-агентами, сколько всё это стоит в эксплуатации и откуда взялась экономия.
Другие кейсы
Все кейсыХотите, чтобы следующий кейс был про вашу компанию?
За 30 минут созвона выберем первую задачу, которую стоит отдать AI, и прикинем, сколько она сэкономит.




