Zero Trust é o modelo de segurança que abandona a confiança implícita. Na definição do NIST, publicada na Special Publication 800-207 em agosto de 2020, trata-se de um conjunto de conceitos destinado a minimizar a incerteza na aplicação de decisões de acesso precisas, de menor privilégio e por requisição, em sistemas e serviços, diante de uma rede considerada comprometida. A ideia central é que a confiança nunca é concedida de forma implícita e precisa ser continuamente avaliada. A maioria das empresas ainda faz com a IA exatamente o oposto: aceita o código, o texto ou a análise como confiáveis porque vieram de uma ferramenta sofisticada. Aplicar Zero Trust à IA muda quatro coisas na prática: enviar apenas o dado estritamente necessário para a tarefa, validar todo output contra critério antes do aceite, saber quem solicitou o quê e manter registro capaz de reconstruir depois como qualquer resultado foi produzido. E há uma consequência que costuma incomodar: confiança em IA não se acumula. Dez saídas corretas não tornam a décima primeira confiável.

O hábito que a segurança abandonou e a IA reintroduziu

Lucio Figueiredo Matias, Head of Operations da CSP Tech, resume a origem do problema em uma observação simples: boa parte das organizações trata o output de um modelo como automaticamente confiável, só porque veio de uma ferramenta sofisticada. Aceita o código, aceita o texto, aceita a análise, sem processo claro de verificação. Como ele nota, isso é confiar por padrão, exatamente o hábito que a segurança de redes abandonou faz tempo.

A comparação é precisa e vale explorar por quê. Durante décadas, a segurança corporativa operou no modelo de castelo e fosso: uma vez dentro do perímetro, o usuário era tratado como confiável e ganhava acesso amplo. O modelo caiu não porque alguém teve uma ideia melhor, mas porque a experiência mostrou que ele falha exatamente onde importa. O NIST registra isso ao apontar que a segurança baseada em perímetro se mostrou insuficiente, já que uma vez que os atacantes o violam, o movimento lateral segue sem obstáculo.

A tese deste guia: a IA corporativa está repetindo hoje o erro que a segurança de redes levou uma década para desaprender, e com um agravante. No modelo de perímetro, ao menos a confiança era concedida a quem havia sido autenticado. Com IA, a confiança costuma ser concedida ao artefato produzido, sem que ninguém tenha sido autenticado ou verificado. É confiança por padrão em estado ainda mais puro do que aquele que o setor abandonou.

O que o NIST realmente estabelece

Vale ir ao documento em vez de repetir o slogan. A publicação define sete princípios que uma arquitetura Zero Trust deve seguir, reconhecendo que são um objetivo ideal e que nem todos serão implementados em forma pura em qualquer estratégia. Em resumo fiel: todas as fontes de dados e serviços de computação são considerados recursos; toda comunicação é protegida independentemente da localização de rede; o acesso a recursos individuais é concedido por sessão; o acesso é determinado por política dinâmica que considera o estado observável da identidade, da aplicação e do ativo que solicita, podendo incluir atributos comportamentais e ambientais; a organização monitora e mede a integridade e a postura de segurança de todos os ativos, já que nenhum ativo é confiável por natureza; toda autenticação e autorização é dinâmica e estritamente aplicada antes de o acesso ser permitido; e a organização coleta o máximo de informação possível sobre o estado atual dos ativos e comunicações e a usa para melhorar sua postura de segurança.

Dois detalhes do documento merecem atenção especial, porque são os que mais deslocam a conversa sobre IA. O primeiro está no terceiro princípio: a autenticação e a autorização a um recurso não concedem automaticamente acesso a outro recurso. O segundo está no sexto princípio, descrito como um ciclo constante de obter acesso, examinar e avaliar ameaças, adaptar e reavaliar continuamente a confiança na comunicação em andamento. Confiança, nesse modelo, não é um estado que se conquista uma vez. É uma avaliação que se refaz.

