Zero Trust для AI-агентов: применяем NIST 800-207 к автономным системам

Когда инженеры впервые слышат про zero trust AI, они обычно думают: «запретить агенту выполнять rm -rf». Но Zero Trust — это не чёрный список команд. Это архитектурная модель, формально закреплённая в NIST SP 800-207 (июль 2020), которая требует простого, но радикального: никогда не доверять по умолчанию, проверять каждый доступ явно и делать это непрерывно, а не один раз на входе в сеть.

Классическая zero trust architecture строилась вокруг людей и их устройств. Автономные AI-агенты ломают обе предпосылки. У Cursor, Claude Code или Copilot нет учётки в Okta, нет MFA-токена и нет ноутбука с EDR. Зато у них есть интерпретатор команд, доступ к вашим репозиториям и способность самостоятельно принимать решения о следующем действии — совершенно новый класс субъекта безопасности, к которому старые периметровые модели не применимы.

В этой статье мы применяем NIST 800-207 к Cursor, Claude Code и Copilot: берём пять пиларов из CISA Zero Trust Maturity Model — identity, device, network, application/workload, data — и проецируем каждый на специфику LLM-агентов. Главный сдвиг: AI agent identity перестаёт быть «учёткой разработчика, под которой запустили агент», и становится самостоятельной, криптографически проверяемой сущностью с ограниченным сроком жизни и явными scope'ами.

Что вы узнаете

• чем NIST 800-207 отличается для людей и для автономных AI-агентов;
• как выдать агенту verifiable identity через SPIFFE/SPIRE и JWT-SVID;
• как организовать mTLS между агентом и MCP-серверами без общего пароля;
• где проходит граница между Policy Decision Point и Policy Enforcement Point, и как описать доступ на Rego;
• как выглядит эталонная архитектура FlowLink и поэтапный план внедрения за 90 дней.

Почему классический Zero Trust не дотягивает до агентов

NIST 800-207 формулирует семь базовых тезисов. Третий звучит так: «доступ предоставляется на каждую сессию, а не один раз при входе». Для человека, открывшего портал в 9 утра, это значит «проверим снова в полдень». Для агента, делающего 400 tool-вызовов в час, это должно означать «проверим каждый вызов». Разница — три порядка величины.

Вторая проблема — скорость делегирования. Человек запрашивает доступ через тикет и ждёт одобрения. Агент в середине задачи сам решает дернуть внешнее API, смонтировать директорию или запустить curl. Если проверка доступа не встроена в критический путь каждого действия, она просто не сработает — агент её «обогнёт» тем же путём, каким обходит медленные CI-пайплайны.

Поэтому для AI-агентов идея Zero Trust переформулируется так: никакой субъект (человек, агент, MCP-сервер, LLM-провайдер) не получает доступ по факту нахождения в доверенной сети или под доверённой учёткой; каждый доступ явно авторизуется policy engine на основе identity, контекста и состояния среды в момент запроса.

Сводная карта: пилар NIST → агентский контроль

Разберём каждый пилар по отдельности — с конфигами, которые реально работают в production.

Принцип 1: Identity для AI-агентов

Первый и самый важный сдвиг. Сегодня 90% развёртываний AI-агентов работают под identity человека: Cursor наследует токен разработчика, Claude Code запускается от пользователя dev@laptop, а Copilot «живёт» внутри GitHub-аккаунта инженера. Это значит, что в логах аудита все действия агента неотличимы от действий человека. Если завтра агент зальёт секрет в публичный gist, следствие покажет на разработчика — а не на автономную сессию LLM.

NIST 800-207 требует, чтобы у каждого ресурса была identity. AI-агент — это ресурс. Следовательно, ему нужен собственный, независимо проверяемый идентификатор, который:

• выдаётся автоматически при старте сессии, а не копируется из .env;
• живёт строго время жизни задачи (TTL), после чего криптографически аннулируется;
• несёт атрибуты: тип агента, задачу, владельца-делегатора, разрешённые scope'ы;
• проверяется на каждом tool-вызове, а не один раз при handshake.

Эталонный стандарт для workload-identity — SPIFFE (Secure Production Identity Framework for Everyone) и его реализация SPIRE. Каждый агент при старте регистрируется и получает SVID (SPIFFE Verifiable Identity Document). Регистрируем сессию Claude Code как workload:

1# Регистрируем AI-агента как workload с уникальным identity
2spire-server entry create \
3  -spiffeID spiffe://flowlink.ai/agent/claude-code/session-a7f3b2 \
4  -parentID spiffe://flowlink.ai/host/prod-runner-04 \
5  -selector "unix:path:/opt/flowlink/agent.sock" \
6  -x509SVIDTTL 3600 \
7  -jwtSVIDTTL 300
8​
9# Агент при старте забирает свой JWT-SVID через workload API
10spire-agent api fetch jwt -audience mcp.flowlink.ai -spiffeID \
11  spiffe://flowlink.ai/agent/claude-code/session-a7f3b2

