# Как отделять доказательства действий агента от заметок расследователя

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

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

## Доказательства и анализ отвечают на разные вопросы

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

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

Заметки должны оставаться редактируемыми, потому что хорошее расследование пересматривает себя. В ранней заметке может быть сказано: «Похоже, вызов c-204 отправил данные клиентов». Изучив контекст запроса и ответа, аналитик может исправить её так: «Вызов c-204 передал внутренний идентификатор в заголовке запроса. Запись не подтверждает, что данные клиентов покинули среду». Это полезное исправление. Ему место в файле дела, где оно остаётся изменением рассуждения, а не изменением доказательства.

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

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

## Устойчивые идентификаторы делают утверждения проверяемыми

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

Идентификатор сессии отвечает на вопрос: «О каком запуске процесса агента идёт речь?» Идентификатор вызова отвечает на вопрос: «Какое конкретное HTTP- или SSH-действие внутри этого запуска подтверждает утверждение?» Сам по себе ни один из идентификаторов ничего не доказывает. Это устойчивые адреса. Доказательство даёт сохранённая запись по этому адресу вместе с вашим объяснением её содержания.

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

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

| ID утверждения | Вывод расследователя | Ссылка на доказательства | Статус |
| C-01 | Запуск агента обратился к платёжному API после первого одобрения. | Сессия `s-7f31`; вызовы `c-204`, `c-205` | Подтверждено |
| C-02 | Запрос изменил платёжную запись. | Сессия `s-7f31`; вызов `c-205`; запись ответа | Не выяснено |
| C-03 | Человек намеревался внести это изменение. | Запись одобрения; ни одно доказательство вызова не устанавливает намерение | Не подтверждено |

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

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

## Читаемый экспорт - производная копия, а не запись

В большинстве расследований нужен читаемый вид. Зашифрованные байты нельзя изучить, просто прищурившись, и никто не должен делать вид, что можно. Создайте производную копию для проверки, но до начала аннотирования явно зафиксируйте её связь с источником.

Начните с записи в реестре доказательств. Укажите ссылку на дело, имя исходного файла или пакета, когда и откуда вы его получили, кто его собрал, охват сессий, если он известен, и результат проверки. Добавьте команду проверки и сохраните её вывод терминала вместе с материалами дела. Не заполняйте пробелы догадками. Если вы не знаете, кто собирал материалы или когда это произошло, напишите «неизвестно» и откройте вопрос.

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

```
sp audit verify <preserved-audit-record>
```

Запишите в реестре доказательств фактическую команду, её аргументы, код завершения и полный вывод. Не вписывайте в отчёт вымышленную строку успеха лишь потому, что команда «должна была» сработать. Вывод - часть события проверки. Если проверка не прошла, не считайте последующие трактовки установленными доказательствами. Сохраните неудачный результат, по возможности снова соберите неповреждённый источник и объясните разрыв, вместо того чтобы тихо подменить его более поздним экспортом.

Затем создайте производную копию для проверки с именем, которое говорит, что это такое. Например:

```
case-2026-041/
  original/
    audit-record.enc
  verification/
    verify-command.txt
    verify-output.txt
  derivatives/
    activity-readable-2026-07-24.json
  notes/
    findings.md
    claim-table.md
```

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

Не называйте преобразованный файл «сырым» только потому, что вы не редактировали текст вручную. Инструмент, который расшифровывает, разбирает, фильтрует, форматирует, нормализует часовые пояса или удаляет поля, меняет представление. Такое преобразование может быть полностью оправданным. Просто назовите его.

## Повторная сериализация создаёт спор, который нельзя выиграть

Повторная сериализация означает декодирование структурированного содержимого и его повторную запись. Расследователи делают это, когда переформатируют JSON, сохраняют таблицу, заново создают отчёт или пропускают данные через парсер, который сам выбирает порядок полей и экранирование. Это кажется безобидным, ведь смысловое содержимое может выглядеть одинаково. В оспариваемом расследовании «выглядит одинаково» - очень слабый критерий.

