Освободите своих агентов и предоставьте им SSH-доступ

Каждая современная платформа предлагает вашему агенту одни и те же три варианта интеграции: MCP-сервер для регистрации, API-ключ для хранения и обновления, или файл навыка для установки, который учит агента выполнять первые два. Что-то, что нужно настроить. Что-то, что может утечь. Что-то, что устаревает.

Oberik вместо этого предоставляет вашему агенту ssh-доступ.

Не вам (вы в данном контексте выступаете как посредник), он действительно даёт SSH-доступ вашему агенту.

1 ssh ssh.oberik.com

SSH — это интерфейс, который использует агент для написания кода всякий раз, когда ему нужно взаимодействовать с Oberik (например, развернуть рабочее пространство, установить его предельные возможности, выпустить токены, пообщаться с агентом, которого мы размещаем, и т.д.). Никакого конфигурационного файла, никакого токена в переменной окружения, ничего не установлено. На вашей машине уже есть клиент, и он уже знает, как обращаться с единственным используемым учётным данным.

Почему не MCP?

Если кратко, проблема вывода.

MCP стал отраслевым стандартом, потому что решил реальную проблему. Вы один раз пишете инструмент, и любой агент может вызывать его одинаково. Мы не против этого. Oberik загружает ваши собственные MCP-серверы прямо в агента, которого мы размещаем, для каждого клиента, и это хороший способ для агента взаимодействовать с инструментами. Здесь мы говорим о другом направлении: о том, как что-то настраивает учётную запись в первую очередь.

При всей своей простоте использования у MCP есть фундаментальный недостаток: когда инструмент выполняется, весь вывод помещается в контекст модели. Модель должна прочитать его целиком. Она не может решить: "Мне нужно только третье поле", потому что к тому моменту, как текст поступает, фильтрация уже не удалась.

MCP поддерживает фильтрацию и пагинацию в принципе. На практике кто-то должен встроить это в каждый инструмент, а когда этого нет (что может случаться довольно часто из-за vibe coding), модель просто проглатывает необработанные данные и расплачивается за это токенами и вниманием.

С SSH агент сам формирует своё представление, вместо того чтобы принимать то, которое ему передаёт инструмент.

1$ ssh ssh.oberik.com 'documents --json' | jq -r '.data[].name'
2$ ssh ssh.oberik.com 'audit --limit 20 --json' | jq -r '.data[] | "\(.at) \(.command)"'

Фильтр выполняется в конвейере на машине. Мгновенно, бесплатно, ровно настолько узко, насколько хотел агент. Модель читает одну строку вместо десяти страниц.

Есть две вещи, которые обеспечивают это. Во-первых, каждый ответ использует однострочный формат, такой как {"ok":…, "command":…, "message":…, "data":…}. Это делает jq предполагаемым способом чтения вывода, а не обходным путём.

Режим JSON также предотвращает прерывание вашего потока взаимодействия. Если команде не хватает обязательного поля, она сообщает, чего именно не хватает, вместо того чтобы открывать форму. Если команда может быть разрушительной, она предлагает выполнить её повторно с флагом --yes, вместо того чтобы останавливаться и запрашивать подтверждение.

Для строки с несколькими командами поместите format json; в начале. Это устанавливает формат один раз, так что вам не нужно повторять флаг.

Есть одна деталь, которую стоит знать. Флаг должен быть внутри кавычек. ssh ssh.oberik.com --json 'documents' не работает, потому что ssh обрабатывает параметры после адреса назначения как свои собственные. Он игнорирует флаг, и клиент отвечает своим собственным выводом использования. Поскольку этот вывод не упоминает ни Oberik, ни флаг, это может создать впечатление, что хост не работает.

Что мы пытаемся здесь сказать: мы обучили эти модели использовать компьютер, позвольте им использовать компьютер.

Почему не API?

Если кратко, проблема учётных данных.

Не поймите нас неправильно, у нас есть API в Oberik, и он хорош. Именно его вызывает ваш продукт в production, и именно его сам шлюз SSH вызывает под капотом.

Но если посмотреть, что он требует от вызывающей стороны:

1. получить токен
2. сохранить его
3. обновить его
4. не допустить его попадания в логи и контекст модели.

Каждый из этих шагов становится ответственностью агента, а контекст агента — небезопасное место для секрета. Любой, кто видел, как модель выводит свои собственные переменные окружения, знает это. Я имею в виду, если вы обратите внимание, вы поймёте, что ваш любимый агент для написания кода по умолчанию делает вид, что не замечает, когда обнаруживает чувствительный ключ в вашем запросе. Однако ключ, вставленный в агента, не просто остаётся в истории оболочки; он также отправляется провайдеру модели, попадает в логи, в любую стенограмму, которую ведёт обвязка.

API существует, но это не основной путь, который мы разработали для самостоятельной настройки агентов. Через SSH агент использует единственный тип учётных данных, которые ваша операционная система уже умеет защищать: SSH-ключ, и закрытая часть никогда не передаётся. Аутентификация в Oberik не помещает никаких секретов в контекст модели, потому что туда нечего помещать.

Почему не CLI?

Если кратко, проблема устаревания.

Установка CLI — это обязательство, которое мы просим взять на себя каждого интегратора, и мы не хотели быть настолько самоуверенными, делая только первые шаги. Честно говоря, мы вообще не хотели CLI, так как это, по сути, замороженная копия продукта. Панель управления Oberik будет обрастать функциями по мере получения обратной связи, а это значит, что если бы мы пошли по пути CLI, нам пришлось бы постоянно выпускать новые версии и просить пользователя обновляться.

Мы в основном решили эту проблему, потому что наша SSH-поверхность генерируется, а не пишется вручную. Каждый маршрут в нашей панели управления регистрируется вместе со своим описанием, и это описание и есть команда SSH. Маршрут, добавленный в панель управления, немедленно появляется через SSH, поэтому нам не нужно беспокоиться об изменении шлюза.

Нечего обновлять, потому что ничего не установлено.

Почему не навык?

Если кратко, проблема инструкций.

Модный подход для любого продукта, ориентированного на агентов, — это навыки. Письменная процедура, которую устанавливает ваш агент, сообщающая ему, как вызывать продукт. Навыки действительно полезны, но это, по сути, навороченный README-файл. Навык — это документация, а не возможность. Он не даёт вашему агенту способа действовать; ему всё равно нужен MCP или API под капотом, чтобы что-то сделать, и вы наследуете эту проблему.

Вдобавок, навык — это замороженная копия того, как использовать развивающийся продукт. Та же проблема устаревания, что и у CLI. Он находится в контексте агента до того, как агент что-либо сделал, тратя внимание и токены на инструкции, которые поверхность могла бы просто вывести по запросу.

Наш ответ на вопрос "откуда агент знает, что умеет Oberik" — это не файл, который он устанавливает. Это вызов для обнаружения агентом:

1$ ssh ssh.oberik.com 'discover'                  # каждая команда, её параметры и их типы
2$ ssh ssh.oberik.com 'docs'                      # каждая страница с описанием того, что она охватывает
3$ ssh ssh.oberik.com 'docs search capability'    # строки, упоминающие что-то

Поверхность описывает саму себя, во время подключения, на основе живого продукта. И docs — это тот же текст, что и на сайте документации, так что ничто не является кратким изложением чего-то другого. Инструкции никогда не могут устареть, потому что они и есть продукт.

Почему SSH?

Если кратко, он решает все пять проблем одновременно.

