Как реализовать контроль доступа и управление доверием в swarm из AI-агентов

Когда ваш swarm агентов превращается в цифровой бардак

Вы запустили swarm. Десятки, а то и сотни AI-агентов теперь крутятся в вашей инфраструктуре. Один агент читает почту, другой пишет посты в соцсети, третий анализирует базы данных. И вдруг вы понимаете: агент для анализа рынка почему-то запросил доступ к личным сообщениям в Slack. Агент-копирайтер пытается исполнить SQL-инъекцию. Агент-планировщик начал слать HTTP-запросы на левые IP-адреса.

Поздравляю. У вас классическая проблема swarm-систем: полное отсутствие контроля за тем, кто, кому и что может делать. В мире людей для этого есть паспорта, пропуска и договоры доверия. В мире агентов пока царит анархия.

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

1 Выдайте каждому агенту цифровой паспорт (DID), а не просто UUID

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

Вместо этого используйте децентрализованные идентификаторы (DIDs). На 28.03.2026 стандарт W3C DID 1.0 уже стал де-факто для идентификации нелюдей. DID - это не просто строка. Это URI, который указывает на документ (DID Document), содержащий публичные ключи, сервисы и другие метаданные, необходимые для проверки подлинности.

# Пример создания DID для агента (используем библиотеку did-python 2.4+)
from did_peer import DIDPeer
from cryptography.hazmat.primitives.asymmetric import ed25519

# Генерируем ключевую пару для агента
private_key = ed25519.Ed25519PrivateKey.generate()
public_key = private_key.public_key()

# Создаем DID методом 'peer' (для p2p сетей)
did = DIDPeer.generate(
    encryption_keys=[public_key],
    signing_keys=[public_key],
    service_endpoints=["https://agent-1.example.com/api"]
)

print(f"DID агента: {did.did}")
print(f"DID Document: {did.document}")

Теперь каждый агент может криптографически доказать, что он - это он. Подписать запрос. Зашифровать сообщение конкретно для другого агента. DID становится основой для всего остального.

2 Реализуйте контроль доступа на основе атрибутов, а не ролей

Ролевая модель (RBAC) для swarm - это боль. Сегодня агент аналитик, завтра - писатель. Послезавтра он и то, и другое. Роли множатся, политики становятся неподъемными.

ABAC (Attribute-Based Access Control) работает лучше. Доступ определяется не ролью, а атрибутами: "агент с подписью от DID X может читать данные с тегом 'финансы', если его репутация > 0.7 и время суток - рабочее".

Реализация? Возьмите OpenFGA (актуальная версия 0.4.1 на март 2026) или OPA. Настройте политики как код.

# Политика ABAC для swarm агентов (OpenFGA модель)
model:
  schema_version: 1.1
  type_definitions:
    - type: agent
      relations:
        member: {}
    - type: dataset
      relations:
        reader:
          union:
            - computed_userset:
                object_type: agent
                relation: member
          conditions:
            - name: "has_finance_tag_and_high_reputation"
              expression: |
                resource.tags.contains('finance') && 
                user.attributes.reputation > 0.7 &&
                time.hour >= 9 && time.hour <= 18
    - type: action
      relations:
        executor:
          union:
            - computed_userset:
                object_type: agent
                relation: member
          conditions:
            - name: "not_destructive"
              expression: |
                !resource.tags.contains('destructive') || 
                (user.attributes.trust_level > 0.9 && 
                 environment.approval_required == false)

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

3 Постройте граф доверия, а не слепо верьте всем подряд

Доверие в swarm - не бинарное понятие. Это граф. Агент A доверяет агенту B на 0.8, агенту C - на 0.3. B доверяет D на 0.9. Можно ли A доверять D? Это вычисляется.

Системы типа Bindu (актуальная версия 3.2 на 2026 год) или собственные реализации на базе верифицируемых учетных данных (VCs) решают эту задачу. Агент выдает другому агенту VC: "Я, аналитик-агент DID:123, подтверждаю, что агент DID:456 правильно предсказал курс акций в 95% случаев".

Это не просто оценка. Это криптографически подписанное утверждение, которое можно проверить, отозвать, передать дальше.

// Пример верифицируемого учетного доверия (JSON-LD формат)
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://trustgraph.example/contexts/v1"
  ],
  "id": "urn:uuid:98765432-1234-5678-1234-567812345678",
  "type": ["VerifiableCredential", "TrustAssertion"],
  "issuer": "did:example:analyst-agent-123",
  "issuanceDate": "2026-03-28T10:30:00Z",
  "expirationDate": "2026-06-28T10:30:00Z",
  "credentialSubject": {
    "id": "did:example:prediction-agent-456",
    "trustScore": 0.95,
    "competenceArea": "stock_predictions",
    "assertion": "Correctly predicted AAPL stock movement 19 out of 20 times"
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2026-03-28T10:30:00Z",
    "verificationMethod": "did:example:analyst-agent-123#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z3M... (подпись) ..."
  }
}

