Veil

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

В этом предложении заключается вся суть. Veil — это MCP-сервер и защищённый брокер ввода: агент говорит «помести ключ Stripe production в Google Secret Manager», человек видит, в какой именно проект и секрет будет произведена запись, и вводит значение в собственное окно Veil, а значение отправляется напрямую в место назначения. Модель никогда его не получает.

Реализовано в соответствии с SPEC.md.

Что решает Veil

Veil устраняет целый класс сбоев, вызванных тем, что агент знает секрет. При использовании Veil учётные данные не проходят через:

• подсказки LLM или историю диалога;

• аргументы инструментов MCP или результаты их работы;

• память агента или сгенерированный код;

• аргументы команд оболочки или argv процесса;

• журналы, отладочные трассировки или телеметрию;

• URL-адреса;

• вывод команд, видимый модели.

Что Veil не решает

Veil не делает ИИ-агента надёжным и не является «безопасным ИИ». Он не гарантирует, что агент выбрал правильное место назначения, что он вас понял, что он защищён от инъекций подсказок, что само место назначения безопасно, что ваша машина не скомпрометирована или что учётные данные не будут использованы не по назначению программным обеспечением, которое их легитимно получит.

Здесь две отдельные проблемы:

Veil отвечает на эти два вопроса. Он не претендует на решение остальных.

Модель доверия

Trusted with the credential value:

  The human at the keyboard
  Veil's secure input UI          (loopback only, in your control)
  Veil's secure input broker      (this process)
  The selected destination adapter
  The destination provider        (e.g. Google Secret Manager)

NOT trusted with the credential value:

  The LLM
  The agent / MCP client
  The conversation
  The prompt and any repository content it read
  Generated code
  Logs, telemetry, crash reports

Эта диаграмма не утверждает, что доверенные компоненты неуязвимы. Она показывает, где учётным данным разрешено находиться. Veil — это программное обеспечение, чувствительное к безопасности: если сам Veil вредоносен или скомпрометирован, граница исчезает. Его исходный код, зависимости и релизы заслуживают той же проверки, которую вы бы применили к любому инструменту для работы с учётными данными.

Два потока

Поток секрета — путь человека, который модель не может наблюдать:

Human ─▶ Veil secure UI (127.0.0.1) ─▶ Broker ─▶ Adapter ─▶ Destination

Поток агента — всё, что видит модель:

LLM ─▶ MCP client ─▶ Veil MCP server ─▶ non-sensitive result metadata

Схема инструмента MCP не содержит свойства, способного передавать учётные данные. Это структурное ограничение, а не инструкция в подсказке: нет поля value, secret_value, password, token, content или raw_secret, которое можно было бы использовать; закрытые схемы отклоняют неизвестные свойства, а аргументы проверяются на наличие значений, похожих на учётные данные, до их разбора.

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

{
  "destination": "gcp-secret-manager",
  "name": "STRIPE_SECRET_KEY",
  "target": { "project": "my-production-project", "secret": "STRIPE_SECRET_KEY" },
  "write_mode": "new-version",
  "environment": "production",
  "description": "Stripe production API key"
}

Veil отвечает request_id, классификацией риска и нормализованным местом назначения — и открывает собственное окно авторизации на вашей машине. Агент опрашивает secret.status.

Агент не получает ссылку для авторизации. Эта ссылка — возможность: любой, кто ею владеет, может завершить человеческую часть потока, а агент с оболочкой или HTTP-инструментом — это именно та модель угроз. Veil передаёт ссылку вашему браузеру и выводит её в собственную консоль. Установите VEIL_DISCLOSE_AUTHORIZATION_URL=true, если ваша конфигурация требует, чтобы агент передавал ссылку (например, для удалённой или безголовой сессии), — и понимайте, что это позволяет скомпрометированному агенту авторизовать собственный запрос.

Что видит человек

Этап A показывает имя учётных данных, провайдера места назначения, проект/аккаунт, ресурс, операцию и риск до ввода значения. Операции высокого риска (перезапись в production, хранение в открытом виде, базы данных приложений, замена учётных данных) требуют второго подтверждения на этапе B, после ввода и перед записью. Значение никогда не отображается повторно.

