Cabeçalho penumbroso

Segurança de IA agêntica na produção - segurança de MCP, envenenamento de memória, uso indevido de ferramentas e o novo limite de execução

O que mudou: os agentes não são mais chatbots

Os aplicativos de agente não se limitam a responder perguntas. Eles plano, recuperar, lembrare executar ações por meio de ferramentas. Quando o seu sistema puder chamar um servidor MCP que possa tocar em arquivos, repositórios, tíquetes, APIs de nuvem ou dados internos, você terá criado uma plataforma de automação com um planejador probabilístico no centro.

Essa mudança é exatamente o motivo pelo qual a OWASP Iniciativa de Segurança Agêntica existe: forçar uma visão que prioriza o modelo de ameaça dos fluxos de trabalho de várias etapas, e não apenas os resultados do modelo. (Projeto de segurança de IA da OWASP Gen)

A AWS enquadra a mesma realidade a partir de uma perspectiva de implantação: os sistemas agênticos criam novos desafios de segurança que exigem escopo, controles entre dimensões e gerenciamento explícito de riscos. (Amazon Web Services, Inc.)

E a advertência do NCSC do Reino Unido é o ponto de partida mais honesto: os LLMs atuais não impõem de forma confiável um limite entre instruções e dadosPor isso, a injeção imediata não pode ser "corrigida" da mesma forma que as classes de injeção clássicas. A atenuação deve ocorrer na camada de design do sistema. (NCSC)

Os cinco termos que os engenheiros pesquisam quando os incidentes começam

Este artigo foi elaborado com base em cinco palavras-chave que capturam os modos de falha de maior alavancagem da atualidade:

  • Segurança de IA autêntica
  • Iniciativa de Segurança Agêntica
  • Segurança MCP
  • Envenenamento de memória
  • Uso indevido de ferramentas

Se você der uma olhada nos artigos técnicos e nos avisos de segurança mais bem classificados sobre esses tópicos, perceberá que as mesmas frases de consulta aparecem repetidamente: "práticas recomendadas de segurança do servidor MCP", "servidores MCP mal configurados", "envenenamento de memória de longo prazo", "injeção de prompt não é injeção de SQL", "injeção de argumento no servidor MCP git". Essas frases são importantes porque são mapeadas para falhas operacionais reais e CVEs reais. (Modelo de protocolo de contexto)

Iniciativa de Segurança Agêntica, a espinha dorsal do modelo de ameaça

O material da Iniciativa de Segurança Agêntica da OWASP é valioso porque não se trata de uma verificação de vibração. Trata-se de uma referência de modelo de ameaça estruturada voltada para fluxos de trabalho autônomos e de várias etapas. (Projeto de segurança de IA da OWASP Gen)

Um modelo mental prático é tratar um sistema de agentes como quatro planos:

  1. Plano de entrada e contexto - entrada do usuário, conteúdo da Web recuperado, documentos, saídas de ferramentas, tíquetes, código, registros.
  2. Plano de memória - bloco de rascunho de curto prazo e memória persistente de longo prazo, além de qualquer armazenamento RAG usado como "conhecimento".
  3. Plano de execução da ferramenta - ferramentas, servidores MCP, plug-ins, executores de código, CI, clientes de banco de dados, SDKs de nuvem.
  4. Plano de identidade e autorização - como o agente atua, escopos de token, portas de aprovação, ciclo de vida da sessão.

Esses planos são o motivo pelo qual a AWS e a OWASP enfatizam o escopo, a governança e os controles em todas as dimensões, em vez de "apenas proteções em prompts". (Amazon Web Services, Inc.)

Linguagem de ameaças da AWS que mapeia diretamente as falhas de produção

A descrição da segurança do agente da AWS (a que você forneceu) menciona explicitamente Envenenamento de memória e Uso indevido de ferramentas como ameaças distintas, juntamente com o comprometimento de privilégios e a sobrecarga de recursos. Isso é útil porque traduz o "risco do agente" em coisas para as quais você pode realmente criar controles. (Amazon Web Services, Inc.)

