Секция 3.2: Изоляция и песочницы: SSH, Docker, gVisor

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

3.2.1. Принцип "Минимально Необходимых Прав" (POLP)

Самая важная изоляция – это изоляция прав пользователя. Никогда не запускайте агента от имени `root` на хост-системе.

Эталонная настройка пользователя:

1. Создание пользователя `gemini-agent` с домашней директорией `/home/gemini-agent`.

2. Ограничение доступа к `sudo`: только конкретные команды (белый список), например `systemctl status`.

3. Использование дисковых квот, чтобы агент не мог забить всё место логами.

3.2.2. Контейнеризация: Агент в Docker

Запуск агента внутри контейнера – это стандарт де-факто для безопасных сред.

Преимущества Docker-изоляции:

**Файловая система:*Агент видит только то, что вы примонтировали через `-v`.

**Сеть:*Вы можете использовать `–network none` или ограничить доступ только к определенным IP (например, только к Gateway 1.1).

**Лимиты ресурсов:*`–memory="1g" –cpus="0.5"`. Агент не сможет "съесть" все ресурсы сервера.

3.2.3. Продвинутая изоляция: gVisor и Kata Containers

Если вы не доверяете ядру Linux (например, боитесь Container Breakout), используйте gVisor. Это песочница, которая перехватывает системные вызовы приложения и выполняет их в пользовательском пространстве.

Для агента это выглядит как обычный Linux, но для хоста агент полностью изолирован. Это критично, если агент имеет право выполнять произвольный код на Python или Bash.

3.2.4. Изоляция SSH (Restricted Shell)

Когда агент заходит на удаленный узел, вы можете ограничить его возможности на стороне этого узла.

Метод `authorized_keys`:

В файле `~/.ssh/authorized_keys` на удаленном сервере можно прописать:

`command="/usr/local/bin/agent-gatekeeper.sh",no-port-forwarding,no-x11-forwarding ssh-ed25519 …`

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

3.2.5. Виртуализация: Агент в чистой VM

Для самых параноидальных сценариев (например, анализ вредоносного ПО с помощью ИИ), агент должен жить в полноценной виртуальной машине (KVM/QEMU). После выполнения каждой задачи VM должна откатываться к чистому снапшоту.

3.2.6. Матрица уровней изоляции

| Уровень | Технология | Когда использовать |

| :– | :– | :– |

| L1: Пользователь | `useradd` + `chroot` | Простая автоматизация на личном ПК |

| L2: Контейнер | `Docker` / `Podman` | Стандартная работа с инфраструктурой |

| L3: Песочница | `gVisor` | Работа с недоверенным кодом |

| L4: VM | `Proxmox` / `ESXi` | Критическая инфраструктура, ИБ-аудит |

––

Резюме раздела:

Изоляция – это не паранойя, а дисциплина. Правильно настроенная песочница позволяет вам дать агенту больше свободы, зная, что цена ошибки ограничена рамками контейнера. В следующей секции мы разберем, как сделать лог аудита агента единственным и неоспоримым источником истины.

Секция 3.3: Аудит и логирование как единственный источник истины

В мире автономных систем доверие – это результат проверяемости. Если агент выполнил команду, которая привела к сбою, вы должны иметь возможность посекундно восстановить ход его мыслей. В этой секции мы разберем архитектуру "неизменяемого аудита" для Gemini CLI.

3.3.1. Разница между системным логом и логом аудита

Обычные логи (syslog, journald) фиксируют, *что* произошло. Лог аудита агента фиксирует, *почему* это произошло.

Состав идеального лога аудита:

1. Request ID: Уникальный идентификатор задачи.

2. User Intent: Что пользователь попросил на самом деле.

3. Thought Trace: Цепочка рассуждений агента.

4. Tool Call: Точный синтаксис вызванного инструмента.

5. Observation: Сырой вывод системы.

6. Safety Justification: Обоснование безопасности (для критических команд).

3.3.2. Проблема "Переписывания истории"

Если агент имеет доступ к своим собственным логам, он (гипотетически) может их стереть или изменить, чтобы скрыть ошибку или вредоносное действие.

Решение: Удаленный логгинг (Remote Audit Sink)

Логи должны немедленно отправляться на выделенный сервер (например, через `fluentd` или `syslog-ng`), к которому у агента нет прав записи.

**Схема:*Agent -> Local Buffer -> Remote Immutable Log Storage.

3.3.3. Структурированный формат JSONL

Мы используем JSON-Lines (`.jsonl`), так как он позволяет читать логи построчно, не загружая весь файл в память. Это критично для систем, работающих месяцами.

Пример записи в аудите:

{

"timestamp": "2026-02-09T18:50:00Z",

"task_id": "8b5a..",

"step": 4,

"thought": "I suspect the database is locked. I will check for long-running queries.",

"action": "run_command",

"params": {"cmd": "psql -c 'SELECT pid, query FROM pg_stat_activity'"},

"safety_score": 0.95

}

3.3.4. Визуализация аудита для комиссий по разбору инцидентов (Post-mortems)

При разборе инцидентов ("Почему GitLab упал в 2 часа ночи?") логи агента становятся главным свидетелем.

Инструменты визуализации (например, специализированные дашборды в Grafana) позволяют превратить сухой JSON в графическую цепочку ReAct, где красным подсвечены моменты, когда "Наблюдение" противоречило "Мысли" агента.

3.3.5. Интеграция с SIEM (Security Information and Event Management)

Для энтерпрайз-сред логи Gemini CLI должны интегрироваться в общую систему безопасности компании (Splunk, Elastic stack). Аномалии в поведении агента (например, внезапный интерес к файлам `/etc/shadow`) должны триггерить моментальные алерты дежурному офицеру безопасности.

3.3.6. Хранение и Цикл Жизни Логов

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

**Hot-storage (7 дней):*Локально в JSONL для быстрого поиска.

**Cold-storage (1 год):*В сжатом виде (`zstd`) на архивном узле (узел 1.4 в нашей сети).

––

Резюме раздела:

Без детального лога аудита автономный агент – это "бомба замедленного действия". Благодаря неизменяемой записи мыслей и действий мы превращаем ИИ из черного ящика в прозрачного и подотчетного сотрудника вашей команды. В финальной секции модуля мы обсудим юридические и этические границы этой подотчетности.

Секция 3.4: Юридические и этические аспекты: Границы ответственности

Завершая Часть 1 нашего руководства, мы должны выйти за рамки кода и логов. Автономность агента порождает фундаментальный вопрос: кто виноват, если всё сломалось? В этой секции мы обсудим юридические и этические рамки использования Gemini CLI в профессиональной деятельности.

3.4.1. Проблема "Субъектности без ответственности"

С точки зрения закона, ИИ-агент не является субъектом права. Вы не можете подать в суд на "модель" или "код".

Юридическая правда: Вся ответственность за действия агента всегда лежит на владельце токена API (индивидууме или компании).

Если агент по вашей просьбе "почистить диск" случайно стер персональные данные клиентов (GDPR violation), штраф будете платить вы, а не разработчики Gemini.

3.4.2. Этический кодекс SRE в эпоху ИИ

Мы предлагаем три столпа этичного использования агентов:

1. Прозрачность: Агент не должен скрывать свои действия за сложными терминами. Его рассуждения должны быть понятны человеку среднего уровня квалификации.

2. Обратимость: Каждое действие агента должно по возможности иметь "путь отката" (Rollback). Если действие необратимо (например, `flash` прошивки), оно обязательно требует двойного человеческого подтверждения.

3. Неприкосновенность приватности: Агент не должен анализировать файлы, не относящиеся к задаче (личные переписки в `/home`, ключи кошельков и т.д.), если это явно не санкционировано.

3.4.3. Агент как со-автор (Attribution)

Если агент написал 90% кода вашей инфраструктуры, является ли этот код вашим?

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

3.4.4. Риск "Деградации навыков" (Skill Rot)

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

Совет: Устраивайте дни "Ручного администрирования", чтобы поддерживать форму.

3.4.5. Будущее: Смарт-контракты ответственности

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

3.4.6. "Human-in-the-Loop" как единственный стандарт

В конечном итоге, единственным этичным и безопасным способом эксплуатации Gemini CLI является принцип Человека в контуре. Агент – это продолжение вашей воли, а не её замена.

––

Резюме раздела:

Технологии всегда обгоняют законы. Работа с Gemini CLI требует от вас не только технических знаний, но и высокой моральной зрелости. Понимая риски и принимая на себя ответственность, вы становитесь настоящим архитектором будущего, а не просто оператором машины.

––

МЫ ЗАВЕРШИЛИ ЧАСТЬ 1: ВВЕДЕНИЕ И ФИЛОСОФИЯ.

Впереди нас ждет Часть 2: Инструментарий, где мы начнем разбирать конкретные команды, скрипты и методы автоматизации на самом низком и детальном уровне.

Глава 3: Установка и Безопасность: Создание безопасной цитадели

Запуск ИИ-агента с правами исполнения команд – это огромная ответственность. В этой главе мы разберем, как развернуть Gemini CLI так, чтобы он стал вашим лучшим помощником, а не точкой входа для взлома.