1Password відмовився від постійних привілеїв для людей, машин і AI-агентів: доступ дають just in time і звіряють із причиною звернення.

Агент логіниться, носить облікові дані й діє від імені людини, а поводиться водночас і як користувач, і як програма. Через цю подвійність звичайні контролі ідентифікації втрачають однозначність.

«Це машина чи це людина? Правильна відповідь — ймовірно, і те, і інше», — каже Ненсі Ванг (Nancy Wang), технічна директорка AgileBits Inc., що працює під брендом 1Password, у розмові з журналістами theCUBE Research на заході Okta Oktane. За даними SiliconANGLE, компанія розглядає AI-агента як гібридну ідентичність, якій потрібен доступ just in time під конкретну задачу, а облікові дані не залишаються в моделі.

Чому агент ламає звичну ідентифікацію?

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

Поки журнал не розділяє власника облікового запису й софт, немає відповіді на практичне питання, кому відкликати доступ. Інвентаризація агентів і даних закриває цю прогалину першою.

Як працює доступ, обмежений однією задачею?

Підхід компанії однаковий для людей, машин і агентів: постійні привілеї відкидаються, доступ дають just in time і звіряють із тим, навіщо він потрібен. Цю ідею 1Password нещодавно перетворила на продукт привілейованого доступу, обмежений однією задачею.

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

Практичний наслідок: у журналі доступу треба явно розділяти людину й агента, інакше незрозуміло, який саме доступ відкликати після інциденту.

Куди зникають секрети й хто ухвалює рішення?

Credential Broker 1Password видає секрет лише в момент, коли він потрібний, і не відкриває його ані агенту, ані базовій моделі. Ключ не залишається в промпті чи контексті виклику, а видачаSecrets відбувається окремо від виконання завдання.

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

Що зробити команді зараз?

Таку модель уже застосовують у 1Password — перенесіть її на своїх агентів. Почніть з тих, хто торкається грошей, даних клієнтів і продакшену, і вкладіть перехід в один спринт.