[позже] Полная система безопасности (архив)

Полная система безопасности для работы с DeepSeek Harness

Раз вы уже осознали риски — давайте построим практическую систему защиты, которая позволит вам пользоваться DSH, не боясь за свои проекты. Никакой теории, только конкретные действия.

🔒 Уровень 1: Защита сервера (САМЫЙ ВАЖНЫЙ)

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

Приём 1.1: Отдельный пользователь для агента

Никогда не давайте агенту доступ под вашим основным пользователем или, тем более, под root.

Создайте отдельного пользователя на сервере, который будет работать только с одной папкой:

# Создаём пользователя только для агента
sudo adduser dsh-agent

# Создаём отдельную папку для его проектов
sudo mkdir /home/dsh-agent/www
sudo chown dsh-agent:dsh-agent /home/dsh-agent/www

# Запрещаем этому пользователю доступ к другим папкам
sudo chmod 750 /home/dsh-agent

Что это даёт: даже если агент попытается удалить всё подряд, он сможет удалить только файлы внутри /home/dsh-agent/www — остальные проекты на сервере останутся нетронутыми.

Приём 1.2: Каждый новый проект — отдельная папка

Не разрешайте агенту работать в корневой папке веб-сервера (например, /var/www/html).

Создайте для каждого проекта отдельную папку внутри /home/dsh-agent/www/:

/home/dsh-agent/www/
├── project1/
├── project2/
└── project3/

В профиле DSH укажите ограничение: агент может работать только внутри /home/dsh-agent/www/[текущий_проект]/. Если агент попытается выйти за пределы этой папки — команда не выполнится.

Как это настроить в DSH:

В cordis.patch.yml вашего профиля:

- patch:
    id: permission
    config:
      sandbox_mode: workspace-write  # агент может писать только в свою рабочую папку
      working_directory: /home/dsh-agent/www/project1  # конкретная папка

Приём 1.3: Ограничьте команды, которые может выполнять агент

Агент может выполнять любые команды в терминале — включая rm -rf / (удаление всех файлов) или chmod -R 777 / (открытие доступа всем).

Что делать:

Установите плагин dsh-ironbound-policy — он блокирует опасные команды:

dsh plugin --profile web add dsh-ironbound-policy

Включите режим подтверждения (ask) для опасных действий в профиле:

- patch:
    id: permission
    config:
      approval_policy: ask   # перед опасными командами — спрашивать
      dangerous_commands: ask

Создайте белый список разрешённых команд:

- patch:
    id: permission
    config:
      allowed_commands:
        - "ls"
        - "cd"
        - "pwd"
        - "git pull"
        - "git clone"
        - "npm install"
        - "node"
        - "python"
        - "rsync"
      blocked_commands:
        - "rm -rf"
        - "sudo"
        - "chmod 777"
        - "dd"

Приём 1.4: Автоматические бэкапы перед каждым запуском

Прежде чем дать агенту задачу на сервере — сделайте бэкап проекта.

Создайте скрипт автоматического бэкапа:

#!/bin/bash
# backup_before_agent.sh

PROJECT_DIR="/home/dsh-agent/www/project1"
BACKUP_DIR="/home/dsh-agent/backups"
DATE=$(date +"%Y%m%d_%H%M%S")

# Создаём бэкап
tar -czf "$BACKUP_DIR/backup_$DATE.tar.gz" -C "$PROJECT_DIR" .

# Оставляем только последние 10 бэкапов
cd "$BACKUP_DIR" && ls -tp | grep -v '/$' | tail -n +11 | xargs -I {} rm -- {}

Запускайте этот скрипт перед каждой сложной задачей. Или настройте автоматический бэкап через cron:

# Автоматический бэкап каждые 6 часов
0 */6 * * * /home/dsh-agent/backup_before_agent.sh

Приём 1.5: Скриншоты и логи — не храните на сервере

Вы упомянули скриншоты — это важный момент. Если агент делает скриншоты для отладки, не храните их на сервере:

Они занимают место.
Могут содержать чувствительные данные.
Агент может случайно удалить или перезаписать их.

Решение: настройте автоматическую загрузку скриншотов в облако (S3, Google Drive, Dropbox) с автоматическим удалением с сервера:

# Скрипт для загрузки скриншотов в облако и удаления с сервера
rclone copy /home/dsh-agent/screenshots/ mycloud:screenshots/ --delete-after

