Защита корпоративных ИИ-агентов в MCP Toolbox: наборы инструментов для определения намерений, аутентификация и логи

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

Протокол Model Context Protocol стал открытым стандартом для подключения моделей к инструментам и источникам данных предприятий. Сам протокол прост, однако его успешное использование в производстве требует строгого соблюдения архитектурных принципов, выходящих далеко за рамки простого предоставления нескольких сырых API. Ниже приведён пример сценария, иллюстрирующий практический опыт создания агентов, работающих с данными предприятий с помощью MCP Toolbox.

Сценарий агента

Современные агенты редко решают сложные корпоративные проблемы с помощью одного вызова инструмента. Реальные операции требуют многоэтапных рабочих процессов: получение метаданных, проверка состояния, выявление аномалий, сбор первичных доказательств и синтез необходимых действий. В этом сценарии PostgreSQL и BigQuery выступают в роли структурированных индексов, которые направляют агента к нужным неструктурированным данным в Google Cloud Storage.

1. Проверка состояния в PostgreSQL. Сначала агент запрашивает базу данных, чтобы подтвердить метаданные клиентского случая, уровни обслуживания и идентификаторы активных инцидентов.
2. Анализ телеметрии в BigQuery. Целенаправленные аналитические запросы позволяют выявить аномальные скачки нагрузки и извлечь соответствующие пути к файлам или временные метки сессий.
3. Углубленный диагностический анализ в GCS. Имея точные временные метки и ключи объектов, агент использует инструменты GCS для получения полных записей пакетов и нередактированных отчетов о угрозах для окончательного анализа.

Всё это объединяют три принципа дизайна.

1. Создавайте наборы инструментов в соответствии с целью

Предоставление модели генерических инструментов вроде execute_sql, read_file или describe_schema редко приводит к созданию хорошего агента. Инструменты низкого уровня заставляют ЯИМ тратить ресурсы на догадки относительно структуры хранилища, ключей объектов и схем до того, как начнётся решение реальной проблемы. Многие ИИ-приложения терпят неудачу не из-за слабости модели, а потому что у агента отсутствовал необходимый контекст в нужный момент. Три подхода помогают в этом:

• Давайте приоритет цели перед техническими деталями. Вместо примитивов хранения предоставляйте специально разработанные инструменты вроде fetch_threat_intel_report или get_incident_summary.

Группируйте инструменты в целенаправленные наборы. Наборы, предназначенные для конкретной области, например incident-triage, делают выбор инструментов предсказуемым и воспроизводимым, причем небольшая группа хорошо спроектированных бизнес-инструментов всегда превосходит обширный набор универсальных инструментов.

Позвольте метаданным хранилища выполнять фильтрацию. Быстрые пути к получению данных вместе с описательными атрибутами объектов (уровень клиента, метки инцидентов, метки регионов) позволяют сотруднику быстро находить важные данные, так что он никогда не загружает информацию, которая ему не нужна.

tools.yaml, определяющий такой набор инструментов для GCS и баз данных, выглядит следующим образом:

# tools.yaml - Intent-Driven GCS & DB Toolset Definition

sources:
  my-agent-gcs-source:
    kind: cloud-storage

  my-agent-pg-source:
    kind: cloud-sql-postgres
    project: my-agent-sec-prod
    instance: customer-db

toolsets:
  incident-triage:
    - get_incident_summary
    - fetch_threat_intel_report

tools:
  - kind: tool
    name: fetch_threat_intel_report
    type: cloud-storage-read-object
    source: my-agent-gcs-source
    description: "Fetch and extract parsed indicators of compromise (IoCs) from a GCS-hosted threat intelligence dossier."
    bucket: customer-diagnostics-vault # Hardcoding prevents cross-bucket traversal attacks

  - kind: tool
    name: get_incident_summary
    type: postgres-sql
    source: my-agent-pg-source
    description: "Retrieve active incident metadata and active session IDs."
    statement: |
      SELECT incident_id, severity, session_id FROM incidents WHERE status = 'ACTIVE'

# BigQuery sources and tools have been omitted to maintain the example's clarity and brevity

2. Защита периметра с использованием концепции нулевого доверия

Доступ к производственным хранилищам данных и корпоративным базам данных сопряжен с серьезными требованиями к безопасности. Агенты обрабатывают неструктурированные данные, такие как комментарии к заявкам или описания сигналов тревоги, поэтому они естественным образом подвержены атакам ввода кода. В ходе атаки типа «забудь предыдущие инструкции» может потребоваться открыть хранилище диагностических данных клиента B вместо ожидаемого. Два встроенных функционала MCP Toolbox помогают сохранять строгие границы безопасности.

