История аудита

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

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

Семейства записей

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

Каждая запись содержит стабильный идентификатор события, монотонную последовательность журнала, временную метку жизненного цикла, субъекта, действие, статус, schemaVersion: 1 и redaction: "metadata_only". Полное описание полей и фильтров запросов приведено в разделе Записи аудита.

События жизненного цикла сообщений

Задайте audit.messages, чтобы выбрать, какие данные записывать, затем перезапустите Gateway:

• off (по умолчанию): записи сообщений отсутствуют.
• direct: только сообщения в личных беседах.
• all: сообщения в личных беседах, группах и каналах.

Записи сообщений создаются на двух авторитетных границах:

• Входящие строки записываются, когда принятое сообщение достигает основной диспетчеризации, включая результаты обработки дубликатов и конечные результаты обработки.
• Исходящие строки записываются, когда общая надёжная доставка достигает конечного результата: отправлено, подавлено, завершилось ошибкой либо получено явное значение unknown для отправок с неоднозначным результатом из-за сбоя. Также учитываются результаты восстановления очереди и перемещения в очередь недоставленных сообщений. Для каждого исходного логического содержимого ответа создаётся одна конечная строка; разбиение на части и разветвление по адаптерам объединяются в resultCount.

Классификация типа беседы

Режим direct является границей конфиденциальности, поэтому сообщение классифицируется как относящееся к личной беседе, только если это подтверждается сведениями о назначении: путь отправки объявил тип беседы назначения либо маршрут сеанса доставки точно указывает канал и получателя, которым выполняется доставка. Менее надёжные признаки, такие как состояние политики или исходная беседа, позволяют классифицировать сообщение как group (исключая его из сбора direct), но не позволяют присвоить ему direct. Сообщения, для которых невозможно доказать принадлежность к личной беседе, классифицируются как unknown и не записываются в режиме direct. Поэтому для каналов, не объявляющих типы чатов, в режиме direct может записываться меньше строк, чем в режиме all.

Модель конфиденциальности

В строках сообщений никогда не хранятся необработанные идентификаторы платформы. Идентификаторы учётной записи, беседы, сообщения и цели, если доступна корреляция, экспортируются только в виде локальных для установки псевдонимов с ключом (hmac-sha256:v1:<keyId>:<digest>):

• Ключ HMAC создаётся при первом использовании, разделяется по доменам для каждого типа идентификатора и хранится в той же базе данных состояния, что и журнал.
• Псевдонимы стабильны в пределах одной установки, поэтому строки, относящиеся к одной беседе, можно сопоставлять без раскрытия идентификатора платформы.
• Это корреляция, а не анонимизация: любой пользователь с доступом на чтение к базе данных состояния также имеет доступ к ключу и может проверять предполагаемые необработанные идентификаторы на соответствие псевдонимам. Экспорт через RPC и CLI никогда не включает ключ.
• Если материал ключа отсутствует или повреждён при сохранённых строках сообщений, Gateway безопасно прекращает запись и отбрасывает новые записи сообщений вместо незаметной замены ключа, которая нарушила бы корреляцию.

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

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

Ограничения охвата и доказательности

Журнал работает по принципу наилучших усилий и намеренно ограничен. Рассматривайте его как свидетельство того, что было записано, а не как доказательство того, что произошло:

• Отсутствие строки ничего не доказывает. Входящие сообщения, отброшенные до допуска, отправки из процессов CLI без запущенного средства записи Gateway, а также локальные для плагина или прямые пути отправки, обходящие общую надёжную доставку, не оставляют записей.
• Запись выполняется ограниченным фоновым рабочим процессом; сбой рабочего процесса или переполнение очереди приводит к отбрасыванию записей и регистрации одного операционного предупреждения.
• Исходящие отправки с неоднозначным результатом из-за сбоя записываются как unknown, а не с вымышленным результатом.

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

Хранение, сроки хранения и миграция

Записи находятся в общей базе данных состояния (state/openclaw.sqlite) и записываются вне критического пути доставки. Запросы никогда не возвращают записи старше 30 дней, а размер журнала ограничен 100 000 строками; просроченные строки удаляются при запуске, во время ежечасного обслуживания и при последующих операциях записи. Обслуживание сроков хранения продолжается даже при отключённом сборе.

При обновлении с версии Gateway, использующей прежний журнал только для запусков и инструментов, схема автоматически мигрируется при запуске (либо через openclaw doctor --fix); существующие строки и их последовательности журнала сохраняются.

Выполнение запросов

• CLI: openclaw audit с фильтрами по агенту, сеансу, запуску, типу, статусу, направлению, каналу, временным границам и постраничному просмотру с курсором.
• RPC Gateway: audit.activity.list (требуется operator.read) возвращает версионированное объединение событий активности V1; поставляемый RPC audit.list остаётся неизменным для прежних клиентов запусков и инструментов. См. раздел Протокол Gateway.

Связанные материалы

• CLI записей аудита
• Справочник по конфигурации
• Протокол Gateway
• OpenTelemetry