Safe Outputs Layer

Safe outputs layer — это точка применения безопасности где каждое изменение которое агент делает — комментарии, патчи, создание issue, обновление статуса — валидируется, проверяется на угрозы и аудируется. Это единственная точка сжима которая гарантирует что политики одобрения и обнаружение угроз никогда не могут быть обойдены.

Почему централизованный слой применения

Без центрального gate, каждый путь мутации нужно был свой policy checks:

• Агент создаёт issue → check policy
• Агент комментирует → check policy
• Агент патчит код → check policy
• и т.д.

Это хрупко — легко забыть проверку на одном пути. Safe outputs layer гарантирует все мутации проходят через одного доверенного applier.

Как работает safe outputs layer

Когда агент выполняет действие, оно проходит через:

1. Нормализовать — канонизировать действие в стандартную форму
2. Policy check — оценить политики одобрения workspace'а
3. Threat scan — сканировать на проблемы безопасности (утечки секретов, prompt injection и т.д.)
4. Apply или queue — выполнить немедленно (если позволено) или queue для одобрения
5. Audit — записать что произошло в immutable лог аудита

Если какой-то шаг флаги проблему, действие либо отрицается либо queue'ется для одобрения в зависимости от severity.

Поддерживаемые типы действий

Safe outputs layer обрабатывает эти действия агента:

Оценка политик

Когда агент пытается действие, policy engine:

1. Собирает все workspace политики которые включены
2. Сопоставляет политики основано на типе действия и путях файлов
3. Решает результат:
   • Allow — действие выполняется немедленно
   • Require approval — действие queue'ется, ожидает ручного одобрения
   • Deny — действие отрицается по-прямому

Например, если вы имеете политику:

Action type: patch
File glob: .github/workflows/**
Effect: require_approval

Любой патч трогающий .github/workflows/ будет queue'ется для одобрения.

Обнаружение угроз

Перед тем как действие применяется, threat detector сканирует на:

• Secret leaks — агент добавляет ли API ключ или кредитиал в код?
• Prompt injection — есть ли injected инструкции attempts в комментариях?
• Dangerous patches — агент модифицирует ли чувствительные файлы?
• Shell command risks — есть ли опасные команды в scripts?
• Network risks — есть ли outbound соединения к неизвестным hosts?

Если угрозы найдены:

• Info-level — логируется но разрешается
• Warn-level — разрешается но флаги в аудите
• Block-level — отрицается или queue'ется, в зависимости от workspace политики

Approval queuing

Когда действие требует одобрения:

1. Действие сохраняется с cryptographic hash его контента
2. Approval request появляется в Inbox → Approvals
3. Авторизованный approver (обычно admin) проверяет и решает
4. На approval, сохранённое действие применяется (hash проверяется чтобы предотвратить tampering)
5. На rejection, агент уведомляется и действие выброшено

Hash гарантирует что точное действие которое было queue'ется — это то что получается применено — никакого tampering в промежутке.

Лог аудита

Каждое действие логируется в safe outputs лог аудита:

• Что произошло — тип действия, результат (applied/queued/rejected)
• Почему — причины от политики или обнаружения угроз
• Когда — timestamp
• Кто — какой агент, какая задача
• Доказательство — hash действия для traceability

Смотри лог аудита в Settings → Audit Logs и фильтруй по:

• Диапазону дат
• Агенту
• Типу действия
• Результату (applied, queued, rejected)

Используй это для:

• Расследования security incidents
• Аудита compliance
• Понимания поведения агента
• Обнаружения паттернов (например, repeated rejections)

Различие humans от agents

Safe outputs layer обрабатывает agent-originated действия иначе чем human-originated действия:

• Agent actions → оценены против политик, threat detection, approval gates
• Human UI actions → не gated по политикам (humans доверяются), но всё ещё аудированы

Это означает:

• Вы (human) всегда можете комментировать, обновлять issues и т.д.
• Agents должны следовать политикам одобрения которые вы установили
• Всё логируется для аудита

Редакция и приватность

Все audit entries автоматически редактируются:

• Секреты и API ключи замаскированы
• Home директории анонимизированы
• Чувствительный контент файлов не логируется

Это гарантирует что логи аудита безопасны для шаринга без accidental exposed credentials.

Интеграция с politikой и threat detection

Safe outputs layer — это integration point для:

• Approval policies (approval-policies.md) — контролируй когда одобрение требуется
• Threat detection (threat-detection-checks.md) — сканируй на security issues

Вместе, они формируют comprehensive security framework:

1. Policies определяют ЧТО вы хотите контролировать (например, "changes to .env are blocked")
2. Threat detection находит КАК (например, "this patch adds an API key")
3. Safe outputs layer ПРИМЕНЯЕТ это (гарантируя оба проверяны)

Лучшие практики

• Комбинируй политики и detection — политики одни недостаточны (rely на ручную config); threat detection одна может produce false positives. Используй оба.
• Проверяй логи аудита регулярно — spot паттерны и adjust политики
• Одобри внимательно — thorough проверь queue'ется действия перед approval
• Документируй политики твои — help team members понять почему certain действия требуют одобрения
• Тестируй на non-production first — enable strict политики на test workspace первой, затем rollout

Ограничения

• Политики применяются только к agents — human actions аудированы но не gated
• Threat detection heuristic — основано на pattern matching, не foolproof
• Approval manual — никакого автоматического одобрения; human должен проверить
• Редакция best-effort — custom secret patterns могут не всё поймать

Следующие шаги

• Approval policies — определи что требует одобрения
• Threat detection checks — сканируй на security issues
• Enterprise governance features — workspace-wide безопасность