Границы доступаCapyAgent1 ноября 2026Редакция 2.1

Кто может читать память агента

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

Все исследования

Главный результат

Проверили 32 контекста с 16 отдельными областями личной памяти. Система вернула 64 разрешённые записи и не вернула ни одной из 960 запрещённых пар «запрос - запись» в этой матрице. Это не доказательство безопасности всех интерфейсов или защиты от вредоносных инструкций.

Термины простыми словами

Tenant: отдельная область клиента или владельца системы.
Профиль: отдельный набор личной памяти пользователя.
Запрещённая пара: запрос и запись, которую этот контекст не вправе читать по заданному правилу.
RBAC: доступ к системам и действиям на основе роли пользователя.

Разбор исследования / 03

Что значит «своя» и «чужая» память

Проверка построена вокруг конкретного вопроса: вернёт ли поиск записи из другой личной области? Для каждого контекста заранее определены разрешённые записи. Затем одинаковая постановка выполняется с разделением областей и с намеренно общим хранилищем. Контроль нужен, чтобы убедиться: чужие записи существуют и способны попасть в выдачу без разделения.

01 / ЗапросОпределён контекст
В тесте задано, к какой личной области относится запрос. Проверяются 32 подготовленных контекста.
02 / РазделениеВыбрана область памяти
Поиск выполняется внутри одной из 16 личных областей, а не по всем записям сразу.
03 / ПроверкаСверены возвращённые записи
Есть ли свои записи? Есть ли чужие? Два вопроса считаются отдельно.
04 / КонтрольОбщее хранилище
При снятии разделения чужие записи попадают в выдачу. Это проверяет чувствительность опыта.

Рисунок 1. Схема компонентного теста чтения памяти. Она не является схемой всей авторизации CapyAgent.

Почему проверяем и разрешение, и запрет

Система, которая никогда ничего не возвращает, тоже покажет ноль чужих записей. Но работать с ней невозможно. Поэтому результат состоит из двух частей: 64 из 64 разрешённых попаданий и отсутствие запрещённых в заданной матрице. Контроль с общим хранилищем дополнительно подтверждает, что тест способен увидеть нарушение границы.

Какие риски этот опыт не закрывает

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

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

Временные права на конкретную задачу

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

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

Почему ответственность остаётся у человека

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

Аннотация

Исследована изоляция личных заметок ScopedFileStore в ревизии CapyAgent 77ac9b72. Созданы 32 синтетических контекста, варьирующих tenant, организацию, команду, пользователя и профиль. По заявленной модели личная память объединяется для одного пользователя и профиля внутри tenant и организации, независимо от команды: получилось 16 отдельных областей по две заметки. Для каждого контекста выполнен одинаковый запрос. Получены все 64 разрешённых попадания и ноль запрещённых попаданий из 960 проверяемых пар. Реально выполненный контроль с общим хранилищем вернул все 960 запрещённых для такого контекста записей. Опыт оценивает один файловый API при заданной конфигурации. Сроки полномочий, сетевые интерфейсы, рабочие учётные записи и устойчивость языковой модели к prompt injection не проверялись.

1. Какую границу проверяем

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

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

В опыте используются только вымышленные идентификаторы и строки «контрольная метка владельца». Никакие реальные заметки, токены, переписки или данные клиентов не читались.

3. Снимок и независимое правило допустимости

Исследован тот же зафиксированный снимок 77ac9b72 [4]. Использован публичный метод ScopedFileStore.Recall, а не копия его логики в оценщике. Созданы все комбинации двух tenant, двух организаций, двух команд, двух пользователей и двух профилей: 32 контекста с одинаковым искусственным идентификатором сессии.

Правило оценки задано отдельно: для private-записи должны совпадать tenant, организация, пользователь и профиль. Команда не меняет владельца личной памяти. Таким образом, контексты объединены в 16 областей, по две записи на область. Каждый запрос вправе получить две записи и не вправе получить остальные 30. Всего проверяются 64 разрешённые и 960 запрещённых пар.

В первой версии нашего оценщика команда ошибочно участвовала в определении нового владельца. Он назвал вторую разрешённую запись «чужой». После сверки с документированным назначением private-хранилища исправлено правило оценки, а не продукт. Прежний вывод исключён из финальных метрик, история изменения сохранена [5]. Это не найденная и затем исправленная утечка CapyAgent.

4. Почему нужен контроль с общим хранилищем

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

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

Нельзя использовать эту матрицу для оценки вероятности утечки в случайном трафике. Контексты образуют зависимые комбинации, а не случайную выборку независимых пользователей. Поэтому доверительный интервал общей «безопасности в процентах» не рассчитывается.

5. Новые измеренные результаты

Таблица 1. Разрешённые и запрещённые пары в заданной матрице
Показатель	Личная память с разделением	Контроль: общая память
Запросы	32	32
Отдельные области личной памяти	16	Одна общая область
Разрешённые попадания	64 из 64	64 из 64
Запрещённые попадания	0 из 960	960 из 960

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

Результат поддерживает конкретное свойство выбранного файлового API в этой конфигурации. Он не распространяется автоматически на общий поиск диалогов, импорт данных, кеши, web-интерфейс, коннекторы или ошибочную выдачу полномочий. Сырые результаты каждого запроса опубликованы [6].

6. Что отдельно показали сценарии согласования

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

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

7. Полномочия на задачу: что остаётся проектным требованием

Для агента, который может менять данные, полезно выдавать доступ только к необходимым системам, только на нужные действия и только на срок задачи. После завершения или отмены задачи доступ должен отзываться. Такое ограничение уменьшает возможную область ошибки и дополняет распределение прав по ролям (RBAC), а не универсально заменяет его.

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

Личные агенты клиентов, по нашему прогнозу на 2027 год, могут сделать такие границы частью продуктового взаимодействия. Это повод проектировать понятные разрешения заранее, а не установленный факт о рынке или уже готовая совместимость CapyAgent с любым агентом.

8. Повторение, ограничения и вывод

Код матрицы находится в research_eval_test.go. Команда: go test -p 1 ./internal/memory -run '^TestResearchScopeMatrixV2$' -count=1 -json. Контексты, подсчёт попаданий, окружение и контрольные суммы опубликованы в приложении [7]. Эксперимент выполнялся в отдельной копии, с пустым пользовательским окружением и без доступа к рабочим данным.

Не проводились атаки на живые сервисы, оценка вредоносных документов с реальной моделью, проверка TTL и отзыва токенов или аудит всех путей чтения. Модельные security-прогоны требуют отдельного разрешённого бюджета и принятой локальной среды; они не выполнены и не названы успешными. Лицензия кода и MIT-атрибуция адаптированных компонентов сохранены.

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

Новые проверки от 1 ноября 2026 · Версия 2.0

Оригинальная статья сайта, редакционная подготовка с применением ИИ. Измеренные результаты отделены от прежних наблюдений и планов. Внешнее научное рецензирование не заявляется. SR-2026-03 - внутренний номер, не DOI.

Первичные источники и материалы проверки

Ссылки и статус материалов проверены 1 ноября 2026 года. Внешние работы используются как источники методов; их показатели не выдаются за результаты CapyAgent.