Секреты подчиняются простому правилу: их не должно быть там, откуда модель их прочитает. Не вставляйте API-ключи в prompt, CLAUDE.md, skill, определение агента, закоммиченные settings, снапшот теста или лог. Используйте secret store провайдера и инъекцию из окружения. Отдельно помните про ANTHROPIC_API_KEY: он имеет приоритет аутентификации и может незаметно перевести с подписки на API-биллинг - /status должен показывать ожидаемого провайдера. Deny-read для .env и ключей - полезный baseline, но не единственная защита.

Сторонний код требует той же настороженности, что и любой недоверенный ввод. MCP-сервер получает ровно те полномочия, что даёт его протокол; плагин может поставлять skills, агентов, hooks, MCP и LSP разом; hook - это программа с правами процесса Claude Code. Отсюда дисциплина: закреплять и просматривать источник, изучать манифест и передаваемые scopes, начинать с тестового аккаунта, удалять сервер или плагин при неясном происхождении и не путать наличие в marketplace с одобрением безопасности.

Инженерный вывод собирает всё в одну архитектуру. Самая сильная практическая защита - это композиция: одноразовый worktree или контейнер, минимальный token, allowlist доменов, deny на секреты, точечные правила инструментов и обязательный review diff и тестов. Ни один отдельный переключатель эту композицию не заменяет. Именно сочетание слоёв, а не самый строгий из них по отдельности, делает автономную работу агента безопасной настолько, насколько это вообще достижимо.

Полезно один раз оформить это как минимальный security gate - чек-лист перед автономным запуском. Ниже он и приведён: ограниченный scope, чистый git, отсутствие production-секретов, доверенная project-конфигурация, sandbox с контролируемым escape hatch, deploy и push в ask/deny, заранее определённые тесты и простой rollback. Типичный провал - довериться одному слою; правильный ход - пройти весь gate, потому что безопасность здесь складывается, а не выбирается.