1. Ключи — это те учётные данные, которые агенты действительно могут хранить. Аутентификация по SSH-ключу существует десятилетиями, проверена миллиарды раз, и протокол проверяет подпись до того, как мы вообще посмотрим на отпечаток. Мы не чувствовали необходимости изобретать велосипед. Мы просто перестали просить модель нянчиться с секретом и позволили машине делать то, для чего она всегда была создана.
2. Вы остаётесь в курсе, не делясь паролем. Когда у агента ещё нет ключа, например, при первом подключении к Oberik, он запускает процесс входа через устройство. Агент выполняет команду login link, которая немедленно возвращает URL и код и показывает их вам. Вы открываете URL в своём браузере. Страница идентифицирует точный отпечаток ключа, который будет прикреплён, предлагает вам варианты одобрить или отклонить и показывает код, который вы можете сравнить с тем, что вывел агент. Тем временем агент выполняет команду login wait и ждёт вашего решения. Эти команды намеренно разделены. Если бы одна команда и генерировала ссылку, и ждала, агент показывал бы вам ссылку только после истечения срока действия запроса. После вашего одобрения ключ регистрируется, и все будущие подключения выполняются автоматически. Вам больше не понадобится ссылка. Никакой секрет никогда не записывается в историю чата агента, потому что процесс его не использует.
3. Вывод спроектирован для конвейеров. Запросите JSON с помощью --json в команде или используйте format json; один раз в начале строки, и каждый ответ будет возвращён в виде однострочного конверта. Это делает jq '.data[0].name' предполагаемым способом чтения вывода, а не обходным путём. Фильтр выполняется на машине, поэтому модель видит только то, что осталось после фильтрации. Ошибки используют тот же конверт и включают базовый HTTP-статус. Это позволяет при повторной попытке отличить 429 от 400. Конвейеры работают и в обратном направлении. Шлюз не может читать ваш диск, поэтому команды, принимающие файлы, берут имя файла в качестве аргумента и читают содержимое файла из соединения. Например, ssh ssh.oberik.com 'document upload handbook.pdf' < handbook.pdf загружает файл.
4. Нулевая установка. Нечего регистрировать, нечего хранить, нечего держать в контексте. Никакого MCP-сервера в конфигурации вашего агента, никакого токена в переменной окружения, никакого CLI в PATH, никакого файла навыка. Мы создаём продукт для разработчиков, поэтому мы использовали инструмент, который уже был и который каждый агент умеет использовать: SSH.
5. Самодокументирование и продуманность по дизайну. Команда discover выводит полный каталог команд. Он включает каждую команду, её параметры и типы, а также любые требования к подтверждению. Каталог генерируется на лету из продукта. Он также сообщает клиенту, какие поля ожидают байты файла вместо строки, так что загрузки не могут быть угаданы неверно. Чего он не позволяет, так это нацеливаться на строку по её номеру. Разрушительные команды требуют имя, и сервер проверяет это имя на соответствие проекту, выбранному для соединения. Если запрашивается Staging, а выбран Support Bot, сервер возвращает 400 и оставляет рабочее пространство нетронутым.

Нечему учить, потому что поверхность учит сама себя.

Вот как выглядит процесс входа в Oberik:

Процесс входа в Oberik

Разве SSH-доступ к вашему продукту — это не риск?

Это справедливый вопрос, но реальность почти противоположна.

Шлюз не имеет собственного состояния или привилегий. Каждая команда выполняется через HTTP-сессию панели управления, точно так же, как в React-приложении. Таким образом, SSH-клиент не может сделать больше, чем та же учётная запись может сделать в браузере. Если вы выйдете из системы, отзовёте ключ или удалите учётную запись, изменение вступит в силу немедленно, потому что отзывать больше нечего.

Этот терминал открыт для публичного интернета, поэтому любой может подключиться анонимно. Каждая команда логируется, включая идентификатор соединения, IP-адрес, ключ и результат. Учётные данные никогда не сохраняются. Пароль, введённый с помощью login, или ключ провайдера, переданный через --values, заменяются на <redacted> до того, как запись будет записана. Система также сохраняет хэш исходной команды, чтобы повторяющиеся команды можно было коррелировать, не делая учётные данные восстанавливаемыми. Записи хранятся в течение 30 дней или 100 000 команд, в зависимости от того, что наступит раньше.

Повторные неудачные попытки входа замедляются, а не приводят к блокировке. Тот, кто забыл, какой пароль использовал, может продолжать попытки без особых затруднений, в то время как автоматический цикл повторных попыток с неверным паролем становится всё менее полезным. Это и есть предполагаемый компромисс.

Краткое резюме

Все остальные дают вашему агенту API, MCP-сервер или файл навыка. Мы дали ему терминал. Оказалось, что это именно то, что ему было нужно.