Segurança
A segurança, tal como o código a aplica.
Um agente tem acessos, age, engana-se. O NakamaOS trata-o como um funcionário de risco: só faz o que autorizar, cada ação fica registada e o que sai aguarda a sua validação. Eis as cinco regras, e o que as sustenta.
Trabalhamos em francês. A partir de Portugal, escreva-nos.
As cinco regras
-
1
Acesso mínimo
O que lê passa; o que escreve, envia ou publica espera por uma permissão.
O que isto impedeQue um texto lido pelo agente — uma página, um e-mail, um ticket — desencadeie uma escrita ou um envio que ninguém viu passar. O controlo de acessos deficiente continua a ser a primeira categoria de risco aplicacional registada, com agentes ou sem eles.
O detalhe técnico
Uma ferramenta que só lê — ler um ficheiro, procurar, fazer uma pesquisa na web — é executada sem pedir autorização. A pesquisa na web e a leitura de uma página passam, portanto, sem pedir autorização: é um caminho de saída conhecido; fechá-lo é um ticket aberto, e a data estará no jornal. Qualquer outra ferramenta para e espera por uma resposta: recusar, autorizar uma vez, para a sessão, ou sempre. Este controlo está no código que executa a chamada, não numa frase da instrução. A permissão dá-se ferramenta a ferramenta e vale para todos os agentes: uma persona é uma descrição de funções posta no início da mensagem, não um conjunto de direitos. No navegador, ler a página é livre; abrir uma página, clicar ou escrever pede permissão, porque uma página lida pode conter uma instrução. Um comando só passa sem pedir autorização se for simples: programa autorizado, nenhum metacaractere, nenhum interpretador, nenhum caminho fora da pasta de trabalho. A pasta das permissões, das chaves e da sessão está fechada aos agentes, em leitura como em escrita. Permissões distintas por persona seriam o passo seguinte; diremos aqui no dia em que for dado.
Referências: OWASP Top 10:2025; CWE-284: Improper Access Control; OWASP Top 10 for Agentic Applications
-
2
Revisão
O que um agente produz é validado antes de entrar em produção: código, resposta a cliente, documento.
O que isto impedeQue um defeito introduzido por um agente — ou uma dependência introduzida por um agente — chegue a produção sem que ninguém lhe tenha pegado.
O detalhe técnico
Para um agente de código, a saída é um pull request com o seu relatório, validado antes do merge: a partir do ramo estável, nada entra sem validação linha a linha. Esta regra está escrita nas instruções do repositório e é mantida pela validação, não pelo motor. Uma resposta a um cliente, um artigo, um documento passam pela mesma porta, e o que é publicado tem o nome de quem redigiu e de quem validou. As alterações que tocam a autenticação, os direitos ou os dados têm prioridade na validação, seja qual for o seu tamanho. Uma dependência acrescentada por um agente é fixada a uma versão e justificada no pedido: um agente que instala uma biblioteca age sobre a sua cadeia de abastecimento.
Referências: Secure Software Development Framework 1.1 (SP 800-218); SLSA — Supply-chain Levels for Software Artifacts, v1.1; OWASP Top 10:2025
-
3
Registo
Cada ação fica rastreada, consultável, copiável tal como está.
O que isto impedeQue um incidente seja constatado sem se poder dizer o que foi tocado, por quem e quando — e que seja preciso acreditar na palavra do agente.
O detalhe técnico
Cada conversa é registada acontecimento a acontecimento: as mensagens, as chamadas de ferramentas, os pedidos de permissão e as respostas. As missões e as suas falhas vão para um registo de atividade, e cada classificação de sensibilidade para um registo de encaminhamento. Estes registos são escritos pelo motor que executa a chamada, não pelo agente: um agente não conta a sua ação, sofre-a. As recusas contam tanto como os sucessos — uma permissão recusada deixa rasto, e são essas linhas que se releem primeiro. São ficheiros de texto, uma linha por acontecimento, legíveis e copiáveis tal como estão — não um ecrã que seja preciso pedir-nos.
Referências: OWASP Top 10:2025; Diretiva (UE) 2022/2555 (NIS2); MITRE ATT&CK
-
4
O nível confidencial
No nível confidencial, as chamadas secundárias seguem para um modelo local; a conversa principal fica no modelo escolhido.
O que isto impedeA fuga de informação sensível pelo caminho mais banal: um documento vertido num contexto que segue para um terceiro.
O detalhe técnico
O dado é classificado pela sua origem — a pasta, a etiqueta do documento — ou por um nível escolhido explicitamente. O encaminhamento lê esse nível: no nível confidencial, as chamadas secundárias — a classificação, o trabalho delegado a um segundo modelo — seguem para um modelo que corre na máquina. Cada decisão de encaminhamento fica escrita num registo consultável: para cada turno, o nível aplicado e a razão. O que esta regra não cobre, e preferimos dizê-lo: a conversa principal segue o modelo escolhido para a instalação, sob o seu contrato e com a sua chave, e o encaminhamento pode ser desativado nas definições — o registo mostra então que o está; na Nakama, ainda está. O nível confidencial só diz respeito às chamadas secundárias: a página «Onde vão os seus dados» nomeia cada fluxo.
Referências: OWASP Top 10 for LLM Applications; Recomendações de segurança para um sistema de IA generativa; Regulamento (UE) 2022/2554 (DORA)
-
5
Validado antes de sair
O que envia, publica, paga ou funde espera uma validação. O agente prepara.
O que isto impedeQue uma sequência de chamadas automáticas produza um compromisso que ninguém quis, e que a autoridade de um agente seja usada por outro.
O detalhe técnico
As ações que comprometem — enviar, publicar, pagar, responder sobre um contrato — param no código e esperam por uma pessoa: esse ponto de passagem está no motor, não na instrução. O merge de um pull request é assegurado pela regra escrita no repositório e pela validação, não pelo motor. Uma pessoa pode conceder de uma vez por todas uma permissão a uma ferramenta precisa — está no seu direito, e fica escrito num ficheiro que se pode reler. O que continua impossível é um agente conceder-se essa permissão a si próprio: o ficheiro das permissões está-lhe fechado pelo código, porque uma única escrita lá dentro bastaria para deitar abaixo todo o resto. Uma missão programada prepara e não expede; tem um gatilho, um perímetro de ferramentas e um prazo ao fim do qual para.
Referências: Regulamento (UE) 2024/1689 relativo à inteligência artificial; AI Risk Management Framework 1.0 (NIST AI 100-1); CWE-441: Unintended Proxy or Intermediary («Confused Deputy»)
O modelo de ameaça de um agente
Um agente não é mais um programa. Tem acessos: tokens, uma caixa de correio, um repositório. Tem ferramentas que agem — escrever, enviar, chamar, executar. Tem uma memória que sobrevive à tarefa. E decide sozinho a ordem das operações. É a definição de um funcionário, sem o contrato de trabalho nem o discernimento.
O que isto implica cabe numa frase: o controlo põe-se no código, não na instrução. O modelo pode ser enganado; o perímetro, esse, não negoceia.
| Risco | O que isto dá na prática | O que lhe opomos |
|---|---|---|
| Injeção de instruções | Um texto lido pelo agente — ticket, página, correio eletrónico, ficheiro — contém uma ordem. O agente muda de objetivo a meio da tarefa. | Toda a entrada é um dado, nunca uma ordem. No navegador, ler é livre; abrir, clicar ou escrever pede permissão. Qualquer ação que escreva ou envie para e espera por uma pessoa. |
| Envenenamento dos dados e da memória | Uma informação falsa entra na memória ou na base de conhecimento, e repete-se em cada tarefa seguinte. | Memória com escrita controlada, fontes datadas e atribuídas, expiração, validação humana do que serve de referência. |
| Fuga pela ferramenta | Uma ferramenta legítima copia um excerto sensível para onde não devia: um registo, um ticket, uma mensagem, um contexto enviado para fora. | Classificação na origem; no nível confidencial, as chamadas secundárias num modelo local; registo do encaminhamento; nenhum segredo no contexto do modelo. |
| Confusão de delegado | Um agente executa para um requerente uma ação que esse requerente não tinha o direito de fazer — porque o agente, esse, tem-no. | As permissões são as que a pessoa deu, ferramenta a ferramenta, e nenhum agente as pode conceder a si próprio. Em modo de resposta direta, um agente não pode lançar outro: a chamada é recusada pelo código. |
| Saída do perímetro | Uma cadeia de chamadas que começa dentro do perímetro acaba fora dele: um envio, uma compra, uma escrita não previstos. | Permissão por omissão sobre tudo o que escreve ou envia; para uma missão, um conjunto reduzido de ferramentas, um prazo de 8 minutos por omissão e nenhuma permissão que possa obter; validação sobre o que compromete. |
| Cadeia de abastecimento | Uma dependência, um modelo ou um servidor de ferramentas de terceiros muda debaixo dos pés do agente. | Versões fixadas, proveniência verificada dos artefactos, qualquer adição passa por um pedido validado, nenhuma instalação em tempo de execução. |
| Ação irreversível sem humano | Um pagamento que partiu, código fundido, uma mensagem publicada que ninguém validou. | Ponto de passagem humano no código para o que envia, publica ou paga; para o merge, a regra escrita no repositório e a validação; ficheiro das permissões fechado aos agentes, registo de cada conversa. |
Ler a análise completa
O que lhe acontece não tem nada de exótico. Lê um ticket, uma página, um correio eletrónico, um ficheiro — e esse texto contém uma instrução escrita para ele. Chama uma ferramenta que faz um pouco mais do que o nome anuncia. Encadeia dez chamadas, e a décima sai do perímetro que as nove primeiras respeitavam. Nenhuma destas três situações pressupõe um atacante sofisticado. Basta escrever num sítio que o agente leia.
Daí a primeira consequência: uma instrução não é um controlo. O modelo recebe a instrução do sistema e os dados que lê pelo mesmo canal, texto. Tudo o que assenta em «o agente tem instruções para não…» é uma política de segurança escrita no campo mais fácil de influenciar. Se uma proibição conta, é aplicada pelo código que executa a chamada, fora do modelo.
A segunda dobra é a identidade. Um agente age por alguém, com direitos que não são os dessa pessoa. Assim que um agente chama outro, a pergunta passa a ser: de quem vêm os direitos da chamada? A resposta tem de ser a mesma em todo o lado — de quem pediu na origem. É o caso clássico do delegado confuso, e não fica novo por haver um modelo pelo meio.
A terceira é a memória. O que um agente retém influencia-o muito depois da tarefa em que o leu. Um dado falso ou hostil escrito uma vez repete-se em cada tarefa seguinte, sem que nenhum alerta dispare. Trata-se portanto a memória como uma base de dados: quem escreve, o que é datado, o que expira, o que se relê.
O que nunca fazemos
- Nomear um cliente, colar código de um cliente, publicar um dado pessoal.
- Publicar o que quer que ajude um atacante: nem modo operatório, nem falha por corrigir, nem detalhe de arquitetura explorável.
- Deixar um agente enviar, publicar, pagar ou fundir sem validação.
- Deixar um agente ler ou alterar as suas próprias permissões, ou pôr um segredo em claro no seu contexto.
- Publicar um número sem a sua fonte, ou calar um incidente constatado.
Na sua empresa: instalado, configurado, verificado todos os meses
A versão instalada na sua empresa é o NakamaOS completo, posto à prova todos os dias na Nakama, configurado por um especialista em segurança aplicacional para que os agentes só façam o que autoriza, e depois verificado todos os meses.
Todos os meses: a versão estável, os testes repetidos na sua versão, a configuração controlada — catálogo de ferramentas, autorizações permanentes, conetores, cifragem do disco —, o diff das instruções e das missões. O boletim é preparado pelos agentes e validado; fica seu.
Instalamos uma empresa de cada vez, pela ordem da lista de espera.
Cada componente do NakamaOS é fixado e verificado a cada versão. Se for publicada uma falha, uma instrução de corte sai num dia útil, e a correção nunca é faturada à parte.
Três perguntas de um CISO
Como impedem um agente de fazer sair os nossos dados?
Com três barreiras, por esta ordem. O dado é classificado pela sua origem, por isso o agente não decide ele próprio o seu nível. O encaminhamento lê esse nível: no nível confidencial, as chamadas secundárias seguem para um modelo que corre na máquina; a conversa principal fica no modelo escolhido, sob o seu contrato e com a sua chave. E tudo o que escreve ou envia pede uma permissão, que um agente não pode conceder a si próprio. Cada decisão de encaminhamento fica escrita num registo, o que permite verificar depois, linha a linha, que chamada seguiu para onde. A resposta honesta cabe numa frase: o nível confidencial só diz respeito às chamadas secundárias, e a página «Onde vão os seus dados» nomeia cada fluxo e cada subcontratante.
O que acontece quando um agente se engana?
Engana-se, está previsto. O que produz não é produção: é uma proposta — um pull request, um rascunho, um ticket qualificado. O erro é apanhado na validação, e a validação é uma pessoa, não um segundo agente. Se passar mesmo assim, o registo diz o que foi tocado, quando e com que ferramenta, o que reduz o perímetro da correção a minutos em vez de dias. O relatório do mês conta o que foi recusado na validação, quando é contado (pull requests recusados), e diz porquê.
O que nos dão para a nossa própria auditoria?
Os registos primeiro: cada conversa, acontecimento a acontecimento, com data e hora, escrita pelo motor e não pelo agente, entregue sob a forma de ficheiros que o seu auditor relê com as suas próprias ferramentas. Depois, o ficheiro das permissões tal como é efetivamente aplicado, ferramenta a ferramenta, e o rasto dos encaminhamentos, que mostra que chamada secundária seguiu para que modelo. Depois, a cadeia de entrega: quem propôs, quem validou, quem fundiu, para cada alteração. Por fim, o dossiê de instalação, o boletim do mês, e a correspondência entre as nossas regras e os quadros que o seu auditor usa. Não fornecemos um certificado; fornecemos com que verificar.
Comunicar uma falha
Uma falha no NakamaOS, neste site ou no nosso serviço online de cibersegurança comunica-se a security@nakamaos.ai; o endereço está em /.well-known/security.txt. Uma resposta escrita, preparada pelos nossos agentes e validada; para uma instalação num cliente, uma instrução de corte num dia útil.
O que daria um modo operatório a um atacante nunca é publicado: uma falha é descrita pela sua classe, uma vez corrigida, com a data da correção.
As referências
Os quadros em que estas regras assentam, e o que cada um serve para decidir. As ligações vão dar aos seus autores, não a nós.
- 1
OWASP Top 10:2025
OWASP Foundation, 2025
A lista de referência dos riscos aplicacionais: o controlo de acessos continua em primeiro, a cadeia de abastecimento entra em terceiro.
- 2
OWASP Top 10 for LLM Applications
OWASP Gen AI Security Project, 2026
A taxonomia dos riscos próprios das aplicações com modelos de linguagem: injeção de instruções, divulgação de informação sensível, envenenamento.
- 3
OWASP Top 10 for Agentic Applications
OWASP Gen AI Security Project, 2026
O quadro próprio dos agentes autónomos: planeamento, uso das ferramentas, identidade, memória, comunicação entre agentes.
- 4
MITRE ATT&CK
MITRE, atualizado
A grelha pela qual alinhamos o que um registo deve permitir detetar e contar depois de um incidente.
- 5
MITRE ATLAS
MITRE, atualizado
O equivalente do ATT&CK para os sistemas de IA: as técnicas realmente observadas contra modelos e as suas cadeias de ferramentas.
- 6
AI Risk Management Framework 1.0 (NIST AI 100-1)
NIST, 2023
O quadro de gestão do risco de IA em que se inscreve o nosso ponto de passagem humano.
- 7
Secure Software Development Framework 1.1 (SP 800-218)
NIST, 2022
As práticas de desenvolvimento seguro a que se liga a revisão obrigatória antes da entrada em produção.
- 8
CWE-284: Improper Access Control
MITRE, atualizado
A designação precisa do defeito que a regra «acesso mínimo» procura tornar impossível.
- 9
CWE-1427: Improper Neutralization of Input Used for LLM Prompting
MITRE, atualizado
A formulação normalizada da injeção de instruções, ligada à família das injeções e não a uma curiosidade da IA.
- 10
CWE-441: Unintended Proxy or Intermediary («Confused Deputy»)
MITRE, atualizado
O nome do problema de delegação que reaparece assim que um agente chama outro.
- 11
SLSA — Supply-chain Levels for Software Artifacts, v1.1
OpenSSF, 2025
Os níveis de proveniência pelos quais se mede que um artefacto vem mesmo da cadeia anunciada.
- 12
Regulamento (UE) 2024/1689 relativo à inteligência artificial
União Europeia, 2024
O texto que funda a obrigação de controlo humano e a classificação das utilizações de alto risco.
- 13
Regulamento (UE) 2024/2847 (Cyber Resilience Act)
União Europeia, 2024
Os requisitos de segurança do produto e de gestão de vulnerabilidades que se aplicarão ao software que entregamos.
- 14
Diretiva (UE) 2022/2555 (NIS2)
União Europeia, 2022
As obrigações de gestão do risco e de notificação de incidentes que o registo deve permitir cumprir.
- 15
Regulamento (UE) 2022/2554 (DORA)
União Europeia, 2022
O quadro que os nossos clientes do setor financeiro nos opõem quanto ao risco ligado a prestadores informáticos terceiros.
- 16
ISO/IEC 27001:2022 — Sistemas de gestão da segurança da informação
ISO / IEC, 2022
A grelha de leitura de um auditor sobre o registo, a gestão de acessos e a prova documental.
- 17
ISO/IEC 42001:2023 — Sistema de gestão da inteligência artificial
ISO / IEC, 2023
A norma com que comparamos a nossa organização, sem a reivindicar.
- 18
Recomendações de segurança para um sistema de IA generativa
ANSSI, 2024
A referência francesa sobre a compartimentação dos ambientes de inferência e a segurança de uma arquitetura de IA generativa.
Os seus agentes passariam neste exame?
A auditoria de IA e agentes começa por aí: que acessos têm hoje as suas ferramentas de IA, quem valida o que produzem, e o que acontece quando se enganam. Uma resposta escrita, preparada pelos nossos agentes e validada.