CrowdStrike Blueprint Alliance Une a Indústria Contra a Lacuna de Identidade dos Agentes de IA
A CrowdStrike se uniu a outros 11 fornecedores fundadores em uma nova aliança construída em torno de um conflito que as empresas já não podem evitar. Agentes de IA precisam de amplo acesso para serem úteis, mas esse mesmo acesso torna sua governança difícil. A CrowdStrike Blueprint Alliance busca fechar essa lacuna com uma arquitetura de segurança compartilhada.
A coalizão, formalmente chamada Blueprint Alliance, foi lançada em 22 de setembro de 2026. Seus membros abrangem identidade, infraestrutura em nuvem, cibersegurança, plataformas de dados, desenvolvimento de aplicações e software empresarial. Essa abrangência é importante porque um agente pode cruzar vários desses domínios ao concluir uma única tarefa.
O anúncio é mais do que outra parceria da CrowdStrike para segurança de agentes de IA. Ele pede que fornecedores que competem por orçamentos empresariais apoiem um modelo operacional comum. Esse modelo trata os agentes como atores identificáveis, com autoridade limitada, delegação rastreável, monitoramento contínuo e contenção reversível.
A questão mais difícil é se princípios compartilhados se transformarão em controles interoperáveis. As empresas precisam de mais do que concordância entre fornecedores sobre terminologia. Elas precisam de comportamentos consistentes de descoberta, autorização, registro e desligamento em produtos que não foram projetados como um único sistema.
CrowdStrike Blueprint Alliance Conecta 12 Partes da Pilha de Agentes
A aliança transforma a segurança de agentes de IA de um recurso no nível do produto em um problema de arquitetura entre fornecedores.
Os 12 membros fundadores são AWS, CrowdStrike, Databricks, Docker, Google Cloud, Lovable, Okta, Proofpoint, Salesforce, ServiceNow, Wiz e Zscaler. GE Appliances e World Central Kitchen atuam como consultores estratégicos.
Segundo o anúncio oficial da aliança, os membros desenvolverão uma arquitetura de referência aberta e multiforncedor. O trabalho amplia um blueprint de segurança que a Okta apresentou pela primeira vez em março de 2026.
A arquitetura começa com quatro questões operacionais:
Onde estão os agentes da organização?
O que cada agente pode fazer?
O que cada agente está fazendo?
Como os defensores devem responder?
Essas perguntas parecem básicas. A maioria das empresas não consegue respondê-las de forma consistente em contas de nuvem, plataformas de software, ambientes de desenvolvimento, sistemas de dados e ferramentas instaladas por funcionários.
Um agente de IA é um software capaz de interpretar um objetivo, reunir contexto, selecionar ferramentas e executar ações com supervisão limitada. Um agente de atendimento ao cliente pode ler um ticket de suporte, analisar o histórico da conta, aprovar um reembolso e atualizar um registro de CRM.
Cada etapa introduz um ponto de controle diferente. O agente precisa de uma identidade antes de se autenticar. Precisa de autorização antes de acessar o registro de um cliente. Suas ações precisam ser monitoradas enquanto a tarefa é executada. Seu acesso deve ser revogado quando a tarefa termina.
Os princípios fundadores refletem essa sequência. Os membros afirmam que cada agente deve receber uma identidade de primeira classe em vez de usar uma credencial humana emprestada. O acesso deve ser delimitado por tarefa, em vez de concedido permanentemente. A delegação deve permanecer rastreável quando um agente chama outro.
A aliança também pede monitoramento contínuo em runtime. O monitoramento em runtime observa o que um agente faz durante sua operação, em vez de depender apenas de aprovação antes da execução. Se o comportamento se tornar inseguro, a contenção deve ser imediata e reversível.
A CrowdStrike entra nesse arranjo pelo lado da detecção e resposta da segurança empresarial. A Okta traz controles de identidade, enquanto AWS e Google Cloud representam a infraestrutura. Salesforce e ServiceNow operam ambientes de aplicações nos quais agentes podem iniciar ações de negócios.
A Databricks cobre a infraestrutura de dados, enquanto Docker e Lovable participam dos fluxos de desenvolvimento e implantação. Proofpoint, Wiz e Zscaler acrescentam controles relacionados a comunicações, exposição na nuvem e acesso à rede.
Essa divisão de funções explica por que nenhum membro isolado pode fornecer toda a arquitetura. Uma plataforma de identidade pode autenticar um agente, mas não consegue ver automaticamente todas as ações posteriores. Um produto de segurança de endpoints ou nuvem pode detectar comportamento suspeito sem controlar todas as permissões upstream.
Assim, a aliança começa com um diagnóstico crível. A segurança de agentes abrange sistemas pertencentes a equipes diferentes e fornecidos por fornecedores distintos. A questão ainda sem resposta é se esses fornecedores conectarão seus controles de maneira suficientemente profunda para tornar a governança contínua.
Por Que Agentes de IA Transformam Problemas Conhecidos de Acesso em Falhas Mais Rápidas
Os agentes ampliam fraquezas antigas de identidade porque podem reutilizar permissões, encadear ações e operar por mais tempo que uma sessão humana.
A automação empresarial tradicional já utiliza contas de serviço, chaves de API e identidades de workload. As equipes de segurança sabem como essas credenciais podem se tornar difíceis de gerenciar quando a propriedade não está clara ou as permissões permanecem ativas indefinidamente.
Os agentes de IA acrescentam caminhos de decisão incertos a esse problema existente. Sua próxima ação pode depender da saída de um modelo, de conteúdo recuperado, de respostas de ferramentas ou de instruções fornecidas por outro agente. O software pode mudar de rota sem alterar seu objetivo declarado.
Essa flexibilidade é a origem da utilidade de um agente. Também é por isso que o acesso amplo e permanente representa um risco especialmente grave. Um agente comprometido ou manipulado pode usar permissões válidas enquanto se comporta fora da intenção do operador.
O NIST identificou esse problema de identidade como prioridade. Sua iniciativa de padrões para agentes abrange segurança, identidade, interoperabilidade e padrões liderados pelo setor para agentes autônomos.
A agência descreve agentes como sistemas capazes de realizar ações autônomas em e-mail, calendários, desenvolvimento de software, compras e outros fluxos de trabalho. Sua utilidade depende de conexões com sistemas externos e dados internos.
Essas conexões criam diversas questões sobrepostas. A organização consegue distinguir um agente do funcionário que o iniciou? Consegue identificar o proprietário e a origem do software do agente? Consegue provar qual autoridade sustentou uma ação específica?
O compartilhamento de credenciais torna essas respostas mais difíceis. Um funcionário pode conectar um assistente usando um token empresarial pessoal. Aplicações downstream então veem a identidade do funcionário, mesmo quando um agente selecionou e executou a ação.
Esse arranjo enfraquece a responsabilização. A aplicação pode registrar uma solicitação válida de usuário sem revelar se uma pessoa aprovou a transação específica. Investigadores de segurança recebem um registro tecnicamente preciso, mas sem o contexto mais importante.
O risco aumenta quando agentes delegam trabalho. Um agente principal pode chamar um agente especializado, que então invoca uma ferramenta por meio de um serviço separado. Cada transferência pode obscurecer o usuário original, a tarefa aprovada e o escopo restante.
O acesso no nível da tarefa oferece um modelo melhor. Um agente recebe apenas os recursos e ações necessários para uma atribuição. A autoridade expira quando a tarefa é concluída, muda materialmente ou viola uma condição definida.
No entanto, o privilégio mínimo se torna mais difícil quando o caminho necessário não é totalmente previsível. Um agente de pesquisa pode descobrir que precisa de uma fonte de dados após iniciar seu trabalho. Conceder todas as permissões possíveis derrota o propósito da delimitação por tarefa.
As empresas, portanto, precisam de autorização dinâmica. Um sistema de políticas deve avaliar identidade, tarefa, recurso, contexto e ação solicitada à medida que o fluxo de trabalho muda. Etapas de alto risco podem exigir nova aprovação sem interromper toda ação rotineira.
Essa é a pressão por trás da Blueprint Alliance em termos práticos. As empresas querem agentes capazes de agir em ambientes de software fragmentados. As equipes de segurança precisam que essas ações permaneçam atribuíveis e limitadas em cada transferência.
O Principal Equilíbrio É Entre Acesso Útil e Autoridade Controlável
A aliança só terá sucesso se limitar a autoridade dos agentes sem reduzir cada fluxo de trabalho a aprovações humanas repetidas.
Um agente sem acesso a sistemas é pouco mais que uma interface conversacional. Um agente com acesso irrestrito pode se tornar um administrador sem monitoramento. As implantações empresariais precisam operar entre esses dois extremos.
Considere um agente que prepara uma atualização semanal de vendas. Ele pode ler registros de CRM, recuperar dados de produtos, analisar reuniões recentes, redigir recomendações e publicar um resumo. Esse fluxo de trabalho cruza informações pertencentes a diversos sistemas e equipes de negócios.
O agente não precisa de autoridade para excluir registros de clientes ou alterar territórios de vendas. Pode precisar de acesso de leitura a detalhes da conta, mas apenas de permissão temporária para publicar um documento. Seu escopo deve acompanhar a tarefa.
A identidade fornece a âncora para essas decisões. A organização precisa de um registro único do agente, de seu proprietário, de seu desenvolvedor e de suas capacidades aprovadas. Essa identidade deve permanecer visível quando o agente delega parte do trabalho.
A orientação de identidade do NIST afirma que os agentes devem ter identificadores, credenciais e direitos exclusivos. Essas propriedades devem permanecer conectadas à pessoa ou ao sistema que opera o agente.
Tecnologias existentes oferecem parte da base. OAuth pode delegar acesso limitado sem compartilhar uma senha. Sistemas de identidade de workload podem autenticar processos de software. Mecanismos de políticas podem avaliar o acesso a recursos com base em condições definidas.
Ainda assim, essas ferramentas não capturam automaticamente a intenção de um agente. Um token válido pode mostrar que um software tinha permissão para chamar uma API. Não prova que a ação resultante correspondia à tarefa aprovada por um usuário.
Essa distinção separa autenticação de governança. A autenticação responde quem ou o que apresentou uma credencial. A autorização determina o que essa identidade pode fazer. A governança conecta essas permissões à propriedade, propósito, supervisão e revisão.
O comportamento em runtime acrescenta outra camada. Um agente pode começar dentro da política e depois recuperar instruções maliciosas de um documento. A injeção indireta de prompt ocorre quando conteúdo não confiável manipula um modelo por meio de dados que o agente foi solicitado a processar.
Uma arquitetura segura deve presumir que a aprovação antes da execução não é suficiente. O monitoramento deve comparar as ações do agente com sua tarefa declarada e seus limites permitidos. Os defensores também precisam da capacidade de pausar ou encerrar a execução.
A reversibilidade é particularmente importante. Interromper um agente impede ações adicionais, mas não desfaz uma mensagem, alteração no banco de dados ou transação externa. Os sistemas precisam de mecanismos de reversão sempre que a aplicação subjacente os suportar.
Algumas ações não podem ser revertidas. Um segredo divulgado não pode voltar a ser privado. Um pagamento enviado para fora da organização pode não retornar imediatamente. Um comando destrutivo pode eliminar dados antes que o monitoramento gere um alerta.
A Blueprint Alliance não pode resolver essas restrições específicas de aplicações com um único controle. Ela pode definir como os produtos trocam sinais de identidade, autorização, telemetria e resposta. Cada plataforma ainda precisa aplicar a ação relevante.
É por isso que a tensão principal é um equilíbrio, não uma simples lacuna técnica. Um acesso mais amplo aumenta o que os agentes podem realizar. Restrições mais fortes reduzem a exposição, mas também podem interromper fluxos de trabalho e aumentar a carga de aprovações.
O melhor resultado não é autonomia ilimitada nem confirmação humana constante. É autonomia condicional, em que ações de baixo risco seguem adiante e etapas sensíveis acionam verificações mais rigorosas. Alcançar esse equilíbrio entre 12 fornecedores exige mais do que concordância sobre princípios.
A Segurança de Agentes de IA da CrowdStrike Agora Abrange Diversas Alianças
A CrowdStrike está construindo uma posição ampla em segurança de agentes, mas coalizões sobrepostas também podem gerar confusão sobre as entregas.
A Blueprint Alliance é diferente da Open Secure AI Alliance, à qual a CrowdStrike aderiu no início de 2026. Os nomes soam semelhantes, e ambas tratam de segurança de IA, mas suas abordagens declaradas diferem.
A CrowdStrike se descreveu como parceira inaugural da coalizão de segurança aberta em 27 de julho. Essa iniciativa apoiada pela Nvidia enfatiza modelos abertos, pesquisa compartilhada, ferramentas de segurança, avaliação e defesa coletiva.
A Blueprint Alliance concentra-se mais especificamente em uma arquitetura multiforncedor para agentes corporativos. Seus temas centrais são descoberta, identidade, acesso com escopo definido, delegação rastreável, monitoramento em tempo de execução e contenção.
A CrowdStrike também oferece seus próprios produtos de criação e segurança de agentes. O Charlotte AI AgentWorks permite que organizações criem agentes de segurança personalizados dentro da plataforma Falcon. A CrowdStrike afirma que o ambiente inclui governança e mecanismos de proteção.
O ecossistema AgentWorks da empresa oferece suporte a modelos e infraestrutura de diversos provedores. Isso dá à CrowdStrike um interesse comercial direto nas regras que regem agentes corporativos.
A participação em produtos, parcerias bilaterais e coalizões pode fortalecer a influência da CrowdStrike. Ela dá à empresa acesso a diversas camadas de discussão técnica, da pesquisa aberta em segurança à aplicação de controles empresariais.
Também pode fragmentar a atenção. As empresas agora enfrentam múltiplas alianças, frameworks, arquiteturas de produtos e padrões propostos. Vocabulário semelhante não garante implementação compatível.
Uma arquitetura de referência documenta componentes e relacionamentos. Ela não fornece necessariamente um protocolo, certificação, suíte de testes ou integração em produção. Compradores devem diferenciar concordância arquitetural de interoperabilidade comprovada.
A amplitude da Blueprint Alliance é uma vantagem se os membros contribuírem com conexões funcionais entre seus sistemas. Torna-se uma fraqueza se cada fornecedor apenas mapear os princípios aos produtos existentes sem um comportamento técnico comum.
Por exemplo, todos os membros podem apoiar a ideia de descoberta de agentes enquanto usam identificadores e formatos de inventário diferentes. Todos podem endossar a contenção enquanto expõem controles de desligamento incompatíveis.
O grupo precisará de definições concretas. O que conta como agente? Como um subagente efêmero é registrado? Qual sistema detém a identidade autoritativa? Como a autoridade delegada transita entre limites de nuvem e aplicação?
Também é necessário um modelo comum de eventos. O monitoramento em tempo de execução é menos útil se um produto não puder interpretar a telemetria de outro. A resposta a incidentes desacelera quando as equipes precisam reconstruir cadeias de identidade e autorização a partir de logs desconexos.
A validação independente também será importante. Fornecedores fundadores têm incentivos para moldar um mercado emergente em torno de suas plataformas. Sua participação é valiosa, mas não substitui testes feitos por clientes, pesquisadores ou órgãos de padronização.
Os consultores estratégicos GE Appliances e World Central Kitchen podem ajudar a manter o trabalho ligado a operações reais. Ambientes de manufatura, logística humanitária e software corporativo criam diferentes níveis de tolerância a atrasos, autonomia e falhas.
Ainda assim, dois consultores não podem representar todos os modelos de implantação. Transações financeiras, fluxos de trabalho de saúde, desenvolvimento de software e agentes voltados ao consumidor introduzem requisitos distintos de responsabilização. A arquitetura precisa permanecer adaptável sem se tornar vaga.
Para compradores corporativos, a resposta prudente é interesse sem suposições. A lista de membros sinaliza que grandes fornecedores reconhecem um problema compartilhado. Ela ainda não prova que seus produtos funcionam como um único sistema governado.
Uma Arquitetura de Referência Ainda Não É um Padrão Aplicável
A maior incerteza é se a aliança publicará interfaces testáveis em vez de um documento de design alinhado a fornecedores.
O anúncio de lançamento estabelece princípios e uma estrutura de coalizão. Ele não estabelece um padrão obrigatório. Tampouco descreve uma autoridade de certificação ou um processo vinculante de conformidade.
Essa distinção importa porque arquiteturas voluntárias podem melhorar o planejamento sem alterar o comportamento dos produtos. Uma empresa pode alegar alinhamento com conceitos amplos, como privilégio mínimo e monitoramento contínuo, enquanto os implementa de maneiras diferentes.
A escala projetada da aliança também merece atribuição cuidadosa. Seu anúncio cita uma previsão da Gartner de que uma empresa global média da Fortune 500 usará mais de 150.000 agentes até 2028. Também afirma que apenas 13% das organizações acreditam ter governança adequada.
Esses números foram apresentados por meio do anúncio da coalizão. Mesmo que a quantidade de agentes cresça rapidamente, a definição de agente afetará fortemente qualquer total. Assistentes persistentes, subagentes de curta duração, automações e invocações de ferramentas não devem ser contabilizados de forma intercambiável.
A descoberta torna-se difícil antes que uma organização alcance algo próximo dessa escala. Funcionários podem autorizar assistentes externos sem uma implantação central. Desenvolvedores podem criar agentes temporários durante testes. Produtos SaaS podem adicionar agentes incorporados por meio de atualizações rotineiras.
Por isso, um inventário deve combinar vários sinais. Sistemas de identidade podem mostrar credenciais e permissões de aplicativos. Plataformas de nuvem podem mostrar cargas de trabalho. Ferramentas de segurança podem observar processos, atividade de rede e comportamento de APIs.
Nenhum sinal isolado captura com confiabilidade todos os agentes. Um agente pode existir brevemente, usar uma credencial compartilhada ou operar dentro de outro aplicativo. É por isso que a estrutura multiforncedor da aliança faz sentido.
No entanto, a interoperabilidade introduz suas próprias questões de confiança. Os fornecedores precisam decidir quais dados de identidade, contexto de autorização e telemetria comportamental trocarão. Os clientes precisarão de controles sobre quanta informação sensível transita entre plataformas.
Falsos positivos apresentam outro risco. A contenção automatizada pode interromper trabalho legítimo se o monitoramento interpretar incorretamente uma ação incomum. Uma contenção fraca mantém um agente perigoso ativo. A arquitetura precisa de formas de calibrar a resposta conforme o impacto e a confiança.
Os controles humanos também exigem projeto cuidadoso. Exigir aprovação para cada decisão elimina grande parte do ganho de produtividade. Permitir que operadores aprovem categorias amplas pode recriar acesso permanente sob outro nome.
A coalizão deveria definir propriedades mensuráveis. Um produto participante poderia comprovar que preserva o histórico de delegação durante uma transferência. Outro teste poderia verificar que uma autoridade revogada interrompe o acesso em serviços conectados dentro de um intervalo definido.
Suítes de teste permitiriam que clientes comparassem implementações. Esquemas compartilhados ajudariam plataformas a trocar dados de inventário e atividade. A certificação poderia mostrar que um produto cumpre requisitos básicos sem implicar segurança completa.
A aliança também deveria documentar o comportamento em caso de falha. A arquitetura de segurança frequentemente descreve o caminho pretendido, dando menos atenção a serviços de política indisponíveis, telemetria atrasada ou revogação parcial.
Um agente não deveria obter autoridade mais ampla porque um controle se tornou inacessível. Ainda assim, uma resposta de negação por padrão pode interromper processos essenciais de negócio. O modo de falha apropriado depende da tarefa e de suas consequências.
Até que esses mecanismos apareçam, a Blueprint Alliance continua sendo uma proposta séria, e não uma camada de segurança verificada. Seu valor está em alinhar as categorias certas de fornecedores em torno das perguntas certas. A execução determinará se esse alinhamento muda o risco.
Três Sinais Mostrarão se a Aliança Pode Cumprir o que Promete
O próximo teste não é outro anúncio de adesão, mas evidências de que a arquitetura funciona entre produtos operados de forma independente.
O primeiro sinal é uma especificação técnica publicada. A aliança deveria definir campos de identidade de agentes, registros de delegação, contexto de autorização, formatos de telemetria e interfaces de resposta.
Uma especificação detalhada fortaleceria o argumento de que os membros pretendem construir controles compartilhados. Um framework de alto nível com mapeamentos específicos por produto o enfraqueceria, pois os clientes ainda precisariam de integração personalizada.
O segundo sinal é uma demonstração multiforncedor funcional. Um exemplo crível deveria acompanhar um agente entre sistemas de identidade, nuvem, dados, aplicações e segurança.
A demonstração deveria mostrar permissões delimitadas por tarefa, trabalho delegado, monitoramento em tempo de execução e revogação. Também deveria mostrar como investigadores reconstroem a cadeia após uma ação insegura.
Essa evidência revelaria se a segurança de agentes de IA da CrowdStrike pode consumir contexto de identidade e atividade de outros membros da aliança. Também mostraria se esses sistemas podem agir com base nas detecções da CrowdStrike.
O terceiro sinal é o teste independente. O NIST, parceiros empresariais de design, pesquisadores de segurança ou outro grupo neutro deveriam avaliar como a arquitetura lida com compartilhamento de credenciais, injeção indireta de prompts, permissões excessivas e agentes comprometidos.
Resultados independentes fortaleceriam as alegações de segurança da aliança. Testes atrasados, demonstrações fechadas ou apenas autoatestações deixariam a questão central sem resposta.
Os compradores não precisam esperar para melhorar seus próprios controles. Podem inventariar os agentes atuais, eliminar credenciais compartilhadas, atribuir proprietários claros e restringir permissões persistentes.
As equipes também devem documentar quais ações exigem aprovação humana e quais podem prosseguir automaticamente. Todo fluxo de trabalho sensível precisa de registros que conectem o agente, o usuário, a tarefa, a permissão, a ferramenta e o resultado.
Organizações que desenvolvem agentes internos podem manter materiais de origem, aprovações e decisões operacionais em uma base de conhecimento de IA pesquisável. Esse registro não substitui a telemetria de segurança, mas pode preservar o contexto de negócio por trás das implantações de agentes.
A CrowdStrike Blueprint Alliance é importante porque identifica o plano de controle que falta às empresas. Os agentes precisam ser descobertos, identificáveis individualmente, autorizados de forma restrita, observados continuamente e rapidamente contidos.
Agora, seus membros precisam traduzir esse consenso em comportamento interoperável. Equipes empresariais devem pedir aos fornecedores esquemas, testes, garantias de revogação e demonstrações entre plataformas. Essas respostas mostrarão se a aliança está construindo infraestrutura compartilhada ou apenas um vocabulário compartilhado.
