Архітектура безпеки TAKpilot: шлюзи підтвердження/відмови та журнал аудиту оператора

Коли система ШІ генерує структуровані виклики API із природномовного вводу та надсилає їх до живої загальної оперативної картини, ціна помилкової дії — це не переміщений файл чи неправильне значення в таблиці. Ворожий маркер, розміщений на сітці, зайнятій дружнім підрозділом, місія, видалена через те що координувала медичну евакуацію, канал, очищений, який розподіляв ISR-канали до активного розвідувального елемента — це не відновити за допомогою Control-Z. TAK Server не має рідного скасування для більшості операцій з даними. Видалення виконується, дані зникають, і COP, яку навігує кожен оператор у мережі, відображає помилку до того часу, поки хтось не помітить і не відновить вручну те, що було втрачено.

Саме в цьому контексті безпеки був розроблений TAKpilot — чат-копілот ШІ для CloudTAK. Архітектура безпеки продукту — це не набір рекомендаційних попереджень або м'яких підтверджень, які оператори можуть поспіхом клацнути. Це набір жорстких структурних обмежень: картки інструментів у реальному часі, що роблять кожну дію ШІ видимою до і під час виконання, обов'язкові шлюзи підтвердження/відмови, які перехоплюють усі деструктивні операції на рівні виконання до будь-якого виклику API, ізоляція даних за сесію, що обмежує зону ураження дій будь-якої окремої сесії, та повний журнал аудиту з позначками часу, який зберігає атрибуцію оператора для кожного запису, виконаного за допомогою ШІ. У цій статті детально описано кожен механізм — як він реалізований, що перехоплює та де його межі.

Ставки: чому помилки ШІ в живій COP є категорично іншими

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

Жива загальна оперативна картина не має таких властивостей відновлення. CloudTAK і TAK Server є системами спільного стану в режимі реального часу: кожен запис одразу видимий усім операторам у мережі. Немає режиму чернетки, немає проміжного шару, немає робочого процесу «запропонувати зміну для перегляду». Коли TAKpilot викликає place_marker, маркер з'являється на кожному підключеному клієнті протягом секунд. Коли він викликає delete_mission, місія зникає з кожного клієнта і зі сховища місій сервера одночасно. Місія вогневої підтримки, видалена через те що ШІ переплутав «оновити статус» з «видалити», не підлягає відновленню через інтерфейс — це потребує відновлення з резервної копії бази даних, що в умовах передового розгортання фактично означає неможливість відновлення.

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

Картки інструментів у реальному часі: повна прозорість до, під час та після виконання

Перший рівень архітектури безпеки TAKpilot — прозорість: кожна дія ШІ повинна бути видима оператору в режимі реального часу, з достатньою деталізацією, щоб оператор міг розпізнати, чи відповідає дія його наміру до того, як ефект поширюється на COP. TAKpilot реалізує це через картки інструментів у реальному часі — складані UI-панелі, що з'являються в інтерфейсі чату в міру ініціювання та завершення кожного виклику функції.

Картка інструменту в реальному часі містить чотири елементи. По-перше, назва функції простою мовою — не внутрішній ідентифікатор API, а опис людською мовою зі схеми інструменту: «Створення місії» замість create_mission. По-друге, повний набір вхідних параметрів, відображений як структурований JSON — кожне поле, кожне значення, щоб оператор міг прочитати точні координати сітки, позивний, тип CoT або назву місії, яка буде записана. По-третє, статус виконання, що відображається в режимі реального часу: очікування, виконання, успіх або збій з детальною інформацією про помилку. По-четверте, затримка виконання від подання до відповіді CloudTAK API в мілісекундах.

Для багатокрокових операцій — де модель ланцюжком з'єднує кілька викликів інструментів для виконання однієї природномовної команди — кожен крок генерує власну картку, що з'являються послідовно в міру виконання ланцюга. Оператор, який надсилає «створити логістичну місію на сітці 37U DP 55555 44444 і повідомити канал LOG-NET», бачить дві картки: одну для create_mission і одну для notify_channel, кожна з власними параметрами та результатом виконання незалежно.

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

Реалізація шлюзу підтвердження/відмови для деструктивних операцій

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