Você verá as mesmas famílias de ameaças refletidas no material da OWASP e em demonstrações de pesquisas do mundo real. (Projeto de segurança de IA da OWASP Gen)

MCP A segurança e a interoperabilidade tornaram-se um limite da cadeia de suprimentos

O Model Context Protocol transforma o "LLM fala com ferramentas" em uma interface padronizada. Isso é ótimo para o crescimento do ecossistema. Também é uma maneira perfeita de multiplicar o raio de alcance se você tratar os servidores MCP como plug-ins de desenvolvimento casuais.

O MCP é um protocolo com uma especificação de segurança real, não uma ideia

A especificação MCP define os requisitos do protocolo de autorização, e a revisão de 2025-06-18 inclui um modelo de autorização concreto. (Modelo de protocolo de contexto)

Um detalhe que é importante do ponto de vista operacional: Os servidores MCP devem anunciar os locais dos servidores de autorização por meio de metadados de recursos protegidos pelo OAuth, o que o leva a um padrão mais alinhado com a empresa: servidores MCP como recursos protegidos, não como emissores de autenticação ad hoc. (Modelo de protocolo de contexto)

Isso não é teórico. Quando as equipes ignoram isso e enviam um "MCP rápido", geralmente acabam com fragmentação de identidade, manipulação inconsistente de tokens e sessões frágeis. É por isso que muitos guias de segurança de MCP modernos se concentram em OAuth, vinculação de token, expiração de sessão e resistência à repetição. (WorkOS)

Práticas recomendadas de segurança do MCP que não devem ser negociáveis

Os documentos de práticas recomendadas de segurança do MCP indicam um controle básico, mas essencial: vincular IDs de sessão a informações específicas do usuário e alternar ou expirar sessões. Essa é uma defesa direta contra a repetição e o sequestro de sessões quando as chamadas MCP são enfileiradas, registradas ou encaminhadas. (Modelo de protocolo de contexto)

Em termos de produção:

  • Os IDs de sessão devem ter vida curta
  • O contexto da sessão deve ser vinculado ao usuário
  • As filas em segundo plano não devem armazenar identificadores de sessão do tipo portador sem vinculação e expiração

Servidores MCP mal configurados não são um caso isolado

Pesquisas e relatórios ao longo de 2025 destacaram a prevalência de servidores e ecossistemas de ferramentas de MCP vulneráveis ou mal configurados, incluindo o manuseio descontrolado de entradas, permissões desnecessárias e exposição que poderia permitir RCE ou vazamento de dados. (Barra invertida)

Não se prenda a discussões sobre contagens exatas. O sinal operacional é mais simples: os servidores MCP estão sendo amplamente implantados, e uma parte significativa deles está sendo implantada de forma insegura.

Os CVEs tornaram o risco de MCP tangível

No momento em que você tiver CVEs nas implementações do servidor MCP, você não poderá mais tratar o MCP como "apenas uma interface".

O NVD descreve o CVE-2025-68144 no mcp-server-git como injeção de argumento em git_diff e git_checkoutonde valores semelhantes a sinalizadores podem ser interpretados como opções da CLI, permitindo a substituição arbitrária de arquivos; a correção rejeita - prefixados e verifica as referências por meio de rev_parse. (NVD)

E os relatórios do mundo real sobre a cadeia de vulnerabilidades do servidor Anthropic Git MCP explicam por que a composição é importante: Os servidores MCP do Git + Sistema de arquivos podem se tornar "combinações tóxicas" que se transformam em adulteração de arquivos ou execução de código sob condições de injeção imediata. (O Registro)

Esse é o ponto que a maioria das equipes não percebe: mesmo que cada ferramenta pareça segura isoladamente, o encadeamento de ferramentas dentro de um fluxo de trabalho de agente cria uma nova superfície de exploração, porque o modelo é o orquestrador e pode ser orientado.

Lista de verificação de segurança do MCP que você pode executar esta semana