Представьте, что аналитик экспортировал действия в JSON, отсортировал вызовы по локальному времени отображения, добавил поле `reviewed: true` и сохранил файл как `audit-final.json`. Позже проверяющий замечает, что у двух событий совпадает отображаемая секунда, но их исходный порядок важен. Из экспорта уже непонятно, сохранила ли сортировка порядок источника. Если при разборе произошла ошибка, изменённый файл может её скрыть. Теперь аналитику приходится защищать цепочку инструментов и рабочий процесс вместо того, чтобы указать на сохранённую запись.

Ещё одна частая ошибка - редактирование путём замены. Кто-то меняет похожее на учётные данные значение на `REDACTED`, а затем распространяет отредактированную запись как доказательство. Это создаёт две проблемы. Значение могло вообще не быть учётными данными, а проверочная копия теперь отличается от оригинала в неизвестном числе позиций, если команда не задокументировала каждое изменение. Редактируйте копию для распространения, помечайте её как отредактированную производную копию и храните источник с нужными средствами контроля доступа.

Заметки людей тоже могут случайно повторно сериализовать доказательства. Вставленное в тикет тело запроса может потерять экранирование, пробелы, порядок или непечатаемые символы. Скриншот может скрыть содержимое за пределами видимой области. Цитата в отчёте может не включить ответ, который меняет смысл запроса. Сначала ссылайтесь на ID вызова. Приводите лишь минимум текста, нужный для объяснения вывода, и указывайте, что цитата взята из читаемой производной копии.

Хороший файл дела описывает преобразования так, чтобы другой человек мог их проверить. Например: «D-03 создана из оригинала O-01 после успешной офлайн-проверки. При экспорте запись расшифровали для проверки, ограничили вид сессией s-7f31 и не перезаписывали O-01». Если вы применили фильтр, скажите об этом. Если нормализовали часовые пояса, скажите об этом. Если инструмент отбросил поля, скажите об этом. Именно в умолчаниях прячется случайное отмывание доказательств.

## Записи одобрения сужают утверждение, а не раскрывают его смысл

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

Это ограничение важно, когда расследование подходит к неудобному вопросу: «Пользователь это разрешил?» Не отвечайте одним словом. Разделите утверждение на части. Пользователь мог разрешить работу процесса в этой сессии. Позже процесс мог использовать учётные данные. Запрос мог выполниться успешно. При этом итоговое действие могло выйти за пределы того, что человек считал разрешённым. Доказательства могут подтвердить часть этих утверждений, а другие оставить открытыми.

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

Пишите выводы с видимой границей. «Доказательства показывают, что пользователь одобрил подписанный процесс для сессии s-7f31» - это утверждение об одобрении сессии. «Доказательства показывают, что пользователь одобрил вызов c-205» требует записи об одобрении каждого вызова для c-205. «Пользователь намеревался изменить платёжную запись» требует доказательств намерения, которые могут находиться вообще вне журнала действий. Не превращайте первое предложение в третье только потому, что так удобнее.

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

## Ведите заметки, которые можно менять без загрязнения дела

Ваши заметки должны приглашать к исправлениям и при этом показывать автора и время. Хороший вывод содержит утверждение, обоснование, ссылки, ограничения и статус. Ему не нужен театральный голос повествователя.

Используйте такой формат:

```markdown
Finding: The agent called the payment API after session approval.

Claim: Session s-7f31 included a credentialed HTTP call to the payment API.
Evidence: Session s-7f31; call c-205; derivative D-03.
Reasoning: The call record identifies the configured HTTP channel and the destination represented in the record.
Limits: This record does not establish the human's business intent or the full downstream effect.
Analyst: initials
Recorded: 2026-07-24T18:32:00Z
Status: supported
```

Слово «обоснование» здесь необходимо. Список ID не заменяет вывод. Опишите связь, которую вы делаете, и то, чего запись установить не может. Читатели больше доверяют выводу, когда его границы ясно изложены.

