Comparar
Onde a Olivares encaixa — integramos, não substituímos
A sua stack já traça os prompts, vigia o host e inventaria o seu património. O que nenhuma camada isolada responde é qual o agente — associado a que identidade — que efetivamente leu ou escreveu em que recurso. É essa a lacuna que a Olivares preenche, e fá-lo consumindo e enriquecendo aquilo que já tem em execução.
O panorama
O que cada camada vê — e onde fica pelo caminho
Cada uma destas categorias faz bem o seu trabalho. Nenhuma delas, por si só, atribui uma leitura ou escrita real na sua infraestrutura a um agente de IA concreto. A Olivares é a correlação ciente dos agentes que se situa entre elas.
Observabilidade de LLM
p. ex. LiteLLM, Langfuse, Phoenix
- Vê
- Prompts, traces, latência e custo de tokens — o raciocínio do modelo, ao nível da aplicação.
- Onde fica pelo caminho
- Não o host: não qual a base de dados, o store ou a API reais que o agente efetivamente leu ou escreveu.
Host e runtime
p. ex. ferramentas eBPF — Falco, Tetragon
- Vê
- Syscalls, processos e tráfego de rede de saída no host, em tempo real.
- Onde fica pelo caminho
- Sem atribuição ciente dos agentes: um processo e um ID de contentor, não um agente e uma identidade com nome.
Torres de controlo de IA
p. ex. Datadog AI Agents Console, Microsoft Agent 365, ServiceNow AI Control Tower
- Vê
- Inventário do património, postura e fluxo de trabalho nas ferramentas que a sua organização já utiliza.
- Onde fica pelo caminho
- Só são tão boas quanto o inventário que recebem — precisam de uma fonte de ground truth por baixo.
Onde a Olivares encaixa
A camada de leitura/escrita ciente dos agentes
A Olivares responde à pergunta que as outras deixam em aberto, e mantém a resposta dentro do seu perímetro.
Quem tocou em quê, leitura versus escrita
Correlaciona os sinais que já emite numa única relação: este agente, associado a esta identidade, lê ou escreve neste recurso — com desvio de least-privilege quando o acesso observado diverge daquilo que autorizou.
Fundida a partir de sinais reais
A auditoria nativa da base de dados, os registos de auditoria da cloud, o OpenTelemetry, o eBPF e a introspeção de MCP são reconciliados num único grafo — a verdade do host fundida com a semântica das chamadas de ferramentas, atribuída a um agente.
Self-hosted e independente do fornecedor
As relações de acesso e o registo de governação permanecem na sua infraestrutura. Sem aprisionamento a fornecedores, sem chamadas para casa obrigatórias.
Integrar, não competir
Reforça as ferramentas que mantém
A Olivares foi concebida para conviver com a sua stack e torná-la melhor, não para lhe pedir que arranque nada.
Acima do seu proxy e dos seus traces
Consome OpenTelemetry e funciona acima de um proxy de LLM e do seu tracing — acrescentando o mapa de leitura/escrita ao nível da infraestrutura que nunca foram concebidos para o fazer.
Fundida com a verdade do host
Trata os fluxos de eBPF e de auditoria nativa como sinais, correlacionando a atividade bruta do host com a semântica das chamadas de ferramentas, de modo a que um acesso fique associado a um agente, e não apenas a um processo.
Enriquecendo a sua torre de controlo
Envia inventário só de leitura, postura e conclusões assinadas e à prova de adulteração (em formatos abertos como o OCSF) para o seu SIEM, ITSM e torre de controlo de IA — alimentando-os com ground truth, em vez de os substituir.
O que a Olivares é — e o que não é
O que é
- O ground truth ciente dos agentes: que agente e identidade tocaram em que recurso, leitura versus escrita, com desvio.
- Self-hosted, independente do fornecedor e open-core sob a AGPL-3.0 — o produto completo, na sua infraestrutura.
- Uma camada que consome os seus sinais existentes e alimenta os seus sistemas existentes.
O que não é
- Um substituto do seu tracing de LLM, do seu proxy, das suas ferramentas eBPF ou da sua torre de controlo — consome esses sinais e alimenta esses sistemas.
- Um fosso competitivo. A camada de correlação ciente dos agentes é uma costura de integração, não uma categoria que afirmamos possuir.
- Uma certificação, nem uma barreira de acesso inline por predefinição — a Olivares é, por predefinição, orientada à leitura e detetiva; a imposição é opcional e governada.
Onde encaixa — perguntas
A Olivares substitui o Langfuse ou o nosso tracing de LLM?
Não. A observabilidade de LLM capta o raciocínio do modelo — prompts, traces, custo de tokens — ao nível da aplicação. A Olivares atua uma camada abaixo, na infraestrutura: que recurso um agente efetivamente leu ou escreveu. Consome OpenTelemetry, pelo que complementa o seu tracing em vez de competir com ele.
Substitui o nosso SIEM ou a nossa torre de controlo de IA?
Não. As torres de controlo e os SIEM só são tão bons quanto o inventário e as conclusões que recebem. A Olivares é uma fonte de ground truth que os enriquece — envia inventário só de leitura, postura e conclusões assinadas para o Datadog, o ServiceNow, a Microsoft e o seu SIEM em formatos abertos.
As ferramentas de runtime/eBPF já não mostram isto?
As ferramentas eBPF veem syscalls, processos e tráfego de saída no host, mas atribuem-nos a um processo e a um contentor — não a um agente e uma identidade com nome. A Olivares funde essa verdade do host com a semântica das chamadas de ferramentas e a identidade por agente, de modo a que um acesso fique associado a um agente concreto.
Porque é que tem de ser self-hosted?
Porque as relações de acesso e o registo de governação são sensíveis. Quando implantada em self-hosted, permanecem dentro do seu perímetro; a Olivares não faz quaisquer chamadas para casa obrigatórias e pode funcionar totalmente air-gapped. O air-gap abrange a própria Olivares — o seu mapa de acessos e o seu registo de governação; os agentes que utilizam modelos alojados continuam a alcançar a API do respetivo fornecedor.
Acrescente a camada que falta à sua stack
Implemente a Olivares na sua própria infraestrutura, aponte-a aos sinais que já emite e obtenha o mapa de leitura/escrita ciente dos agentes — sem substituir o que quer que seja.