Подключение автономного агента нужно начинать с заблокированного хранилища

Автономные агенты должны получать доступ поэтапно. Если первым делом вы выдаете агенту рабочий токен и просите его «быть осторожным», вы пропускаете единственную часть настройки, которая показывает, как средства контроля ведут себя под нагрузкой.

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

Цель не в том, чтобы как можно быстрее сделать агента полезным. Нужно точно понять, что он может делать, что вы обязаны одобрять, какие записи он оставляет и как его остановить до подключения к работе с реальными последствиями.

Начните с хранилища, которое отказывает в любом действии

Первой успешной проверкой должен стать отказ. Заблокированное хранилище обязано отклонить действие агента, даже если запрос выглядит вполне разумным и учетные данные уже настроены.

Это кажется странным, пока вы не увидите, как агент повторяет неудачное действие. Агенты не испытывают сомнений. Если инструмент сообщает, что доступ недоступен, агент может попробовать другую конечную точку, изменить аргумент, вызвать связанный инструмент или запросить подтверждение. Граница безопасности должна ответить раньше, чем учетные данные покинут защищенное хранилище.

На Mac убедитесь, что приложение запущено, но оставьте хранилище заблокированным. Запустите агента обычным рабочим способом и дайте ему намеренно безобидный запрос, например получить тестовый ресурс из API, которому вы еще не разрешали доступ.

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

Запишите, что сообщил агент. Вам нужно проверить три вещи:

• Агент может обратиться к шлюзу действий через MCP-соединение.
• Шлюз хранилища останавливает действие, пока хранилище заблокировано.
• Секрет не появился в расшифровке диалога агента, выводе терминала или аргументах инструмента.

Важно различать недоступные учетные данные и заблокированное хранилище. Недоступные учетные данные обычно указывают на проблему настройки. Заблокированное хранилище означает, что настройка работает, а доступ намеренно закрыт. Если считать оба случая одной и той же ошибкой, «токен не сработал», со временем вы отключите средство контроля, которое вас защищало.

Sallyport использует это как первый уровень принятия решения: пока хранилище заблокировано, любое действие запрещено. На поддерживаемом оборудовании Mac шлюз хранилища использует Secure Enclave и Touch ID, а не просит агента что-либо доказывать о себе.

Подключите агента, не передавая ему секрет

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

Настройте агента с поддержкой MCP на использование встроенного stdio-shim:

sp mcp

Shim представляет собой обычный MCP-сервер. Агент обращается к нему, просит выполнить HTTP- или SSH-действие и получает результат. Учетные данные остаются в зашифрованном хранилище внутри приложения. Агент не получает открытый токен, заменяющий токен или похожую на секрет заглушку, которой позже можно злоупотребить.

Это более четкая граница, чем та, которую проводят многие команды. Они говорят: «у агента ограниченный доступ», хотя на самом деле агент получает токен в окружении с ограниченными правами. Это разные системы.

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

До разблокировки проверьте конфигурацию агента на типичные утечки:

• Удалите токены из файлов .env, файлов запуска оболочки, инструкций агента и документации проекта.
• Не добавляйте учетные данные в аргумент инструмента только потому, что инструмент поддерживает поле token.
• Не давайте агенту доступ на чтение к тому же менеджеру паролей, файлу секретов или каталогу облачных учетных данных, который вы пытаетесь защитить.
• Первый запуск агента должен проходить отдельно от терминальной сессии, где загружены привилегированные переменные окружения.

Именно здесь разработчики часто дают популярный, но плохой совет: «Сначала используйте временный токен, а потом усильте защиту». Временный токен все равно остается секретом, как только попадает в контекст агента. Да, используйте учетные данные с ограниченным ущербом. Но не воспринимайте их как разрешение отказаться от границы между агентом и секретом.

Сначала выполните один простой HTTP-запрос

Первым разрешенным действием должен стать один HTTP-запрос с учетными данными узкого назначения. Лучше выбрать доступ только для чтения. Еще лучше использовать тестовую учетную запись. Идеальный вариант, конечная точка, которая возвращает известный несекретный объект.

Выберите запрос, который можно независимо проверить. Подойдут метаданные тестового репозитория, созданный вами профиль sandbox или конечная точка состояния для нетестовой учетной записи. Избегайте конечных точек со списками настоящих клиентов, исходным кодом, платежными данными или широкими настройками учетной записи. Даже успешное чтение может раскрыть больше, чем вы планировали.