Полученный JWT-SVID — это и есть AI agent identity. Обратите внимание на короткий TTL: 300 секунд для JWT, 1 час для x509. Сессия агента живёт час — значит и её identity не должна пережить задачу. Если хакер украдёт токен, через 5 минут он превратится в тыкву. Содержимое токена несёт контекст, недоступный из обычного логина:

1{
2  "sub": "spiffe://flowlink.ai/agent/claude-code/session-a7f3b2",
3  "iss": "spiffe://flowlink.ai",
4  "exp": 1779864000,
5  "aud": "mcp.flowlink.ai",
6  "flowlink.agent_type": "claude-code",
7  "flowlink.task": "refactor-auth-module",
8  "flowlink.owner": "team-platform",
9  "flowlink.scopes": ["bash", "read", "write:src", "mcp:github"],
10  "flowlink.budget_usd": 12.50,
11  "flowlink.human_approval": false
12}

Теперь в audit journal каждая запись однозначно связана с конкретной сессией агента, конкретной задачей и конкретным человеком-делегатором. Это фундамент, без которого все остальные пилары бессмысленны — нельзя применять политику к субъекту без identity.

Принцип 2: Device и runtime-постура

Пятый тезис NIST 800-207: предприятие «мониторит и измеряет целостность и состояние безопасности всех активов непрерывно». Для ноутбука это posture-check (антивирус обновлён, диск зашифрован). Для AI-агента «device» — это процесс и его runtime: какие syscall'ы он делает, какие файлы трогает, не отклонилось ли поведение от заявленной задачи.

Здесь ключевую роль играют механизмы уровня ядра Linux. Подробно defence-in-depth для агентов (eBPF LSM, mount namespaces, capabilities) мы разбирали в статье про постановку Claude Code в production — здесь сосредоточимся на том, как runtime-контроль встраивается в Zero Trust-цикл. Суть в том, что проверка постуры должна быть не одноразовым gate'ом при старте, а потоком телеметрии, на который опирается policy engine:

1// eBPF-программа: непрерывно докладывает posture-сигналы агента
2SEC("lsm/bprm_check_security")
3int BPF_PROG(monitor_agent_exec, struct linux_binprm *bprm) {
4    char comm[16];
5    bpf_get_current_comm(&comm, sizeof(comm));
6​
7    // Агент должен запускать только команды из декларации задачи
8    if (is_flowlink_agent(comm) && !declared_in_task(bprm->filename)) {
9        emit_event(&((struct posture_event){
10            .kind   = UNEXPECTED_EXEC,
11            .agent  = current_agent_id(),
12            .target = bprm->filename,
13        }));
14        // PEP решит: заблокировать или запросить human approval
15        return -EPERM;
16    }
17    return 0;
18}

Дополнительно жёсткий seccomp-bpf-профиль отсекает syscall'ы, которые агенту в принципе не нужны: ptrace, mount, unshare, keyctl, bpf. Это не «правило политики», а физическое ограничение ядра — даже если policy engine скомпрометирован, агент не сможет делать то, чего ядро не позволяет. Таким образом device-пилар становится последней линией обороны и независимым источником достоверных фактов о поведении.

Принцип 3: Сеть — mTLS без неявного доверия

Второй тезис NIST: «вся коммуникация защищена независимо от расположения в сети». Это прямое убийство идеи «внутренний трафик доверенный, внешний — нет». Для AI-агента это значит, что соединение агента с MCP-сервером внутри того же VPC должно быть зашифровано и аутентифицировано точно так же, как соединение с внешним SaaS.

На практике это mTLS с mutual SPIFFE-аутентификацией. Ни один компонент не общается plaintext, ни у кого нет «общего пароля от MCP». Каждый участник предъявляет свой SVID, и доверие устанавливается через единый trust bundle. Подробно про защиту credential-потока между агентом и инструментами — в статье про предотвращение утечек MCP-кредов, а здесь — рабочая конфигурация PEP на стороне MCP-gateway:

1# /etc/flowlink/mcp-gateway.conf — mTLS между агентом и MCP-сервером
2server {
3    listen 8443 ssl;
4    server_name mcp.flowlink.ai;
5​
6    # Сертификат gateway как workload (SVID), валидируется через SPIFFE bundle
7    ssl_certificate     /var/lib/spire/agent/svid.pem;
8    ssl_certificate_key /var/lib/spire/agent/svid.key;
9​
10    # ОБЯЗАТЕЛЬНО mutual: агент тоже предъявляет свой SVID
11    ssl_client_certificate /var/lib/spire/trust/bundle.pem;
12    ssl_verify_client on;
13    ssl_verify_depth  2;
14​
15    # Отклоняем соединения с истекшим/аннулированным SVID
16    if ($ssl_client_verify != SUCCESS) { return 496; }
17​
18    location / {
19        # PEP: проксируем SPIFFE-ID дальше, в PDP, вместе с телом tool-вызова
20        proxy_set_header X-SPIFFE-ID   $ssl_client_s_dn_cn;
21        proxy_set_header X-Task-ID     $http_x_task_id;
22        proxy_pass http://127.0.0.1:9000;   # → Policy Decision Point
23    }
24}

Теперь даже если кто-то получит сетевой доступ к mcp.flowlink.ai, без валидного SVID из trust domain flowlink.ai он не пройдёт даже handshake. Никаких shared API-ключей в .env, никаких «внутренних» эндпоинтов без TLS. Сеть перестаёт быть источником доверия — им становится криптография и policy.

Принцип 4: Application / Workload — Policy Decision Point на каждый вызов

Это ядро Zero Trust, выраженное в архитектурных компонентах NIST 800-207: Policy Enforcement Point (PEP) перехватывает запрос, Policy Decision Point (PDP) — он же Policy Engine — принимает решение, а Policy Administrator ведёт журнал. PEP и PDP всегда разделены: тот, кто исполняет решение, не должен сам его принимать. Иначе компрометация одного компонента открывает всё.

Для AI-агента PEP — это MCP-gateway и eBPF-shield из предыдущих разделов. PDP — отдельный сервис с policy engine на OPA (Open Policy Agent), куда сходятся все сигналы: identity из SPIRE, posture из eBPF, бюджет из governor, классификация данных. Решение описывается декларативно на Rego:

1package flowlink.authz
2​
3# По умолчанию — запрет. Zero Trust не выдаёт права «на всякий случай».
4default allow := false
5​
6allow if {
7    # 1. Identity: SVID из доверенного trust domain, тип агента заявлен
8    input.identity.trust_domain == "flowlink.ai"
9    input.identity.agent_type  == "claude-code"
10​
11    # 2. Запрошенный инструмент входит в scope текущей сессии
12    input.action.tool in input.identity.scopes
13​
14    # 3. Команда прошла статический анализ: деструктивных паттернов нет
15    not destructive(input.action.command)
16​
17    # 4. Budget governor: в сессии ещё остались средства
18    input.session.budget_remaining > 0
19​
20    # 5. Runtime-постура чиста: за последние 60с не было аномалий от eBPF
21    input.posture.anomaly_score < 0.3
22​
23    # 6. Данные: операция не затрагивает restricted-секреты без одобрения
24    not touches_restricted(input.action)
25}
26​
27destructive(cmd) if {
28    lower(cmd) == destructive_patterns[_]
29}
30​
31destructive_patterns := [
32    "rm -rf /", "DROP TABLE", "DROP DATABASE",
33    ":(){ :|:& };:",                 # fork-bomb
34    "dd of=/dev/sda", "mkfs",
35]
36​
37# restricted-данные требуют явного human approval в момент вызова
38touches_restricted(action) if {
39    action.resource.classification == "restricted"
40    not input.session.human_approval
41}

Важный нюанс: решение PDP не кешируется надолго. NIST требует per-session авторизации; для агента мы идём дальше — per-call. Стоимость одного вызова OPA с загруженными данными — единицы миллисекунд; на фоне секунды LLM-генерации это шум. Зато если в середине сессии eBPF зафиксирует аномалию или бюджет иссякнет, следующий tool-call будет отклонён немедленно, без ожидания «переавторизации в конце часа».

Принцип 5: Данные и модели

Последний пилар — защита самих данных. Для AI-систем сюда попадают четыре категории, которых нет в классическом DLP: промпты, RAG-корпус, embedding'и и веса моделей. Контроль доступа к ним должен подчиняться тем же правилам, что и к таблицам в БД: классификация + авторизация на каждое чтение.

Возьмём RAG поверх корпоративного knowledge base. Векторы лежат в pgvector, и «агент с доступом к базе» не должен автоматически видеть всё. Классификация записей и проверка scope'ов выполняется на уровне SQL-запроса:

1-- RAG-поиск с enforcement-фильтром по classification и scope агента
2WITH agent AS (
3  SELECT :scope_bits AS scopes, :session_id AS sid
4)
5SELECT chunk.id, chunk.text,
6       chunk.embedding <=> :query_vec AS distance
7FROM   document_chunks chunk
8CROSS JOIN agent
9WHERE  chunk.classification IN ('public', 'internal')
10   OR (chunk.classification = 'restricted'
11       AND 'read:restricted' = ANY(agent.scopes)
12       AND EXISTS (SELECT 1 FROM approvals a
13                   WHERE a.session_id = agent.sid
14                     AND a.resource_id = chunk.id))
15ORDER BY distance
16LIMIT 10;

