A Olivares AI fica no caminho do pedido entre um agente e os seus dados?

Não. O plano de controlo é detetivo por defeito — ingere registos, OpenTelemetry e auditoria nativa fora de banda e constrói o mapa de acessos sem intercetar o tráfego. Um coletor que falhe não pode deitar a produção abaixo. Quando o produto pode agir sobre um achado, fá-lo com negação por defeito e a pedido, nunca como um executor genérico.

O plano de controlo pode correr air-gapped?

O plano de controlo da Olivares — governação, observação, o registo de auditoria — pode correr totalmente self-hosted e air-gapped na sua própria infraestrutura. Isso é distinto dos modelos que governa; um modelo alojado como o Claude nunca está air-gapped, e apenas os modelos self-hosted (vLLM, Ollama) correm offline. A Olivares governa o acesso em qualquer dos casos.

A Olivares AI está certificada para SOC 2 ou para o EU AI Act?

Não. O módulo de conformidade é concebido em direção a esses referenciais e produz evidência à prova de adulteração mapeada para os respetivos controlos, mas a Olivares AI não detém qualquer certificação e não reivindicamos nenhuma. Trate a evidência como entrada para a sua própria avaliação, não como uma atestação.

Já temos um gateway de LLM e uma stack de observabilidade. Porquê acrescentar isto?

Esses dizem-lhe o que foi invocado e quanto custou. Não lhe dão um mapa de acessos de leitura/escrita tipado em todo o seu património de dados, uma comparação entre permitido e observado, nem uma barreira de aprovação com negação por defeito, com um mínimo de duplo controlo e um kill-switch a nível de todo o património. A Olivares integra-se a par deles em vez de os substituir — consulte /compare.

Veja e governe os agentes de IA que já existem no seu património tecnológico

O problema: não pode governar aquilo que não consegue ver

Os agentes já lá estão. Um assistente de programação com uma credencial de base de dados, um serviço de RAG interno que silenciosamente ganhou acesso de escrita a um object store, uma tarefa agendada que invoca um servidor MCP que ninguém registou. Foram aprovisionados por equipas a avançar depressa, e a organização de segurança herda o raio de impacto sem nunca ter visto o mapa. Os analistas têm um nome para esta forma — proliferação de agentes — e a lacuna de governação por baixo dela é mensurável.

Das organizações que sofreram uma violação relacionada com IA, cerca de 97% não tinham controlos de acesso a IA adequados (IBM Cost of a Data Breach 2025, Ponemon). Isto não é uma história de maturidade de ferramentas; é a ausência de uma superfície de controlo. Ao mesmo tempo, a Gartner espera que mais de 40% dos projetos de IA agêntica sejam cancelados até ao final de 2027 e projeta que os “agentes guardiões” representem 10–15% do mercado de IA agêntica até 2030 (Gartner, imprensa) — o mercado já está a incorporar o facto de que agentes não governados não sobrevivem ao contacto com uma revisão de segurança a sério.

O padrão é mais amplo do que as equipas de segurança. Num estudo preliminar, ainda não revisto por pares, cerca de 95% dos pilotos de GenAI não mostraram impacto mensurável nos resultados financeiros, e as ferramentas adquiridas externamente tiveram sucesso cerca de duas vezes mais do que os desenvolvimentos internos (MIT “GenAI Divide”, projeto NANDA, via Fortune, ago. 2025 — preliminar). Seja qual for a causa, um património cheio de agentes que ninguém consegue justificar é exatamente a condição em que tanto o risco de violação como o risco de pilotos desperdiçados se agravam.

Isto mapeia de forma limpa no enquadramento AI TRiSM — gestão de confiança, risco e segurança para IA — onde a governação e a inspeção em tempo de execução se situam como camadas distintas. A Olivares AI é construída para ser a camada que descobre, observa e governa o acesso dos agentes, e é honesta sobre onde isso termina.

O que a Olivares AI dá a um líder de segurança

Um mapa de acessos de leitura/escrita tipado como superfície de controlo

O mapa de acessos modela cada agente como um nó e cada recurso que ele pode alcançar — bases de dados, object stores, servidores MCP, APIs, filas — como um nó, com cada aresta tipada R (leitura) ou RW (leitura-escrita). Essa tipagem R-versus-RW é o ponto central: o desvio do least-privilege e o raio de impacto de um incidente são ambos funções do acesso de escrita, não da mera conectividade, e uma lista plana de “tem acesso” esconde precisamente isso. Isto é reconhecimento para defensores — o mesmo mapa que um atacante quereria, construído para quem defende o património.

Ler o grafo completo é deliberadamente uma ação privilegiada, restrita ao tenant e totalmente auditada, porque um mapa completo daquilo que cada agente pode tocar é, em si mesmo, um guia de reconhecimento. O mapa guarda a relação — origem, recurso, R/RW, fonte, confiança, marcas temporais — e nunca os payloads, corpos de SQL, segredos ou PII que circularam pela aresta. Aquilo que não é guardado não pode vazar.

Permitido vs observado: a comparação que se torna um achado

Cada aresta carrega dois factos independentes: se o acesso é permitido (uma concessão ou política o autoriza) e se foi observado (a telemetria e a auditoria nativa mostram-no a acontecer). A diferença entre essas duas camadas é o sinal de controlo:

Acesso inesperado — observado, mas não permitido. Um agente tocou em algo que nenhuma concessão cobre. Este é o cabeçalho relevante para a segurança.
Concessões não utilizadas — permitidas, mas nunca observadas. A sua lista concreta de limpeza de least-privilege, não um lembrete vago de “reveja o seu IAM”.

