Перейти к основному содержанию
Финансовый агент сверяет реестры, оформляет возвраты, двигает деньги и читает данные карт и счетов. Радиус поражения одного плохого вызова инструмента — убегающего цикла возвратов, DROP на таблице реестра, номеров карт, утекающих в промпт — измеряется в долларах и аудиторских находках. Этот рецепт собирает контроли, которые делают такого агента безопасным для запуска: tight- автономия как пол, человеческое подтверждение на инструментах, двигающих деньги, пер-прогонный кост-кап как предохранитель и устанавливаемый комплаенс-пак SOC 2 / PCI, который материализует политику и подписанные доказательства, которые попросит аудитор.
Всё здесь настраивается в консоли (Firewall → Posture / Policies, Guardrails, Compliance). Эти маршруты управления используют вашу консольную сессию, а не ключ ретрансляции — только вызовы /v1/*, которые делает ваш агент, несут ключ sk-orca-…. Редактирование политик требует роли Developer; установка комплаенса / go-live / резидентность требуют Admin рабочего пространства и платного плана.

1. Почему безопасному финансовому ИИ-агенту нужно больше, чем guardrails

Проверка контента ловит номер карты в промпте. Она не останавливает агента от вызова refund.issue десять тысяч раз, достижения внутреннего хоста 10.x или запуска деструктивной миграции. Позиция финансового уровня должна управлять обеими плоскостями сразу:

Текстовая плоскость

Guardrails проверяют текст запроса и ответа — PII замаскирован, секреты заблокированы, до того, как их увидит модель.

Плоскость действий

Firewall управляет каждым вызовом инструмента, MCP-диспетчем и исходящим запросом — allow, audit, deny, sanitize, hold или cap cost.
Этот рецепт наслаивает четыре контроля друг на друга. Сначала прочитайте базис Secure Agents и Guardrails vs Firewall, если две плоскости ещё не ясны.

2. Пол: примените tight-автономию

Начните с самой сильной одношаговой позиции. В Firewall → Posture примените уровень автономии tight (уровень автономии) (роль Developer). В одной транзакции она задаёт обе плоскости:
ПлоскостьЧто материализует tight
FirewallDefault-deny; запрет деструктивного shell; запрет SSRF-egress (fetch-образные имена инструментов)
GuardrailsPII Shield + Secrets Blocker применяются на запросах
Переключатель автономии пишет реальные, редактируемые строки политики autonomy_* и guardrail — это семя, а не чёрный ящик. У неё есть отмена в один клик из снимка аудита.
На агенте, двигающем деньги, не переключайтесь прямо в tight в production. Примените его в shadow-режиме (или начните с balanced), чтобы каждый применяющий вердикт понижался до audit с причиной [shadow] would …. Понаблюдайте за Firewall → Events / Runs, убедитесь, что политика срабатывает на ожидаемом, затем применяйте.

3. Подтверждения: удержите инструменты, двигающие деньги, на человека (HITL)

Default-deny останавливает то, что вы не разрешили. Инструменты, которые вы всё же разрешаете, но которые двигают деньги — refund.issue, payment.send, ledger.adjust — должны быть ни авто-разрешены, ни авто-запрещены. Дайте им вердикт pending_approval, чтобы человек подписывал вне основного канала. В Firewall → Policies добавьте правило выше вашего default:
  • Глоб инструмента: refund.* (или payment.send, ledger.adjust, …)
  • Вердикт: pending_approval
Когда агент его вызывает:
  1. Удержанный вызов возвращает HTTP 400 firewall_approval_pending с id подтверждения; вызов не достигает инструмента.
  2. Ревьюер разрешает его — из консоли (Developer+) или через подписанный HMAC вебхук-колбэк к вашей собственной системе подтверждений на POST /api/v1/firewall/approvals/:id/callback.
  3. Агент опрашивает GET /api/v1/firewall/approvals/:id, затем повторно отправляет исходный вызов с одноразовым заголовком X-OrcaRouter-Firewall-Approval — шлюз пропускает его этот один раз.
Закрепите предикат аргумента, чтобы только крупные операции требовали человека: глоб refund.issue с клаузой JSONPath {"path":"$.amount_cents","op":"gt","value":50000}, вердикт pending_approval. Мелкие возвраты текут; возврат от $500 ждёт ревьюера. См. Правила firewall для полного набора операторов (eq, contains, regex, in, cidr_match, gt, lt).

4. Предохранитель: ограничьте стоимость прогона

Финансовый агент, застрявший в цикле повторов, — это и баг корректности, и баг биллинга. Правило cap_cost — это предохранитель убегающего цикла: оно запрещает вызов инструмента, как только накопленные траты прогона агента пересекают пер-правило кап в центах. Добавьте правило с вердиктом cap_cost и потолком cap_cost_cents — например, 2000 (USD $20.00) — ограниченное инструментами вашего агента. Как только текущие траты прогона превышают кап, дальнейшие вызовы в этом прогоне запрещаются; свежий прогон стартует чисто.
cap_cost ограничивает траты прогона агента, а не пожизненный бюджет одного ключа. Для жёсткого потолка на ключе установите credit_limit_usd на самом API-ключе (0 = без лимита) — двое сочетаются: бюджет ключа ограничивает суммарные траты, cap_cost ограничивает любой один прогон.

5. Подстраховка на текстовой плоскости

tight уже применяет PII Shield и Secrets Blocker. Для финансового агента опирайтесь на специфику:
Guardrail Secrets Blocker ловит API-ключи и учётные данные в промпте до того, как их увидит модель. Для данных карт правило pii с credit_card, установленным в действие block (через пер-сущностный entity_actions), отклоняет запрос целиком с HTTP 400 guardrail_blocked — и блок не стоит квоты (input-блоки срабатывают до учёта). См. Guardrails §5.
Пресет PII Shield — это одно правило pii, mask, стадия both. Маскирование на стадии input работает: iban или ssn в запросе отрисовывается как [IBAN] / [SSN] до вызова модели. (Live- маскирование вывода/потока в дорожной карте; block на выводе применяется на потоке и без потока уже сегодня.)
Вердикт sanitize Firewall редактирует совпавшие подстроки из аргументов вызова инструмента перед пересылкой — он никогда не переписывает то, что инструмент возвращает. Чтобы вообще не дать секрету попасть в запрос, это задача guardrail Secrets Blocker на текстовой плоскости.

6. Комплаенс-пак: SOC 2 и PCI в одной установке

Контроли выше — это реализация. Аудитору нужны доказательства. Плоскость Compliance замыкает эту петлю: просмотрите каталог фреймворков (бесплатно, любой Member), затем установите пак как Admin рабочего пространства на платном плане. Установка пака материализует guardrails и политики firewall, которые отображаются на контроли фреймворка — так что та же установка, что даёт вам аудиторский артефакт, также поднимает реальное применение.
# Console action (UserAuth session) — install the PCI DSS pack
POST /api/compliance/packs/pci_dss/install
# then, when you're ready to enforce:
POST /api/compliance/packs/pci_dss/golive
Подтверждённые паки, релевантные финансовому агенту, включают soc2 (AICPA SOC 2 Trust Services Criteria), pci_dss (PCI DSS 4.0), glba (Gramm-Leach-Bliley) и dora_eu (Digital Operational Resilience Act) — наряду с фреймворками приватности (gdpr, uk_gdpr, ccpa), фреймворками безопасности/ИИ (iso_27001, iso_42001, nist_ai_rmf, eu_ai_act, nist_800_53) и паком owasp_llm (OWASP Top 10 for LLM Applications). Просмотрите живой каталог для полного набора.

Отчёт, который аудитор может проверить

ЧтоДеталь
ПодписьEd25519 над хешем доказательств SHA-256 — устойчива к подделке
ФорматыCSV / JSON / PDF
ПроверкаПубличная — GET /api/public/compliance/pubkey, POST /api/public/compliance/verify
ШарингRead-only ссылка для аудитора: GET /api/public/compliance/share/:token
Бесплатный план включает один отчёт; экспорт CSV/JSON и дополнительные отчёты платные. Генерация отчёта и go-live серверно ограничены платными планами — каталог и представления готовности остаются бесплатными.

7. Резидентность, срок хранения и стирание данных

Позиция финансового уровня должна ответить «где доказательства и как долго вы храните логи».
  • Резидентность — это регион артефакта отчёта комплаенса — us, eu, uk, ap, cn или global, задаётся через PUT /api/compliance/residency (Admin). Межрегиональные чтения отклоняются. (Это привязывает артефакт, а не место, где работает инференс.)
  • Срок хранения — request-логи по умолчанию 30 дней и серверно ограничены жёстким максимумом в 180 дней.
  • Стирание — самообслуживаемое удаление аккаунта входит в окно 30-дневной отсрочки, затем необратимый скраб PII каскадирует через совпадения guardrail, request-логи и события firewall.
Каждое изменение политики, правила и комплаенса пишет строку аудита (рабочее пространство + центральная). Изменения guardrail и firewall также версионируются — сравнивайте diff и откатывайте любой guardrail из его вкладки History.

8. Проверьте, прежде чем полагаться

Не выкатывайте финансовую политику на веру. У обеих плоскостей есть песочница, которая ничего не сохраняет и ничего не диспетчеризует:
  • Guardrails → Test — вставьте образец, выберите стадию, посмотрите вердикт и отрендеренный (замаскированный) текст.
  • Firewall → Test (Developer+) — прогоните образец вызова инструмента вхолостую и посмотрите вердикт, совпавшее правило и причину.
После запуска в production Firewall → Events / Runs — это пер-прогонная запись каждого вычисления, а лента аномалий флагирует всплески частоты/стоимости против обученного базиса рабочего пространства по часу недели, retry_loop и никогда ранее не виданные пути инструментов — в точности сигналы, которые предшествуют финансовому инциденту.

Резюме

Базис Secure Agents

Что материализует tight и как симулировать до применения.

Правила Firewall

Предикаты аргументов, кост-капы, egress и последовательности в глубину.

Доказательства SOC 2

Превратите материализованные контроли в подписанный аудиторский артефакт.

PII-безопасное логирование

Держите данные карт и счетов вне ваших request-логов.

Режимы применения

Observe → shadow → enforce, безопасная выкатка для инструментов, двигающих деньги.

Опасные вызовы инструментов

Угроза, от которой защищает allow-list инструментов финансового агента.