O que o NIST já dizia sobre agentes de software em 2020

Há uma seção do documento que quase ninguém cita e que envelheceu de forma notável. Ao tratar de ameaças associadas à arquitetura, o NIST dedica um item às entidades não-humanas usadas na administração do próprio ambiente, observando que inteligência artificial e outros agentes de software vêm sendo implantados para gerir questões de segurança e precisam interagir com os componentes de decisão e execução de política, às vezes no lugar de um administrador humano. O texto registra que a forma como esses componentes se autenticam era, à época, uma questão em aberto.

E então vem o trecho que impressiona pela antecipação. O documento aponta como risco associado a possibilidade de um atacante induzir ou coagir uma entidade não-humana a executar alguma tarefa que o atacante não tem privilégio para executar, observando que o agente de software pode ter uma barreira de autenticação mais baixa do que a de um usuário humano para realizar tarefas administrativas ou de segurança. E acrescenta que, se um atacante conseguir interagir com o agente, poderia teoricamente enganá-lo para obter acesso maior ou fazer com que executasse alguma tarefa em nome do atacante.

Um documento de arquitetura de segurança de rede publicado em agosto de 2020 descreveu, em termos gerais, o risco que hoje discutimos como sequestro de objetivo de agente. A conclusão prática não é que o problema é antigo, e sim que o repertório para tratá-lo já existe e não precisa ser inventado do zero.

Onde a analogia precisa ser estendida

Importar Zero Trust para IA sem ajuste seria intelectualmente preguiçoso, porque existe uma assimetria entre os dois casos que muda o desenho.

Na arquitetura de rede, o sujeito não confiável é quem pede acesso. O ponto de decisão avalia a requisição, e o ponto de aplicação libera ou bloqueia. O que atravessa depois é o recurso solicitado, que a empresa presume íntegro porque é dela.

Com IA, há dois sujeitos não confiáveis, e não um. A requisição que entra, que segue a mesma lógica de acesso, e o artefato que sai, que é produzido no momento e entra na empresa como se fosse trabalho de alguém confiável. Um código gerado, um texto gerado, uma análise gerada: nenhum deles existia antes, nenhum tem procedência, e todos serão usados como se tivessem. É por isso que aplicar Zero Trust à IA exige verificar o pedido **e** o resultado, enquanto na rede basta verificar o pedido.

Esta extensão da analogia é formulação editorial da CSP Tech. A publicação do NIST trata de decisões de acesso a recursos e não define requisitos de validação de artefatos produzidos por modelos generativos.

Os princípios traduzidos para o uso corporativo de IA

A coluna da esquerda resume princípios da publicação do NIST. As duas colunas seguintes são tradução editorial da CSP Tech para o contexto de uso corporativo de IA, e não constam do documento original.

Por que confiança em IA não se acumula

Este é o ponto que mais gera resistência em conversa com times técnicos, e é o mais importante. O comportamento humano diante de uma ferramenta que funciona bem é relaxar a verificação. É racional em quase todo contexto: se o fornecedor entregou certo dez vezes, o custo de conferir a décima primeira parece desperdício.

Com modelos generativos, essa heurística falha por uma razão específica. O acerto anterior não é evidência sobre a saída seguinte, porque cada geração é um evento independente que depende do contexto daquela requisição, e não da qualidade média histórica. É a mesma lógica que o terceiro princípio da publicação expressa para acesso, ao estabelecer que autorização a um recurso não concede automaticamente acesso a outro, e que o sexto expressa ao descrever a reavaliação contínua da confiança.

Traduzido para a operação: a verificação precisa ser barata o suficiente para acontecer sempre. Se validar exige leitura integral por um especialista, ela vai deixar de acontecer na terceira semana, e a política existirá apenas no documento. É por isso que critério verificável importa mais do que rigor declarado, tema que tratamos em artigo próprio deste blog sobre critérios de aceite.

Onde cada princípio se implementa