Теперь агенты принимают решения о сотрудничестве не на основе слепой веры, а на основе проверяемой репутации. И если агент начинает врать, его VC истекают или отзываются - доверие падает.

4 Используйте MCP не только для данных, но и для безопасного контекста

Model Context Protocol (MCP) к 2026 году из протокола для загрузки данных в промпты превратился в стандарт для безопасного обмена контекстом между агентами. Проблема: когда агент А делится контекстом с агентом Б, как убедиться, что Б не передаст его агенту В, у которого нет прав?

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

# Агент запрашивает контекст через MCP с проверкой прав
import mcp
from mcp.client import Client

async def get_context_with_auth(agent_did, resource_uri, auth_token):
    async with Client("wss://mcp-server.example") as client:
        # Предъявляем DID и токен доступа
        await client.authenticate({
            "did": agent_did,
            "proof": generate_did_proof(agent_did),
            "access_token": auth_token
        })
        
        # Запрашиваем ресурс - сервер проверит права автоматически
        resources = await client.list_resources()
        # Только ресурсы, доступные данному агенту
        
        # Чтение конкретного ресурса
        context = await client.read_resource(resource_uri)
        # Контекст может быть зашифрован для данного агента
        return decrypt_context(context, agent_private_key)

Ключевое отличие: сервер MCP знает политики доступа. Он не отдаст финансовый отчет агенту-копирайтеру, даже если тот технически может подключиться. И да, это значит, что ваш домашний Deep Research должен работать с аутентификацией.

5 Ведите неизменяемый журнал всех меж-агентных взаимодействий

Когда что-то пошло не так (а это произойдет), вам понадобится не просто лог, а криптографически верифицируемая запись того, кто, что, кому и когда сказал.

Используйте архитектуру с записью событий (Event Sourcing) или, что проще, ведите журнал в виде подписанных событий. Каждое сообщение между агентами должно содержать:

• Отправитель (DID)
• Получатель (DID)
• Временная метка
• Хэш содержимого
• Цифровая подпись отправителя

И все это - в систему, которую нельзя задним числом изменить. Hyperledger Fabric, обычная база с WAL (Write-Ahead Log), или даже простой файл с append-only доступом. Главное - чтобы нельзя было стереть или изменить историю.

Потому что когда агент-аналитик вдруг начнет рекомендовать вкладывать все деньги в мемные токены, вам нужно будет понять: он сам до этого додумался или ему кто-то "посоветовал"?

Где все ломается: частые ошибки и как их избежать

Я видел, как команды реализуют "безопасные" swarm, которые на деле были дырявыми, как решето. Вот топ ошибок:

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

Ответы на вопросы, которые вы постеснялись задать

А не слишком ли это сложно для простого swarm из 3-4 агентов?

Да, для 3-4 агентов это оверкилл. Но поставьте вопрос иначе: эти агенты имеют доступ к вашей почте? К корпоративным данным? К API банка? Если да - то даже для двух агентов нужна безопасность. Начните с простого: хотя бы уникальные ключи для каждого и базовый контроль доступа. Потом, когда агентов станет 10, вы скажете себе спасибо.

Что делать, если агент потерял свой приватный ключ или был скомпрометирован?

Во-первых, у каждого DID должен быть механизм обновления (в DID Document). Вы публикуете обновление: "старый ключ отозван, новый ключ - такой-то". Во-вторых, у вас должен быть kill-switch. Не просто остановить контейнер, а криптографически отозвать все доверительные отношения. Детерминированный kill-switch - это не роскошь, а необходимость.

Как совместить все это с автономностью агентов? Они же должны быстро принимать решения.

Кеширование. Локальная проверка политик. Предварительное вычисление доверия. Агент не должен ходить в сервис политик при каждом чихе. Но периодически - должен синхронизироваться и получать обновления. Баланс между безопасностью и производительностью - это engineering.

А если я использую cloud-решения типа OpenAI Assistant API?

Тогда вы делегируете безопасность провайдеру. Но даже там: настройте отдельные API-ключи для разных агентов. Используйте вековые истины из практического руководства по безопасности. И помните - облачный провайдер защитит свою инфраструктуру, но не вашу бизнес-логику.

Итог: безопасный swarm - это не опция, а обязательное условие

Представьте, что через год ваш swarm из агентов не просто помогает с аналитикой, а зарабатывает реальные деньги. Или управляет IoT-устройствами в умном доме. Или координирует доставку дронами.

Теперь представьте, что в этот swarm проник злонамеренный агент. Или что легитимный агент "сошел с ума" из-за ошибки в модели.

Контроль доступа и управление доверием - это не про то, чтобы усложнить жизнь разработчикам. Это про то, чтобы ваш swarm не превратился в роящихся цифровых ос, которые разнесут все, к чему прикоснутся.

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

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

И да, это уже происходит.

Подписаться на канал