Захищене сховище облікових даних не завадило тестовому агенту підтримки віддати токен службового облікового запису. У дослідженні від 18 вересня Unit 42 через звернення до підтримки змусила AWS AgentCore Harness прочитати пам’ять середовища виконання, а потім використала отриманий токен із ноутбука. Це лабораторна демонстрація, а не повідомлення про злам клієнта.
Звернення перетворилося на команду
Дослідники створили вигадану службу підтримки, підключену до MCP-сервера — сервісу, який надає агенту інструменти. Перша модель відмовилася виконувати запити з командами, тому команда обрала менш обмежувальну модель. Прихований HTML-коментар у зверненні спрямував агента завантажити й виконати скрипт.
Командна оболонка працювала з правами root усередині середовища агента й могла читати пам’ять головного процесу. Токен зі сховища вже перебував там у відкритому вигляді: він був потрібен для автентифікації в підключеному сервісі.
Під час тесту вдалося отримати токен розміром 1034 байти та адресу сервера. Повторне використання цих даних дало доступ до тестових записів клієнтів і дозволило створити звернення. Токен належав службовому обліковому запису оператора, а не людині, яка просила допомоги.
Сховище й сеанс захищають різні речі
Ця різниця важлива для тих, хто підключає помічника до клієнтських записів, платежів чи внутрішніх інструментів. Дозвіл поставити запитання помічнику та право скористатися його службовим обліковим записом — різні повноваження. Якщо обробка звернення відкриває другі, агент стає мостом між ними.
AWS описує кожен сеанс як ізольовану microVM. Це межа навколо сеансу, а не обіцянка, що всі його інструменти ізольовані від кожного токена всередині. Чинна документація покладає на клієнта авторизацію користувачів, перевірку вхідних даних і конфігурації моделі. Вона також пояснює: середовище перевіряє структуру запиту, але не аналізує зміст промптів для забезпечення поведінкових обмежень.
Тест не доводить виходу до середовища іншого клієнта чи зламу шифрування сховища. Він показує, чому шифрування збереженого секрету й контроль робочого сеансу розв’язують різні задачі. Інший шлях витоку показано в розслідуванні, де агент передав пастці власний контекст: там дані пішли до неперевіреного сервісу зі звичайним запитом, без продемонстрованої ін’єкції промпту.
Обмежте інструменти та перевірте окремий шлях запуску команд
За документацією AWS, shell і file_operations доступні за замовчуванням. Якщо allowedTools не задано, дозволені всі інструменти. Помічнику, якому потрібна лише визначена функція пошуку клієнта, варто явно дозволити саме її: тоді модель матиме менше можливостей, ніж із повноцінною командною оболонкою.
Є й окрема перевірка: allowedTools обмежує вибір інструментів моделлю під час InvokeHarness. AWS прямо зазначає, що цей параметр не керує InvokeAgentRuntimeCommand — API прямого виконання команд з окремим дозволом IAM. Якщо такий доступ не потрібен, його дозвіл теж слід виключити: самого списку інструментів моделі недостатньо.
Спосіб передавання ідентичності також потрібно обирати свідомо. Нині AWS документує обмеження облікових даних підключених сервісів за конкретним користувачем через вхідний OAuth; автентифікація SigV4 цю ідентичність далі не передає. Перевірте, від якого облікового запису насправді виконується запит до сервісу, перш ніж вважати, що він має обмеження автора звернення.
За даними Unit 42, 10 червня AWS закрила повідомлення як інформаційне в межах моделі спільної відповідальності. Практична перевірка для оператора проста: встановити, чий обліковий запис використовує агент, які команди може виконувати та куди звертатися. Сховище — лише одна частина цієї системи.
Джерела
- Нів Рабін, Unit 42. Дослідження доступу до облікових даних у пам’яті AgentCore Harness. 18 вересня 2026 року.
- Amazon Web Services. Інструменти AgentCore Harness. Перевірено 20 вересня 2026 року.
- Amazon Web Services. Безпека та контроль доступу AgentCore Harness. Перевірено 20 вересня 2026 року.