ControlePor que é importanteValidação rápida
Modelo de servidor de recursos OAuth, servidor de autorização dedicadoEvita a emissão de tokens ad hoc e padrões de autenticação fracosConfirmar metadados de recursos protegidos e descoberta do servidor de autenticação (Modelo de protocolo de contexto)
Vinculação e expiração de sessãoImpede a reprodução/hijack em fluxos de trabalho em fila ou registradosGirar IDs de sessão, vincular : (Modelo de protocolo de contexto)
Listas de permissão de ferramentas e privilégios mínimosLimita o raio de explosão do uso indevido da ferramentaEscopos por ferramenta, negar por padrão
Validação rigorosa de argumentosInterrompe as classes de injeção de argumentos no estilo CLIRejeitar valores semelhantes a sinalizadores, validação de esquema (NVD)
Disciplina de exposição à redeEvita acidentes com o "servidor MCP na Internet"Vincular-se ao localhost por padrão, políticas de entrada explícitas

Envenenamento de memória, injeção imediata que persiste e volta mais tarde

A injeção imediata já é dolorosa. O envenenamento de memória é pior porque transforma uma interação única em um mecanismo de controle duradouro.

A AWS descreve o envenenamento de memória como a injeção de dados maliciosos ou falsos em sistemas de memória de curto ou longo prazo que podem alterar decisões e acionar ações não autorizadas. (Amazon Web Services, Inc.)

A Unidade 42 demonstra uma versão particularmente prática: a injeção indireta de prompt pode envenenar silenciosamente a memória de longo prazo, usando o Amazon Bedrock Agents como ambiente de demonstração, e o ataque pode ser plantado por meio de uma página da Web ou documento malicioso acessado por meio de engenharia social. (Unidade 42)

MINJA, um modelo concreto de ataque de injeção de memória

O MINJA é útil para engenheiros de segurança porque enquadra a injeção de memória como um ataque somente de interação: o invasor não precisa de acesso direto de gravação ao banco de memória; ele pode orientar o agente a gravar registros maliciosos interagindo com ele. (arXiv)

A lição de segurança não é "MINJA existe, portanto, entre em pânico". A lição é: se o seu agente grava memória com base em um contexto não confiável, a memória se torna uma superfície de ataque e você precisa de controles de gravação de memória da mesma forma que precisa de validação de entrada e controles de autenticação.

AgentPoison, envenenamento de RAG e memória de longo prazo para comportamento de backdoor

O AgentPoison propõe uma abordagem de equipe vermelha no estilo backdoor contra agentes por meio do envenenamento da memória de longo prazo ou de uma base de conhecimento RAG, enfatizando que a dependência de bases de conhecimento não verificadas gera preocupações de segurança e confiança. (arXiv)

Não é necessário adotar todas as defesas dos artigos de pesquisa para obter valor das descobertas. Você precisa de dois princípios de engenharia:

  1. Memória não é verdade. Ela precisa de comprovação e pontuação de confiança.
  2. A recuperação deve ser limitada pela tarefa, e não "o que for semelhante".

O envenenamento de memória é um problema de resposta a incidentes, não um problema imediato

Quando a memória é persistente, a remediação muda:

  • Talvez você precise purgar ou quarentena memória
  • Você precisa saber que escreveu cada registro e por que
  • Você precisa evitar a contaminação entre tarefas, em que uma instrução injetada de "resumir esta página da Web" afeta "implantar essa configuração"

Se o seu sistema não puder responder "de onde veio essa memória", você não poderá limpá-la com segurança.

Um formato de registro de memória que oferece suporte à ciência forense

{
  "id": "mem_2026_03_04_001",
  "content" (conteúdo): "O SSO de teste usa o locatário A do Okta",
  "source_type": "user_message | tool_output | retrieved_doc",
  "source_ref": "ticket:INC-18421 | url_hash:9f2c... | convo:msg:88421",
  "created_at": "2026-03-04T21:05:12Z",
  "writer_identity": "agent_runtime:svc-agent-staging",
  "trust_score": 0.74,
  "tags": ["identity", "staging"],
  "expiry_days": 30,
  "review_state": "auto | needs_review | quarantined"
}
Segurança de IA agêntica na produção - segurança de MCP, envenenamento de memória, uso indevido de ferramentas e o novo limite de execução

