Система для AI-процесу — це не один промпт чи один API. Вона складається з джерел, клієнта, інтеграції, правил доступу, виконання та спостереження за результатом. Кожен компонент має відповідати за свою дію. Інакше важко знайти причину збою та перевірити, чи спрацював контроль.
Намалюйте потік від тригера до наслідку. Для кожного кроку запишіть власника, ідентифікатор, вхід, вихід і поведінку на відмові. Потім вирішіть, де потрібна модель, а де достатньо детермінованого правила чи процесу.
Модель пропонує, авторизація дозволяє
Модель може перетворити запит на запропоновану операцію, але її намір не є дозволом. Авторизація перевіряє суб’єкта, ресурс, роль і умови там, де дія реально виконується. Сервіс, що змінює запис, має перевіряти права; кнопка погодження в інтерфейсі не замінює контроль доступу.
Відокремте вердикт політики від відповіді інструмента. «Дозволено» означає, що запит пройшов перевірку за певним контекстом і версією правил; успіх API означає лише технічне завершення. Зв’яжіть ці події, щоб розбір показав і дозвіл, і фактичну зміну.
Ідентифікатор кореляції має проходити через кожний шар, включно з чергою чи зовнішнім API, якщо це можливо. Інакше одна операція може виглядати як кілька непов’язаних подій. Не використовуйте його як дозвіл: він допомагає зіставити дані, але авторизація має перевіряти реальну роль і ресурс.
Обирайте MCP чи API за клієнтами
MCP стандартизує виявлення та виклик інструментів сумісними клієнтами; прямий API може бути простішим для одного вузького сценарію. MCP може використовувати API усередині сервера. Вибір залежить від кількості клієнтів, потреби в спільному інтерфейсі, порядку кроків і відповідального за підтримку.
Не вважайте MCP обов’язково модельним вибором дій або прямий API автоматично безпечнішим. Повтори, ідемпотентність, тайм-аут і права мають бути реалізовані у відповідному шарі. Для запису захистіть повтор після невизначеної відповіді від дублювання.
Після тайм-ауту клієнт не завжди знає, чи зовнішня система застосувала запит. Спочатку прочитайте стан операції або використайте безпечний ключ повтору; не відправляйте зміну вдруге лише тому, що відповідь не надійшла. Визначте для кожного інтеграційного партнера, як отримати остаточний стан.
Офіційне джерело: MCP: architecture overview.
Зробіть відмову явним станом
Недоступне джерело, відмова в доступі, конфлікт правил, прострочене погодження та невідомий тип дії — різні стани. Не зводьте їх до порожнього результату чи загального «спробуйте пізніше». Поверніть причину, зупиніть непідтверджений запис і передайте випадок визначеній ролі.
Перевірте, що повтор не дублює операцію, скасування має запис, а зміна політики має версію й власника. Для зовнішньої системи визначте авторитетний стан і спосіб підтвердження результату. Програйте недоступність інтеграції, запізнілу відповідь і часткове виконання.
Під час змін запускайте тести на всіх шляхах до операції: вебклієнт, фонова задача, інструмент агента й аварійний ручний шлях. Перевірте, що вони використовують однакові правила доступу й записують однозначні результати. Новий адаптер не повинен непомітно обійти шлюз, який працює для основного інтерфейсу.
- Кореляційний ідентифікатор
- Версія правила та вердикт
- Запит і відповідь інструмента
- Причина зупинки чи ескалації
Що можна зробити зараз
Намалюйте процес і перевірте кожну межу: хто має право, що саме дозволено і як підтвердити наслідок? Додайте успішний, заборонений і невизначений випадки. Це допоможе обрати мінімальну архітектуру, що покриває задачу та має власника підтримки.
