> ## Documentation Index
> Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt
> Use this file to discover all available pages before exploring further.

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

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

Gateway зберігає обмежений журнал аудиту, що містить лише метадані, у спільній базі даних стану OpenClaw. Він дає відповіді на операційні запитання, як-от «який агент виконувався, коли та як завершив роботу», «які дії інструментів виконувалися під час запуску», а коли аудит повідомлень увімкнено — «чи надійшло прийняте вхідне повідомлення до диспетчеризації» та «чи досягло вихідне повідомлення кінцевого стану доставки».

Журнал зберігає ідентичність, порядок, походження, дію, стан і нормалізовані коди результатів. Він ніколи не зберігає запити, тіла повідомлень, аргументи чи результати інструментів, вкладення, назви файлів, URL-адреси, вивід команд або необроблений текст помилок.

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

Події запусків і дій інструментів записуються щоразу, коли аудит увімкнено (типове налаштування). Події життєвого циклу повідомлень вмикаються окремо й типово вимкнені.

| Сімейство        | Дії                                                      | Типово    |
| ---------------- | -------------------------------------------------------- | --------- |
| Запуски агентів  | `agent.run.started`, `agent.run.finished`                | увімкнено |
| Дії інструментів | `tool.action.started`, `tool.action.finished`            | увімкнено |
| Повідомлення     | `message.inbound.processed`, `message.outbound.finished` | вимкнено  |

Кожен запис містить стабільний ідентифікатор події, монотонну послідовність журналу, часову позначку життєвого циклу, виконавця, дію, стан, `schemaVersion: 1` і `redaction: "metadata_only"`. Повний опис полів і фільтрів запитів див. у розділі [Записи аудиту](/cli/audit).

## Події життєвого циклу повідомлень

Установіть [`audit.messages`](/uk/gateway/configuration-reference#audit), щоб вибрати, що записувати, а потім перезапустіть 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](/uk/gateway/opentelemetry) або інструменти на рівні каналів.

## Зберігання, термін зберігання та міграція

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

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

## Виконання запитів

* CLI: [`openclaw audit`](/cli/audit) із фільтрами за агентом, сеансом, запуском, типом, станом, напрямком, каналом, часовими межами та сторінковою навігацією за курсором.
* RPC Gateway: `audit.activity.list` (потребує `operator.read`) повертає версіоноване об'єднання подій активності V1; випущений RPC `audit.list` залишається незмінним для старіших клієнтів запусків та інструментів. Див. [Протокол Gateway](/uk/gateway/protocol#audit-ledger-rpc).

## Пов’язані матеріали

* [CLI записів аудиту](/cli/audit)
* [Довідник із конфігурації](/uk/gateway/configuration-reference#audit)
* [Протокол Gateway](/uk/gateway/protocol#audit-ledger-rpc)
* [OpenTelemetry](/uk/gateway/opentelemetry)