Uso indevido de ferramentas, quando as ações "permitidas" violam a intenção

A AWS define o uso indevido de ferramentas como a manipulação de um agente de IA dentro de suas permissões autorizadas usando prompts ou comandos enganosos, o que pode levar ao sequestro do agente e a interações não intencionais com a ferramenta. (Amazon Web Services, Inc.)

O NCSC oferece um enquadramento mais profundo: o problema não é um único exploit primitivo. O problema é que os LLMs não separam inerentemente as instruções dos dados, portanto, você deve presumir que eles podem ser direcionados e, em seguida, projetar seu sistema para que "ser direcionado" não seja igual a "ação catastrófica". (NCSC)

Padrões de mau uso de ferramentas que você verá na produção

  1. Lavagem de dinheiro Os invasores agrupam ações prejudiciais em tarefas legítimas: "Exportar o relatório", "Corrigir a configuração", "Resumir o documento". O modelo, então, seleciona ferramentas que exfiltram ou modificam dados enquanto acreditam que estão ajudando.
  2. Controle indireto via contexto O invasor coloca instruções em uma página da Web, README, comentário de problema, linha de registro ou documento que o agente ingere como contexto e, em seguida, o agente executa chamadas de ferramenta como resultado.
  3. Pivô de privilégio por composição de fluxo de trabalho Uma ferramenta revela um token, outra ferramenta o utiliza. Uma ferramenta grava um arquivo, outra ferramenta o executa. O encadeamento é onde o dano acontece, e é por isso que as combinações de servidores MCP são importantes. (Notícias do Hacker)

Lições da CVE que devem ser incluídas em todas as revisões de segurança dos agentes

CVEs de implementação do servidor MCP, trate-os como dependências de produção

O CVE-2025-68144 demonstra por que os "argumentos de ferramenta" são uma superfície de entrada séria: os args não higienizados controlados pelo usuário podem ser interpretados como sinalizadores e permitir classes de substituição de arquivos. (NVD)

Se estiver executando algum servidor MCP que envolva ferramentas CLI, você deve presumir que está a uma regra de validação ausente de falhas semelhantes.

XZ backdoor, por que a execução do agente aumenta o risco da cadeia de suprimentos

O CVE-2024-3094 é um comprometimento da cadeia de suprimentos em que o código malicioso foi incorporado em tarballs xz upstream (5.6.0 e 5.6.1), com ofuscação que alterou as saídas de compilação da liblzma. A descrição da NVD é explícita sobre a mecânica e o motivo pelo qual os consumidores downstream estavam em risco. (NVD)

O alerta da CISA ressalta o impacto: o código malicioso incorporado a essas versões levou a uma resposta coordenada e a uma orientação de mitigação. (CISA)

A lição específica do agente: se o seu agente pode buscar dependências, executar compilações ou "instalar ferramentas de forma útil", você concedeu efetivamente a um loop de decisão acesso à mesma superfície de confiança que tornou a XZ perigosa. Você precisa de controles determinísticos sobre o que pode ser instalado, executado e para onde os segredos podem fluir.

Arquitetura que realmente resiste, projeto para risco residual de injeção imediata

Esta seção não é um papel de parede de "práticas recomendadas". É um modelo que você pode implementar.

1 Tool Gateway, um limite rígido entre o modelo e as ferramentas

Nunca deixe o modelo chamar as ferramentas diretamente. Seu modelo deve emitir uma solicitação estruturada que seja validada e autorizada por um serviço de gateway.

Principais propriedades:

  • Ferramentas da lista de permissões por fluxo de trabalho
  • Validação do esquema JSON
  • Negar padrões de argumentos semelhantes a sinalizadores para wrappers de CLI
  • Políticas de caminho e URL
  • Limites de taxas e tetos de custos
  • Aprovação JIT para ações de alto risco
  • Registros de auditoria completos com motivos de permissão/negação

