Модель рисков и классы защиты

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

Чувствительные области

Некоторые части системы требуют повышенной защиты — не только от внешних атак, но и от внутренних агентов. Распространённое заблуждение звучит так:

Пользователь вправе это видеть — значит, ИИ тоже вправе.

Это неверно. Фактический доступ ИИ определяется пересечением разрешений пользователя, разрешений агента, уровня доверия клиента, чувствительности ресурса, цели и статуса подтверждения. Каждый из этих элементов — отдельный барьер, а не только роль пользователя.

К чувствительным областям, требующим особой защиты, относятся:

• Финансовые данные — банковские реквизиты, платёжные данные, детали расчётов
• Медицинские данные — медицинские документы, истории болезни, справки
• Данные о зарплатах — оклады, бонусы, история выплат, расчётные ведомости
• Кадровые дела — договоры, материалы по найму, внутренние оценки
• Учётные данные и API-ключи — пароли, приватные ключи, токены доступа
• Функции удаления и массовых операций — удаление пользователей, тенантов, Bulk Export
• Управление правами — выдача и отзыв разрешений, изменение ролей
• Журналы безопасности — Audit Trails, Security Events, активные сессии
• Конфиденциальная переписка — личные заметки, внутренние оценки
• Налоговые данные и договоры — налоговые документы, юридически значимые контракты
• Персональные данные по GDPR — все данные, идентифицирующие физическое лицо

Шесть классов защиты

Каждый Resource и каждый Tool относится к одному из шести классов защиты. Класс определяет, кто получает доступ, видит ли агент Tool в Discovery вообще, и какое подтверждение требуется перед выполнением.

Public

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

help.article.read
public.product_info.read

Internal

Только для авторизованных пользователей. Достаточно аутентификации; особых прав не требуется. Типично для запросов списков, поисков и общих рабочих представлений собственного контекста.

project.list
contact.search

Confidential

Доступно только с явной ролью и назначенным Scope. Простого входа в систему недостаточно. Данные внутренние, но не предназначены для всех сотрудников.

contract.read
customer_private_note.read

Sensitive

Только с дополнительным подтверждением или ограниченной передачей контекста. Агент не вправе загружать эти данные в контекст без проверки. При передаче ИИ объём должен быть строго ограничен, а цель задокументирована.

salary.read
bank_account.read
health_document.read

Critical

ИИ не вправе действовать в этом классе автономно. Каждое выполнение требует явного подтверждения пользователя, часто Step-up Authentication. Действия создают внешний эффект, с трудом поддаются отмене или непосредственно затрагивают третьих лиц.

payment.execute
user.delete
contract.send
email.send_external
security.change_permissions

Forbidden for AI

Этот класс — жёсткая граница, не решение политики. Tools и Resources этого класса полностью скрываются от агентов при Tool Discovery. Агент не может ни читать их, ни вызывать, ни использовать как ссылку.

password.read
private_key.read
full_database_export
raw_access_token.read

Модель рисков

Модель рисков переводит классы защиты в операционные правила для каждого случая выполнения. Она определяет, разрешена ли автономия, нужно ли подтверждение и какой вид подтверждения требуется.

Low

Чисто читающие операции или действия без длительного внешнего эффекта. Агенты вправе вызывать эти Tools автономно.

Medium

Данные или состояния создаются или изменяются, но в строго ограниченном Scope без внешнего эффекта. Автономное выполнение разрешено, если Scope и контекст однозначно следуют из рабочего процесса.

High

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

Critical

Внешняя коммуникация, платежи, удаление, изменение разрешений. Всегда требуется подтверждение, часто Step-up Auth. Автономное выполнение не разрешено.

Forbidden

Полностью заблокировано для ИИ-агентов — ни для чтения, ни для записи. Не видно в Discovery, не может быть вызвано, не может использоваться как ссылка.

UX подтверждения

Техническая модель рисков в полной мере работает только тогда, когда интерфейс соответствует своей роли. Подтверждение не лучше информации, на основании которой оно выдаётся.

Прежде чем человек подтверждает критическое действие агента, он должен чётко видеть семь вещей:

1. Что хочет сделать агент? — Конкретное действие, а не намерение агента своими словами.
2. Почему агент хочет это сделать? — Какой Intent или поручение вызвало это действие.
3. Какие данные используются? — Получатели, вложения, связанные сущности.
4. Какие внешние эффекты возникнут? — Что изменится за пределами системы: письмо будет отправлено, платёж инициирован, документ передан.
5. Кто затронут? — Люди, компании, тенанты, внешние стороны.
6. Можно ли отменить действие? — Чёткое утверждение: обратимо или необратимо.
7. Что произойдёт при подтверждении? — Полное описание следующих состояний системы.

Следующий пример показывает, как выглядит полная карточка подтверждения для Tool emails.send_external:

Агент ждёт решения пользователя. Он не вправе предвосхищать подтверждение, устанавливать действие по умолчанию или основывать выполнение на временной метке предыдущего подтверждения.