Модель безопасности

Агентно-ориентированный не значит неконтролируемый. Система MCP-first описывает каждую возможность машиночитаемо — и одновременно определяет, кто вправе её вызвать, при каких условиях и какие следы при этом остаются. Безопасность — не дополнение постфактум, а часть дизайна возможностей.

Шесть уровней авторизации

Аутентификация отвечает на вопрос: Кто ты? Авторизация отвечает: Что тебе позволено? Система MCP-first требует обоих вопросов — и отвечает на них на шести независимых уровнях, которые вместе определяют фактический доступ.

Уровень 1: User Role

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

admin
manager
employee
viewer
external_client

Уровень 2: Tenant Scope

В мультитенантных системах каждый доступ должен быть привязан к тенанту. Никакой агент не вправе читать или писать данные за пределами тенанта, даже если его роль пользователя технически допускает это.

tenant:abc
project:123
contact:456

Уровень 3: Tool Scope

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

contacts:read
contacts:write
projects:read
projects:write
files:read
files:write
emails:draft
emails:send
calendar:create
billing:read
billing:write
admin:users
admin:security

Уровень 4: Resource Scope

Помимо Tool Scopes, доступ можно ограничить отдельными типами ресурсов. Это гарантирует, что агент с contacts:read всё равно не сможет просматривать каждый ресурс контакта.

resource.project.visible
resource.contact.visible
resource.employee.visible
resource.file.downloadable
resource.email.readable

Уровень 5: Risk Level

Каждый инструмент несёт объявленный уровень риска. Этот уровень влияет на Confirmation Policy и конфигурацию аудита.

Уровень 6: Confirmation Policy

Confirmation Policy определяет, какое дополнительное препятствие необходимо преодолеть перед выполнением. Она настраивается для каждого инструмента и применяется Policy Layer — не самим агентом.

no_confirmation_required
confirmation_required
step_up_auth_required
admin_approval_required
four_eyes_required
not_allowed_for_ai

Видимость инструментов

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

Sales Assistant, например, получает следующий отфильтрованный список инструментов:

Human-in-the-loop

MCP-first не означает полную автоматику. Это означает полную управляемость — но под контролем. При чувствительных или рискованных действиях система прерывает агента и активно запрашивает согласие пользователя.

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

Следующий пример показывает типичный диалог согласования для массовой рассылки внешних электронных писем — одного из наиболее частых критических действий агента:

Step-up Authentication

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

Типичные триггеры для Step-up Auth:

• Изменение или назначение прав администратора
• Изменение платёжных данных или подписки
• Данные о зарплатах или экспорт расчётов
• Создание или ротация API-ключей
• Полные экспорты данных
• Удаление пользователей или тенантов

Принятые методы Step-up (в зависимости от системной политики):

Повторный запрос пароля
TOTP / приложение аутентификатора
Passkey
Разрешение администратора от второго лица
Принцип четырёх глаз

Consent Ledger

Каждое согласие на действие агента — это событие, которое должно храниться постоянно. Consent Ledger позволяет впоследствии восстановить, какое действие было одобрено кем, на какой объём и каким методом безопасности.

Сохраняемые поля записи о согласии:

consentId        — уникальный идентификатор согласия
userId           — пользователь, давший разрешение
agentId          — действующий агент
clientId         — подключённый MCP-клиент
toolName         — вызванный инструмент
inputSummary     — структурированная сводка входных данных (не открытый текст)
riskLevel        — объявленный уровень риска инструмента
approvedAt       — временная метка разрешения
expiresAt        — срок действия разрешения (если ограничен по времени)
approvalMethod   — использованный метод разрешения (например, "totp", "passkey", "manual")

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

Audit Trail

Каждое MCP-действие создаёт запись аудита. Эта запись неизменна, привязана к тенанту и машиночитаема. Она является основой для подтверждения соответствия, обнаружения аномалий и внутренних проверок.

{
  "event": "mcp.tool.executed",
  "tool": "emails.send_external",
  "tenantId": "tenant_123",
  "userId": "user_456",
  "agentId": "agent_sales_assistant",
  "clientId": "client_claude_desktop",
  "riskLevel": "critical",
  "confirmationId": "confirm_789",
  "inputHash": "sha256:a3f2c1...",
  "result": "success",
  "createdAt": "2026-06-11T10:00:00Z"
}

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