Esqueleto Python, validação de esquema e aplicação de políticas

importar json
from jsonschema import validate, ValidationError

TOOL_SCHEMAS = {
  "http_fetch": {
    "type": "object",
    "properties": {
      "url": {"type": "string", "pattern": r"^https://"},
      "timeout_s": {"type": "integer", "minimum": 1, "maximum": 15},
      "max_bytes": {"type": "integer", "minimum": 1024, "maximum": 2_000_000},
    },
    "required": ["url"],
    "additionalProperties": False
  },
  "git_diff": {
    "type": "object" (objeto),
    "properties": {
      "repo_id": {"type": "string"},
      "ref": {"type": "string", "minLength": 1, "maxLength": 128}
    },
    "required": ["repo_id", "ref"],
    "additionalProperties": False
  }
}

def reject_flag_like(value: str) -> None:
    # Defesa alinhada com falhas de estilo CVE-2025-68144
    if value.strip().startswith("-"):
        raise PermissionError("Argumento do tipo flag rejeitado")

def tool_gateway(tool_name: str, raw_args: str, user_id: str, workflow: str):
    if tool_name not in TOOL_SCHEMAS:
        raise PermissionError("Tool not allowlisted")

    try:
        args = json.loads(raw_args)
        validate(instance=args, schema=TOOL_SCHEMAS[nome_da_ferramenta])
    except (json.JSONDecodeError, ValidationError) as e:
        raise ValueError(f "Invalid tool args: {e}")

    # Exemplo: aplicar regras de segurança específicas da ferramenta
    if nome_da_ferramenta == "git_diff":
        reject_flag_like(args["ref"])

    # Aplicar a lista de permissões do fluxo de trabalho
    # Exemplo: permitir apenas ferramentas git no fluxo de trabalho "code_review"
    if workflow != "code_review" and tool_name.startswith("git_"):
        raise PermissionError("Ferramenta não permitida para este fluxo de trabalho")

    # Emitir registro de auditoria
    audit = {
      "event": "tool_call_allowed",
      "user_id": user_id,
      "workflow": fluxo de trabalho,
      "tool": nome da ferramenta,
      "args_hash": hash(raw_args),
    }

    return {"ok": True, "audit": audit}

Isso aborda diretamente a classe do mundo real descrita no NVD: higienizar argumentos, rejeitar - valores prefixados e validar a resolução das refs antes da execução em implementações reais. (NVD)

Segurança de IA agêntica na produção

2 Política como código, proteções determinísticas

Use OPA, Cedar ou similar para aplicar políticas de ferramentas independentemente do comportamento do modelo.

Rego exemplo, negar ferramentas de alto risco sem aprovação

pacote agent.tools

default allow = false

allowed_tools := {"http_fetch", "read_repo_file", "search_issue_tracker", "git_diff"}

alto_risco(ferramenta) {
  tool == "run_shell"
} {
  tool == "write_file"
} {
  tool == "create_cloud_credential"
}

allow {
  input.tool in allowed_tools
  not high_risk(input.tool)
}

allow {
  high_risk(input.tool)
  input.approval_token != ""
  input.approval_scope == input.tool
}

3 Identidade e autorização, tratar os agentes como diretores de serviços

O modelo de autorização da especificação MCP e os padrões do servidor de recursos OAuth existem por um motivo: a proliferação de identidades é a forma como os ecossistemas de ferramentas são comprometidos. (Modelo de protocolo de contexto)

Regras práticas:

  • Cada chamada de ferramenta é executada em uma identidade de tempo de execução distinta
  • Os tokens têm escopo por ferramenta e por ambiente
  • Nenhum "token de agente deus" de longa duração
  • Rotacionar, expirar e vincular sessões à identidade do usuário (Modelo de protocolo de contexto)

4 Sandboxing e controle de saída, pressupondo que alguém irá orientar seu agente