TAKpilot класифікує кожен інструмент у своїй бібліотеці як адитивний або деструктивний. Адитивні операції — place_marker, create_mission, subscribe_channel, create_data_package — створюють або доповнюють дані COP. Їх можна скасувати наступною командою, яка сама проходить через деструктивний шлюз. Деструктивні операції — delete_mission, remove_track, clear_channel, delete_data_package та масові операції оновлення, що зачіпають кілька записів — видаляють або суттєво змінюють дані COP у способи, що не можуть бути тривіально скасовані.

Класифікація міститься у config/gates.json і перевіряється рівнем виконання TAKpilot до будь-якого виклику API до CloudTAK. Коли модель повертає виклик інструменту для деструктивної операції, рівень виконання перехоплює його та ініціює процес шлюзу замість переходу до API. Процес шлюзу має чотири кроки:

1. Перелік обсягу — TAKpilot запитує CloudTAK, щоб точно перелічити, що буде зачеплено операцією: для delete_mission з фільтром за сектором це означає отримання кожної місії в цьому секторі. Для clear_channel — отримання поточних підписників каналу та повідомлень, що очікують.
2. Відображення картки шлюзу — перелічені записи відображаються в чаті як картка шлюзу. Кожний запис показується з символом NATO (де застосовно), його назвою, призначеним позивним або власником та позначкою часу останньої зміни. Оператор бачить реальні записи, які будуть зачеплені, а не абстрактну кількість на зразок «3 місії буде видалено».
3. Рішення оператора — оператор вводить «confirm» або натискає кнопку «Підтвердити», щоб авторизувати виконання, або натискає «Відхилити». Шлюз не має тайм-ауту. Якщо оператор не відповідає, операція ніколи не виконується. Закриття картки шлюзу або надсилання іншого повідомлення скасовує операцію, що очікує.
4. Маршрутизація виконання або відмови — після підтвердження виклик API надсилається і завершується стандартний процес картки інструменту в реальному часі. Після відмови TAKpilot надсилає відмову назад до моделі як результат інструменту зі статусом denied_by_operator. Модель генерує відповідь із запитанням, чи уточнити, переглянути обсяг або скасувати запит.

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

Як обробляється відхилена дія

Коли оператор відхиляє операцію, що очікує, відмова — це не просто скасування, а сигнал зворотного зв'язку, який повертається до контексту моделі. TAKpilot надсилає відмову назад як структурований результат інструменту: {"status": "denied_by_operator", "reason": "<текст оператора, якщо надано>"}. Модель отримує цей результат як частину поточної розмови і генерує відповідь, що визнає відмову та пропонує альтернативи.

На практиці відповіді на відмову слідують передбачуваним зразкам. Якщо оператор відхиляє через занадто широкий обсяг («Я мав на увазі не всі місії видалити, лише місії для Взводу 2»), модель використовує причину відмови для звуження обсягу та представляє переглянуту картку шлюзу. Якщо оператор відхиляє через те, що операція була ініційована неправильно зрозумілою командою, модель запитує уточнення замість повторної спроби. Якщо причина не надана, модель задає одне питання: «Бажаєте змінити обсяг цієї операції чи скасувати її повністю?»

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

Ізоляція даних за сесію та модель ідентифікації оператора

Архітектура сесій TAKpilot розроблена для обмеження впливу дій будь-якої окремої сесії та для забезпечення того, щоб операції за допомогою ШІ були атрибутовані правильному оператору-людині в кожній системі аудиту, що їх фіксує.

Кожна сесія чату ізольована у пісочниці за сесію. Контекст сесії — журнал розмови, результати викликів інструментів, будь-який вміст завантаженого файлу — зберігається в пам'яті та видаляється після завершення сесії. TAKpilot не зберігає журнал розмови на диску або в базі даних. Немає витоку контексту між сесіями: команда, видана в одній сесії, не може посилатися на дані або впливати на дані іншої сесії оператора. У багатокористувацьких розгортаннях CloudTAK, де кілька операторів спільно використовують вузол, ізоляція сесій забезпечує, що картка шлюзу оператора A не видима оператору B і що виклики інструментів оператора B не з'являються в журналі аудиту оператора A.

