Всегда-on агенты уже здесь: как не превратить Claude Duet в источник утечек, ложных действий и хаоса в доступах

Я — Denis Shokhirev, Agentic AI Systems Architect из Freiburg im Breisgau, Germany. В DennisCraft AI Studio я собираю production-grade агентные системы на Claude, Supabase, n8n, Doppler и self-hosted Postgres, и главная боль в always-on сценариях не в модели, а в том, что один неудачный вызов инструмента ночью может создать утечку, записать мусор в БД или раздать доступы шире, чем вы планировали.

Когда агент работает не по кнопке, а постоянно, меняется профиль риска. Ошибка перестает быть единичным инцидентом в чате и становится автоматизированным процессом. Именно поэтому Claude Duet и любые связки с агентами, tool use и внешними системами надо проектировать как оператора с правами, а не как “умный интерфейс”.

1. Где всегда-on агент ломает прод быстрее всего

Я вижу 3 повторяющихся класса отказов в B2B системах для DACH: утечка контекста, ложное действие и хаос в доступах. Все 3 появляются не потому, что модель “плохая”, а потому что вокруг нее нет нормальной границы исполнения.

Утечка контекста

Чаще всего это происходит через слишком широкие prompts, логи, debug traces и tool outputs. Если агент видит секреты, customer PII и внутренние identifiers в одном контексте, вопрос уже не в том, “ответит ли он правильно”, а в том, куда эти данные попадут дальше: в n8n execution logs, в таблицы аудита, в внешние webhooks или в analyst-facing UI.

Ложное действие

Вторая проблема — агент формирует правдоподобный, но неправильный вызов. Не тот customer_id, не тот SQL filter, не тот workflow branch. В always-on режиме это хуже, чем обычная hallucination, потому что ошибка не останавливается на тексте: она переходит в side effect.

Хаос в доступах

Третья проблема — “временное” сервисное право, которое остается навсегда. Агенту дают один технический token “пока протестируем”, потом к нему подключают Supabase service role, Postgres superuser или универсальный n8n credential. Через месяц никто уже не понимает, какой агент что может.

2. Модель не должна иметь прямой путь к секретам и записи

Anthropic в документации по tool use прямо рекомендует ограничивать инструменты, валидировать входы и держать человека в цикле для чувствительных действий. Это базовый принцип, но в проде его часто нарушают ради скорости. Ссылка: Anthropic Docs, Tool Use, 2024, https://docs.anthropic.com/

Я исхожу из простого правила: модель никогда не получает “сырой” доступ к секретам и не пишет напрямую в критичные системы. Она может только запросить действие через узкий контракт, а уже исполнение делает отдельный слой с проверками.

3. Минимальный контур защиты, который я ставлю первым

Если система уже работает 24/7, я сначала строю не “умнее reasoning”, а 4 барьера: scoped credentials, статический анализ, policy checks перед действием и post-action audit. Это не теория; без этого любая демонстрация превращается в дорогой эксперимент на клиентских данных.

Статический анализ кода и секретов

Для Python и automation glue я обычно прогоняю semgrep, bandit и gitleaks. OWASP регулярно напоминает, что insecure design и secrets exposure остаются типовыми причинами инцидентов; для агентной системы это особенно заметно, потому что generated code часто наследует плохие привычки окружения. Если агент сам пишет integration code, проверка до merge обязательна.

#!/usr/bin/env bash
set -euo pipefail

gitleaks detect --source . --no-banner
bandit -r app -q
semgrep --config=p/security-audit --error

python -m pytest tests/test_tools.py -q
echo "checks passed"

Узкий API между агентом и данными

Никогда не давайте модели SQL как основной интерфейс действий, если речь не о sandbox. Даже если вы потом фильтруете запросы, риск слишком высокий. Лучше пусть агент вызывает 5-10 заранее описанных операций с валидацией типов, owner scope и лимитами.

from pydantic import BaseModel, Field
import psycopg

class UpdateTicket(BaseModel):
    ticket_id: int = Field(gt=0)
    status: str
    actor_id: str

