비교
Olivares의 위치 — 우리는 통합합니다, 대체하지 않습니다
여러분의 스택은 이미 프롬프트를 추적하고, 호스트를 감시하며, 인프라를 체계적으로 목록화하고 있습니다. 어떤 단일 계층도 답하지 못하는 질문은, 어떤 에이전트가 — 어떤 아이덴티티에 묶여 — 실제로 어떤 리소스를 읽었거나 썼는가입니다. 바로 이 공백을 Olivares가 채웁니다. 그것도 여러분이 이미 운영 중인 것을 소비하고 강화하는 방식으로 말입니다.
지형
각 계층이 보는 것 — 그리고 멈추는 지점
이 범주들은 각자 맡은 일을 훌륭히 해냅니다. 그러나 그 어느 것도 단독으로는 인프라에서 발생한 실제 read 또는 write를 특정 AI 에이전트에 귀속시키지 못합니다. Olivares는 그 사이에 자리 잡은, 에이전트를 인식하는 상관관계 계층입니다.
LLM 가시성
예: LiteLLM, Langfuse, Phoenix
- 보는 것
- 프롬프트, 트레이스, 지연 시간, 토큰 비용 — 애플리케이션 수준에서 모델의 추론 과정을 봅니다.
- 멈추는 지점
- 호스트는 보지 못합니다. 에이전트가 실제로 어떤 데이터베이스, 스토어, API를 읽었거나 썼는지는 알 수 없습니다.
호스트 & 런타임
예: eBPF 도구 — Falco, Tetragon
- 보는 것
- 호스트에서 발생하는 syscall, 프로세스, 네트워크 egress를 실시간으로 봅니다.
- 멈추는 지점
- 에이전트를 인식한 귀속이 없습니다. 보이는 것은 프로세스와 컨테이너 ID일 뿐, 이름이 붙은 에이전트와 아이덴티티가 아닙니다.
AI 컨트롤 타워
예: Datadog AI Agents Console, Microsoft Agent 365, ServiceNow AI Control Tower
- 보는 것
- 조직이 이미 운영 중인 도구 전반의 자산 인벤토리, 보안 태세, 워크플로를 봅니다.
- 멈추는 지점
- 주입되는 인벤토리의 품질에만 좌우됩니다. 그 아래에 그라운드 트루스 소스가 필요합니다.
Olivares의 위치
에이전트를 인식하는 read/write 계층
Olivares는 다른 도구들이 열어 둔 질문에 답하고, 그 답을 여러분의 경계 안에 둡니다.
누가 무엇을 건드렸는가, read인가 write인가
이미 내보내고 있는 신호들을 하나의 관계로 상관시킵니다. 이 에이전트가, 이 아이덴티티에 묶여, 이 리소스를 읽거나 씁니다 — 그리고 관측된 액세스가 허용한 범위에서 벗어날 때 최소 권한 드리프트를 함께 보여 줍니다.
실제 신호로부터 융합
네이티브 데이터베이스 감사, 클라우드 감사 로그, OpenTelemetry, eBPF, MCP 인트로스펙션을 하나의 그래프로 조율합니다 — 호스트의 진실을 도구 호출 의미론과 융합하여 에이전트에 귀속시킵니다.
자체 호스팅이며 벤더 중립적
액세스 관계와 거버넌스 기록은 여러분의 인프라에 남습니다. 벤더 종속도, 강제적인 외부 통신도 없습니다.
통합하되 경쟁하지 않습니다
유지하는 도구를 강화합니다
Olivares는 여러분의 스택 곁에 자리 잡아 그것을 더 낫게 만들도록 설계되었습니다. 무언가를 걷어내라고 요구하지 않습니다.
프록시와 트레이스 위에서
OpenTelemetry를 소비하며 LLM 프록시와 트레이싱 위에서 동작합니다 — 그것들이 본래 만들어 내도록 설계되지 않은 인프라 수준의 read/write 맵을 더해 줍니다.
호스트의 진실과 융합
eBPF와 네이티브 감사 스트림을 신호로 다루어 원천 호스트 활동을 도구 호출 의미론과 상관시킵니다. 그 결과 액세스가 단순한 프로세스가 아니라 특정 에이전트로 귀속됩니다.
컨트롤 타워를 풍부하게
읽기 전용 인벤토리, 보안 태세, 서명되고 변조 방지된 발견 사항을 (OCSF 같은 개방형 포맷으로) 여러분의 SIEM, ITSM, AI 컨트롤 타워에 푸시합니다 — 대체하는 것이 아니라 그라운드 트루스를 공급합니다.
Olivares가 무엇인가 — 그리고 무엇이 아닌가
무엇인가
- 에이전트를 인식하는 그라운드 트루스: 어떤 에이전트와 아이덴티티가 어떤 리소스를 건드렸는가, read인가 write인가, 그리고 드리프트까지.
- 자체 호스팅이며 벤더 중립적이고 AGPL-3.0 기반의 오픈 코어 — 완전한 제품을 여러분의 인프라 위에서.
- 기존 신호를 소비하고 기존 시스템에 공급하는 계층.
무엇이 아닌가
- 여러분의 LLM 트레이싱, 프록시, eBPF 도구, 컨트롤 타워를 대체하는 것이 아닙니다 — Olivares는 그 신호들을 소비하고 그 시스템들에 공급합니다.
- 해자가 아닙니다. 에이전트를 인식하는 상관관계 계층은 통합 접점이지, 우리가 소유를 주장하는 범주가 아닙니다.
- 인증이 아니며, 기본적으로 인라인 게이트도 아닙니다 — Olivares는 기본적으로 read 우선이며 탐지형입니다. 시행은 옵트인 방식이며 거버넌스로 관리됩니다.
우리의 위치 — 질문들
Olivares가 Langfuse나 우리의 LLM 트레이싱을 대체하나요?
아닙니다. LLM 가시성은 애플리케이션 수준에서 모델의 추론 과정 — 프롬프트, 트레이스, 토큰 비용 — 을 포착합니다. Olivares는 한 계층 아래, 인프라에서 동작합니다: 에이전트가 실제로 어떤 리소스를 읽었거나 썼는가. OpenTelemetry를 소비하므로 여러분의 트레이싱과 경쟁하지 않고 보완합니다.
우리의 SIEM이나 AI 컨트롤 타워를 대체하나요?
아닙니다. 컨트롤 타워와 SIEM은 주입되는 인벤토리와 발견 사항의 품질에만 좌우됩니다. Olivares는 이들을 풍부하게 하는 그라운드 트루스 소스입니다 — 읽기 전용 인벤토리, 보안 태세, 서명된 발견 사항을 개방형 포맷으로 Datadog, ServiceNow, Microsoft, 그리고 여러분의 SIEM에 푸시합니다.
런타임/eBPF 도구가 이미 이것을 보여 주지 않나요?
eBPF 도구는 호스트의 syscall, 프로세스, egress를 보지만, 이를 프로세스와 컨테이너 ID로만 귀속시킬 뿐, 이름이 붙은 에이전트와 아이덴티티에는 귀속시키지 못합니다. Olivares는 그 호스트의 진실을 도구 호출 의미론 및 에이전트별 아이덴티티와 융합하여, 액세스가 특정 에이전트로 귀속되게 합니다.
왜 자체 호스팅이어야 하나요?
액세스 관계와 거버넌스 기록은 민감하기 때문입니다. 자체 호스팅으로 운영하면 그것들은 여러분의 경계 안에 머뭅니다. Olivares는 강제적인 외부 통신을 하지 않으며, 완전한 에어갭 환경에서도 동작할 수 있습니다. 에어갭은 Olivares 자체 — 그 액세스 맵과 거버넌스 기록 — 에 적용됩니다. 호스팅 모델을 사용하는 에이전트는 여전히 각자 제공자의 API에 연결됩니다.
여러분의 스택에 빠진 계층을 더하세요
Olivares를 여러분 자신의 인프라에 배포하고, 이미 내보내고 있는 신호를 가리킨 다음, 에이전트를 인식하는 read/write 맵을 확보하세요 — 무엇 하나 대체하지 않고.