Перейти к основному содержанию
Каждый MCP-сервер, который вы регистрируете, каждый навык, который устанавливает агент, и каждый хост, которого достигает инструмент — это зависимость, которую вы не писали. Цепочка поставок агента динамична — она растёт во время выполнения, часто без человека в цикле — так что классическая модель «проверь lockfile во время сборки» не работает. Навык сообщества может быть перехвачен после того, как вы ему доверились; удалённый MCP-сервер может тихо добавить инструмент; инструмент выборки может быть направлен на хост, контролируемый злоумышленником. Ответ OrcaRouter — управлять цепочкой поставок там, где она действует — на шлюзе, при первом использовании — вместо попыток проверять каждую зависимость во время установки. Эта страница — лендинг сценария использования для ai supply chain security; справочники Firewall и Skills несут полную механику.

​
1. Безопасность цепочки поставок ИИ для агентов, на шлюзе

Контрольная точка — это relay-путь. Была ли возможность зарегистрирована вручную, автоустановлена агентом или вытянута из реестра сообщества, её первый вызов инструмента пересекает api.orcarouter.ai — и именно там Firewall его оценивает. Четыре контроля комбинируются в единую позицию:

MCP-шлюз, оценка каждого вызова

Каждый tools/call оценивается относительно вашей политики до отправки — манифест никогда не является источником истины.

Риск-полосы навыков и карантин

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

Зашифрованные учётные данные MCP

Секреты аутентификации сервера шифруются в покое и инъектируются при отправке — никогда не раскрываются модели, агенту или аргументам вызова.

Egress allow-lists

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

​
2. Угроза: зависимость, которая растёт после того, как вы ей доверились

ВекторЧто происходит
Rug-pullЗарегистрированный MCP-сервер добавляет инструмент (shell.exec, новый fetch), который вы никогда не одобряли.
Расползание навыкаУстановленный навык использует инструменты или хосты, которые его манифест никогда не объявлял.
Кража учётных данныхРеализация инструмента скомпрометированного сервера читает собственный секрет аутентификации, чтобы позвонить домой.
Egress-эксфильтрацияЦепочка retrieve→send отправляет ваши данные на хост, контролируемый злоумышленником.
Общая первопричина: «я доверяю этому серверу» трактуется как постоянное, и агент продолжает вызывать новые или изменённые инструменты без дальнейшей проверки.

​
3. Один конкретный пример — регистрация и закрепление MCP-сервера