A decisão por requisição, no dado (consultoria Databricks)

O princípio de decidir por requisição, em vez de conceder confiança prévia por perfil, tem implementação direta na camada de dados. A documentação da Databricks descreve controles de granularidade fina aplicados no momento da consulta, como máscaras de coluna e filtros de linha, com a garantia de que o usuário não vê o valor da tabela base antes do tratamento. Isso é, literalmente, decisão tomada na requisição e não confiança herdada. Some-se a isso que o Unity Catalog aplica as mesmas permissões a pessoas, notebooks e modelos, o que faz o alcance de um agente ser definido pela mesma estrutura que governa o acesso humano, e não por uma credencial criada à parte para facilitar.

A identidade de quem solicitou, no fluxo de trabalho (consultoria Jira)

Zero Trust depende de identidade: a publicação é explícita ao colocar a identidade do sujeito no centro da decisão de acesso. Aplicado à IA corporativa, isso corresponde à prática que Lucio descreve como saber sempre quem solicitou o quê, para que exista responsabilidade clara sobre cada interação. Numa operação, a identidade da requisição vive onde o trabalho é pedido e registrado, com solicitante, aprovador quando aplicável e histórico de transições. Sem essa camada, o registro descreve o que a máquina fez e não quem pediu, o que basta para depuração técnica e não basta para responsabilidade.

A validação do artefato, no portão de aceite

A verificação do output é a extensão que a analogia exige e não tem equivalente na arquitetura de rede. Ela precisa de critério declarado antes da execução e de um ponto do fluxo onde nada avança sem passar. É o mesmo mecanismo que pipelines de dados já usam ao declarar regras que barram ou colocam em quarentena o registro que não atende ao esperado, aplicado agora à entrega assistida.

Por que isso exige competências que costumam estar separadas: o princípio vem da segurança da informação, o controle de acesso ao dado vive na plataforma de dados, a identidade da requisição vive no sistema de trabalho e a validação do artefato vive na engenharia de qualidade. Um programa conduzido só pela segurança produz política sem implementação; um conduzido só pela engenharia produz controle sem princípio. A CSP Tech atua nas camadas onde o princípio vira mecanismo, como especialistas Databricks no dado governado e com consultoria Jira, como Atlassian Gold Partner, na camada de solicitação e responsabilidade.

Quando o rigor completo é desproporcional

•     Uso pessoal de apoio, sem dado sensível e sem consequência de negócio. Redigir, traduzir ou resumir material público não justifica portão de validação. O rigor deve acompanhar a consequência, e a própria publicação do NIST reconhece que os princípios são um objetivo ideal, nem sempre implementável em forma pura.

•     Quando a verificação custa mais que o erro. Se validar consome mais esforço do que corrigir uma eventual falha de baixo impacto, a validação obrigatória vira desperdício. O cálculo muda quando o erro se propaga ou atinge pessoas.

•     Antes de existir inventário do uso. Aplicar princípios a um uso que ninguém mapeou produz política sobre o que se imagina. Mapear vem primeiro, e tratamos disso em artigo próprio sobre estruturar governança quando a adoção já aconteceu.

Perguntas frequentes

O que é Zero Trust?

É o modelo de segurança que elimina a confiança implícita baseada em localização de rede ou em autenticação prévia. Na definição da publicação do NIST sobre arquitetura Zero Trust, de agosto de 2020, trata-se de conceitos destinados a minimizar a incerteza na aplicação de decisões de acesso precisas, de menor privilégio e por requisição, diante de uma rede considerada comprometida. O documento estabelece sete princípios, entre eles o de que nenhum ativo é confiável por natureza e o de que autenticação e autorização são dinâmicas e aplicadas antes de o acesso ser permitido.

Como aplicar Zero Trust à inteligência artificial?