Добавьте HTTP-учетные данные в хранилище с нужным сервису способом аутентификации: bearer, basic или пользовательским заголовком. Название учетных данных должно быть достаточно понятным, чтобы вы узнали его в карточке подтверждения. «Чтение тестового API» лучше, чем «токен 2». В будущем вам не придется открывать менеджер паролей, чтобы понять, безопасно ли одно нажатие.

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

Не сводите проверку к «я узнаю имя агента». Знакомая команда может быть запущена неожиданной оберткой, скопированным бинарным файлом или другим инструментом разработки. В карточке подтверждения сначала указана подпись кода процесса, потому что важнее сам процесс, запросивший доступ, а не текстовая задача, которую он обещает выполнять.

Одобряйте запуск, только если верны все условия:

1. Вы сами запустили процесс агента.
2. Идентификатор подписи соответствует ожиданиям.
3. Запрошенные учетные данные имеют нужную узкую область действия.
4. Запрос соответствует поручению, которое вы дали агенту.

Затем попросите агента выполнить ровно один вызов. Сравните результат с ручным запросом вне рабочего процесса агента. Вы не доказываете, что HTTP работает. Вы проверяете, что агент может запросить действие, шлюз может подставить сохраненные учетные данные, а результат возвращается без раскрытия самих учетных данных.

Полезная запись для первого дня короткая:

Credential: Test API read
Agent task: Retrieve one known test object
Expected result: Object identifier and status only
Manual comparison: Same identifier and status
Unexpected data returned: None

Если ответ содержит больше полей, чем вы ожидали, остановитесь. Не просите агента пересказать лишние данные и продолжить. Уменьшите область действия API, выберите меньший тестовый объект или более узкую конечную точку. Первый HTTP-вызов должен создавать уверенность за счет ограничения, а не впечатлять результатом.

Подтверждение сеанса разрешает запуск, но не дает карт-бланш

Авторизация на сеанс отвечает на конкретный вопрос: одобряете ли вы этот процесс агента на время текущего запуска? Она не определяет, одинаково ли подходят для него все учетные данные и все запрошенные действия.

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

Считайте сеанс ограниченной рабочей единицей. Запускайте его для одной задачи. Наблюдайте за первыми действиями. Завершайте, когда задача выполнена. Для следующей отдельной задачи запускайте новый процесс, чтобы получить новое решение об авторизации.

Журнал Sessions должен поддерживать эту привычку. Он записывает запуски агентов, и любой запуск можно мгновенно отозвать. Используйте отзыв, если агент начинает отклоняться от задачи, вы понимаете, что одобрили не тот процесс, или задача меняется в середине работы.

Вот типичный сценарий сбоя. Вы просите агента «проверить тестовый API и исправить очевидные проблемы». Он начинает с безобидного GET-запроса. Вы одобряете сеанс. Агент находит несоответствие конфигурации, видит среди доступных действий конечную точку записи и решает, что очевидное исправление, обновить настройку. Учетные данные могут это позволять, а исходное одобрение все еще может распространяться на весь запуск.

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

Разделите работу. Одобрите сеанс обнаружения только для чтения. Изучите результаты. Затем запустите отдельный процесс для предлагаемого изменения, желательно с другими учетными данными и более узкими правами записи. Одобрение имеет смысл, когда относится к рабочей единице, которую можно описать одним предложением.

Добавляйте SSH только после того, как граница HTTP станет привычной

SSH это не «HTTP для серверов». Последствия здесь серьезнее: успешное подключение может выполнять произвольные команды, читать файлы, менять права и передавать данные по каналам, которых нет у узкого API.

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

Sallyport направляет SSH-действия через встроенный статeless-помощник sp-ssh на Go. Агент запрашивает действие через ту же модель шлюза, а сохраненные SSH-учетные данные остаются в хранилище и не превращаются в файл закрытого ключа, который агент может прочитать.

Первое SSH-упражнение должно быть намеренно узким:

Host: isolated development host
Remote account: restricted test account
Allowed task: Read one known text file
Expected response: The exact line placed in that file
Stop condition: Any attempt to inspect other paths or run a second command

Не начинайте с фразы «запусти диагностику». Она слишком широкая. Диагностика часто означает списки процессов, сетевые настройки, перечни пакетов, логи, домашние каталоги и конфигурацию приложений. Способный агент поймет запрос широко, потому что именно широкое толкование часто помогает завершить задачу.

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

Ограниченная тестовая учетная запись делает сбой понятным. Если агент запросит неожиданный путь, вы увидите попытку в журнале и сможете отклонить ее или отозвать запуск, не гадая, успел ли он найти более чувствительный файл.

