Інструменти визначають фактичні можливості
Роль описує призначення subagent, але список tools визначає, що він реально може зробити. Текстова заборона «не змінюй production-код» не замінює технічного обмеження, якщо агент усе ще має Edit або Write.
Найбезпечніший профіль починається з мінімуму: надайте лише ті інструменти, без яких конкретний результат неможливий.
| Рівень | Що контролює | Приклад |
|---|---|---|
| L1 — сесія | Максимально доступні дії | Режим лише читання або повні дозволи |
| L2 — subagent | Інструменти конкретної ролі | Reviewer має Read і Grep без Edit |
| L3 — проєкт | Правила команди та каталоги | Tester пише лише в tests/ |
Ризики інструментів
| Інструмент | Користь | Що контролювати |
|---|---|---|
| Read | Перегляд файлів | Дозволені каталоги й чутливі дані |
| Grep | Пошук за кодом і конфігурацією | Ширину пошуку та секрети у виводі |
| Bash | Тести, build і діагностика | Команди, побічні ефекти та умови зупинки |
| Edit | Зміна файлів | Write boundary і явний дозвіл |
Профілі за ролями
reviewer: Read, Grep, Bash(read-only checks)
tester: Read, Grep, Bash, Edit(tests only)
documenter: Read, Grep, Edit(docs only)
db-analyst: Read, Grep
Правило: якщо роль працює без інструмента,
не підключайте його «про запас».Спроєктуйте набір дозволів
- Назвіть очікуваний результат: review, тест, документація або аналіз.
- Перелічіть мінімальні дії для цього результату.
- Оцініть наслідки неправильного використання кожного інструмента.
- Заберіть непотрібні permissions.
- Для Edit задайте межі каталогів або типів файлів.
- Перевірте, чи може агент вийти за межі початкової задачі.
Канонічне джерело уроку · JavaRush
Відкрити матеріал JavaRush