Как работает модель доверия агентов

Проблема: этой платформой управляют LLM-агенты — читают состояние, заводят дефекты, запускают прогоны. Агент — легитимный пользователь и недоверенный одновременно: он галлюцинирует, ретраит, его можно prompt-инжектить контентом, который он читает. Классический RBAC предполагает пользователя, который в основном ведёт себя хорошо; эта платформа предполагает такого, который иногда не будет.

Слой 1 — лестница токенов

Три тира доступа по возрастанию силы:

Тир	Читает	Пишет
Read-only scoped	Allowlist GET-поверхностей	Ничего
Agent	Платформу, с всегда вымаранными секретами	Только свой грант-пул контрактов
Owner	Всё	Всё

Интересен агентский тир: чтение широкое (агент, который не видит, не может рассуждать), но каждый ответ проходит рекурсивную редакцию секретов — креды не доходят до агента, даже когда он читает конфиг, который их содержит.

Слой 2 — default-deny гранты с двумя слоями принуждения

Права записи живут в одной таблице: строка на пару (агент, контракт) с явным списком capabilities. Нет строки = нет доступа; чувствительная capability publish не выдаётся по умолчанию даже внутри выданного пула. Принуждение двухслойное — грубый allowlist роутов (агент-токены вообще принимает лишь небольшой набор write-роутов), затем объектная проверка в каждом хендлере, что конкретный целевой контракт в пуле вызывающего с конкретной capability. Второй слой останавливает классический BOLA-отказ: валидный токен, тихо пишущий в объект, который ему не выдавали.

MCP не обходит ничего: маунт MCP требует валидный токен на каждый вызов, и каждый тул повторяет те же проверки capability в своём теле.

Слой 3 — discovery для самого слабого агента

Платформа рассчитывает на наименее способного клиента, а не на сильнейшего: онбординг-страница без auth, курируемый llms.txt, MCP-тул start_here с упорядоченным планом и — выстраданный урок — смысл живёт в значениях payload, а не в схемах, потому что многие агенты никогда не интроспектируют описания тулов. Всё, что агент обязан знать для правильного поведения, лежит в данных, которые он реально читает.

Слой 4 — недоверенные входные поверхности

Там, где агенты отправляют контент, платформа считает их враждебным потоком: дефект-репорты идут через цепочку гейтов (rate limit → фингерпринт-дедуп → проверка actionability), а публичный приёмник отвечает голым 202 — без id тикета, без вердикта — чтобы эндпоинтом нельзя было энумерировать доску. Репорт без шагов воспроизведения или доказательств уходит в карантин, а не в доверие.

Трейд-оффы, честно

Редакция по умолчанию изредка прячет то, что агенту законно нужно, — решение всегда явный грант, никогда обход. Голый 202 означает, что благонравный агент не может убедиться, что его репорт долетел; ответ — отдельная аутентифицированная read-поверхность (тулы доски), а не более дырявый приёмник. И перевыпуск токена заменяет весь грант-пул — острая грань, задокументированная в Аутентификации.

Пощупать за две минуты

Вызови my_capabilities по MCP — ответ и есть твоя точная оболочка доверия: читаемые домены, записываемые контракты, capabilities по каждому.

Спеки: SPEC-075 (read-only тир), SPEC-084 (агентский тир + пул), SPEC-085 (read-all + редакция), SPEC-089 (discovery-цепочка), SPEC-004 (недоверенный приёмник), SPEC-112 (модель доступа доски).