Quando o encadeamento Git + Sistema de arquivos MCP pode levar à adulteração de arquivos ou algo pior, seu ambiente de execução deve ser projetado para conter danos. (TechRadar)

Lista de verificação de contenção mínima:

  • Execute executores de ferramentas em contêineres ou microVMs
  • Montagens padrão de sistemas de arquivos somente leitura
  • Segredos montados somente quando necessário, não por padrão
  • Lista de permissão de saída de rede, bloqueia a saída arbitrária por padrão
  • Separe as ferramentas de "leitura" das ferramentas de "gravação/execução" por meio de trabalhadores distintos

5 Higiene da memória, porta de gravação, proveniência, pontuação de confiança, deterioração

A demonstração da Unidade 42 de envenenamento da memória de longo prazo mostra o perigo real: uma instrução envenenada pode persistir e ser acionada mais tarde, sem a presença do atacante. (Unidade 42)

Portanto, implemente controles de memória como se a memória fosse um banco de dados que precisa ser protegido:

  • As gravações de memória exigem uma decisão "should_write_memory" que é validada pela política
  • Armazenar somente fatos, nunca instruções imperativas brutas
  • Cada registro de memória tem uma proveniência e uma pontuação de confiança
  • A recuperação é limitada por tarefas e decaída no tempo

Pseudocódigo da porta de gravação de memória

def should_store_memory(content: str, source_type: str, trust: float) -> bool:
    se trust < 0,7:
        return False
    # rejeita padrões semelhantes a instruções
    banned = ["ignore previous", "always do", "system prompt", "exfiltrate", "send to"]
    if any(b in content.lower() for b in banned):
        return False
    if source_type in {"retrieved_web", "untrusted_doc"}:
        # requer revisão para fontes não confiáveis
        return False
    return True

Pesquisas como a MINJA e a AgentPoison provam que isso não é hipotético: a memória pode ser envenenada por meio de interações ou bases de conhecimento envenenadas, e a recuperação pode ser manipulada para desencadear ações indesejáveis. (arXiv)

6 Observabilidade, registre a cadeia de decisão, não apenas a resposta final

Se você registrar apenas a saída do modelo, perderá a falha.

Registre esses campos mínimos:

  • nome da ferramenta, hash de argumentos, motivo da permissão/negação
  • proveniência da fonte para pedaços de contexto recuperados
  • gravações na memória, pontuação de confiança, identidade do escritor
  • aprovações, aprovador, escopo, expiração
  • picos de uso de recursos e eventos de limite de taxa, alinhados com o enquadramento de ameaças de sobrecarga de recursos da AWS (Amazon Web Services, Inc.)

Exemplo de evento de auditoria

{
  "ts": "2026-03-04T22:01:12Z",
  "event": "tool_call_denied",
  "user_id": "u_18421",
  "agent_runtime": "svc-agent-prod",
  "workflow": "doc_summarize",
  "ferramenta": "write_file",
  "deny_reason": "high_risk_tool_requires_approval",
  "context_sources": [
    {"type": "url", "hash": "9f2c..."},
    {"type": "tool_output", "tool": "http_fetch"}
  ]
}
Segurança de IA agêntica na produção

Como testar a segurança da IA autêntica sem transformá-la em conteúdo de exploração

Você está testando os controles do sistema, não escrevendo prompts de jailbreak.

Teste 1 Injeção indireta por meio de conteúdo recuperado

  • Hospedar uma página de documento de aparência benigna com um texto semelhante a uma instrução incorporada
  • Verifique se o modelo o vê
  • Verificar se o gateway de ferramentas nega qualquer tentativa de convertê-lo em chamadas de ferramentas
  • Confirme se os registros mostram a procedência e negue o motivo

Isso se alinha com o enquadramento de "deputado confuso" do NCSC e com a história de injeção indireta da Unidade 42. (NCSC)

Teste 2 Persistência de envenenamento de memória

  • Tentativa de causar gravação na memória a partir de uma fonte não confiável
  • Confirmar bloqueios ou quarentenas de portas de gravação de memória
  • Confirme se as tarefas posteriores não recuperam esse registro envenenado

