Модель безопасности

Модель безопасности Wippy определяет, к чему ваш код имеет доступ, к чему не имеет и кто обеспечивает эти границы. Её стоит прочитать до начала разработки, потому что она работает на двух уровнях, которые большинство фреймворков объединяют в один: среда выполнения изолирует каждый процесс, так что опасные возможности попросту отсутствуют, а слой политик на основе атрибутов управляет тем, какие возможности реестра процессу разрешено использовать. Понимание обоих уровней меняет то, как вы структурируете приложение.

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

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

Поверх этого доступ к возможностям реестра управляется контролем доступа на основе атрибутов (ABAC). Каждая защищённая операция проверяется относительно области безопасности текущего актора — набора политик, разрешающих или запрещающих действие над ресурсом, опционально с условиями по метаданным актора и ресурса. Это декларативно: политики задаются в конфигурации, а не в коде приложения.

Когда процесс работает и с актором, и с областью, доступ запрещён по умолчанию: запрос разрешается, только если какая-то политика явно его допускает и ни одна не запрещает. Строгий режим управляет неполным случаем, когда актор или область не установлены. Он включён по умолчанию, поэтому неполный контекст получает отказ; установка security.strict_mode: false в конфигурации среды выполнения переключает на разрешающее поведение. Планировать нужно то, что процесс без объявленного контекста безопасности при значении по умолчанию не проходит ни одну проверку — задайте такому процессу блок security: в его записи или запускайте его по пути, который контекст предоставляет. В сочетании с политиками наименьших привилегий это даёт авторизацию с отказом по умолчанию поверх изоляции через отсутствие. Синтаксис политик, правила вычисления и форму блока security: смотрите в справочнике по безопасности.

Изоляция процессов

Каждая единица исполнения в Wippy работает в изолированном процессе с собственным встроенным интерпретатором (Lua или WASM).

Что у процесса есть: собственное пространство памяти (базовые накладные расходы ~13 КБ для Lua). Ограниченное представление реестра. Идентичность актора и область безопасности. Управляемый жизненный цикл с восстановлением после сбоев и лимитами перезапусков.

Чего у процесса нет: доступа к файловой системе (кроме как через контролируемые реестром записи файловой системы). Доступа к сети (кроме как через выданные модули HTTP-клиента или инструментов). Доступа к памяти других процессов. Доступа к среде выполнения Go, в которой он размещён. Доступа к переменным окружения (кроме как через выданные записи окружения).

Как обеспечивается изоляция: каждый процесс Lua стартует с минимальной стандартной библиотекой. Файловый ввод-вывод, доступ к процессам ОС, динамическая загрузка кода и работа с сетью никогда не загружаются, поэтому их нет в окружении, и процесс не может восстановить то, чего не существует. Загрузка модулей ограничена: require разрешает только модули и записи реестра, явно выданные процессу, без поискового пути по файловой системе. Процессы WASM достигают эквивалентной изоляции через WASI: доступны только хост-функции и смонтированные записи файловой системы, настроенные для этой записи.

Это не песочница через разрешения времени выполнения (вроде seccomp или AppArmor). Это песочница через отсутствие. Опасные возможности никогда не загружаются, поэтому их нельзя эксплуатировать, обойти или повысить.

Контроль возможностей

Реестр — это хранилище возможностей Wippy, а политики безопасности — его слой авторизации.

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

Идентификаторы записей пространственно именованы. ID имеет форму namespace:name с одним двоеточием, а пространства имён иерархичны через сегменты, разделённые точками, например tenant_acme.tools:read (пространство имён tenant_acme.tools, имя read). Политики сопоставляются с действиями и ресурсами, а шаблоны ресурсов могут указывать на префикс пространства имён, так что одно правило может покрыть целое пространство имён.

Политики решают вопрос доступа. Каждое обращение к возможности (поиск в реестре, вызов функции, дескриптор базы данных, открытие файла) проверяется относительно области актора. Политика объявляет покрываемые действия и ресурсы, эффект разрешения или запрета и опциональные условия по метаданным актора и ресурса. Вычисление происходит при каждом обращении, а не один раз при старте: если хоть одна политика запрещает — доступ запрещён; если хотя бы одна разрешает и ни одна не запрещает — разрешён; если ни одна политика не подошла — доступ запрещён. (Когда в контексте вообще нет актора или области, этот неполный случай разрешается строгим режимом, а не вычислением политик.)

Контекст объявляется, а не берётся из воздуха. Функции наследуют актора и область вызывающей стороны. Порождённый процесс наследует их тоже: его фрейм ответвляется от фрейма породившего, а блок security: в собственной записи затем изменяет этот унаследованный контекст — указанный в нём actor заменяет унаследованного актора, а перечисленные по ID реестра политики и группы политик сливаются с унаследованной областью. Разрешение атомарно: если какая-либо указанная политика или группа отсутствует, порождение завершается неудачей, а не продолжается с частичной областью. Команда CLI может дополнительно объявить meta.command.security, применяемый только на доверенном пути запуска, когда оператор сам запустил команду.

Аргументы инструментов имеют форму схемы. Инструмент объявляет JSON Schema для своих входных данных. Эта схема передаётся модели, чтобы она генерировала соответствующие аргументы, а доступ к инструменту проверяется политиками до выполнения вызова.

Границы данных

Соединения с базами данных — записи реестра. Процесс не собирает собственную строку подключения. Он запрашивает соединение по ID реестра, и этот запрос проверяется политиками до того, как будет возвращён дескриптор. Процесс, чьи политики не дают доступа к записи базы данных арендатора B, не сможет получить к ней дескриптор.

