Kokpit dla agentów AI działających w Twojej infrastrukturze

Prowadzisz już dashboardy dla wszystkiego innego w swoim środowisku: hostów, kolejek, magazynów danych, ścieżki żądań. A potem pojawia się kilkanaście agentów AI — copiloty, serwery MCP, zadania zaplanowane, instancja Claude Code, którą ktoś podłączył do produkcji — i nie masz jednego miejsca, które odpowiadałoby na pierwsze pytanie operatora: co właściwie działa i do czego każdy z tych elementów rzeczywiście może dosięgnąć?

To ten sam wzorzec, co niezarządzana infrastruktura widmo (shadow infrastructure), z tą różnicą, że obciążenia przechowują poświadczenia i działają samodzielnie. Spośród organizacji, które doświadczyły naruszenia związanego z AI, około 97% nie miało odpowiednich mechanizmów kontroli dostępu do AI (IBM Cost of a Data Breach 2025, Ponemon). Branża ma już na to słowo — agent sprawl — a Gartner przewiduje, że ponad 40% projektów agentic-AI zostanie anulowanych do końca 2027 roku (Gartner), często dlatego, że nikt nie był w stanie operować nimi bezpiecznie, gdy się zaczęły mnożyć.

Co zyskuje operator

Olivares AI to otwarta, możliwa do samodzielnego hostowania platforma, która działa tam, gdzie działają Twoi agenci. Wykrywa ich, buduje mapę dostępu do odczytu/zapisu pokazującą, czego każdy z nich dotyka, i daje Ci kontrole do zarządzania tym dostępem oraz jego audytowania. Dla SRE lub sysadmina pięć właściwości liczy się bardziej niż lista funkcji.

Pasywny — poza ścieżką żądań

Wykrywanie jest budowane z telemetrii oraz natywnego dla źródła audytu poza pasmem (out of band). Widok kondycji i niezawodności jest konsumentem szyny zdarzeń, a nie sondą, która otwiera gniazda do Twojej infrastruktury — liveness (dostępność) jest wnioskowana z zaobserwowanej aktywności, a agent, który przestaje emitować, sam w sobie jest sygnałem. Ponieważ Olivares nie jest proxy ani sidecarem przed Twoimi agentami, awaria Olivares nie jest w stanie ich wyłączyć. Jedynymi powierzchniami, które kiedykolwiek znajdują się w linii (inline), są opcjonalne bramki aktywacji, które zdecydujesz się podłączyć, a te zawodzą w trybie zamkniętym (fail closed).

Jeden samodzielnie hostowany statyczny plik binarny

Wdraża się jako pojedynczy statyczny plik binarny z wbudowaną konsolą webową — bez floty agentów do wypchnięcia, bez operatora Kubernetes płaszczyzny kontroli do niańczenia. Magazyn to czysty Go SQLite (Postgres dla wielonajemczości), więc nie ma łańcucha narzędzi C, z którym trzeba by walczyć. Instalujesz jeden plik, uruchamiasz go jako dedykowany użytkownik usługi i masz kokpit. Zobacz instalację i samodzielny hosting.

Płaszczyzna kontroli działa wewnątrz Twojego perymetru i może działać w trybie air-gapped — Twoje dane governance i obserwacji nigdy go nie opuszczają. Jedno zastrzeżenie, o którym operatorzy powinni pamiętać: to nie jest AI działające offline. Hostowane modele takie jak Claude wciąż łączą się z API dostawcy; air-gapped oznacza, że dane Twojego środowiska zostają na miejscu, a nie że model działa lokalnie. Tylko modele rzeczywiście możliwe do samodzielnego hostowania (vLLM, Ollama) działają w pełni offline. Więcej w bezpieczeństwie i architekturze.

Natywne dla OTel pozyskiwanie danych

Ścieżka pozyskiwania danych przypina konwencje semantyczne OpenTelemetry GenAI obok OCSF, formatów SIEM i W3C Trace Context — więc telemetria, którą już emitujesz, to telemetria, którą odczytuje. Jedna uczciwa granica: Olivares koreluje Twój rejestr zarządzanych zdarzeń po W3C trace_id; nie przechowuje pełnych spanów OTel. Czasy trwania i status w widoku śledzenia to okna zdarzeń rejestru, a nie zrekonstruowane dane spanów. Pełne spany pozostają w Twoim własnym kolektorze OTLP, gdzie ich miejsce. Olivares mówi Ci, kto czego dotknął i czy było to dozwolone — nie zastępuje Twojego backendu śledzenia. (Zobacz stronę porównania, aby zobaczyć, gdzie plasuje się obok LiteLLM/Langfuse.)

Sondy i kondycja, jak każda usługa, którą prowadzisz

Plik binarny udostępnia punkty końcowe, których Twój orkiestrator już oczekuje:

GET /livez     liveness  — czy proces jest uruchomiony
GET /readyz    readiness — czy obsługuje (i nie jest zimnym standby)
GET /healthz   liveness wyłączony z setupu dla scraperów
GET /metrics   ekspozycja Prometheus

/readyz zwraca 503, gdy magazyn podkładowy jest nieosiągalny, zamiast się zawieszać, więc load balancer wycofuje węzeł z ruchu, zamiast kierować ruch do czarnej dziury. Na dodatek moduł XXII śledzi kondycję, SLA i czas pracy samych agentów oraz serwerów MCP — co jest zdrowe, co jest zdegradowane i co od czego zależy — oraz emituje ustalenia typu down/degraded/ recovered/SLA-breach do Twojej istniejącej szyny (Slack, PagerDuty, SIEM). Wytwarza sygnał; nie próbuje być Twoim systemem powiadomień.

Read-first, z prawdziwym zatrzymaniem obejmującym całe środowisko

Olivares jest domyślnie detektywistyczny i domyślnie odmawiający (deny-closed). Obserwuje i zarządza szeroko; nie aktywuje szeroko. Ale gdy agent zacznie sprawiać problemy o 3 nad ranem, operator potrzebuje jednej dźwigni, która działa bez ceremonii — dlatego kill-switch jest prawdziwy i zbudowany do użycia:

• Włączenie jest tanie. Poziom admina, jeden obowiązkowy powód, jedno kliknięcie. Nie ma bramki zatwierdzania ani podniesienia uprawnień przy włączeniu — zatrzymanie awaryjne, które czeka na kworum, nie jest zatrzymaniem. Zakres obejmujący całe środowisko odmawia dostępu do każdej zarządzanej powierzchni aktywacji dla najemcy (tenant); zakres agenta zatrzymuje jednego agenta na każdej powierzchni, na której można go nazwać.
• Ponowne włączenie już nie. Zniesienie zatrzymania wymaga dual-control (dwóch odrębnych ludzi) i jest następowane przez obowiązkowy przegląd po fakcie, który musi podpisać trzecia, niezaangażowana osoba. „Środowisko pozostaje zatrzymane” to stan bezpieczny.
• Zawodzi w trybie zamkniętym (fail closed). Każda bramka aktywacji sprawdza bieżący stan zatrzymania przy każdym wywołaniu i odmawia przy błędzie odczytu — nieodczytywalne zatrzymanie nigdy nie oznacza „działaj”.

Bądź wobec siebie szczery co do zakresu: zatrzymanie jest tak szerokie, jak bramki, które podłączyłeś. Nie może zamrozić powierzchni, do której Olivares nie ma szwu (seam). To celowy kompromis systemu read-first — i dlatego wykrywanie oraz mapa są na pierwszym miejscu.

Czym to jest — a czym nie jest

• Jest pasywnym, samodzielnie hostowanym kokpitem: wykrywa agentów, mapuje ich dostęp do odczytu/zapisu, obserwuje ich kondycję i trzyma zatrzymanie obejmujące całe środowisko o jedno kliknięcie.
• Nie jest proxy w linii (inline), backendem śledzenia ani systemem, który po cichu przemontowuje Twoich agentów. Aktywacja jest opt-in, na żądanie i domyślnie odmawiająca (deny-closed) — każdy szew (seam) podłączasz świadomie.
• Jest w fazie przed 1.0 i open-core. Katalog wymienia 23 moduły funkcjonalne; mniej więcej dwadzieścia jest już podłączonych, reszta jest na etapie projektowania lub po wersji v1. Odniesienie do modułów oznacza, co jest aktywne.
• Nie jest certyfikowany. Olivares jest projektowany w kierunku SOC 2, ISO/IEC 42001 oraz EU AI Act — nie posiada tych certyfikatów i nie będzie tego twierdził. Zobacz bezpieczeństwo, aby poznać uczciwą postawę.
• Wierność (fidelity) jest warstwowa i tak też pokazywana. Pokrycie odczyt-vs-zapis jest clean w magazynach z natywnym audytem, lossy w niektórych magazynach dokumentów/wektorów oraz unknown tam, gdzie nie da się go zrekonstruować pasywnie (Redis, SQLite, D1); atrybucja per agent jest firm tylko wtedy, gdy sygnał to wspiera, a approximate za współdzielonym kontem. Nic nie jest zgadywane. Zobacz wierność.

Od czego zacząć

• Postaw to: samodzielny hosting, a następnie szybki start dla syntetycznego środowiska.
• Podłącz swój pierwszy sygnał: podłącz źródło.
• Zrozum model: dozwolone vs zaobserwowane oraz mapę dostępu.
• Persony pokrewne operatorom: inżynieria platformy oraz liderzy bezpieczeństwa.