Подтверждение каждого использования нужно для важных учетных данных

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

Разработчики часто сопротивляются, потому что повторные запросы кажутся неэффективными. И они правы насчет цены. Запрос при каждом чтении с низким риском приучит нажимать кнопку, не читая карточку. Это усталость от подтверждений, и она делает контроль хуже отсутствующего: появляется ложная уверенность.

Включайте настройку для действий, которым нужно отдельное решение человека. Хорошие кандидаты, учетные данные, которые могут:

• создавать, изменять или удалять удаленные ресурсы;
• читать личные, клиентские, финансовые или связанные с безопасностью записи;
• вызывать административные методы API;
• открывать SSH-доступ к общей машине разработки, тестовой среде или машине рядом с рабочей средой;
• запускать развертывание, задание, рабочий процесс или внешнее уведомление.

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

Здесь важно различать два режима. Авторизация на сеанс спрашивает, может ли определенный процесс действовать во время запуска. Подтверждение каждого использования спрашивает, можно ли прямо сейчас применить конкретные учетные данные. Одно относится к идентификатору процесса и сроку жизни запуска, другое, к последствиям одного сохраненного секрета. Если считать их взаимозаменяемыми, команда либо одобрит слишком многое, либо будет получать столько запросов, что перестанет читать карточки.

Когда появляется запрос, смотрите не только на название учетных данных. Проверьте действие, назначение и то, оправдано ли оно текущей задачей агента. Если нет, отклоните использование и попросите агента объяснить план простыми словами, прежде чем одобрять что-либо еще.

Журнал активности превращает сюрпризы в доказательства

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

После HTTP-проверки откройте журнал Activity и прочитайте каждый отдельный вызов. Затем сделайте то же после SSH-проверки. Сравните записи с описанием упражнения: ожидаемой конечной точкой или хостом, ожидаемым действием и ожидаемым результатом. Так вы научитесь замечать несоответствие, пока его еще легко объяснить.

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

Не используйте рассказ агента как запись событий. Агент может точно пересказать действия, пропустить деталь, неправильно понять ответ инструмента или составить убедительное объяснение поступка, который вы бы не одобрили. Журнал нужен для проверки произошедшего, а не для оценки текста вокруг него.

Здесь же становится полезным мгновенный отзыв. Если агент переходит от согласованной задачи к исследованию, сначала отзовите сеанс. Разобраться, был ли вызов безобидным, можно после остановки дальнейших действий. Ждать полного объяснения разумно на совещании, но плохо подходит для активного процесса с учетными данными.

Проверьте цепочку аудита до того, как она понадобится в споре

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

Выполните это после первых двух упражнений:

sp audit verify

Sallyport может проверять хеш-цепочку офлайн по шифротексту, поэтому для проверки не нужен секрет хранилища. Это удобно при расследовании: целостность записи можно проверить, не разблокируя то же хранилище, которое управляет действиями агента.

Один раз выполните команду в спокойной обстановке. Запишите, где будете хранить результат для изменения, теста или инцидента. Затем повторите проверку после намеренно отклоненного действия, одобренного HTTP-вызова и одобренного SSH-вызова. Вы проверяете последовательность с известными событиями, поэтому неожиданный результат позже будет проще заметить.

Не ждите серьезного рабочего вопроса, чтобы выяснить, кто может выполнить команду, где лежат логи и понимает ли команда разницу между записью сеанса и отдельным вызовом. Это типичный сбой. Команды устанавливают журналирование, считают, что оно работает, и открывают логи только после вопроса «Кто это одобрил?». К этому моменту им приходится одновременно изучать инструмент и восстанавливать событие.

Журнал аудита проецируется в журналы Sessions и Activity из одной зашифрованной записи, невидимой для записи и построенной на хеш-цепочке. Это дает два операционных представления, не делая их единственным доступным доказательством.

Пусть первая неделя будет сложнее первой демонстрации

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

В первую неделю масштаб должен быть таким, чтобы вы могли объяснить каждое действие. Добавляйте только одни новые учетные данные или одну новую возможность за раз. Если новая настройка требует нескольких исключений, широких прав и запроса, который трудно быстро понять, она еще не готова для автономного агента.

Практическая проверка проста: когда агент просит выполнить действие, можете ли вы сказать, кто его запрашивает, какие сохраненные учетные данные будут использованы, какая внешняя система получит действие и где вы потом это проверите? Если любой ответ расплывчат, вернитесь к предыдущему этапу и сузьте проверку.

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