Traduzindo os princípios para quatro práticas: enviar apenas o dado e o contexto estritamente necessários para a tarefa, o que corresponde ao menor privilégio; validar todo output contra critério explícito antes do aceite; registrar quem solicitou o quê, para que exista responsabilidade sobre cada interação; e manter registro capaz de reconstruir como cada resultado foi produzido. A diferença em relação à arquitetura de rede é que na IA existem dois sujeitos a verificar, a requisição que entra e o artefato que sai.

Por que a confiança em um output de IA não se acumula?

Porque cada geração é um evento independente, que depende do contexto daquela requisição específica e não da qualidade média histórica do modelo. Dez saídas corretas não são evidência sobre a décima primeira. É a mesma lógica do princípio de acesso por sessão da publicação do NIST, segundo o qual a autorização a um recurso não concede automaticamente acesso a outro, e da descrição de reavaliação contínua da confiança ao longo da comunicação.

O modelo Zero Trust já previa riscos de agentes autônomos?

Em termos gerais, sim. Ao tratar de ameaças, a publicação do NIST de 2020 dedica um item às entidades não-humanas usadas na administração do ambiente e registra o risco de um atacante induzir ou coagir um agente de software a executar tarefa que o atacante não tem privilégio para executar, observando que o agente pode ter barreira de autenticação mais baixa que a de um humano. O documento também registrava como questão em aberto a forma de autenticar esses componentes.

Próximo passo

A pergunta com que Lucio encerra a reflexão dele serve de diagnóstico rápido para qualquer liderança: a sua política de IA tem algum princípio herdado do Zero Trust? Se a resposta é que a política trata de ferramentas permitidas e não de verificação por requisição, ela está no modelo que a segurança abandonou. Solicite uma avaliação de governança de IA com a CSP Tech e receba o mapa do seu caso: onde a confiança está sendo concedida por padrão, o que precisa ser verificado por requisição e onde cada princípio pode se apoiar no que a sua empresa já opera.

Autor: Guilherme Matos, estrategista de conteúdo e IA, certificado HubSpot, Google, Anthropic e Semrush. Com contribuição de Lucio Figueiredo Matias, Head of Operations da CSP Tech, cuja reflexão sobre Zero Trust aplicado à IA originou este artigo. Revisão técnica por especialistas de dados e Atlassian da CSP Tech (parceira Databricks, Atlassian Gold Partner, Microsoft Gold Partner, participante do Anthropic Partner Network, 34 anos de mercado).

Fontes (acesso ago/2026): Rose S, Borchert O, Mitchell S, Connelly S, “Zero Trust Architecture”, NIST Special Publication 800-207, National Institute of Standards and Technology, agosto de 2020, 59 páginas, consultada em texto integral em nvlpubs.nist.gov. Dela provêm a definição operativa de Zero Trust, os sete princípios de arquitetura, a observação sobre a insuficiência da defesa de perímetro diante do movimento lateral, o princípio de acesso por sessão e de que a autorização a um recurso não concede acesso a outro, a descrição da reavaliação contínua da confiança, e o item sobre entidades não-humanas na administração da arquitetura, incluindo o risco de indução ou coação de agente de software a executar tarefa não privilegiada e a observação sobre barreira de autenticação mais baixa. Todas essas afirmações são paráfrases fiéis do documento original, sem transposição de contexto. A tradução dos princípios para o uso corporativo de IA e a formulação sobre a assimetria entre verificar requisição e verificar artefato são editoriais da CSP Tech e estão assim identificadas no corpo do texto. Databricks Documentation (docs.databricks.com), quanto a máscaras de coluna e filtros de linha aplicados no momento da consulta e ao Unity Catalog com permissões aplicáveis a pessoas, notebooks e modelos. Atlassian, documentação de Jira quanto a tipos de item, campos e histórico de transições (atlassian.com). As observações atribuídas a Lucio Figueiredo Matias constituem relato de experiência profissional, identificado como tal. Este conteúdo trata de arquitetura e governança técnica e não constitui aconselhamento jurídico.