Кожен програмний продукт, яким ви користуєтеся сьогодні, був побудований на одній-єдиній передумові: перед екраном сидить людина з пальцями. Кнопки передбачають намір. Майстри налаштування керують складністю. Форми структурують людські думки. Ця архітектура визначала дизайн продуктів протягом десятиліть, тому що донедавна клікали лише люди.
Ця передумова тепер зруйнована. ШІ-агенти не читають інтерфейси. Вони не отримують переваг від корисних підказок або діалогових вікон підтвердження. Коли автономній системі потрібно діяти від імені користувача, елементи інтерфейсу стають на заваді. Результатом є зростаюча невідповідність між тим, як створюються продукти, і тим, як насправді поводяться сучасні викликачі.
Парадигма кліку
Традиційне програмне забезпечення покладається на візуальний контракт. Людина бачить кнопку, розуміє підпис і вирішує, чи натиснути її. Робочі процеси навмисно сповнені перешкод. Багатоетапні майстри налаштування існують тому, що люди роблять помилки і потребують захисних механізмів. Випадаючі списки та перемикачі обмежують введення, оскільки вільний текст провокує хаос.
Це добре працює, коли оператором є людина. Це перестає працювати, коли оператором є агент. Машині не потрібен п'ятиетапний майстер, щоб скасувати підписку або змінити запис. Їй потрібне чітке твердження про те, які операції існують, і остаточна відповідь про те, чи дозволено її виконувати. Коли команди ігнорують це, вони зазвичай вдаються до двох спрощених шляхів.
По-перше, вони передають агенту API-ключ. По-друге, вони загортають існуючий інтерфейс користувача в чат-бот і вважають інтеграцію завершеною. Жоден із цих підходів не вирішує реальну проблему.
API-ключ відповідає на запитання: «Чи надійне це джерело запиту?» Він ніколи не відповідає на важливе запитання: «Чи може цей конкретний викликач прочитати цей конкретний запис?» Ключ — це універсальний ключ. Після видачі він зазвичай надає широкий доступ до ресурсів і контекстів. Він нічого не знає про політику, що керує окремими діями всередині вашої системи.
Загортання GUI у чат-бот є ще більш крихким рішенням. Агент успадковує кожну людиноцентровану передумову, закладену в інтерфейс. Він імітує кліки через модальні вікна та форми, розроблені для очей, а не для автономної логіки. Чат-бот може успішно орієнтуватися в інтерфейсі, але він робить це без розуміння. Це «театр автоматизації». Під цим усе ще немає машиночитаного контракту про те, що дозволено.
Агентам потрібен не черговий ключ від вхідних дверей. Їм потрібні брами.
Що насправді роблять брами
Брама — це керований рівень виконання. Замість того, щоб довіряти обліковим даним і сподіватися на належну поведінку викликача, система з брамами оцінює кожен запит відповідно до оголошених правил. Ці правила існують незалежно від будь-якого інтерфейсу, людського чи іншого.
Належна брама визначає чотири речі. Вона оголошує, які дії існують у продукті. Вона вказує, хто може викликати їх і за яких умов. Вона визначає, коли викликач повинен зупинитися і запитати явну згоду перед тим, як спричинити побічні ефекти. І вона гарантує, що система фіксує кожне рішення у структурованому журналі аудиту, за яким можна здійснювати запити.
Це принципово відрізняється від традиційного контролю доступу. Рольові системи часто запитують біля дверей: «Ви адміністратор?», а потім дозволяють вам вільно ходити будівлею. Брами запитують на кожному перехресті: «Чи дозволено вам перемкнути саме цей важіль прямо зараз?». Ідентифікація стає другорядною порівняно з поведінкою. Політика супроводжує дію.
Щоб це було конкретніше, уявімо агента, якому потрібно повернути кошти клієнту. Підхід на основі ключів може дозволити будь-якому носію ключа здійснити повернення, якщо ендпоінт доступний. Підхід на основі брам перевіряє маніфест доступних дій, перевіряє права агента щодо конкретного запису клієнта, вимагає явного схвалення користувача для фінансового побічного ефекту та записує всю послідовність у журнал аудиту. Брама забезпечує виконання політики, а не просто ідентифікації.
Тестування на Whistler
Ми впровадили цю модель у Whistler. Замість того, щоб будувати окремі конвеєри для людей і машин, ми написали єдиний рівень політик і запустили проти нього двох різних викликачів.
Одним викликачем була людина, що використовувала вбудовану Shell. Іншим був сторонній агент, розроблений поза нашою командою. Обидва підключалися до одного маніфесту. Обидва проходили ідентичні перевірки дозволів на кожному кроці. Коли будь-який викликач намагався виконати дію з побічними ефектами, наприклад, змінити дані або ініціювати зовнішню подію, система вимагала явного схвалення. Кожен запит, схвалення та відмова створювали однаковий структурований журнал аудиту.
Жоден із викликаючих не використовував майстер-ключ API. Не було ні бекдорів, ні підвищених облікових даних, які б обходили політику. Людина не отримувала менш суворих обмежень лише тому, що мала пароль і браузер. Агент не стикався з довільними блокуваннями через відсутність «людського відбитка». Шлюз оцінював дію, контекст і правила. Це була вся транзакція.
Результатом стала система, де додавання нового викликаючого — людини чи машини — не потребувало рефакторингу логіки доступу. Ви оновлювали політику. Шлюз її забезпечував.
Переосмислення продуктового питання
Якщо ваша команда зараз намагається зрозуміти, як додати ШІ-агентів у продукт, створений людьми, ви, ймовірно, починаєте з неправильного питання. Команди інстинктивно запитують, чи варто їм відкривати API. Натомість їм слід запитати, чи мають вони керований рівень виконання для кожного викликаючого.
API без шлюзу — це просто ширші двері. Якщо ваші внутрішні політики існують лише в логіці майстрів (wizards), валідації форм та зрозумілому для людини тексті допомоги, то жоден опублікований вами ендпоінт не буде безпечним для автономних викликаючих. Агент або отримає занадто високий рівень довіри через ключ, або здійснюватиме крихке «маріонеткове» керування через обгортку чатбота.
Побудова шлюзів насамперед означає перелічення кожної значущої дії у вашому продукті як оголошеної операції. Це означає відокремлення перевірки дозволів від інтерфейсу користувача, щоб і користувач Shell, і зовнішній агент стикалися з однаковим механізмом забезпечення виконання під час роботи. Це означає впровадження хуків згоди для деструктивних операцій ще до того, як вони знадобляться, а не після того, як агент видалить не той набір даних. І це означає створення журналів аудиту, які команди з безпеки та комплаєнсу можуть перевіряти, не зважаючи на те, чи був викликаючий вуглецевим, чи кремнієвим.
Це вимагає справжнього архітектурного зсуву. Дизайн, орієнтований на людину, огортає логіку емпатією та тертям. Дизайн, готовий до агентів, відкриває логіку через чіткі, машиночитані контракти. Інтерфейс перестає бути політикою. Політикою стає маніфест.
Цей перехід не про заміну людей. Він про визнання того, що ваше програмне забезпечення тепер має більше ніж один тип викликаючих. Кожен заслуговує на таку ж суворість.
Головний висновок
Припиніть проектувати під клік. Почніть проектувати під правило. Якщо ваша система може керувати кожним викликаючим через оголошені дії, контекстні дозволи, перевірки згоди та спільні журнали аудиту, то не має значення, хто чи що знаходиться на іншому кінці. Людина чи агент — усі вони стикаються з одним і тим самим шлюзом. Побудуйте шлюз першим. API — це лише двері. Політика — це те, що зберігає кімнату цілісною.