API-ключи LLM живут в системе окружения. Ключи для Claude, GPT и других провайдеров читаются из системы окружения (например, переменные окружения ОС, доступные через запись env.storage.os, на которые ссылаются записи env.variable, чтение которых проверяется политиками через действие env.get). Провайдер читает их внутренне; они не передаются в аргументах процесса и не возвращаются в вызывающий код.

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

Безопасность агентов

Агенты — это процессы на базе LLM с использованием инструментов. Они принимают решения во время выполнения, которые ваш код не контролирует напрямую, поэтому их границы важны. Wippy решает это теми же механизмами реестра и политик, что и для любого другого процесса.

Доступ к инструментам. Агент может вызывать только инструменты, перечисленные в его определении, и каждое выполнение инструмента идёт через funcs.call, который проверяется политиками. Запрещённый вызов завершается неудачей до запуска функции инструмента. Агент, спроектированный для чтения клиентских данных, но не для их удаления, либо не имеет инструмента удаления в определении, либо получает отказ на это действие по политике.

Внешние и MCP-инструменты. Wippy может потреблять внешние инструменты и предоставлять собственные по Model Context Protocol. Потребляемые инструменты идут через тот же путь вызова функций и те же проверки политик, что и нативные. Инструменты, которые Wippy предоставляет внешним MCP-клиентам, защищены ограниченными по области отзываемыми токенами доступа, которые ограничивают набор действий клиента.

Структурированный вывод. Модуль LLM может запрашивать вывод, ограниченный схемой (структурированный), используя нативную поддержку структурированного вывода провайдера, так что вывод агента можно удерживать в объявленной форме.

Наблюдаемость. При включённом OpenTelemetry вызовы LLM-провайдеров и инструментов трассируются, а расход токенов записывается через контракт usage-tracker. Это даёт вам аудиторский след того, что агент вызывал и сколько потратил. См. Наблюдаемость.

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

Многопользовательский контроль

Для развёртываний, где несколько клиентов используют один инстанс Wippy, изоляция обеспечивается вычислением политик до выполнения любой операции, а не кодом приложения, проверяющим ID арендаторов.

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

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

Конкурентность ограничена на хосте. Хосты процессов ограничивают конкурентность через пулы воркеров. Группы процессов (pg.scope) предоставляют изолированные кластерные пространства членства и широковещания и могут ограничивать количество групп и участников. Ограничения CPU или памяти на арендатора не являются встроенной возможностью среды выполнения; обеспечивайте их на уровне инфраструктуры.

Отдельное руководство по многопользовательской архитектуре запланировано.

Область применения и ограничения

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

Шифрование данных на диске. Шифрование баз данных, дисков и блоб-хранилищ обеспечивается нижележащей инфраструктурой (PostgreSQL TDE, шифрование дисков и подобное). Wippy предполагает, что шифрование обеспечивает слой хранения.

Изоляция на сетевом уровне. Изоляция процессов происходит на уровне приложения. Сегментация сети между Wippy и его зависимостями (база данных, API LLM, внешние сервисы) обеспечивается инфраструктурой: VPC, группы безопасности, межсетевые экраны.

Управление идентичностью. Аутентификация (проверка того, кем является пользователь) обеспечивается вашим слоем аутентификации. Модель безопасности Wippy начинается после аутентификации: она контролирует, что могут делать процессы аутентифицированного пользователя, а не кем этот пользователь является. Токены, несущие актора и область, можно выпускать и проверять через хранилище токенов.

Аудиторские журналы инфраструктуры. Трассировка Wippy покрывает операции уровня процессов: вызовы функций, вызовы инструментов, активность процессов. Доступ уровня инфраструктуры (SSH к серверу, административные операции с базой данных) должен аудироваться инструментами инфраструктуры.

Частые вопросы

Может ли агент одного арендатора получить доступ к данным другого? Нет, если ресурсы каждого арендатора ограничены политиками. С политиками на арендатора и строгим режимом среда выполнения отказывает в доступе к ресурсам вне области арендатора до запуска кода агента.

Может ли агент повысить собственные права? Только если его политики разрешают запись в собственное определение. Записи в реестр проверяются политиками, поэтому запрещающая политика на собственном пространстве имён агента предотвращает самомодификацию. Агент, который может создавать инструменты в одном пространстве имён, не может выдать себе доступ к пространствам имён, которые его область ещё не покрывает.

Как посмотреть, что делал агент? При включённом OpenTelemetry вызовы LLM и инструментов трассируются, а расход токенов записывается через контракт usage-tracker. См. Наблюдаемость.

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

Изоляция арендаторов обеспечивается моим кодом или средой выполнения? Средой выполнения. Движок политик вычисляет каждое обращение до выполнения операции. Ваша задача — написать политики для каждого арендатора; среда выполнения их применяет.

Как защищены внешние MCP-инструменты? Инструменты, потребляемые по MCP, идут через тот же путь вызова функций и те же проверки политик, что и нативные. Инструменты, которые Wippy предоставляет внешним MCP-клиентам, защищены ограниченными по области отзываемыми токенами доступа. Подключение MCP-сервиса не обходит модель безопасности.

Справочник по безопасности

См. также

• Справочник по безопасности - Политики, области, акторы, хранилища токенов и блок security:
• Управление зависимостями - Проверка дайджестов модулей
• Кластер - Межузловая идентичность и доверие пиров
• Воркфлоу Temporal - Передача подписанного контекста
• Registry - Хранилище возможностей
• Модель процессов - Изоляция и жизненный цикл процессов
• Агенты - Определения агентов и использование инструментов