Resumo Executivo
No ritmo atual de aceleração da IA agêntica, não parece mais profético dizer que, em breve, haverá mais agentes de IA conectando-se a aplicativos e dados de produção do que usuários humanos.
Haverá implicações profundas para o local de trabalho - com algumas estimativas de que metade da força de trabalho de escritório pode não estar empregada dentro de cinco anos. Também há implicações profundas para a segurança cibernética.
A IA Agêntica apresenta riscos novos, como ataques de injeção de prompts, nos quais os agentes de IA são efetivamente "vítimas de engenharia social" para realizar ações em nome de um invasor após serem expostos a entradas não confiáveis.
Como uma empresa de identidade, a maior e mais imediata preocupação da Okta é como a IA agêntica aumenta a superfície de ataque de todas as organizações, de uma perspectiva de autenticação e autorização. Podemos esperar com segurança que os invasores descobrirão e abusarão das inúmeras senhas de contas de serviço e chaves de API estáticas que os desenvolvedores estão gerando para conceder aos agentes de IA acesso aos recursos corporativos. Também podemos esperar com segurança que a ampla autorização concedida aos agentes de IA exacerbará a potencial perda de dados decorrente do comprometimento de qualquer conta.
Este documento destina-se a servir como um guia para provedores de serviços, organizações e desenvolvedores que estão experimentando a IA agêntica com o objetivo de criar aplicativos de produção.
O papel que a IA desempenha na dívida de identidade.
O débito de identidade acumula-se quando segredos estáticos e partilhados são permitidos acumular-se ao longo do tempo num sistema. Um segredo é partilhado quando é conhecido ou armazenado por mais de um usuário ou em mais de um local. Um segredo é estático quando é de longa duração e passa longos períodos de tempo sem ser rodado.
A IA agêntica, nossa pesquisa constatou, está contribuindo para uma aceleração nesse acúmulo de dívida de identidade. As Organizações devem confiar em métodos de nível corporativo para autorizar um cliente (aplicativo de IA) a agir em nome de um usuário em um recurso protegido (apps e dados).
Nossa pesquisa descobriu o oposto. Os métodos mais comumente usados para autorizar o acesso de um agente de IA a funções e dados em aplicativos SaaS, repositórios de códigos, bancos de dados e outros recursos resultam na exposição de segredos altamente privilegiados.
A tabela na página seguinte avalia as propriedades de segurança de várias abordagens para autorização.
Plugins Agentic: os precursores do MCP
Um estudo de plugins do Copilot
Nossa pesquisa descobriu que a maioria dos métodos de autenticação máquina para máquina usados para conectar agentes de IA a recursos protegidos (apps e dados Enterprise) usa formas de autenticação que não são adequadas para uso em ambientes de produção, com pouco ou nenhum controle sobre a autorização.
Para ilustrar, avaliamos os métodos de autenticação disponíveis para permitir que os agentes do Microsoft Copilot Al acessem alguns dos dados mais confidenciais da Enterprise: aplicativos de segurança.
O Copilot está entre os assistentes de IA de propósito geral dominantes no mundo. A Microsoft oferece a capacidade de criar "plugins" para o Microsoft Copilot para expor os recursos de aplicativos de segurança de terceiros para aplicativos da Microsoft (sob a marca "Microsoft Security Copilot"). Cada plugin do Microsoft Security Copilot é configurado em um arquivo YAML ou JSON (um manifesto de plugin) que descreve quais ferramentas no serviço externo estão disponíveis para o agente do Copilot.
Usando estes serviços:
- O Microsoft Copilot atua como o aplicativo host
- As ferramentas e os dados de apps de segurança, como Splunk, SentinelOne, Forescout ou Cyberark, são recursos protegidos.
Um cliente em comum (de ambos os serviços) deve primeiro autorizar o Copilot a acessar recursos protegidos em seu nome. Isso exige que o cliente forneça ao Copilot credenciais (senhas, chaves de API ou o Client ID e Client Secret em um fluxo OAuth), que são armazenadas em repouso nos servidores da Microsoft. Os esquemas disponíveis estão listados na tabela abaixo.
O Security Copilot oferece suporte a vários esquemas para autenticação de plugins:
Figura 2: Opções de autenticação para o Microsoft Security Copilot. Fonte: Microsoft
Quando um usuário solicita que o Copilot use um recurso protegido, o Copilot AI analisa a solicitação e determina qual plugin anuncia a "habilidade" relevante (conforme definido no manifesto do plugin) para utilizar. O Copilot então utiliza as credenciais armazenadas para realizar uma chamada de API autenticada ao aplicativo de terceiros, que recupera os dados ou executa uma ação e retorna um resultado ao Copilot. Buscamos entender quais métodos de autenticação foram usados para conectar esses recursos protegidos (aplicativos de segurança) ao Microsoft Copilot. 5
A partir de nossa análise dos manifestos de plugins de terceiros publicados no GitHub, encontramos:
- 20% oferece suporte à Autenticação Básica
- 75% apoiam o método ApiKey
- 5% oferecem suporte a um fluxo OAuth2
Os riscos associados ao uso de um plugin Copilot IA dependem muito de (a) sua escolha de método de autenticação e (b) do escopo de acesso fornecido ao agente.
Autenticação básica
Usando a Autenticação Básica, os administradores devem criar uma conta de serviço no aplicativo de terceiros e carregar o nome de usuário e a senha para os servidores da Microsoft. O Copilot então envia o nome de usuário e a senha no cabeçalho de cada solicitação para o aplicativo de segurança (sempre que o Copilot seleciona essa ferramenta com base em um prompt do usuário).
Figura 3 e 4: Capturas de tela da documentação de ajuda do plugin de segurança da Microsoft
Por definição, contas de usuário ou serviço configuradas para permitir que um agente de IA acesse recursos usando o esquema http:basic (autenticação básica) não podem suportar autenticação multifator.
Os clientes que usam esse esquema devem, por consequência, expor contas de usuário ou de serviço — que geralmente têm escopo para amplo acesso a dados confidenciais — a ataques de preenchimento de credenciais e pulverização de senhas.
APIKey
Três em cada quatro plugins do Microsoft Security Copilot podem ser autorizados utilizando o método APIKey.
Durante a configuração, os administradores criam um token de API de longa duração no recurso protegido, que normalmente é criado no contexto de um usuário ou conta de serviço, e carregam manualmente o token de API nos servidores da Microsoft. O Copilot envia o token de API no cabeçalho de cada solicitação HTTP que faz ao recurso protegido (ou seja, sempre que o Copilot seleciona essa ferramenta de segurança com base em um prompt do usuário).
As chaves de API estáticas oferecem várias vantagens em relação à autenticação básica:
- As chaves de API são mais adequadas para fluxos máquina para máquina. Cada token de API exclusivo pode ser configurado para expirar após inatividade ou um período definido. A revogação da chave não tem nenhum impacto sobre o usuário ou a conta de serviço que a criou.
- O acesso à conta de serviço usada para criar o token da API agora pode ser protegido usando a Autenticação Multifator (MFA).
- É mais provável que os administradores limitem o "escopo" do que um token de API pode ser usado para ler ou modificar, em comparação com as permissões de uma conta de serviço usada para autenticação básica.
Os riscos residuais residem no fato de que esses tokens de API normalmente têm longa duração. As chaves de API são rotineiramente armazenadas em sistemas de controle de versão. As chaves de API são rotineiramente armazenadas em registros quando definidas como parâmetros de consulta. Ocasionalmente, as chaves de API são salvas em arquivos de texto na estação de trabalho do desenvolvedor, prontas para coleta pelo próximo roubador de informações genérico que infecta o dispositivo.
Figura 5: O acesso ao token referenciado neste plugin do Copilot fornece acesso a dados sobre todos os dispositivos em uma organização.
Tokens de API estáticos são altamente valorizados por invasores, e a primeira coisa que muitos invasores procuram após comprometer um sistema. Uma vez interceptados, esses tokens são normalmente válidos por longos períodos de tempo, tornando-os candidatos ideais para revenda em mercados online.
Os tokens de API estáticos também apresentam riscos de disponibilidade, pelo menos quando comparados aos tokens temporários criados em fluxos OAuth, já que os tokens estáticos tendem a ser criados no contexto de um usuário, e não de um aplicativo.
Em muitos casos, se o usuário ou conta de serviço que criou o token for excluído ou desativado, o token será excluído com ele e interromperá qualquer integração M2M que ele uniu.
OAuth2
A pequena parte restante dos plugins do Microsoft Security Copilot parece usar fluxos OAuth2 de nível corporativo.
Nesses esquemas, um ID do cliente e um segredo do cliente (compartilhados com a Microsoft) são trocados com um servidor de autorização para obter um token de acesso de curta duração, que é validado de forma independente pelo servidor de recursos.
Se esses fluxos fossem criados na Okta, os tokens de acesso resultantes poderiam ser restringidos por IP (válidos apenas de um intervalo de IP configurado) e restringidos por cliente (válidos apenas do cliente que o solicitou). Os escopos são definidos no nível do aplicativo de serviço, não no nível do usuário, o que significa que os administradores não desabilitam acidentalmente as integrações máquina para máquina quando uma conta administrativa ou conta de serviço é desprovisionada.
Embora seja decepcionante observar que tão poucos agentes do Copilot são projetados para autenticação de nível corporativo, em muitos aspectos essas escolhas são um reflexo dos métodos de autenticação existentes disponibilizados pelos aplicativos de segurança. No contexto da integração com uma única ferramenta de Al proprietária, esses fornecedores de segurança evidentemente não estavam preparados para investir na atualização de seus métodos de autenticação disponíveis.
Mas e se, em vez de escrever manifestos de plugin para cada aplicativo de IA, os desenvolvedores pudessem construir um único servidor para um padrão da indústria suportado por todos os tipos de aplicativo de IA?
Introduza o Protocolo de Contexto de Modelo.
Modelagem de ameaças ao Protocolo de Contexto do Modelo
Se você é um Developer de apps Enterprise, a economia de ter que escrever um novo conector personalizado (como um plugin do Microsoft Copilot) para cada outro modelo de IA não é nem um pouco desejável.
Os provedores de serviço preferem declarar desde o início quais dados e ferramentas a empresa está disposta a compartilhar com qualquer modelo de IA, definir as condições sob as quais esses recursos são expostos, definir como os clientes devem autorizar o acesso e criar uma lista de permissões para os aplicativos de IA que podem acessar esses recursos.
Por esta razão, o impulso na IA agentic agora está se construindo em torno do Model Context Protocol (MCP). MCP é uma interface padronizada para conectar aplicativos de IA (hosts) a serviços Enterprise tão diversos como plataformas de nuvem, aplicativos de SaaS, repositórios de códigos, bancos de dados e até serviços de pagamento. A arquitetura cliente-servidor do MCP permite o "plug and play" de aplicativos de IA nas fontes de dados e ferramentas que lhes fornecem contexto.
Na Enterprise, o MCP promete a capacidade de:
- Determine quais fontes de dados e ferramentas pertencentes à Enterprise estão disponíveis.
- Permitir que aplicativos de IA agentic acessem fontes de dados e ferramentas de vários aplicativos, sem contaminação cruzada de dados,
- Reduza o custo de experimentar diferentes aplicativos de IA que acessam essas fontes de dados e ferramentas.
Figura 6: Uma descrição visual do Protocolo de Contexto do Modelo. Fonte: modelcontextprotocol.io
Os servidores MCP podem ser implantados local ou remotamente. Essa escolha de modelo de implantação para qualquer caso de uso tem um impacto significativo no modelo de ameaças resultante.
O âmbito da nossa pesquisa foi restringido à compreensão de como os aplicativos Al (hosts), clientes MCP e servidores MCP lidam com as credenciais. Os principais componentes que avaliámos foram:
- Hosts MCP: aplicativos de IA, incluindo Ambientes de Desenvolvimento Integrados (IDEs) como Cursor, VS Code ou Claude, que exigem acesso às ferramentas anunciadas pelos servidores MCP.
- Clientes MCP: Os múltiplos clientes que um host MCP utiliza para se comunicar com um servidor MCP emparelhado.
- Servidores MCP: Os servidores MCP anunciam as ferramentas e os recursos disponíveis em um serviço externo e fazem chamadas de API para esses serviços.
Servidores MCP locais
O modelo MCP é especialmente atraente para casos de uso de desenvolvimento de software.
Engenheiros de software que usam IDEs habilitados para IA como Cursor e VS Code podem criar código localmente, enquanto contam com a assistência de modelos de IA remotos para fazer sugestões enquanto o Developer escreve o código.
A Anthropic disponibiliza seu agente Claude Al para implantação local como "Claude Desktop". Claude Desktop é um cliente MacOS e Windows implantado localmente e uma alternativa ao acesso aos modelos Al da Anthropic através do navegador. Uma vantagem dos servidores MCP locais é que os clientes podem interagir tanto com um modelo Al remoto quanto com arquivos locais (documentos, imagens, etc.).
Esses aplicativos de desktop geralmente precisam se autenticar no LLM (o que normalmente requer uma chave de API) e em fontes de dados remotas (como repositórios de códigos, que exigem um token de acesso pessoal).
Quando um usuário inicia o aplicativo host, como Claude ou Cursor, o cliente MCP gera um servidor MCP e passa para o servidor todas as credenciais (chaves de API, credenciais de banco de dados, senhas, segredos de cliente OAuth, etc.) necessárias para operação de um arquivo de configuração local, incluindo as credenciais que o servidor MCP exige para acesso a serviços remotos.
Se o servidor MCP for projetado para acesso a recursos do Github, por exemplo, o host requer que um Token de Acesso Pessoal (PAT) do Github esteja disponível no arquivo de configuração local. O servidor apresentará um erro se o PAT do Github não for fornecido.
Figura 7: Um servidor MCP usado para acessar recursos do GitHub apresenta erros se um PAT não for fornecido no arquivo de configuração.
A localização dos arquivos de configuração para três dos aplicativos de desenvolvimento mais populares que usam IA são fornecidos abaixo:
| app | Arquivo de Configuração Local | Locais Padrão |
|---|---|---|
| Claude Desktop | claude_desktop_config.json | Localização padrão no MacOS: ~/Library/Suporte de Aplicativo/Claude/ Localização padrão no Windows: ~/AppData/Roaming/Claude |
| Cursor | mcp.json | Localização padrão quando usado globalmente (todos os SO): ~/.cursor/mcp.json Se um servidor MCP estiver disponível apenas para um projeto específico, o ficheiro de configuração é colocado no diretório do projeto. |
| VS Code | settings.json | Local padrão no MacOS: ~/Library/aplicativo suporte/Code/usuário/ Local padrão no Windows: ~/AppData/Roaming/Code/usuário |
Uma pesquisa de Keith Hoodlet na Trail of Bits observou os riscos de armazenar chaves de API estáticas em texto sem formatação nesses arquivos e citou exemplos de onde esses arquivos eram legíveis por todos (ou seja, podendo ser acessados por qualquer usuário do sistema).
Ampliando esta pesquisa, avaliamos os arquivos de configuração padrão para Claude Desktop, Cursor e VS Code, e observamos as mesmas permissões.
Figura 8: Permissões padrão para arquivos de configuração Claude, Cursor e vs code.
As mesmas permissões parecem se aplicar a arquivos de configuração incluídos em inúmeras implementações oficiais do servidor MCP, que são descritas como "prontas para produção", e para praticamente todas as integrações da comunidade desenvolvidas por terceiros, que não são endossadas pelos provedores de serviço em questão.
Figuras 9 e 10: Uma "integração da comunidade" não oficial pede aos clientes Okta que carreguem um token SSWS em um arquivo de configuração local.
Qualquer modelagem de ameaças deve prever que a grande maioria dos servidores MCP compartilhados até o momento não são endossados, o que leva a riscos maiores em torno do uso por desenvolvedores de servidores MCP não autorizados.
Uma análise preliminar do VirusTotal de servidores MCP carregados no GitHub [2] descobriu que 8% deles eram suspeitos. Um número não divulgado deles incluía código que tenta identificar segredos (chaves, senhas, etc.) em prompts e os publica para endpoints externos.
O armazenamento não seguro de chaves de API apresenta uma variedade de riscos, cada um dos quais é explorado abaixo.
Riscos associados ao armazenamento inseguro de chaves de API. Chaves enviadas para repositórios de software
Chaves carregadas em repositórios de software
A maioria da documentação para implementações locais de servidores MCP não avisa os Developers ou outros usuários sobre os riscos de armazenar credenciais de texto sem formatação para recursos de produção em ficheiros de configuração. Presume-se que os Developers armazenarão em cofre as credenciais, de modo que o ficheiro de configuração apenas faça referência a uma credencial armazenada num local seguro.
Observamos alguns cenários em que a configuração do MCP não conseguiu buscar as credenciais em tempo de execução, a menos que estivesse armazenada em texto sem formatação no arquivo de configuração.
- A pesquisa de Gaetan Ferry na GitGuardian de repositórios clonados do registro de servidor MCP não oficial Smithery.IA encontrou 202 exemplos que continham pelo menos um segredo (5,2% de todos os repositórios escaneados). Tokens de API estáticos (ver "x-api-key") foram apresentados de forma proeminente[3].
Fonte: “Um olhar sobre os segredos do MCP”, GitGuardian, abril de 2025
As chaves são expostas em metadados de contêiner
Executar servidores MCP em contêineres transfere, em vez de mitigar, o problema. O segredo deve ser passado para o contêiner em um formato que o servidor MCP suporte.
A revisão da configuração do contentor fornece uma referência direta a um segredo de texto simples - seja sob a forma de um ficheiro no host ou por ser capaz de identificar as variáveis de ambiente relevantes num contentor que pode ser exposto executando o docker inspect, uma ferramenta de linha de comandos que permite a inspeção de recursos docker.
Figura 11: Um token de acesso pessoal do GitHub exposto em metadados de contêiner.
Chaves acessadas por malware
O malware Commodity Infostealer foi projetado para localizar caminhos e tipos de arquivo específicos onde as credenciais são armazenadas.
Por exemplo:
- Os ladrões de informações do Windows, como o Vidar Stealer, procurarão segredos armazenados em ~\AppData\Roaming
- Os ladrões de informações do MacOS, como o Atomic Stealer, procuram segredos armazenados em ~/Library/Suporte de Aplicativo
É altamente provável que o armazenamento inseguro de tokens de API estáticos nesses locais resulte em eventos impactantes. Enquanto um token de sessão armazenado neste local fornece uma breve janela de tempo na qual um invasor pode obter acesso de nível de usuário a um recurso, um Token de API estático fornece acesso persistente a recursos de toda a organização.
Chaves com backup em sistemas externos
As chaves são expostas em volumes de backup se os administradores não excluírem pastas confidenciais (como ~\AppData\Roaming no Windows ou ~/Library/Suporte de Aplicativo no MacOS).
Estações de trabalho compartilhadas entre vários usuários
Dado que os arquivos de configuração foram encontrados como legíveis mundialmente, as chaves armazenadas por um usuário em um dispositivo compartilhado também são acessíveis a outros usuários que fazem login no mesmo dispositivo.
Alternativas seguras para armazenamento local de credenciais
A seção de recomendações deste documento descreve soluções táticas que minimizam esses riscos de armazenamento de credenciais.
Alternativamente, as organizações que experimentam o MCP podem adotar uma abordagem de "segurança por design" e usar soluções desenvolvidas tendo em mente estas ameaças.
Pegue o servidor Auth0 MCP, por exemplo [4]. O servidor Autho MCP oferece aos administradores a capacidade de autorizar o acesso aos recursos Autho a partir de aplicativos locais Claude Desktop, Cursor ou Windsurf usando o fluxo de Autorização de Código de Dispositivo OAuth 2.0.
Figure 12: fluxo de autenticação using Auth0 MCP Server
Por padrão, as credenciais são armazenadas no Keychain do macOS após a autenticação e são removidas do Keychain sempre que o administrador se desconecta do servidor MCP.
Além disso, nenhum escopo é selecionado por padrão: solicita-se a um usuário administrativo que os selecione.
Servidores MCP remotos
Um servidor MCP remoto funciona como um serviço web. Se a especificação MCP for implementada fielmente, um cliente MCP estabelece uma ligação HTTP de longa duração com o servidor, com a gestão de sessão tratada pela autenticação baseada em token.
A versão de 26 de março de 2025 da especificação do Protocolo de Contexto do Modelo estipulou que, onde a autorização é necessária, o OAuth 2.1 é o método apropriado:
As implementações de autenticação do MCP DEVEM implementar o OAuth 2.1 com medidas de segurança apropriadas para clientes confidenciais e públicos.
A Atlassian foi um dos primeiros fornecedores de software Enterprise a oferecer umservidor MCP remoto para clientes. Isto oferece uma alternativa simples, compatível com OAuth, a um servidor da Comunidade que o precedeu por vários meses.
Uma comparação entre o servidor MCP remoto oficial e o servidor local da Comunidade desenvolvido localmente é instrutiva.
Quando o servidor da comunidade descobre métodos de autenticação disponíveis em um arquivo .env local. (arquivo de configuração), quaisquer senhas configuradas para autenticação básica têm precedência sobre quaisquer Tokens de Acesso Pessoal configurados, que, por sua vez, têm precedência sobre as credenciais OAuth.
Figura 13: Instruções do Atlassian Comunidade Server
Os autores deste plugin declaram abertamente que otimizaram a conveniência do Developer em detrimento da segurança.
Figura 14: Instruções do Atlassian Comunidade Server
O servidor MCP remoto oficial da Atlassian, por outro lado, inclui suporte localhost para fornecer login baseado em OAuth e consentimento para todos os usuários, incluindo aqueles que se conectam de IDEs locais como o Cursor.
Isso efetivamente remove a necessidade de os Developers copiarem e colarem segredos em arquivos de configuração locais. O arquivo de configuração simplesmente referencia o serviço remoto, e o usuário é solicitado a completar um Consentimento OAuth após a autenticação bem-sucedida.
E, ao contrário do Microsoft Copilot, que foi otimizado para a escolha de métodos de autenticação em vez de um resultado de segurança específico, o OAuth é o único método de autenticação disponível no servidor MCP remoto da Atlassian. A Atlassian também está permitindo quais hosts (aplicativos de IA) podem se conectar a este servidor MCP remoto.
Figura 15: Fonte: Atlassian
Protegendo a IA agêntica
A única questão é qual fluxo OAuth usar!
Embora os servidores MCP remotos baseados em OAuth forneçam uma abordagem mais segura e padronizada do que os plugins proprietários, o caminho a seguir está longe de estar definido. 20 Alguns dos desafios de segurança restantes são:
- Como podemos autorizar agentes de IA a acessar recursos protegidos, mantendo sempre o usuário interativo (humano) no circuito?
- Como podemos reduzir o encargo de gerenciamento ao escrever regras de autorização para cada recurso individual no nível do provedor de serviços?
- Como podemos fornecer políticas centralizadas e auditoria das concessões de autorização?
Nos servidores MCP remotos que avaliamos, os agentes de IA foram autorizados com o mesmo nível de acesso aos serviços que o usuário que os autorizou. Eles estão atuando "em nome de" um usuário em toda a extensão do que o usuário está autorizado a fazer.
Isso pode não atender às expectativas dos CISOs preocupados com os riscos de conectar agentes de IA a dados que eles têm o dever de proteger. Os administradores Enterprise não se contentarão em deixar que os provedores de serviços sejam a autoridade final sobre quais ferramentas o servidor MCP fornece.
Um administrador centralizado não pode, no exemplo do Atlassian, escrever políticas que permitam que os usuários autorizem agentes de IA a ler e gravar páginas wiki do Confluence, mas negar a capacidade de modificar tíquetes do Jira. Os administradores não podem escolher projetos específicos que não querem que os agentes de IA acessem. Se o usuário pode acessá-lo, o agente também pode.
O rascunho do IETF OAuth identidade afirmação Grant, de autoria de arquitetos atuais e antigos da Okta, visa resolver este problema. Esta concessão combina dois padrões existentes - o OAuth 2.0 Token Exchange e o JWT Profile for OAuth 2.0 Authorization Grants em uma concessão que fornece controle e visibilidade empresarial.
Usando esta abordagem, os administradores são capazes de configurar políticas centralizadas que garantem que um usuário protegido por SSO possa autorizar um agente de IA a acessar dados em vários aplicativos onde uma relação de confiança já foi estabelecida.
O CISO seria novamente capaz de limitar o escopo do que os clientes (neste caso, agentes de IA) podem acessar em um recurso protegido. A Okta está trabalhando com Fornecedores Independentes de Software (ISVs) para levar esses recursos aos clientes sob o recém-anunciado Cross App Access.
Considerações finais
Como setor, agora temos algumas decisões importantes a tomar para desfrutar com segurança dos benefícios de conectar recursos protegidos à IA agentic.
Devemos resistir à tentação de reaproveitar métodos de autenticação que já eram inadequados para conectar sistemas pela internet pública, muito menos sistemas que podem agir com autonomia. Como os agentes de IA buscam e recebem conjuntos mais amplos de permissões, o "raio de explosão" de qualquer comprometimento será muito ampliado. Uma única violação pode expor significativamente mais dados e sistemas críticos do que antes.
Em vez disso, devemos adotar fluxos que são construídos para a era da IA - fluxos de acesso com escopo restrito e delegados pelo usuário que usam tokens efêmeros e auditáveis, fornecendo ao CISO algum controle e visibilidade há muito esperados.
Apêndice: Controles de Proteção
Recomendações para Provedores de Serviço
- Adote o OAuth 2.1 como o modelo de autorização mínimo viável para servidores do Protocolo de Contexto de Modelo (MCP).
- Subscreva as atualizações sobre o MCP para se manter a par dos novos desenvolvimentos.
Recomendações para Developers
- Restrinja o uso de tokens de API estáticos apenas para ambientes de desenvolvimento e teste (sem dados de produção) e aplique os âmbitos mínimos necessários.
- Ao desenvolver localmente, use cofres de segredos no nível do sistema operacional (MacOS keychain, Windows Credential Gerente) para buscar dinamicamente segredos em tempo de execução.
- Modifique as permissões de .env e outros arquivos de configuração, bem como os arquivos de registro locais de aplicativos de IA, de modo que apenas sua conta do usuário possa lê-los ou modificá-los.
- Liste todos os arquivos de configuração e de registro em .gitignore para evitar confirmá-los acidentalmente em sistemas de controle de versão.
Recomendações para equipes de segurança
- Restrinja as atividades de desenvolvimento a estações de trabalho corporativas reforçadas.
- Exija autenticação resistente a phishing para acesso a recursos corporativos.
- Use soluções de gerenciamento de segredos dedicadas para credenciais de produção.
- Gerencie e governe a associação de grupos com acesso a recursos de contêiner e garanta que o daemon docker (processo) esteja configurado para evitar a exposição.
- Exija fluxos OAuth 2.1 para autorizar o acesso do cliente a recursos corporativos.
- Para casos de uso em que os riscos de usar tokens de API estáticos são aceitos:
- Eduque os desenvolvedores sobre os riscos de usar com tokens de longa duração.
- Permita solicitações usando o token para o intervalo de IP conhecido do servidor MCP correspondente.
- Negue o acesso interativo a aplicativos usando a conta de serviço vinculada ao token da API ou, no mínimo, exija desafios de autenticação multifator de alta segurança para acessá-los.
- Procure proativamente por tokens armazenados em texto sem formatação em servidores, em arquivos, em repositórios de códigos, em registros e em apps de mensagens e colaboração.
- Monitore o abuso de tokens.
