Звільніть своїх агентів і надайте їм SSH-доступ

Кожна сучасна платформа пропонує вашому агенту одні й ті самі три варіанти інтеграції: MCP-сервер для реєстрації, API-ключ для зберігання та оновлення, або файл навички для встановлення, який навчає агента виконувати перші два. Щось, що потрібно налаштувати. Щось, що може витекти. Щось, що застаріває.

Oberik надає вашому агенту ssh-доступ замість цього.

Не вам, ви в цьому контексті виступаєте як проксі, він надає SSH-доступ саме вашому агенту.

1 ssh ssh.oberik.com

SSH — це поверхня, яку використовує кодуючий агент щоразу, коли йому потрібно взаємодіяти з Oberik (наприклад, створити робоче середовище, встановити його граничні можливості, випустити токени, поспілкуватися з агентом, якого ми хостимо, тощо). Жодного конфігураційного файлу, жодного токена в змінній середовища, нічого не встановлено. Ваша машина вже має клієнт, і вона вже знає, як зберігати єдиний необхідний обліковий запис.

Чому не MCP?

Якщо коротко, проблема виводу.

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

Хоч ним і легко користуватися, MCP має фундаментальний недолік: коли інструмент виконується, весь вивід надсилається в контекст моделі. Модель повинна прочитати все це. Вона не може вирішити: "Мені потрібне лише третє поле", тому що до моменту надходження тексту фільтрація вже не спрацювала.

MCP підтримує фільтрацію та пагінацію в принципі. На практиці хтось повинен вбудувати це в кожен інструмент, а коли цього немає, що може траплятися досить часто завдяки вайб-кодингу, модель просто поглинає необроблений корисний вантаж і платить за це токенами та увагою.

З 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?

Якщо коротко, проблема облікових даних.

Не зрозумійте нас неправильно, у Oberik є API, і він хороший. Саме його ваш продукт викликає в роботі, і саме його використовує сам 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-адресу, ключ і результат. Облікові дані ніколи не зберігаються. Пароль, введений під час входу, або ключ постачальника, переданий через --values, замінюється на <redacted> перед записом. Система також зберігає хеш оригінальної команди, щоб повторювані команди можна було співставити, не роблячи облікові дані відновлюваними. Записи зберігаються протягом 30 днів або 100 000 команд, залежно від того, що настане раніше.

Повторні невдалі спроби входу сповільнюються замість того, щоб викликати блокування. Хтось, хто забув, який пароль використовував, може продовжувати спроби без особливих перешкод, тоді як автоматичний цикл повторних спроб із неправильним паролем стає дедалі менш корисним. Це передбачений компроміс.

Коротко

Усі інші дають вашому агенту API, MCP-сервер або файл навички. Ми дали йому термінал. Виявляється, це те, що він хотів.