Привязка параметров URL

Чтобы предотвратить воздействие на большую языковую модель с целью изменения конфиденциальных параметров, разработчики могут закрепить параметры приложения в URL подключения к серверу. Инструментарий выявляет эти параметры запроса, привязывает их на уровне транспортного слоя и удаляет их из схемы инструмента, которую получает модель. Большая языковая модель никогда не видит таких параметров, как bucket или project, поэтому внедренные инструкции не имеют возможности что-либо изменить:

import asyncio
from toolbox_core import ToolboxClient, Protocol

async def run_incident_triage():
    # Sensitive GCS bucket and GCP project parameters are bound at connection time.
    # The LLM never sees or modifies 'project' or 'bucket' arguments.
    async with ToolboxClient(
        "https://mcp.internal.demo.net/mcp?project=my-agent-sec-prod&bucket=customer-diagnostics-vault",
        protocol=Protocol.MCP_v20260728 # Stateless MCP transport
    ) as toolbox:

        # The Client SDK automatically forwards bound parameters across toolsets
        incident_tools = await toolbox.load_toolset("incident-triage")

        # The agent invokes the tool with only the necessary business argument
        threat_tool = await toolbox.load_tool("fetch_threat_intel_report")
        result = await threat_tool(report_id="INC-89211")

        print("Triage analysis complete:", result)

if __name__ == "__main__":
    asyncio.run(run_incident_triage())

Детальная авторизация инструментов

Общий учетный аккаунт службы с широкими правами — это неподходящее решение. Вместо этого Toolbox может интегрироваться с системой управления идентичностями предприятия через OAuth2 или OIDC, так что агент будет работать под точными учетными данными человека-аналитика, который запустил рабочий процесс:

# auth.yaml - MCP Server Auth & Scoped Tools

kind: authServices
name: my-agent-okta-auth
type: generic
audience: my-agent-mcp-toolbox
authorizationServer: https://identity.demo.com/oauth2/default
mcpEnabled: true
scopesRequired:
  - openid
  - profile
---
kind: tool
name: fetch_threat_intel_report
type: cloud-storage-read-object
source: my-agent-gcs-source
description: "Fetch parsed indicators of compromise from GCS"
# Enforce fine-grained tool-level scopes
authRequired:
  - my-agent-okta-auth
scopesRequired:
  - read:gcs_threat_intel
  - tier:enterprise_support

Если оператор без привилегий read:gcs_threat_intel запускает агента, Toolbox возвращает ответ HTTP 403 Forbidden ещё до того, как будет загружен хотя бы один объект хранилища.

3. Возможность наблюдения с первого дня

Отладка автономного агента отличается от отладки детерминированного приложения, поскольку требует возможности просмотра всей цепочки рассуждений модели и её взаимодействия с инструментами. Серверы MCP следует рассматривать как инфраструктуру первого класса для производственных целей, а не как временные утилитные скрипты. Внедрение в Toolbox структурированной логгирования и метрик выполнения позволяет инженерной команде отслеживать частоту вызовов, задержки, размеры данных и закономерности возникновения ошибок со временем:

# Configure MCP Toolbox for structured logging
./toolbox --config "tools.yaml" --log-level info --logging-format json

# Configure MCP Toolbox to export traces and metrics
./toolbox --telemetry-gcp

Каждое вызов может также генерировать структурированный отчет об исполнении:

# Structured execution log emitted by the MCP Server runtime
logger.info(
    "Tool invoked",
    extra={
        "tool": "fetch_threat_intel_report",
        "storage_source": "gcs://customer-diagnostics-vault",
        "report_id": "INC-89211",
        "bytes_streamed": 1048576,
        "latency_ms": 142.5,
        "request_id": "req-01HX89Z2A",
        "user_email": "analyst@demo.com"
    }
)

Отправка этих структурированных данных в Cloud Logging и отслеживание их движения по многоэтапной работе позволяет быстро определить, связан ли скачок задержек с очень большим объектом в GCS, запросом в BigQuery без индекса или медленной работой самой модели.

Вывод

Эффективность агента определяется количеством и качеством структурированной информации, которая ему предоставляется. Сочетание Google Cloud Storage с MCP Toolbox создаёт агентскую рабочую силу, обладающую высокой скоростью, богатым контекстом и корпоративными характеристиками. Дизайн инструментов, ориентированный на цели, привязка параметров URL и встроенная авторизация OIDC позволяют моделям получать доступ к критически важным источникам данных без ущерба для безопасности или возможностей мониторинга.