A comparação é deliberadamente conservadora. Onde a plataforma ainda não consegue ligar com firmeza uma credencial atuante ao agente para o qual a sua concessão foi escrita, a aresta é marcada como reconciliation_pending — incerteza honesta, nunca uma violação fabricada. Consulte permitido vs observado para o contrato de reconciliação completo.

Fidelidade que se recusa a fingir

Uma ferramenta de segurança que exagera o que sabe é pior do que nenhuma. Cada aresta carrega dois eixos honestos. A cobertura da classificação R/RW é escalonada em clean | lossy | opaque — clean onde a auditoria nativa a torna inequívoca (Postgres via pgAudit, object storage via CloudTrail, os data warehouses, mais uma salvaguarda eBPF ao nível do kernel), descendo até stores opaque (Redis, SQLite, D1) onde o modo é marcado como unknown em vez de adivinhado. A atribuição é firm onde um sinal de identidade por agente resolve o acesso a um único agente, e approximate onde uma conta de serviço partilhada esconde qual agente atuou. Uma aresta clean/firm e uma mal vista nunca são apresentadas como igualmente certas — leia o modelo de fidelidade.

Governação com negação por defeito, duplo controlo e um kill-switch

A governação é primeiro-leitura e com negação por defeito. O núcleo de autorização é deny-by-default e restrito ao tenant, fechando por construção as classes de confused-deputy e de IDOR. Qualquer política baseada em atributos que ligue por cima só pode restringir ainda mais — a composição é uma interseção, pelo que uma política nunca pode alargar uma concessão.

Onde o produto controla uma ação, o ciclo é: uma superfície apresenta-se (um desvio, um achado) → um operador autorizado decide → a decisão é registada. O motor de aprovação impõe a separação de funções (quem pede não pode decidir o seu próprio pedido) e uma salvaguarda de decisor duplicado, ancorada numa identidade humana estável — um token de sistema não tem identidade e não pode decidir. Uma ação critical carrega um mínimo obrigatório de duas pessoas derivado da NIST SP 800-53 AC-3(2), imposto tanto na criação como re-derivado na decisão, de modo que nem mesmo uma política de operador que baixe o escalão consiga tornar uma ação crítica executável por uma só pessoa. Existe uma válvula de break-glass auditada para o incidente das 03:00 — ruidosa por construção, com elevação por hardware, limitada no tempo e forçada a revisão posterior.

O kill-switch é a barreira de negação a nível de todo o património. Acioná-lo é deliberadamente barato (escalão de admin, um motivo, sem quórum), porque uma paragem que espera por consenso não é uma paragem; cada barreira de atuação governada consulta a linha de paragem em tempo real e falha fechada perante um erro de leitura. A reativação nunca é unilateral — está dependente de uma nova aprovação de duplo controlo e não tem caminho de break-glass, porque “o património permanece parado” é o estado seguro.

Evidência à prova de adulteração

Cada ação mutável é anexada a um registo de auditoria apenas de adição, encadeado por hash na mesma transação que a alteração, com o ator real; as leituras sensíveis auto-auditam-se numa escrita confirmada. Reescrever o histórico é detetável, e o registo nunca contém PII. O módulo de conformidade mapeia essa evidência em tempo de execução para os referenciais de controlo, de modo que uma avaliação seja alimentada pela realidade observada em vez de um questionário.

O que isto é — e o que não é

Self-hosted e soberano. O plano de controlo corre na sua própria infraestrutura e pode ser air-gapped. A Olivares AI é uma plataforma aberta e self-hostable (AGPL-3.0). Consulte o modelo de segurança e a arquitetura.
Detetivo por defeito; com negação por defeito onde atua. Observa e governa de forma ampla; não atua de forma ampla. Onde pode tomar uma ação, essa superfície é em tempo real, a pedido ou uma costura declarada — e o catálogo de módulos indica qual. Uma ausência de imposição é, normalmente, intencional.
Pré-1.0, com um catálogo publicado de 23 módulos (cerca de 20 ligados hoje). Nem tudo está em produção; dizemos o que é o quê em vez de dar a entender uma cobertura total.
O air-gap aplica-se ao plano de controlo da Olivares, não aos seus modelos. Um modelo alojado como o Claude nunca está air-gapped; apenas os modelos self-hosted (vLLM, Ollama) correm offline. A Olivares governa o acesso em qualquer dos casos.
Não certificado. A Olivares AI é concebida em direção a SOC 2, ISO/IEC 42001 e o EU AI Act; não detém qualquer certificação e não reivindicamos nenhuma.

Os patrimónios do ensino superior e da investigação têm uma versão paralela deste problema — uso amplo de IA por docentes e funcionários enquanto a governação formal de IA e a cobertura de utilização aceitável ficam para trás (investigação EDUCAUSE, 2025). Se esse for o seu contexto, consulte ensino superior; as equipas de plataforma que gerem a infraestrutura devem começar em engenharia de plataforma.

Para onde ir a seguir

Mapa de acessos — o grafo R/RW tipado e a sobreposição permitido-versus-observado sobre uma captura real.
Kill-switch — a barreira de negação a nível de todo o património, em termos de produto.
Conformidade — evidência à prova de adulteração mapeada para os referenciais de controlo.
Conceitos de governação — primeiro-leitura, negação por defeito, duplo controlo.
Comparar — como a Olivares se posiciona a par de gateways, observabilidade e control towers.
Comece já — veja o mapa num património de demonstração.