Ви хочете, щоб ваш AI-асистент працював з HURMA? Розкажемо, які дані він зможе побачити, чи отримає доступ до всієї бази та що станеться, якщо підключення потрібно буде вимкнути.
У HURMA доступ до даних контролюється на кількох рівнях. AI не отримує окремих або розширених прав лише через сам факт підключення. Навпаки, для конкретної інтеграції можна додатково визначити, яку інформацію дозволено читати і хто з працівників компанії може нею користуватися.
Підключення AI-асистента не відкриває йому всю інформацію, яка зберігається в системі.
По-перше, доступ не може бути ширшим за права користувача HURMA, від імені якого працює підключення. По-друге, під час створення самого підключення можна додатково визначити, які дані AI буде дозволено читати.
Тобто запит у чаті не може розширити доступ. Якщо користувач або конкретне підключення не мають права на певну інформацію, AI її не отримає.
Під час налаштування підключення HURMA дозволяє вибрати інформацію, яку AI може використовувати для відповідей та аналітики.
Окремо можна налаштувати доступ до полів співробітників і кандидатів. Не обов'язково відкривати все: для конкретного сценарію можна залишити лише потрібні дані, а чутливі поля не передавати.
Це особливо важливо, якщо AI використовується для аналітики, де для розрахунків потрібні, наприклад, статуси або інші робочі дані, але не потрібні контакти чи домашня адреса людини.
Для роботи з аналітикою AI не завжди потрібно знати ім'я конкретного співробітника або кандидата.
У HURMA кожен запис має внутрішній ID. Тому можна не відкривати AI ПІБ, контакти, адресу та інші поля, які не потрібні для конкретної задачі, але при цьому зберігати можливість розрізняти записи між собою.
Замість імені в результаті може використовуватися внутрішній ID HURMA. За потреби користувач із відповідними правами може зіставити його з конкретним профілем уже всередині системи.
Тобто назовні передається менше інформації, але система продовжує розрізняти записи.
Під час створення AI-підключення потрібно окремо визначити, хто з працівників компанії може ним користуватися.
Сам факт наявності акаунта HURMA не дає автоматичного доступу до всіх створених інтеграцій. Навіть автор підключення має бути доданий до списку користувачів, яким воно дозволене.
Компанія також може створити кілька окремих підключень із різними дозволами для різних задач або команд.
Поточне підключення працює лише на читання.
AI може отримати дозволені дані, проаналізувати їх і використати для відповіді чи звіту. Але через це підключення він не може створювати нові записи або змінювати наявну інформацію в HURMA.
Наприклад, AI може допомогти знайти вакансії, які довго залишаються відкритими, але не може самостійно змінити їхній статус.
У HURMA можна контролювати створені підключення, перелік працівників із доступом та статус підключення.
Якщо інтеграція більше не потрібна або доступ конкретного користувача потрібно припинити, його можна відкликати. Після цього пов'язані дані авторизації стають недійсними й не можуть використовуватися для нових звернень до HURMA.
Це основні механізми для IT та security-команд: від автентифікації до журналювання.
Для підключення AI використовується MCP — Model Context Protocol, протокол взаємодії AI-клієнтів із зовнішніми системами.
MCP HURMA працює через окремий сервіс-посередник і звертається до даних через HURMA API v3. Прямого підключення AI-клієнта до бази даних HURMA немає.
Авторизація побудована на механізмах OAuth 2.1 із authorization code flow та PKCE S256.
Користувач проходить вхід на стороні HURMA. Логін і пароль не передаються AI-клієнту або MCP-сервісу: після успішної авторизації взаємодія відбувається через токени.
Сценарій, за якого зовнішня система отримує пароль користувача та обмінює його на токен, для MCP-клієнта не використовується.
Облікові записи HURMA додатково захищаються хешуванням паролів за допомогою bcrypt, обмеженням кількості спроб входу та двофакторною автентифікацією.
MCP не має окремого привілейованого доступу до HR-даних.
На серверній стороні застосовується модель прав HURMA API v3. Для кожного запиту система перевіряє, чи:
існує та чи дійсний токен;
не був він відкликаний;
активний користувач;
дозволено цьому користувачу працювати з конкретним підключенням;
має клієнт потрібний scope — дозвіл на відповідний тип операції;
дозволені запитані дані та поля.
Якщо необхідної авторизації немає, запит відхиляється з відповідним HTTP-статусом 401 або 403 до виконання операції з даними.
Окремо під час створення MCP-підключення можна обмежити доступні поля співробітників і кандидатів. Тому фактичний доступ визначається одночасно правами користувача HURMA та дозволами конкретного підключення.
HURMA визначає, до якого робочого простору належить запит, на основі валідованого токена, а не параметра, який передає зовнішній клієнт.
Тому підміна ідентифікатора компанії в URL, параметрах або тілі запиту не дозволяє використати чинний токен для доступу до іншого інстансу. Кожен інстанс HURMA ізольований як окремий тенант і має власний ключ підпису токенів.
Зовнішній обмін із сервісом відбувається через HTTPS. Незашифрований трафік до сервісу не допускається на інфраструктурному рівні.
Access-токени передаються тільки через HTTP-заголовок Authorization. Вони не додаються до URL або query-параметрів, де могли б потрапити до історії браузера, кешу проксі чи інших технічних журналів.
Для авторизації використовуються одноразові коди: після обміну на токен код стає недійсним.
Refresh-токени ротуються. Після оновлення доступу видається новий refresh-токен, а попередній більше не може бути використаний. Строк життя токенів може налаштовуватися для конкретного інстансу HURMA.
API-токени та ключі генеруються криптографічно стійким генератором випадкових чисел. Збережені OAuth-секрети клієнтів і токени HURMA зберігаються в зашифрованому вигляді із застосуванням Fernet.
Активні MCP-підключення та користувачів, яким вони доступні, можна переглядати й контролювати в HURMA.
Після відкликання доступу запускається відкликання пов'язаних access- і refresh-токенів. Раніше авторизований клієнт після цього не може продовжити використовувати їх для нових запитів.
Це дозволяє припинити доступ як для конкретного користувача, так і для інтеграції, яка більше не використовується.
Ні. MCP не працює як універсальний проксі до внутрішнього API HURMA.
Назовні доступний визначений перелік маршрутів, необхідних для роботи авторизації та MCP. Операції, які може викликати AI-клієнт, визначені реалізованими інструментами, а передані ідентифікатори та інші параметри перевіряються сервером.
Внутрішні сервіси та бази даних розміщені в приватній мережі й не доступні безпосередньо ззовні.
Для моніторингу роботи сервісу HURMA веде операційні логи.
У них зберігаються технічні метадані, необхідні для контролю стабільності, наприклад ідентифікатор тенанта, маршрут і код статусу відповіді.
При цьому в операційні логи не записуються access-токени та тіла запитів і відповідей.
Таким чином, для діагностики роботи інтеграції не потрібно дублювати в технічних журналах сам вміст HR-даних, які передаються в межах запиту.
Коли AI-асистент отримує дані з HURMA, їх подальша обробка відбувається вже на боці провайдера AI (наприклад, Anthropic, OpenAI чи іншого сервісу, який ви використовуєте). HURMA не контролює, як довго ці дані зберігаються в межах сесії AI-клієнта та чи використовуються вони провайдером це визначається угодою між вашою компанією та провайдером AI.
Тому ми рекомендуємо перед підключенням:
перевірити політику обробки даних вашого AI-провайдера зокрема, чи використовуються дані для навчання моделей і які строки зберігання діють (для бізнес-тарифів провайдери зазвичай пропонують режими без навчання на даних клієнта та угоди про обробку даних, DPA);
передавати через інтеграцію лише той мінімум полів, який потрібен для конкретної задачі, — саме для цього в HURMA є налаштування доступних полів і можливість працювати з внутрішніми ID замість імен і контактів;
за потреби узгодити підключення з вашим DPO або юридичною командою, якщо через інтеграцію передаються персональні дані працівників чи кандидатів.
HURMA контролює, які дані можуть залишити систему, а вибір AI-провайдера та умови обробки на його боці залишаються під контролем вашої компанії.
AI-інтеграція HURMA не створює окремого необмеженого доступу до HR-даних.
Межі визначаються правами користувача та налаштуваннями конкретного підключення. Окремо можна контролювати доступні поля співробітників і кандидатів, не передавати непотрібні персональні дані, визначати користувачів інтеграції та відкликати їхній доступ.
На технічному рівні ці обмеження доповнюються перевіркою кожного запиту, ізоляцією інстансів, захищеною передачею даних, ротацією й відкликанням токенів, закритим мережевим периметром і обмеженим журналюванням.
Тобто AI отримує контрольований доступ на читання до конкретно дозволених даних у межах заданих прав.
