Історія аудиту

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, а також локальні для Plugin або прямі шляхи надсилання, які оминають спільну надійну доставку, не залишають записів.
• Записи проходять через обмежений фоновий робочий процес; збій робочого процесу або переповнення черги призводить до відкидання записів і реєстрації одного операційного попередження.
• Вихідні надсилання з неоднозначним через аварійне завершення результатом записуються як 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