--- title: Как работает модель доверия агентов description: Платформа считает LLM-агентов полноправными, но недоверенными пользователями — лестница скоупов токенов, default-deny гранты, редакция секретов и анти-энумерация by design. locale: ru version: 0.2.0 canonical: https://enterium-developer-docs.pages.dev/developers/ru/how-it-works/agent-trust-model/ --- > Documentation index: https://enterium-developer-docs.pages.dev/developers/llms.txt — every page of this portal has a Markdown twin at .md; the frozen API contract is at https://enterium-developer-docs.pages.dev/developers/api/openapi.json. **Проблема:** этой платформой *управляют* LLM-агенты — читают состояние, заводят дефекты, запускают прогоны. Агент — легитимный пользователь и недоверенный одновременно: он галлюцинирует, ретраит, его можно prompt-инжектить контентом, который он читает. Классический RBAC предполагает пользователя, который в основном ведёт себя хорошо; эта платформа предполагает такого, который иногда не будет. ## Слой 1 — лестница токенов Три тира доступа по возрастанию силы: | Тир | Читает | Пишет | | --- | --- | --- | | Read-only scoped | Allowlist GET-поверхностей | Ничего | | **Agent** | Платформу, с всегда вымаранными секретами | Только свой грант-пул контрактов | | Owner | Всё | Всё | Интересен агентский тир: чтение широкое (агент, который не видит, не может рассуждать), но каждый ответ проходит рекурсивную **редакцию секретов** — креды не доходят до агента, даже когда он читает конфиг, который их содержит. ## Слой 2 — default-deny гранты с двумя слоями принуждения Права записи живут в одной таблице: строка на пару (агент, контракт) с явным списком capabilities. **Нет строки = нет доступа**; чувствительная capability `publish` не выдаётся по умолчанию даже внутри выданного пула. Принуждение двухслойное — грубый allowlist роутов (агент-токены вообще принимает лишь небольшой набор write-роутов), затем объектная проверка в каждом хендлере, что *конкретный целевой контракт* в пуле вызывающего с *конкретной* capability. Второй слой останавливает классический BOLA-отказ: валидный токен, тихо пишущий в объект, который ему не выдавали. ```mermaid flowchart LR T[Agent token] --> L1[Layer 1
route allowlist] L1 --> L2[Layer 2
object-level grant check] L2 --> W[Write executes] L1 -- route not agent-writable --> R1[403] L2 -- contract not in pool --> R2[403 naming the gap] ``` MCP не обходит ничего: маунт MCP требует валидный токен на каждый вызов, и каждый тул повторяет те же проверки capability в своём теле. ## Слой 3 — discovery для самого слабого агента Платформа рассчитывает на *наименее* способного клиента, а не на сильнейшего: онбординг-страница без auth, курируемый `llms.txt`, MCP-тул `start_here` с упорядоченным планом и — выстраданный урок — **смысл живёт в значениях payload, а не в схемах**, потому что многие агенты никогда не интроспектируют описания тулов. Всё, что агент обязан знать для правильного поведения, лежит в данных, которые он реально читает. ## Слой 4 — недоверенные входные поверхности Там, где агенты *отправляют* контент, платформа считает их враждебным потоком: дефект-репорты идут через цепочку гейтов (rate limit → фингерпринт-дедуп → проверка actionability), а публичный приёмник отвечает **голым 202** — без id тикета, без вердикта — чтобы эндпоинтом нельзя было энумерировать доску. Репорт без шагов воспроизведения или доказательств уходит в карантин, а не в доверие. ## Компромиссы Редакция по умолчанию изредка прячет то, что агенту законно нужно, — решение всегда явный грант, никогда обход. Голый 202 означает, что благонравный агент не может убедиться, что его репорт долетел; ответ — отдельная аутентифицированная read-поверхность (тулы доски), а не более дырявый приёмник. И перевыпуск токена **заменяет** весь грант-пул — острая грань, задокументированная в [Аутентификации](../../guides/authentication/#-ловушка-токен-заменяет-пул). ## Пощупать за две минуты Вызови `my_capabilities` по MCP — ответ и есть твоя точная оболочка доверия: читаемые домены, записываемые контракты, capabilities по каждому.