Коротко: MCP — це спосіб описати дозволене, а не механізм заборони. Реальні межі створюють набір дозволів Business Central, обліковий запис інтеграції та вузько спроєктовані операції. Якщо ці три речі зроблені правильно, MCP додає зручність перевірки; якщо ні — він нічого не рятує.
Головна помилка розуміння
Найпоширеніша фраза в обговореннях: «ми поставили MCP, тому доступ обмежений». Це неправильно на рівні логіки.
MCP-сервер віддає моделі перелік операцій. Якщо серед них є операція «виконати довільний запит до таблиці», модель отримає рівно те, що зможе через неї дістати, — і протокол тут ні до чого. Безпека визначається змістом переліку, а не тим, що перелік описаний за стандартом.
Що MCP справді дає для безпеки: перелік дозволеного стає документом, який можна прочитати за один раз і віддати на перевірку. У зашитій у код інтеграції ця інформація розмазана по файлах, і перевірити її можна тільки читанням коду. Це реальна користь, але це користь для аудиту, а не заборона.
Чотири шари захисту
Кожен працює незалежно від інших — це і є сенс шарів.
| Шар | Що обмежує | Хто забезпечує |
|---|---|---|
| Перелік операцій | Що модель може спробувати | Ваш MCP-сервер |
| Перевірка параметрів | З якими значеннями | Ваш MCP-сервер |
| Набір дозволів | До чого має доступ обліковий запис | Business Central |
| Процеси погодження | Що виконується без людини | Business Central |
Третій рядок — головний. Він працює, навіть якщо ваш сервер спроєктований погано: якщо облікового запису немає права проводити документи, він їх не проведе, хай би що просила модель.
Чого в таблиці немає: інструкції для моделі. Промпт не є контролем. Він визначає поведінку в нормальних умовах, і будувати на ньому захист — те саме, що покладатися на ввічливе прохання.
Проєктування операцій
Тут зосереджена та частина безпеки, за яку відповідаєте ви, а не платформа. Чотири правила.
Вузько замість гнучко. «Отримати прострочену заборгованість понад суму за період» — правильно. «Отримати дані з таблиці з довільним фільтром» — переносить межу з коду в судження моделі. Друге зручніше розробнику й саме тому трапляється.
Операції запису — окремі й точкові. Не «оновити картку клієнта», а «оновити дату останнього контакту». Різниця в тому, що перше дозволяє змінити кредитний ліміт, і обмеження діє в коді, а не в надії.
Повертати рівно потрібне. Інструмент, який віддає таблицю й лишає моделі фільтрувати, надсилає назовні більше даних, ніж потрібно, і впирається в обмеження інтенсивності запитів Business Central. Обсяг переданого — це рішення архітектора, а не властивість провайдера.
Явна відповідь «даних немає». Порожній результат і помилка мають розрізнятися. Інакше модель схильна заповнити пропуск правдоподібним числом, а у фінансовому контексті це найнебезпечніша поведінка з можливих.
Обліковий запис і розмежування
Рішення, яке визначає всю модель доступу й дорого змінюється потім.
Сервісний обліковий запис. Сервер працює під одним технічним записом. Просто, передбачувано, але всі користувачі бачать однаковий зріз. Якщо керівник напряму й фінансовий директор мають бачити різне — не підходить.
Делегований доступ. Сервер діє від імені того, хто питає. Кожен бачить своє, журнал показує реальну людину. Складніше в реалізації й правильно для більшості компаній.
Незалежно від варіанта: окремий набір дозволів під інтеграцію, а не копія ролі бухгалтера. Надлишкові права ніхто потім не звужує — це закономірність. І область компанії, якщо юридичних осіб кілька. Ширший контекст — у матеріалі про права користувачів.
Окремий випадок — зовнішній доступ, коли з системою говорить клієнт. Тут фільтрація за ідентифікатором клієнта має бути в самій операції, а ідентифікатор підставлятися кодом із сесії, не моделлю. Якщо модель може вибрати, чиї дані запитати, захисту немає.
Аудит і журнал
Звернення видно в журналі змін Business Central під тим обліковим записом, який використовується. З цього випливає практична вимога: окремий обліковий запис на кожну інтеграцію й на кожного агента.
Якщо кілька агентів працюють під спільним сервісним записом, розібрати постфактум, хто саме що зробив, буде складно — а питання ставлять зазвичай тоді, коли вже щось сталося. Вирішити це при проєктуванні коштує нічого.
Другий журнал — на боці MCP-сервера: які операції викликалися, з якими параметрами, що повернулося. Business Central бачить факт звернення, ваш сервер бачить намір. Для розбору інциденту потрібні обидва.
Перелік перевірок до продуктиву
Мінімум, який варто пройти. Кожен пункт — це спроба зробити те, чого не можна.
- Запит операції, якої немає в переліку — сервер відмовляє, модель повідомляє, що не може.
- Операція поза набором дозволів — Business Central відмовляє, помилка обробляється коректно.
- Параметри поза межами — сума за межами діапазону, дата з майбутнього, чужий код компанії.
- Порожній результат — система каже «даних немає», а не рахує від нуля.
- Часткова невдача — завершує по тих, де вдалося, і окремо повідомляє про решту.
- Спроба дістати дані іншого користувача або іншої компанії.
- Аномальний обсяг — тисяча операцій замість звичних двадцяти зупиняє процес.
Загальна картина безпеки AI над ERP — у розборі дозволів, доступу й захисту даних.
Що зробите самі
Набір дозволів і окремий обліковий запис ви зробите краще за будь-якого підрядника: це знання про вашу модель прав. Так само перелік полів, які взагалі не мають залишати контур, — це рішення бізнесу.
Що складно без досвіду — це проєктування операцій під модель даних Business Central і перелік перевірок відмов. Друге особливо: невідомо, що саме тестувати, бо перелік граничних випадків складається з чужих помилок.
Орієнтир: AI Discovery від $750 включає оцінку даних, дозволів і архітектури з письмовим висновком; асистент від $3 000, агент від $6 000.
Часті запитання
Чи робить MCP інтеграцію безпечнішою?
Сам по собі — ні. Він робить перелік дозволеного видимим і придатним до перевірки, що корисно для аудиту. Забороняє ж набір дозволів Business Central і зміст переліку операцій, а не сам протокол.
Чи може модель обійти обмеження через формулювання запиту?
Ні, якщо захист побудований правильно. Модель формує намір, а виконує сервер, який приймає лише операції з переліку й перевіряє параметри. Далі Business Central застосовує дозволи. Промпт не є межею безпеки в жодному з цих шарів.
Як розмежувати доступ між користувачами?
Делегованим доступом: сервер діє від імені того, хто питає, і кожен бачить те, що йому дозволено в Business Central. Спроба розділити доступ інструкцією для моделі не працює.
Що фіксується в журналі?
Business Central бачить факт звернення під обліковим записом інтеграції. Ваш MCP-сервер бачить, яка операція викликалася і з якими параметрами. Для розбору інциденту потрібні обидва журнали.
Скільки операцій безпечно віддавати моделі?
Питання не в кількості, а в ширині кожної. Двадцять вузьких операцій безпечніші за одну універсальну. Перелік має вміщатися в документ, який читається за один раз, — інакше його ніхто не перевірить.
Чи потрібен окремий аудит перед запуском?
Корисно, і найпростіша форма — пройти перелік перевірок вище, тобто спробувати зробити те, від чого система має відмовитися. Це пів дня роботи, яка дає більше, ніж будь-який опис архітектури.