Приём 1.6: Ограничьте время выполнения

Агент может уйти в бесконечный цикл и нагружать сервер.

В профиле DSH укажите таймауты:

- patch:
    id: agent
    config:
      max_steps: 20           # максимум шагов
      max_tokens: 50000       # максимум токенов
      timeout: 300            # 5 минут на задачу

На сервере используйте systemd или cron с ограничением времени:

# Запуск с ограничением 5 минут
timeout 300 dsh --profile headless "задача"

🔒 Уровень 2: Защита GitHub

Ваш код тоже может пострадать — агент может случайно закоммитить что-то не то или затереть нужные изменения.

Приём 2.1: Используйте отдельный репозиторий для тестов

Никогда не давайте агенту доступ к вашему основному репозиторию на первых порах.

Создайте тестовый репозиторий (например, dsh-test) и работайте с ним, пока не поймёте, как агент себя ведёт.

На GitHub:
1. Создайте репозиторий с названием dsh-test.
2. Дайте агенту доступ ТОЛЬКО к этому репозиторию.

При создании токена в GitHub выберите:
- Only select repositories → выберите только dsh-test.
- Permissions → Contents → Read and write (только для этого репозитория).

Никаких прав на другие репозитории.

Приём 2.2: Отдельная ветка для экспериментов

Если вы всё же работаете с основным репозиторием — создайте отдельную ветку для агента:

Создайте ветку dsh-experiment:

git checkout -b dsh-experiment
git push origin dsh-experiment

В промпте укажите агенту: «Работай ТОЛЬКО в ветке dsh-experiment. Не трогай ветку main и другие ветки».
После того как агент завершит работу — вы сами вручную создаёте Pull Request из dsh-experiment в main и проверяете все изменения перед слиянием.

Приём 2.3: Запрет force push

Force push может уничтожить историю коммитов — это одна из самых опасных операций.

Запретите агенту force push:

В профиле DSH:

- patch:
    id: permission
    config:
      forbidden_git_commands:
        - "git push --force"
        - "git push -f"
        - "git push --force-with-lease"

Или в настройках GitHub: Settings → Branches → Branch protection rule → добавьте правило, запрещающее force push для ветки main.

Приём 2.4: Два этапа — сначала анализ, потом действие

Это самое важное правило для работы с кодом. Никогда не давайте агенту задачу «сделай и залей» сразу.

Всегда делайте в два этапа:

Этап 1 (анализ):

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

Вы смотрите предложенные изменения и утверждаете.

Этап 2 (выполнение):

«Я утвердил изменения. Теперь примени их: создай коммит с сообщением "...", запушь в ветку dsh-experiment и создай Pull Request.»

Приём 2.5: Обязательные тесты перед коммитом

Настройте автоматические тесты, которые запускаются перед каждым коммитом агента:

# В GitHub Actions
name: Pre-commit checks for agent

on:
  push:
    branches: [ "dsh-experiment" ]

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run linter
        run: npm run lint
      - name: Run tests
        run: npm test
      - name: Check for sensitive data
        run: |
          if grep -r "API_KEY\|SECRET\|PASSWORD" .; then
            echo "⚠️ Найдены секреты в коде!"
            exit 1
          fi

Если тесты не проходят — коммит не принимается, и агент не может запушить изменения.

🔒 Уровень 3: Защита вашего компьютера (локальной среды)

Агент работает и на вашем компьютере — он может изменять файлы и там.

Приём 3.1: Изолированная папка для экспериментов

Создайте отдельную папку на компьютере для работы с DSH:

~/dsh-workspace/
├── projects/
│   ├── test-site/
│   ├── parser/
│   └── experiment/
└── backups/

Всегда выбирайте эту папку как рабочую область (workspace) в DSH. Никогда не открывайте доступ к другим папкам.

Приём 3.2: Используйте режим «только чтение» для анализа

Если задача — анализ, а не изменение кода — используйте режим read-only:

DSH_PERMISSION_MODE=read-only dsh web

Агент сможет читать файлы, но не сможет их изменить.

Приём 3.3: Регулярные бэкапы локальной папки

Перед запуском агента делайте копию рабочей папки:

cp -r ~/dsh-workspace/projects/test-site ~/dsh-workspace/backups/test-site_$(date +%Y%m%d_%H%M%S)

Или используйте Git: коммитьте перед каждым запуском, чтобы можно было откатиться.