Усі виклики CloudTAK API надсилаються за допомогою власного токена сесії оператора — не службового облікового запису, не ідентифікатора бота, не спільних облікових даних. Це означає, що з точки зору CloudTAK кожний запис, виконаний TAKpilot, невідрізнений від запису, зробленого оператором безпосередньо в інтерфейсі CloudTAK. Рідний журнал аудиту CloudTAK показує ім'я оператора для кожної дії, виконаної за допомогою TAKpilot. Права доступу оператора застосовуються: якщо оператор не має дозволу на видалення місії в моделі дозволів CloudTAK, спроба TAKpilot видалити її отримає 403 від API, і операція завершиться помилкою з відповідною карткою помилки в чаті.

Формат і зміст журналу аудиту

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

Кожний запис журналу містить:

• Позначка часу — ISO 8601 з точністю до мілісекунди (2026-05-30T14:32:17.441Z).
• Ідентифікатор оператора — ім'я користувача CloudTAK, пов'язане з токеном сесії (sgt_kovalenko), а не ідентифікатор бота або служби.
• Природномовний ввід — точне повідомлення оператора, що ініціювало дію, збережене дослівно, включаючи артефакти транскрипції диктування за наявності.
• Викликаний інструмент — назва функції (delete_mission).
• Вхідні параметри — повний JSON параметрів, поданий до рівня виконання.
• Статус шлюзу — чи операція була виконана автоматично (адитивна) чи потребувала підтвердження/відмови, і якщо шлюзувалась — позначка часу підтвердження та будь-який запис відмови.
• HTTP-статус відповіді — код відповіді від CloudTAK API (200, 403, 404).
• Затримка виконання — мілісекунди від подання API до відповіді.

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

Як перевірити гарантії безпеки TAKpilot для вашого розгортання

Наступні кроки описують, як перевірити, що архітектура безпеки TAKpilot правильно налаштована для конкретного розгортання:

1. Перегляньте config/gates.json — підтвердьте, що всі деструктивні операції у вашій бібліотеці інструментів перелічені в масиві gated. Будь-які спеціальні інструменти, додані до бібліотеки для вашого розгортання, повинні бути явно класифіковані — якщо інструмент відсутній у класифікації, він за замовчуванням є адитивним (без шлюзу).
2. Перевірте шлюз з тестовою місією — у не-виробничому середовищі CloudTAK надішліть команду видалення, що цілеспрямована на відому тестову місію. Перевірте, що з'являється картка шлюзу, що вона перераховує правильний запис і що операція не виконується до введення «confirm».
3. Перевірте процес відмови — повторіть вищезазначене та відхиліть операцію. Перевірте, що відмова зафіксована в журналі сесії і що модель генерує відповідь замість того, щоб мовчки повторювати спробу.
4. Перевірте ідентифікатор оператора в аудиті CloudTAK — після виконання шлюзованої операції перевірте рідний журнал аудиту CloudTAK. Запис повинен з'явитися під вашим іменем оператора, а не під службовим обліковим записом.
5. Перевірте ізоляцію сесій — відкрийте дві сесії на одному вузлі з різними обліковими даними оператора. Підтвердьте, що картки інструментів і записи журналу аудиту з Сесії A не з'являються в чаті Сесії B.
6. Перегляньте журнал сесії перед закриттям — наприкінці тестової сесії перегляньте повний журнал аудиту в чаті і підтвердьте, що кожна дія, включаючи відмови, зафіксована з правильними позначками часу та значеннями параметрів.
7. Задокументуйте конфігурацію моделі та шлюзу в СОП підрозділу — запишіть, яка модель активна на кожному типі вузла, які операції шлюзуються та процедуру експорту журналів сесій для розбору після дій. Ця документація є частиною архітектури безпеки, а не необов'язковим доповненням.

Часті запитання

Оновлено: Для огляду того, як TAKpilot перетворює природну мову на операції CloudTAK наскрізно, дивіться TAKpilot: управління COP природною мовою для тактичних операторів CloudTAK. Для базових шаблонів CloudTAK API, на яких побудована бібліотека інструментів TAKpilot, дивіться Інтеграція CloudTAK API: підключення зовнішніх систем до TAK Server. Про те, як архітектури LLM-агентів обробляють виклики інструментів і безпеку з людиною в петлі загалом, дивіться ШІ-копілот для тактичних застосунків: як LLM-агенти управляють COP.