Вы регистрируете сторонний MCP-сервер из консоли (Settings → Firewall → MCP servers; запись требует Developer+). Секрет аутентификации сервера хранится зашифрованным — вы предоставляете его один раз, шлюз инъектирует его при отправке, и он маскируется при каждом чтении после этого. Запись MCP-сервера несёт:
ПолеЗначения
auth_modenone, bearer, oauth, basic
statusok, degraded, down (устанавливается health-зондом)
credentialsзашифрованы в покое, никогда не возвращаются в открытом виде
После регистрации зондируйте его из консоли, чтобы перечислить его текущие инструменты. Зонд — это операция сессии рабочего пространства (/api/workspace/firewall/*), которая требует Developer+, а не relay-ключа — регистрация, зондирование и написание правил происходят на плоскости управления: 
# Console / management plane — workspace session, Developer+.
# (The relay sk-orca-... key is for /v1/* traffic only.)
curl -X POST https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/<id>/probe \
  -H "Authorization: Bearer <workspace-session-token>"
Зонд сохраняет достижимость сервера и делает снимок базового хеша его рекламируемого набора инструментов (trust-on-first-use). Затем ограничьте правило Firewall с tool_name_glob: <server>.* до pending_approval, пока вы не увидите чистую историю вызовов — каждый вызов от этого сервера удерживается для человека до запуска. Как только вы ему доверитесь, ослабьте правило до audit или allow. С этого момента MCP-шлюз оценивает каждый tools/call на поверхности mcp до отправки — так что если rug-pull позже добавит необъявленный инструмент, ваша политика, а не манифест сервера, решает, запустится ли он.
Перезондируйте после любого повышения версии вышестоящего (POST /api/workspace/firewall/mcp_servers/:id/probe, Developer+). Если рекламируемый набор инструментов дрейфует от одобренного базового уровня, schema_status сервера переключается на changed, и отправка закрывается, пока админ не перебазирует (approve_schema) или не поместит в карантин — rug-pull не может тихо выйти в эфир.

​
4. Риск-полосы навыков и карантин

Каждая устанавливаемая возможность — зарегистрировали ли вы её или шлюз автообнаружил её во время выполнения — пропускается через сканер навыков. Находки сворачиваются в риск-полосу и режим применения:
low · medium · high · critical. Полоса выводится из детерминированных проходов сканера над манифестом и объявленными областями (использование необъявленного инструмента, сетевой egress вне одобренных областей, небезопасные записи в файловую систему, текст манифеста в форме инъекции).
allow (решают ваши правила политики), quarantine (любой не-deny вердикт эскалирует до pending_approval — человек одобряет каждый вызов), block (принудительный deny на всех инструментах этого навыка независимо от правил). Навык полосы high помещается в карантин автоматически; critical блокируется.
Возможность, которую агент самоустанавливает, или инструмент, который добавляет rug-pull, удерживается в pending_approval независимо от своей оценки сканирования, пока человек её не проверит. Оператор не может тихо добавить инструмент и заставить ваших агентов начать его использовать.
Режим применения всегда только ужесточается — одобрение навыка никогда не ослабляет блокировку, установленную свежим сканированием.

​
5. Egress allow-lists — сдержите «звонок домой»

Самый разрушительный исход цепочки поставок — скомпрометированная зависимость, которая эксфильтрует. Поверхность egress Firewall оценивает исходящий адрес назначения (host / IP / CIDR), который сообщает инструмент, так что вы можете закрепить, куда данным разрешено идти. Вы пишете правило egress сами: host/CIDR allow-list с предикатом cidr_match запрещает всё вне списка. Сочетайте его с правилом последовательности, которое разрывает цепочку retrieve→egress, и отравленный инструмент, пытающийся отправить извлечённый документ на неизвестный хост, запрещается на шлюзе.
Уровень автономии tight поставляет пресет SSRF, но он запрещает имена инструментов в форме выборки (http_fetch, web_search, fetch_url, request) — это не denylist по CIDR/cloud-metadata. Если вам нужна блокировка egress по RFC-1918 / metadata / конкретному CIDR, напишите правило deny по egress host/CIDR сами. См. Firewall: Rules для оператора cidr_match и ограничения egress.

​
6. Зашифрованные учётные данные — скомпрометированный сервер не может прочитать ваши ключи

Секреты аутентификации сервера шифруются в покое и инъектируются шлюзом во время отправки. Они никогда не достигают модели, агента или аргументов вызова инструмента — так что скомпрометированный или вредоносный сервер не может эксфильтровать ваши API-ключи, читая собственный блоб учётных данных. Консоль всегда возвращает секрет замаскированным — даже Admin. Расшифрованное значение выдаётся ровно по одному пути: запрос, несущий токен с областью firewall-gateway (выделенный тип токена, который Admin явно создаёт для шлюза/прокси), так что обычный утёкший relay-ключ не может перечислить ваши учётные данные MCP.

​
7. Сворачиваем для аудита

Управление цепочкой поставок — это также артефакт аудита. OrcaRouter маппится на OWASP Top 10 for LLM Applications — включая контроль LLM05 Supply Chain — в рамках комплаенс-движка, наряду с фреймворками вроде soc2, iso_27001, iso_42001, nist_ai_rmf и eu_ai_act. Установка комплаенс-пакета (POST /api/compliance/packs/:key/install, рабочее пространство Admin, платный план) материализует соответствующие guardrails и политики firewall и начинает с позиции observe-first. Отчёты комплаенса включают секцию AI-supply-chain evidence — вышестоящих провайдеров, к которым ваше рабочее пространство фактически маршрутизировало, плюс обзор привилегированного доступа и гигиены ключей — и подписаны Ed25519 и публично проверяемы. Просмотр каталога и готовности бесплатен для каждого участника; см. Комплаенс для полного жизненного цикла.
Управление MCP — это два дополняющих слоя: оценка firewall для каждого вызова на поверхности mcp (применение к тому, что зависимость делает), плюс базовый уровень целостности схемы инструментов (хеш trust-on-first-use рекламируемого набора инструментов, перепроверяемый при каждом зондировании — дрейф переключает schema_status сервера на changed и закрывает отправку, пока админ не перебазирует или не поместит в карантин). Вместе с риск-полосами навыков и карантином — это применение и к тому, что зависимость делает, и проверяемая запись того, что она объявила.

​
8. Базовый уровень цепочки поставок

Зарегистрируйте его, зондируйте его набор инструментов и ограничьте правило <server>.* до pending_approval или audit. Прочитайте находки сканирования — любая находка необъявленного инструмента или внешнего egress — причина держать его в карантине. Проверьте, кто контролирует URL конечной точки.
Держите egress allow-list закреплённым для любого агента с инструментами выборки/поиска/экспорта. Наблюдайте за представлением Discovered tools на предмет возможностей, появившихся без правила, и за лентой аномалий на предмет новых путей инструмент-к-инструменту.
Отключите сервер (PUT .../mcp_servers, "enabled": false) — его учётные данные никогда не расшифровываются, пока он отключён. Перезондируйте, чтобы всплыли новые инструменты, пересканируйте навык и проверьте очередь pending_approval, а не одобряйте оптом.

​
9. Связанные угрозы и концепции

Firewall: MCP-серверы

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

Firewall: Навыки

Сканируйте и риск-оценивайте каждую устанавливаемую возможность. Помещайте в карантин или блокируйте рискованные навыки до запуска их инструментов.