🔒 Уровень 4: Защита конфиденциальных данных

Приём 4.1: Всегда используйте `.env` — никогда не вставляйте ключи в промпт

Правило: ни один API-ключ, пароль или токен никогда не должен появляться в промпте.

Как сделать правильно:
1. Создайте файл .env в проекте:

GITHUB_TOKEN=ghp_xxxxxx
TELEGRAM_BOT_TOKEN=123456:ABC
DATABASE_URL=postgresql://user:pass@localhost/db

В промпте скажите агенту: «Используй переменные окружения из файла .env. Не выводи их в ответ».
Добавьте .env в .gitignore, чтобы случайно не закоммитить.

Приём 4.2: Сканируйте код на наличие секретов

Используйте git-secrets или trufflehog для проверки, не попали ли в репозиторий секретные данные:

# Установка git-secrets
git secrets --install
git secrets --register-aws  # или настройте свои паттерны

# Проверка перед коммитом (автоматически через pre-commit hook)

🔒 Уровень 5: Дисциплина работы

Самый важный уровень — это ваши привычки.

Приём 5.1: Всегда начинайте с малого

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

Схема работы:
1. Простая задача (займёт 1 минуту): «Покажи содержимое папки» — проверяем, что агент видит файлы.
2. Средняя задача (5 минут): «Создай файл test.txt и напиши в него "hello"» — проверяем, что агент умеет создавать файлы.
3. Сложная задача: только после того, как первые две удались.

Приём 5.2: Всегда просматривайте Trajectory после выполнения

После каждой задачи — особенно после сложной — открывайте Trajectory и смотрите, что делал агент:

Какие команды выполнял?
Какие файлы читал/изменял?
Не было ли подозрительных действий?

Это поможет заметить проблемы на ранней стадии.

Приём 5.3: Ведите журнал удачных промптов

Когда промпт сработал хорошо — сохраните его. Когда что-то пошло не так — запишите, что именно. Со временем у вас будет своя библиотека «безопасных промптов».

Приём 5.4: Никогда не оставляйте агента без присмотра

Для сложных задач: не запускайте и не уходите. Смотрите, что делает агент. Если видите подозрительную команду — немедленно остановите сессию.

Для автоматических задач (по расписанию): настройте уведомления (Telegram/Slack) о каждом запуске. Если задача не завершилась или завершилась с ошибкой — вы сразу узнаете.

📋 Сводная таблица: что защищать и как

Что защищать	Как защищать
Сервер	Отдельный пользователь, отдельная папка, белый список команд, бэкапы перед запуском
GitHub	Отдельный репозиторий для тестов, отдельная ветка, запрет force push, два этапа (анализ → действие)
Локальный компьютер	Изолированная папка, режим read-only для анализа, бэкапы
Ключи и пароли	Файл .env, сканирование на секреты, никогда не вставлять в промпт
Деньги (токены)	Лимиты в профиле, плагины для мониторинга, короткие промпты
Время	Таймауты, ограничение шагов, не оставлять без присмотра

⚡ Быстрый чек-лист перед каждым запуском

Перед тем как отправить задачу агенту, пробегитесь по этому списку:

[ ] Агент работает в изолированной папке (workspace)?
[ ] Установлен лимит на шаги (max_steps: 20)?
[ ] Установлен лимит на токены (max_tokens: 50000)?
[ ] Включён режим подтверждения (approval_policy: ask)?
[ ] Если задача на сервере — сделан бэкап?
[ ] Если задача на GitHub — используется тестовый репозиторий или отдельная ветка?
[ ] В промпте нет API-ключей и паролей?
[ ] Я готов смотреть Trajectory после выполнения?

🚨 Что делать, если что-то пошло не так

Немедленно остановите сессию (кнопка Stop в веб-интерфейсе).
Откройте Trajectory и посмотрите, что сделал агент.
Если пострадали файлы — восстановите из бэкапа.
Если пострадал GitHub — откатите коммит или ветку вручную.
Запишите проблему и добавьте ограничение в профиль или в правила для агента.

💡 Главный принцип

Всегда думайте: «Что самое плохое может сделать агент в этой задаче?» — и закрывайте эту возможность заранее.

Если вы последуете этим правилам, DSH станет вашим мощным помощником, а не источником проблем. Начните с малого, постепенно расширяйте права агента по мере того, как вы учитесь им управлять.