Память может быть правдивой и всё равно небезопасной

Постоянная память меняет поверхность риска у ИИ-агентов. Агент может восстановить старые решения, факты, approvals и планы — и уверенно продолжить работу из состояния, которое было правильным вчера, но уже не подходит для действия сейчас.

Сигнал пришёл из дискуссии о provenance.

В обсуждении памяти Claude Code участник DanceNitra разделил формальное наличие поля source и реальную возможность вернуться к источнику. В описанном хранилище около 98,3% записей имели заполненный source, но лишь 24 записи — примерно 0,01% — содержали идентификаторы, которые действительно можно было повторно получить и проверить.

Значение вроде agent:scholar может указывать автора, но не обязательно даёт адрес исходного контента. Значит, наличие provenance-метаданных ещё не гарантирует возможность обнаружить drift, удаление или подмену источника.

Та же дискуссия показывает второй класс риска: caller-controlled metadata становится опасной, если библиотека позже интерпретирует её так, будто она была создана собственным доверенным verification path.

Но даже хорошего provenance недостаточно.

Представим, что агент помнит: pull request был проверен на commit A. Это может быть абсолютной исторической правдой. Но ветка уже ушла на commit B, политика изменилась, tenant другой, API обновился или срок действия разрешения закончился.

Если агент спрашивает только «была ли эта память валидной?», он может ответить «да» и всё равно принять неверное решение.

Из обсуждения — в исполняемый контракт.

Мы реализовали это различие в open-source Causal Memory Layer (CML) как детерминированный слой Current-State Applicability. Реализация прошла review, была усилена против stale-SHA и cross-repository substitution, смержена и прошла тестовые Python lanes, deterministic-contract проверки, package validation, secret scan, dependency audit и CodeQL.

Почему repository и commit SHA стали строгими.

На review проявился важный edge case: если историческая память вообще не была привязана к repository или commit SHA, совпадающий source digest мог позволить ей выглядеть безопасной уже в другом контексте кода. Теперь, если текущая authoritative-среда предоставляет repository или commit SHA, отсутствие соответствующей исторической привязки ведёт к REVALIDATE, а не к MATCH.

Отсутствие исторического контекста — не разрешение предполагать непрерывность.

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

Не каждое изменение должно инвалидировать каждую память. Правка нерелевантного README не обязана отзывать память о tenant-scoped billing rule. Поэтому applicability требует purpose-bound fingerprint: в решение входят только те измерения среды, которые действительно важны для конкретного действия.

Нужно истечение полномочий, а не истины.

Старая approval должна оставаться в аудите даже после окончания срока. Review старого commit остаётся исторической правдой после движения ветки. Источник, который позже удалили, не должен исчезать из истории.

Это не должно становиться vendor moat.

Мы поделились предложением и с Anthropic, и с OpenAI. Причина простая: revalidation памяти полезнее как совместимый safety primitive между экосистемами, чем как закрытая фича одного поставщика.

memory
→ provenance verification
→ source re-fetch / integrity
→ current environment comparison
→ applicability verdict
→ current authority
→ action

Полезно также разделять четыре метрики покрытия:

1. Locator coverage: можем ли мы идентифицировать происхождение?
2. Re-fetch verification coverage: можем ли мы снова получить источник и сравнить digest?
3. Source enumeration coverage: можем ли мы обнаружить удаление или orphaning?
4. Environment binding coverage: знаем ли мы достаточно о контексте, в котором повторное использование безопасно?

Память говорит агенту, что было правдой. Applicability говорит, имеет ли эта правда право управлять действием сейчас.