Не включайте изменяемые личные пометки в имена файлов доказательств или метаданные объектов. Имя вроде `bad-call-confirmed.enc` превращает мнение в кажущуюся истину источника. Используйте нейтральные имена, например `O-01-audit-record.enc`, а мнение храните в `F-04-findings.md`. Это избавит от проблем, когда после повторной проверки «подтверждено» превращается в «не подтверждено».

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

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

## Неудачная временная шкала обычно начинается с безобидной правки

Представьте инцидент, в котором агент для программирования обращается к внутреннему API развёртывания. Оператор замечает незнакомое изменение и экспортирует журнал действий в таблицу. Чтобы его было легче читать, оператор сортирует строки по местному времени, удаляет поля, которые выглядят повторяющимися, и выделяет цветом строку, которую считает причиной. Затем он добавляет комментарий: «Агент развернул неутверждённую конфигурацию» и отправляет книгу группе реагирования.

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

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

Третья проблема возникает, когда команда развёртывания говорит, что ответ API означал «принято на обработку», а не «конфигурация развёрнута». Выделенная строка была настоящей. Вывод оказался слишком широким. Поскольку оператор поместил его внутрь выглядящего как доказательство артефакта, читатели приняли его за свойство записи, а не за ошибочную трактовку.

Более чистая реконструкция выглядит иначе. Сохраните зашифрованную запись аудита как O-01. Выполните `sp audit verify` для O-01 и сохраните результат команды. Создайте D-01 как читаемый вид. В файле дела запишите три отдельных утверждения: какая сессия сделала какой вызов, какой охват одобрения применим и что устанавливает ответ. Третье утверждение может потребовать записи системы развёртывания. Если оно остаётся невыясненным, так и оставьте. Это не незавершённое расследование, а честное расследование.

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

## Проверка должна пройти до того, как трактовка закрепится

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

Последовательность должна быть простой. Соберите источник, не меняя его. Запишите, откуда он получен и кто с ним работал. Проверьте зашифрованный материал поддерживаемой офлайн-командой. Сохраните результат проверки. Только после этого создайте помеченную читаемую производную копию. Затем начинайте вести таблицу утверждений и заметки.

Проверка хеш-цепочки особенно полезна, потому что она проверяет сохранённую зашифрованную запись без ключа хранилища. Так разделяются два вопроса, которые люди часто объединяют: «Сохранила ли запись целостность цепочки?» и «Кому разрешено читать чувствительное содержимое?» Расследователь может ответить на первый вопрос, не расширяя доступ к секретам ради обычной проверки целостности.

Успешная проверка не устанавливает личность источника, полноту за пределами собранного диапазона или трактовку. Она означает, что проверяющее средство приняло предъявленную ему цепочку. Зафиксируйте реальный объём собранных материалов. Если дело касается предполагаемого пробела до первой сохранённой сессии, не пишите «аудит не показывает более раннего действия», если вы не знаете, что сбор включает нужную более раннюю историю. Защищаемая формулировка уже: «В собранной записи нет более раннего действия этого типа».

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

## Отдавайте на проверку файл дела, а не источник на правку

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

Полезная проверка задаёт четыре прямых вопроса:

1. Могу ли я найти каждую указанную сессию и вызов в сохранённой записи или документированной производной копии?
2. Отличает ли вывод зафиксированное событие от предположения аналитика?
3. Соответствует ли заявленный охват одобрения выводу, который из него делают?
4. Указал ли автор преобразование, фильтр, редактирование или отсутствующий контекст, влияющие на это утверждение?

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

Для команд, использующих Sallyport, журналы Sessions и Activity дают расследователям два естественных уровня ссылок, а мгновенный отзыв сессии даёт отдельное событие контроля для изучения. Используйте эти записи как опоры, а не как замену анализу. Журнал может сказать, что в нём зафиксировано, а файл дела должен объяснить, какой вывод команда может ответственно сделать на этом основании.

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