Вызов инструментов в Go: почему вызов модели ещё не разрешение выполнить команду

Проблема описана в классификации OWASP LLM06:2025 Excessive Agency (избыточные полномочия ИИ-агента): приложение даёт модели слишком широкие возможности, и ошибочный либо спровоцированный ответ приводит к нежелательному действию. Для российских SaaS-команд это прямой риск нарушения 152-ФЗ (о персональных данных) и ФЗ-161 (о национальной платёжной системе), где изоляция данных между арендаторами (tenant isolation) не рекомендация, а требование.

Ниже пошаговый разбор на Go: как отделить намерение модели от контекста безопасности, чтобы ни галлюцинация (когда модель уверенно выдумывает то, чего не было), ни prompt injection (внедрение вредоносной инструкции через пользовательский текст) не обошли проверки backend.

Что понадобится?

• Go 1.21 или новее
• Доступ к любой LLM с поддержкой вызова инструментов (tool calling): OpenAI API, GigaChat API или локальная модель через Ollama
• Базовое понимание структур и интерфейсов в Go
• Примерно 40 минут на реализацию и тесты

Пошаговая инструкция

1. Замените прямое действие на предложение.

Не давайте модели инструмент issue_refund (выполнить возврат). Дайте ей propose_refund (предложить возврат). Разница принципиальная: первый исполняет финансовую операцию, второй создаёт заявку, которую ещё предстоит проверить.

2. Разделите данные модели и данные backend на две структуры.

Модель формирует только намерение. Контекст безопасности создаёт сервер на основании аутентифицированного пользователя:

type Actor struct {
    UserID          string
    TenantID        string
    CanRequestRefund bool
}

type RefundIntent struct {
    PaymentID   string `json:"payment_id"`
    AmountMinor int64  `json:"amount_minor"`
}

RefundIntent собирается из аргументов, которые вернула модель. Actor создаётся backend из проверенных серверных данных. Даже если LLM подсунет поле tenant_id или is_admin, оно не попадёт в структуру авторизации.

3. Опишите платёж и предложение возврата.

type Payment struct {
    ID              string
    TenantID        string
    RefundableMinor int64
}

type RefundProposal struct {
    UserID      string
    TenantID    string
    PaymentID   string
    AmountMinor int64
    Status      string
}

Платёж хранит организацию-владельца и сумму, доступную для возврата. Предложение фиксирует параметры и пользователя. Никакого реального списания на этом этапе нет.

4. Задайте интерфейсы доступа к данным.

type PaymentReader interface {
    Find(ctx context.Context, paymentID string) (Payment, error)
}

type ProposalStore interface {
    Create(ctx context.Context, proposal RefundProposal) error
}

За ними может стоять PostgreSQL, тестовый стаб или что угодно. Сейчас важна сама логика проверок.

5. Напишите сервис, который не доверяет аргументам модели.

var (
    ErrForbidden     = errors.New("forbidden")
    ErrNotFound      = errors.New("payment not found")
    ErrInvalidAmount = errors.New("invalid amount")
)

type Service struct {
    payments  PaymentReader
    proposals ProposalStore
}

func (s *Service) ProposeRefund(
    ctx context.Context,
    actor Actor,
    in RefundIntent,
) error {
    if !actor.CanRequestRefund {
        return ErrForbidden
    }
    if in.AmountMinor <= 0 {
        return ErrInvalidAmount
    }

    payment, err := s.payments.Find(ctx, in.PaymentID)
    if err != nil {
        return err
    }
    if payment.TenantID != actor.TenantID {
        return ErrNotFound
    }
    if in.AmountMinor > payment.RefundableMinor {
        return ErrInvalidAmount
    }

    return s.proposals.Create(ctx, RefundProposal{
        UserID:      actor.UserID,
        TenantID:    actor.TenantID,
        PaymentID:   payment.ID,
        AmountMinor: in.AmountMinor,
        Status:      "pending_approval",
    })
}

Порядок проверок: право на возврат, валидность суммы, существование платежа, принадлежность платежа организации пользователя, допустимость суммы возврата. Только после всех пяти шагов создаётся предложение со статусом pending_approval.

6. Обратите внимание на ответ при чужом платеже.

Если модель подставила идентификатор платежа другой организации, сервис возвращает ErrNotFound, а не ошибку авторизации. Это осознанное решение: для вызывающей стороны лучше не раскрывать сам факт существования чужого платежа.

Как это выглядит в реальном сценарии?

{
  "name": "propose_refund",
  "arguments": {
    "payment_id": "pay_1842",
    "amount_minor": 4900
  }
}

Что делать с этим прямо сейчас, по ролям?

Разработчику SaaS-сервиса в РФ. Проверьте, есть ли в вашем приложении инструменты, которые выполняют действие без промежуточного шага подтверждения. Особенно это касается операций с деньгами и персональными данными: 152-ФЗ требует изоляции данных между организациями, а ФЗ-161 регулирует переводы. Паттерн «propose, а не execute» (предложить, а не исполнить) закрывает основной вектор атаки.

Автору Дзена, который встраивает ИИ-функции в свои инструменты. Если вы используете модель для автоматизации (публикация, модерация комментариев, работа с аналитикой), убедитесь, что вызов инструмента проходит через слой проверки прав, а не исполняется напрямую.

Предпринимателю. Спросите у своей команды: «Что произойдёт, если модель вызовет правильную функцию с чужим идентификатором?» Если ответ «выполнится», у вас проблема, которую этот паттерн решает за один рефакторинг.

Если у вас в сервисе модель может вызывать функции с финансовыми последствиями, добавьте между ней и исполнением ровно одну прослойку: структуру актора из серверных данных и статус pending_approval. Это занимает час, а закрывает класс уязвимостей, который OWASP выделил в отдельный пункт.