Страница, которую читает человек, и операция, которую выполняет исполнитель, — это один и тот же неизменяемый объект — нет отдельного «отображаемого места назначения». Любое изменение места назначения, проекта, имени секрета, операции, режима записи или адаптера аннулирует авторизацию и требует новой.

Поддерживаемые адаптеры

Места назначения arbitrary-network (универсальные HTTP POST, вебхуки) не реализованы, и реестр адаптеров отказывается их регистрировать.

Допущения и ограничения безопасности

Сказано прямо, потому что инструмент безопасности, который себя переоценивает, хуже, чем его отсутствие:

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

• CPython не может надёжно стирать память. SecretBuffer затирает изменяемый буфер, которым владеет, но процентное декодирование, преобразования str/bytes и SDK провайдеров создают неизменяемые копии, которые интерпретатор может хранить до сборки мусора. Veil минимизирует это и не даёт ложных гарантий.

• Интерфейс — это loopback HTTP. Любой процесс, работающий от вашего имени на вашей машине, может до него добраться, и любой такой процесс также может его имитировать. Каждый процесс Veil выводит случайную идентификационную фразу, которую отображают его страницы (помощь против подделки, а не криптографический контроль). Сокрытие ссылки от агента повышает планку, но не останавливает процесс, который может читать вывод консоли Veil, просматривать argv браузера или сканировать loopback-порты.

• Veil не проверяет место назначения. Если вы авторизуете запись учётных данных в документ Firestore, Veil записывает их туда и сообщает, что это плохая идея; он не препятствует этому.

• Предварительная проверка — с максимальными усилиями. Если провайдер недоступен во время предварительной проверки, он сообщается как недоступный, а не угадывается.

• Семантика сбоев. Сбой между записью провайдера и ответом может оставить учётные данные записанными без локальной записи об успехе. Veil сообщает о запросе как о неудачном; источником истины является место назначения.

Локальная разработка

uv venv
uv pip install -e ".[dev]"

# run the server the way an MCP client would
uv run veil serve

# with optional providers
uv pip install -e ".[dev,gcp,firestore]"

Конфигурация читается из собственного окружения Veil — никогда из аргументов инструмента:

Конфигурация MCP-клиента

{
  "mcpServers": {
    "veil": { "command": "uv", "args": ["run", "veil", "serve"] }
  }
}

Тесты

uv run pytest                  # everything
uv run pytest tests/security   # the adversarial suite only
uv run ruff check .
uv run mypy

Набор тестов безопасности — это требование продукта, а не приятное дополнение. Он включает обнаружение утечек-канареек по каждому наблюдаемому каналу, тесты вредоносного агента, фикстуры для инъекций подсказок, тесты TOCTOU и повторного воспроизведения, 100-поточный стресс-тест, состояния гонки, пути сбоев, симуляцию отказа провайдера, проверки интерфейса и фаззинг. Релиз блокируется, если происходит любая утечка канарейки, любая успешная обходная авторизация, любая успешная мутация после утверждения, любой завершённый запрос может быть воспроизведён повторно, любой секрет пересекает границу запроса, любая ошибка провайдера в сыром виде достигает MCP или любая операция высокого риска пропускает подтверждение.

См. docs/SECURITY_MODEL.md для карты инвариантов и тестов.

Статус проекта

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

MVP завершён, и полный набор тестов — включая состязательный — проходит. Что остаётся, прежде чем кто-либо сможет положиться на него в реальной работе: независимая проверка, тестирование человеческого фактора интерфейса подтверждения (SPEC.md §35) и подписанные артефакты релиза (§43).

Участие в разработке

Безопасность здесь — это продукт, поэтому требования к изменениям скорее конкретны, чем бюрократичны:

• Изменение, затрагивающее обработку учётных данных, авторизацию или поверхность MCP, требует теста, который пытается нарушить затрагиваемый инвариант, а не только показывает его работоспособность.

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

• Новые зависимости времени выполнения в ядре по умолчанию отклоняются. Брокер — это доверенная вычислительная база для учётных данных; SDK провайдеров относятся к опциональному расширению.

• Запустите ruff check ., ruff format --check ., mypy и pytest перед открытием pull request.

Нашли уязвимость? Пожалуйста, сообщите о ней конфиденциально через систему безопасности GitHub, а не через публичное обращение.

Лицензия

Apache License 2.0 © 2026 Eduardo Rosostolato.