Мой production-action gate — это не теория из whitepaper, это работающий код: ни одна команда kubectl exec, ssh в прод или terraform apply против живой инфраструктуры не проходит без явного, поимённого одобрения в текущей сессии, причём формулировка от третьего лица «пользователь авторизовал» отклоняется. И когда я читаю свежую статью Debmalya Biswas об архитектуре безопасности агентных систем — с её AI-шлюзом, IAM-провайдером для людей и сервис-принципалами для приложений, потоками OAuth (OBO, Token Exchange, Client Credential Grant) и сводным каталогом рисков R1–R16 из материалов OWASP и IBM — я узнаю в его рекомендациях ровно те примитивы, которые у меня уже собраны и запущены. Только у Biswas они описаны как корпоративная сантехника на Azure-стеке, а у меня — как однопользовательский harness. Этот текст — попытка перенести его корпоративные паттерны вниз, в реальность solo-инженера, и показать, где перенос работает, а где статья решает не тот слой.
Что описывает Biswas
Референсная архитектура у Biswas честная и подробная. Пользователь аутентифицируется через IAM, приложение получает токен, AI-шлюз делает обмен on-behalf-of, чтобы получить нисходящий токен для агента с aud = agent, проверяет JWT по скоупу и роли, форвардит запрос. Когда агент должен вызвать инструмент через MCP, он не пробрасывает входящий токен, а делает token exchange: новый токен с ограниченным скоупом и другой аудиторией, при этом sub-клейм сохраняет исходного пользователя — ради линейности и аудита. Для фоновых M2M-процессов без пользовательского контекста — Client Credential Grant. Всё это увенчано каталогом из шестнадцати рисков и тезисом, который для меня оказался самым ценным во всей статье.
Biswas прямо отказывается верить в магический центральный слой защиты. По его словам, guardrails «need to be specific to the underlying use-case, and implemented in their respective platform components / layers» — и это «has a direct impact on the overall solution architecture». То есть защита не живёт в одной коробке с надписью «governance»; она размазана по тем компонентам, где реально происходит опасное действие. Я подписываюсь под каждым словом — потому что построил систему ровно по этому принципу, ещё не прочитав статью.
Моя рамка: перенос вниз
Корпоративная версия предполагает Entra ID, сервис-принципалы, APIM-шлюз и OpenTelemetry-конвейер. У меня нет ничего из этого, и не нужно. Но риски-то те же самые: автономный агент с доступом к инструментам может сделать что-то разрушительное, и вопрос лишь в том, на каком уровне я это перехвачу. Поэтому я читаю каталог R1–R16 не как чек-лист для отдела безопасности enterprise, а как список того, что я обязан закрыть в одиночку — и большую часть уже закрыл.
Что реально переносится
Три риска ложатся на мою уже работающую инфраструктуру почти без зазора.
R14 и R15 — Human Manipulation и Overwhelming Human in the Loop. Biswas называет human-in-the-loop как governance-измерение, но в статье это остаётся существительным: HITL упомянут, но не операционализирован — нет ни одного шага потока, который описывал бы, как именно человек встаёт в цепочку и что именно ему предъявляют. Мой production-action gate — это и есть тот самый HITL-примитив, доведённый до кода. Опасное действие останавливается, мне предъявляется конкретная команда, и пройти дальше можно только моим явным поимённым «да» в этой же сессии. Отклонение формулировок от третьего лица — прямая защита от R14: агент не может «процитировать» чьё-то мнимое разрешение и протащить действие.
R1 — Misaligned & Deceptive Behaviors. Под этот риск у меня заточен /security-check: сканер инъекций в промпт, который ловит подозрительные паттерны регулярками, скрытые Unicode-символы и base64-обёртки до того, как недоверенный текст попадёт в контекст агента. Это ровно та «специфичная для компонента» защита, о которой пишет Biswas: не абстрактный guardrail, а фильтр на входной границе.
R3 — Tool Misuse. Этот риск закрывается тем же gate-ом: инструмент с разрушительным потенциалом не вызывается автономно, между намерением агента и реальным эффектом стоит человек. Так что три из шестнадцати рисков у меня не на бумаге, а в проде — и это и есть ответ на вопрос «как выглядит рекомендация Biswas, когда её действительно строят на solo-масштабе».
Где статья решает не тот слой
А теперь резкая часть. Вся механика токенов у Biswas — OBO, Token Exchange, Client Credential Grant, аккуратное сужение скоупа, сохранение sub-клейма, тезис «token propagation must not cross application boundaries» — это безупречная работа с идентичностью. Она отвечает на вопрос «кто и с какими правами вызывает это действие». Но она не отвечает на вопрос «стоит ли вообще это действие выполнять».
Корректность потока токенов не равна безопасности на уровне намерения. Семантически опасное действие, которое при этом идеально авторизовано, проходит сквозь безупречный OAuth без единого возражения. Представьте агента с честно выданным, узко заскоупленным токеном на удаление ресурсов в его собственном домене — token exchange отработает идеально, aud и sub будут правильными, аудит-лог зафиксирует чистую линейность. И ничто из этого не остановит само удаление, если оно разрушительно. Идентичность говорит «этому субъекту можно», но молчит о том, что конкретное действие не следует совершать.
Именно этот слой — слой намерения — Biswas отдаёт на откуп тому самому центральному guardrails-компоненту, в нереалистичность которого он сам же не верит парой абзацев выше. Его каталог R1–R16 честно называет интент-риски (R2 — Intent Breaking & Goal Manipulation стоит вторым в списке), но архитектурная часть статьи закрывает их идентичностью и token scoping, а реальную остановку опасного намерения оставляет ненаписанной. Получается разрыв: риски названы, а слой, на котором они живут, в эталонных потоках не достроен.
Вердикт
Это полезная корпоративная инвентаризация. Каталог R1–R16, сведённый из двух разных источников, сам по себе ценен как карта поверхности атаки. Слой идентичности проработан хорошо — потоки токенов корректны, сужение скоупа разумно, требование не пробрасывать токены через границы доменов справедливо. И тезис о том, что guardrails должны жить в конкретных компонентах, а не в магической коробке, — точное third-party-подтверждение того, как я и сам строю защиту.
Но слой намерения — тот самый, где живёт настоящая опасность, — это ровно то, до чего статья не дотягивается. Идеальная аутентификация не спасает от семантически разрушительного, но корректно авторизованного действия. У Biswas остановка такого действия делегирована абстрактному центральному компоненту; у меня она прибита к коду в виде поимённого gate-а. Перенос корпоративных паттернов вниз, на solo-масштаб, в итоге показывает не только то, что переносится, но и то, чего в оригинале не хватало с самого начала: операционализированной защиты на уровне намерения, а не только идентичности.