Security Blog

Уся індустрія щойно погодилася: ваш агент не має бачити ваші ключі. Просто їх ховають не в тому місці.

#353

October 2, 2026 · By Marketing team

← All posts

За один тиждень Claude Code, Hermes і Codex випустили виправлення, щоб агенти не бачили відкриті облікові дані. Збіжні патчі — це не архітектура: ключі взагалі не повинні жити в оболонці агента.

Цього тижня Anthropic непомітно додала один рядок до журналу змін Claude Code: "Fixed MCP servers requiring authentication exposing auth-stub tools to the model in headless/SDK mode" [1]. Простіше кажучи — коли Claude Code працював у безголовому режимі (так він працює в CI та автоматизованих конвеєрах агентів), засоби автентифікації, які мали лишатися прихованими, опинялися доступними для моделі: ШІ бачив назви цих засобів, їхні параметри й міг ними поводитися. У найпопулярнішому в світі агенті для написання коду — 133 тис. зірок — шар облікових даних просочувався туди, де він потрібен найменше: у власний контекст моделі.

Це виправили. Але виправлення — це не головна історія. Головна — чому кожна серйозна оболонка агента раптом веде ту саму боротьбу.

Три оболонки, один тиждень, той самий інстинкт

Подивіться, що вийшло впродовж однієї 24-годинної вікна:

  • Claude Code виправив витік auth-stub, описаний вище, і посилив перевірку автентифікації MCP [1].
  • Hermes (v0.17.0) додав Managed Scope — секрети, закріплені адміністратором і недоступні для зміни користувачем, зафіксовані на рівні файлової системи, щоб оператор агента не міг їх перевизначити, — плюс вилучення секретів із діагностичних дампів і блокування конфігурацій MCP з ознаками витоку до їхнього запуску [2].
  • Codex (v0.141.0) обгорнув трафик віддаленого виконання в зашифровані канали Noise і почав маршрутизувати плагіни за режимом їхньої автентифікації [3].

Три конкуренти, три підходи, один спільний висновок: оболонка має володіти секретами, а агент ніколи не повинен бачити відкриті ключі. Коли конкуренти сходяться так само впродовж одного тижня — це не мода. Це категорія, яка нарешті визнає, для чого вона існує.

Наступна проблема — розпорошення облікових даних

Але є нюанс. Кожне з цих виправлень живе всередині оболонки. І випадок із Claude Code це видає: коли автентифікація живе в оболонці, поряд із моделлю, «агент ніколи не повинен її бачити» перестає бути фактом і стає властивістю, яку доводиться постійно проектувати — і час від часу не втримувати, у безголовому режимі, де за ним ніхто не спостерігає. Це не можна оголосити один раз. Це захищаєш, реліз за релізом.

Але глибша проблема — не в окремому витоку, а в тому, що буде, коли кожна оболонка, кожен постачальник і кожен сценарій випускає власне рішення. Ви отримуєте сховище всередині Claude Code, сховище всередині Hermes, сховище всередині Codex, пул OAuth тут, файл секретів там — окреме сховище облікових даних для кожного інструменту, який ви запускаєте. Це і є розпорошення облікових даних, і це наступна проблема, а не вже розв'язана.

Розпорошення — це вже збій, навіть якщо жодне зі сховищ не протікає. Ваші секрети копіюють у кожне з них, щоб воно працювало, — більше копій, більше місць, звідки їх можна викрасти. Ротацію треба виконувати N разів, вручну, і саме той, який ви забули, вас і підведе. І ніхто не може відповісти на єдине питання, яке справді має значення — який агент використав який ключ, проти чого і коли, — бо відповідь розкидана по десятку сховищ, які між собою не спілкуються. Не можна розгортати нове сховище для кожного постачальника й кожного робочого процесу. Це не масштабується. Це саме те, що ламається.

Ключі взагалі не належать до оболонки

Виправлення, яке вам ніколи не доведеться випускати, — те, за яким агент взагалі не тримає автентифікацію. Покладіть облікові дані в один орган, який існує поза кожною оболонкою — не сховище на кожного постачальника, а одне під усіма ними. Агент — у Claude Code, у Codex, у Hermes, це неважливо — запитує конкретну іменовану дію й отримує обмежений, короткочасний обліковий запис, що вводиться саме для неї, отримується в реальному часі й зникає після використання. У контексті моделі немає auth-stub, який можна випадково викрити, бо автентифікації в оболонці ніколи не було. Немає й розпорошення, бо замість сховища на кожен інструмент є одне — ротація один раз, а не N. І кожен доступ потрапляє в єдиний журнал аудиту замість розсіювання по десятку сховищ, які не можуть відповісти, хто що використав. (Тримати секрет подалі від місця, де виконується код, — майже на самому верху правил, яких має дотримуватися засіб для роботи з обліковими даними — індустрія щойно витратила тиждень, щоб це відкрити.)

А частина, яка стосується саме межі безпеки, а не зручності, така: обліковий запис не може жити в тій самій системі, що й агент. Покладіть їх поруч — і в них спільний радіус ураження: промпт-ін'єкція, отруєний сервер MCP, спільний діагностичний дамп, наступна вразливість auth-stub, і все, що досягне агента, досягне разом із ним і ключів. Тому сама лише видимість — це вже витік: щойно секрет опинився там, де агент може його побачити, ви вважаєте його вже скомпрометованим і робите ротацію — так, як кожна обережна команда поставилася до того auth-stub у Claude Code в день виходу. Тримайте обліковий запис на витягнутої руки, в системі, куди агент може лише звернутися — ніколи не прочитати, ніколи не втримати, — і навіть повністю скомпрометований агент не зможе вивести те, що ніколи не було в його досяжності. Він може попросити виконати дію. Він не може піти з ключем. Відстань і є захистом; сховище в тому самому процесі не має її за жодну ціну.

Саме таку межу проводить Clavitor. Усе поле щойно довело принцип — агент не повинен бачити ключі. Ми лише вважаємо, що вам не доведеться доводити це знову в кожній оболонці, яку ви запускаєте, і що те, що зберігає ваші ключі, не повинно бути тим самим, що щойно зламав атакувальник.

Віддамо належне командам оболонок: секрети, закріплені адміністратором, зашифровані канали передавання, типові значення, що блокують доступ при збої, — це справжня, якісна інженерія. Але тижневе виправлення витоку, що знову й знову з'являється, — це не архітектура, а симптом. Архітектура — це відсутність ключів там, звідки може статися витік.

Коли три конкуренти за один тиждень латають ту саму рану, то рана — це і є дизайн. Агент не має бачити ваші ключі — тож перестаньте тримати їх там, де він їх бачить.

Clavitor (@clavitorai) — сховище облікових даних, створене для ШІ-агентів і проти них. clavitor.ai

Джерела

[1] Claude Code v2.1.183 — «Fixed MCP servers requiring authentication exposing auth-stub tools to the model in headless/SDK mode» — https://github.com/anthropics/claude-code/releases/tag/v2.1.183

[2] Hermes Agent v0.17.0 — Managed Scope (секрети, закріплені адміністратором), вилучення секретів, блокування конфігурацій для витоку — https://github.com/NousResearch/hermes-agent/releases

[3] OpenAI Codex v0.141.0 — зашифровані канали передавання Noise, маршрутизація плагінів за режимом автентифікації — https://github.com/openai/codex/releases