Чи є провайдер Terraform відкритим, і за якою ліцензією?

Так. Провайдер terraform-provider-olivares публікується за ліцензією AGPL-3.0-only — не Apache-2.0. Він декларативно керує вашою власною self-hosted панеллю керування (агенти, політики, розгортання, прив'язки ідентичностей, бюджети) через стабільний API продукту. Плануйте відповідно, якщо ваша модель розповсюдження чутлива до copyleft.

Чи замінює Olivares AI наш провайдер ідентичності?

Ні. Це не IdP. Він федерує ідентичність агентів у режимі read-only — зчитує реєстри з Entra Agent ID, AWS AgentCore Identity і Google Agent Identity та звіряє їх з реєстром SPIFFE/WIF, щоб граф доступу ніс точну або приблизну атрибуцію для кожного ребра. Він не видає жодних облікових даних і нічого не записує назад до цих реєстрів.

Чи інтеграція з Backstage — це справжній плагін, чи iframe?

Цільовим проєктним рішенням є нативний плагін з пріоритетом читання, що відображає інвентар агентів, активні сесії та карту доступу R/RW усередині вашого порталу, з автентифікацією через панель керування. Це інтеграція в портал, а не другий дашборд. Сприймайте глибину плагіна як стан до версії 1.0 — статус дивіться у довіднику модулів.

Розмістіть ваших AI-агентів у платформі, яку ви вже використовуєте

Проблема: агенти з’являються швидше, ніж ваша платформа встигає їх описати

Ви експлуатуєте внутрішню платформу для розробників. У вас є каталог сервісів, IdP, інфраструктура як код, узгодження через GitOps і портал, який інженери справді відкривають. Цей механізм існує саме для того, щоб ніщо важливе не працювало неописаним — жодного сервісу без власника, жодного доступу без політики, жодної зміни без diff.

AI-агенти порушують цей контракт. Сесія Claude Code, MCP-сервер, запланований автономний агент — кожен з них може читати й записувати в ті самі бази даних, об’єктні сховища та API, яких торкаються ваші сервіси, але вони з’являються поза каталогом. Їх запускають розробники, а не ви. Так само часто вони автентифікуються як спільні службові облікові записи. А гіперскейлери погіршили ситуацію, зробивши ідентичність агентів GA-примітивом у трьох взаємно несумісних реєстрах.

Ринковий сигнал прямолінійний. Gartner очікує, що понад 40% проєктів агентного AI буде скасовано до кінця 2027 року (Gartner, прес-реліз), а дослідження IBM Cost of a Data Breach 2025 (Ponemon) виявило, що серед організацій, які зазнали порушення, пов’язаного з AI, приблизно 97% не мали належних засобів контролю доступу до AI. Попередній висновок MIT з проєкту NANDA — the GenAI Divide, через Fortune, серпень 2025, ще не рецензований — повідомляє, що близько 95% пілотів GenAI не показали жодного вимірюваного впливу на P&L, і що зовнішньо придбані інструменти були успішними приблизно вдвічі частіше, ніж внутрішні розробки. У контексті роботи платформної команди це вказує в той самий бік: неконтрольоване, неописане розростання агентів — це там, де витікає цінність і просочується ризик.

Як Olivares AI вписується в платформу, яку ви вже використовуєте

Olivares AI — це відкрита, придатна до self-hosted платформа, яка виявляє AI-агентів у вашій інфраструктурі, картографує те, що кожен з них може читати й записувати, та контролює й аудитує цей доступ. Проєктна мета для платформних команд — не ще одна консоль, а зробити агентів повноцінними громадянами платформи, яку ви вже експлуатуєте.

Агенти як повноцінні сутності каталогу

Платформа виявляє агентів, MCP-сервери, сесії та нелюдські ідентичності й будує карту доступу: граф кожного ребра агент → база даних / сховище / API, кожне з яких позначене як читання (R) або читання-запис (RW). Цей граф — це той запис у каталозі, який агент мав би мати від самого початку: що це таке, чого воно торкається й чи відповідає те, чого воно торкається, тому, що йому дозволено.

Ця остання відмінність — це ядро продукту. Ребра класифікуються як дозволені vs спостережувані, тож дрейф від принципу least-privilege видимий, а не припущений. Дивіться карту доступу і сторінку концепції про дозволене vs спостережуване.

Застереження щодо чесності важливе тут, і ми тримаємо його на видноті: точність R/RW багаторівнева. Покриття є clean для джерел з нативним аудитом, lossy там, де ребра грубі, і opaque там, де взагалі немає пасивного сигналу читання/запису; атрибуція є firm, коли джерело несе ідентичність кожного агента, і approximate, коли спільний обліковий запис її приховує. Карта показує рівень, а не імітує впевненість — дивіться точність.

Керування як кодом: провайдер Terraform/OpenTofu

Для платформної команди config-as-code — це базова вимога. Olivares AI постачає terraform-provider-olivares, який декларативно керує вашою власною self-hosted панеллю керування через її стабільний API. Провайдер надає ресурси та джерела даних для агентів, політик, розгортань, прив’язок ідентичностей агентів, бюджетів, конфігурації можливостей і маршрутів сповіщень, з підтримкою import, plan/apply та обробки дрейфу — тож агенти, якими ви керуєте, узгоджуються так само, як ArgoCD чи Flux уже узгоджують решту вашого парку.

Одна деталь щодо ліцензії, яку варто уточнити, бо вона відрізняється від SDK для конекторів: провайдер має ліцензію AGPL-3.0-only, а не Apache-2.0.

resource "olivares_agent" "billing_assistant" {
  name = "billing-assistant"
  # ...managed alongside the rest of your platform, as code
}

resource "olivares_policy" "billing_least_privilege" {
  # least-privilege intent, versioned in Git, reconciled like everything else
}

Наведений вище HCL ілюструє форму, а не є контрактом для копіювання — генеруйте за власною опублікованою схемою провайдера. Продукт перебуває у стані до версії 1.0: розглядайте покриття ресурсів як таке, що відстежує поверхню API, і перевіряйте довідник модулів щодо того, що під’єднано сьогодні.

Інтеграція з вашим IdP — федерація, а не заміна

Olivares AI — це не провайдер ідентичності, і він не намагається ним бути. Він федерує ідентичність агентів у режимі read-only: зчитує реєстри з Microsoft Entra Agent ID, AWS AgentCore Identity і Google Agent Identity та звіряє їх з реєстром SPIFFE/WIF, тож кожне ребро на карті доступу несе точну або приблизну атрибуцію. Виділені ідентичності агентів і робочих навантажень розв’язуються до точної атрибуції; принципали-шаблони, постачальники облікових даних і агенти на службових облікових записах залишаються приблизними, а не підвищуються до сфабрикованої ідентичності. Він не видає жодних облікових даних і нічого не записує назад до цих реєстрів — федерація суворо read-only.

Він також виявляє корисний клас дрейфу для безпеки платформи: довгоживучі статичні облікові дані, виявлені на ідентичностях агентів, відповідно до рекомендацій Five Eyes 2026 щодо короткоживучих облікових даних. Автентифікація OAuth-клієнта на основі SVID (робота draft-ietf-oauth-spiffe-client-auth) реалізована як проєктний орієнтир — жодної заяви про відповідність немає, доки сервер авторизації не опублікує відповідний потік. Дивіться ідентичність і федерацію.

Інтеграція з порталом: Backstage, з пріоритетом читання

Якщо ваші розробники живуть у Backstage, інвентар агентів має жити там само. Цільовим проєктним рішенням є нативний плагін з пріоритетом читання — інвентар, активні сесії та карта доступу R/RW, відрендерені всередині порталу й автентифіковані через панель керування, — а не iframe і не другий дашборд. Пріоритет читання — навмисний: він відповідає позиції продукту (нижче) і робить інтеграцію з порталом малоризиковою.

CLI-first, зі стабільним API під капотом

Уся платформа — це один бінарний файл Go, controlplane, який запускається до заповненого графа доступу; вебконсоль вбудована в той самий origin, що й API. Усе, що ви можете робити в UI, ви можете виконати з CLI або через поверхню OpenAPI 3.1, на якій будуються провайдер Terraform, плагін Backstage і ваша власна автоматизація. Почніть з довідника конфігурації, робочого процесу CLI та поверхні керування MCP.

Що це таке — і чим воно не є

Це продукт, орієнтований на безпеку, тож ми тримаємо жорстку межу щодо того, що він заявляє.

Пріоритет читання й deny-closed. Він широко спостерігає й контролює, але не виконує дії широко. Більшість дій виконується live-on-demand або через задекларований deny-closed шов — apply для розгортання повертає 503, доки ви не надасте виконавця, а не мовчазний no-op. Дивіться дозволене vs спостережуване і сторінку чесність і обмеження.
До версії 1.0, open-core. Каталог містить 23 модулі; приблизно 20 під’єднано у стандартній інсталяції. Ніщо тут не означає, що всі 23 повністю активні — довідник модулів позначає статус кожного модуля.
Air-gap означає панель керування, а не Claude. Площина контролю й спостереження працює повністю self-hosted і може бути air-gapped. Інференс Claude ніколи не є self-hosted — Anthropic не публікує ваги, тож будь-який виклик Claude досягає API. Лише моделі, які ви справді розгортаєте локально (vLLM, Ollama), працюють офлайн. Дивіться безпеку.
Не сертифіковано. Він спроєктований з орієнтацією на EU AI Act, NIST AI RMF, ISO/IEC 42001, SOC 2 та інші, з аудиторськими доказами, отриманими з журналу append-only зі зчепленими хешами. Він не сертифікований за SOC 2 / ISO / EU AI Act. Дивіться відповідність.
Він доповнює ваші вежі контролю; він не заявляє, що замінює їх. Федерація ідентичності й експорт стану доступу за задумом є read-only.

Якщо ви хочете спочатку побачити архітектурну картину, прочитайте архітектуру; якщо ви хочете знати, де ми перебуваємо відносно шлюзів, спостережуваності й веж контролю агентів, дивіться порівняння. А якщо ви зважуєте ліцензію та межу open-core, відкритий код — це чесна версія.

Пов’язані персони: лідери безпеки, SRE і системні адміністратори та вища освіта.