Так агент никогда не «случайно» подтянет в контракт секретный договор — фильтр сработает на уровне БД, ещё до того, как текст попадёт в промпт. Дополнительно:

• Промпты проходят санитизацию: инъекции и PII редачатся до отправки LLM-провайдеру;
• Секреты никогда не попадают в промпт напрямую — они выдаются через credential vault по принципу just-in-time, на конкретный tool-call и с аудитом;
• Веса моделей и embedding'и классифицируются как restricted-активы: их экспорт за пределы trust domain приравнен к выгрузке исходников.

Наконец, к данным относится и бюджет потребления моделей. Расход токенов — это тоже доступ к ресурсу, и NIST-логика применима к нему в полной мере: лимит задаётся в identity агента, governor списывает стоимость каждого вызова, а при исчерпании PDP перестаёт выдавать allow. Подробнее — в материале про budget governor для LLM-вызовов.

Эталонная архитектура

Соберём все пять пиларов в единую картину. Ниже — текстовая диаграмма того, как компоненты FlowLink реализуют эталонную архитектуру Zero Trust из NIST 800-207 (PEP, PDP, PA) применительно к автономным агентам. Каждый блок — независимый сервис со своим SVID и своим пределом ответственности; компрометация любого одного не разрушает всю систему.

                     ┌─────────────────────────────────┐
                     │   Человек-делегатор (delegator)  │
                     │   одобряет high-risk операции,   │
                     │   задаёт budget и scope задачи   │
                     └────────────────┬────────────────┘
                                      │ делегирует identity
                     ┌────────────────▼────────────────┐
   AI-агент ──SVID──▶│      PEP  :  MCP Gateway         │
   Cursor / Claude   │   mTLS, проверка SVID, журналир. │
   Code / Copilot    └────────────────┬────────────────┘
                                       │  запрос + контекст
                     ┌────────────────▼────────────────┐
                     │   PDP  :  Policy Engine (OPA)    │
                     │   Rego-политики + Trust Algorithm│
                     └─┬──────────┬──────────┬─────────┘
            ┌──────────┘          │          └────────────┐
   ┌────────▼─────────┐  ┌────────▼─────────┐  ┌──────────▼──────────┐
   │ Credential Vault │  │ eBPF Runtime     │  │  Audit Journal      │
   │ JIT-секреты,     │  │ Shield: posture, │  │  append-only,       │
   │ short-lived      │  │ seccomp, DNS     │  │  криптографич.       │
   └──────────────────┘  └──────────────────┘  └─────────────────────┘
            │                      │                      │
            └──────────┬───────────┴──────────────────────┘
                       ▼
            ┌───────────────────────┐   ┌──────────────────────┐
            │  LLM Provider (API)   │   │  Monitoring          │
            │  бюджет контролирует  │   │  Prometheus + alert  │
            │  budget governor      │   │  на аномалии         │
            └───────────────────────┘   └──────────────────────┘

Поток одного tool-вызова: агент с SVID стучится в PEP (MCP gateway); PEP мува запрос в PDP; PDP опрашивает vault (есть ли секрет), eBPF-shield (чиста ли постура) и governor (есть ли бюджет); на основе Rego-политики выносит allow или deny; решение вместе с полным контекстом уходит в append-only audit journal; если allow — PEP исполняет действие и списывает бюджет. Ни одна стрелка на схеме не подразумевает «доверия по умолчанию».

План внедрения за 90 дней

Не пытайтесь построить всю архитектуру сразу — это самый частый повод свернуть Zero Trust-инициативу. Делайте пилары последовательно, каждый приносит измеримую пользу сам по себе. Вот проверенный на практике roadmap:

Итог

Zero Trust для AI-агентов — это не продукт и не галочка в чеклисте. Это переосмысление субъекта доступа: вместо «доверенного пользователя в доверенной сети» мы получаем проверяемую workload-identity, mTLS на каждом соединении, PDP на каждый вызов и непрерывный контроль runtime и данных. NIST 800-207 даёт каркас из пяти пиларов; задача — честно применить каждый к реалиям автономных LLM-систем, а не переносить корпоративные SSO-шаблоны туда, где они не работают.

Технологии для этого уже成熟: SPIFFE/SPIRE, eBPF, seccomp, OPA, pgvector, mTLS. FlowLink собирает их в единый каркас — policy engine, eBPF-shield, MCP gateway, credential vault, budget governor и audit journal — так что не приходится склеивать пять инструментов руками. Начните с identity, остальное наворачивается инкрементально, и за 90 дней вы приходите к архитектуре, где ни один агент не получает доступ «по умолчанию».