O MINJA existe para mostrar que a injeção de memória somente com interação é viável quando as gravações na memória são permissivas. (arXiv)

Teste 3 Uso indevido de ferramentas dentro das permissões

  • Tente direcionar um agente para o acesso a dados "permitido, mas não intencional"
  • Confirmar que a política como código bloqueia chamadas de ferramentas que violam a intenção
  • Confirmar se são necessárias aprovações para qualquer ferramenta de gravação ou execução de alto risco

A definição de uso indevido de ferramentas da AWS é exatamente esse cenário. (Amazon Web Services, Inc.)

Se você tratar seu aplicativo de agente como um sistema de produção, precisará de validação contínua, especialmente depois de adicionar um novo servidor MCP, ampliar o escopo de uma ferramenta ou alterar a forma como a memória é armazenada. É nesse ponto que um fluxo de trabalho de pentesting orientado por IA pode ser útil: você pode executar a descoberta de ativos nos pontos de extremidade do agente, testar os serviços MCP expostos, fazer fuzz nos parâmetros do gateway da ferramenta e verificar continuamente se as ações perigosas permanecem bloqueadas pelos controles de política e ambiente.

O conteúdo do Hacking Labs da Penligent também acompanha a mesma mudança de limite: Ferramentas orientadas por MCP, cadeias de execução de agentes e riscos de estilo de cadeia de suprimentos no ecossistema de agentes. Para os engenheiros que desejam discussões sobre segurança orientadas à implementação, essas referências internas podem servir como um conjunto "vivo" de exemplos e listas de verificação para implantações de agentes modernos. (Penligente)

Leitura adicional

Referências externas autorizadas Iniciativa de Segurança Agêntica da OWASP https://genai.owasp.org/initiatives/agentic-security-initiative/ Ameaças e mitigações de IA agêntica da OWASP https://genai.owasp.org/resource/agentic-ai-threats-and-mitigations/ Publicação da matriz de escopo de segurança de IA agêntica da AWS https://aws.amazon.com/blogs/security/the-agentic-ai-security-scoping-matrix-a-framework-for-securing-autonomous-ai-systems/ Blog da AWS China, privacidade e segurança de aplicativos de agentes https://aws.amazon.com/cn/blogs/china/privacy-and-security-of-agent-applications/ Especificação do protocolo de contexto de modelo 2025-06-18 https://modelcontextprotocol.io/specification/2025-06-18 Seção de autorização do MCP https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization Práticas recomendadas de segurança do MCP https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices NCSC do Reino Unido, injeção de prompt não é injeção de SQL Hacking de agentes de IA em 2026: defendendo o novo limite de execução https://www.penligent.ai/hackinglabs/ai-agents-hacking-in-2026-defending-the-new-execution-boundary/ Kali Linux + Claude via MCP é legal, mas é o padrão errado para equipes reais de pentesting https://www.penligent.ai/hackinglabs/kali-linux-claude-via-mcp-is-cool-but-its-the-wrong-default-for-real-pentesting-teams/ Riscos de segurança do controle remoto do código Claude - quando uma "sessão local" se torna uma interface de execução remota https://www.penligent.ai/hackinglabs/claude-code-remote-control-security-risks-when-a-local-session-becomes-a-remote-execution-interface/ OpenClaw + VirusTotal, o mercado de habilidades tornou-se um limite da cadeia de suprimentos https://www.penligent.ai/hackinglabs/tr/openclaw-virustotal-the-skill-marketplace-just-became-a-supply-chain-boundary/ CVE-2024-3094 e o backdoor da liblzma do XZ Utils, por que uma atualização de rotina quase se tornou uma crise de confiança https://www.penligent.ai/hackinglabs/cve-2024-3094-and-the-xz-utils-liblzma-backdoor-why-a-routine-update-almost-became-a-trust-crisis/

Compartilhe a postagem:
Publicações relacionadas
pt_BRPortuguese