def update_ticket(cmd: UpdateTicket, dsn: str) -> None:
    allowed = {"open", "pending", "closed"}
    if cmd.status not in allowed:
        raise ValueError("invalid status")
    with psycopg.connect(dsn) as conn:
        with conn.cursor() as cur:
            cur.execute(
                "update tickets set status=%s, updated_by=%s where id=%s",
                (cmd.status, cmd.actor_id, cmd.ticket_id),
            )
        conn.commit()

Policy gate перед side effects

Перед каждым действием с внешним эффектом я добавляю машинно-проверяемую политику: можно ли этому агенту выполнить именно это действие, над этим объектом, в это время, при этом confidence и при таком источнике данных. Если хотя бы одно условие не выполняется, действие блокируется или уходит на human review.

agent_policy:
  agent_name: claims_triage
  allow_actions:
    - read_customer_note
    - create_internal_task
  deny_actions:
    - export_pii
    - change_bank_details
  require_human_review:
    - close_claim
    - send_external_email
  limits:
    max_records_per_run: 25

4. Claude Duet опасен не сам по себе, а в связке с “удобными” правами

Самая неприятная категория инцидентов у меня почти всегда связана не с prompt quality, а с тем, что кто-то сэкономил на доступах. Один универсальный token кажется удобным до первого сбоя. Потом выясняется, что агент для triage мог читать finance records, а агент для отчетов — писать в operational tables.

Для Supabase это означает жестко разделять anon, authenticated и service_role сценарии. Для Postgres — использовать отдельные роли на чтение, запись и admin-функции. Для n8n — не переиспользовать одни и те же credentials между workflow, особенно если часть цепочки работает с персональными данными или финансовыми операциями.

Если работаете в европейском контуре, думайте не только о сбое, но и о доказываемости. Кто инициировал действие? Какой контекст был доступен? Почему система решила, что может выполнить запись? Если этого нет в аудите, у вас нет нормального incident review.

5. Что я считаю production-ready для always-on агентов

Ниже — короткий список условий, без которых я не называю always-on систему готовой к реальной нагрузке:

• у каждого агента отдельная identity и отдельные credentials;
• секреты живут вне prompts и tool outputs;
• критичные действия идут через typed interfaces, не через свободный SQL или shell;
• есть pre-action policy gate и post-action audit trail;
• логи редактируют PII и не хранят лишний контекст;
• semgrep, bandit и gitleaks входят в CI, а не запускаются “иногда”.

OpenAI Cookbook и Anthropic docs постоянно подводят к одному и тому же выводу: tool-using systems требуют контроля среды исполнения, а не только хороших prompts. Это совпадает с тем, что я вижу в B2B проектах: качество агента определяется не только моделью, а дисциплиной границ вокруг нее.

FAQ

Можно ли дать агенту read-only доступ к Postgres?

Да, если это действительно read-only роль и если ответы проходят фильтрацию по чувствительным полям. Но даже read-only доступ может создать утечку, если агент потом пересылает данные во внешние каналы или пишет их в логи.

Достаточно ли human-in-the-loop для защиты?

Нет. Human review нужен для чувствительных действий, но он не заменяет scoped credentials, policy gate и аудит. Иначе человек просто подтверждает систему, которую никто нормально не ограничил.

Нужно ли запрещать агенту писать SQL полностью?

Для production workflows с персональными данными или деньгами — почти всегда да. Для sandbox, analytics или внутреннего read-only исследования можно оставить это в контролируемой среде с лимитами и аудитом.

Что важнее сначала: безопасность prompt или безопасность инструментов?

Сначала инструменты и права. Prompt можно улучшать итеративно, но слишком широкие credentials ломают систему даже при хорошем prompt.

Как понять, что у меня уже есть access chaos?

Если вы не можете за 15 минут перечислить все agent identities, их credentials и допустимые действия, хаос уже начался. Второй признак — один и тот же token используется несколькими workflow “временно”.

На каком этапе вашего LLM pipeline сейчас ловится больше всего проблем в проде — статический анализ, runtime sandbox, policy gate перед действием или ручная проверка? Мне правда интересно сравнить это с тем, что я вижу на агентных системах в DACH.
Я делаю бесплатный 30-минутный stack audit для founders и CTO, которые строят AI для регулируемых рынков. Напишите мне в LinkedIn или в @ger_dennis_ai.