A Segurança de ERP Tem Dificuldade para Acompanhar os Agentes de IA

O BankInfoSecurity trouxe ao Google News um conflito incômodo: os controles de segurança de ERP têm dificuldade para acompanhar o ritmo à medida que agentes de IA ganham autoridade operacional.

A questão não é se um assistente consegue resumir uma fatura ou responder a uma pergunta sobre compras. O risco começa quando um agente pode recuperar registros, acionar ferramentas, alterar transações e coordenar ações entre diversos sistemas empresariais.

SAP, Oracle, Microsoft e Workday estão conduzindo os softwares de ERP nessa direção. Seus agentes prometem reduzir o trabalho repetitivo em finanças, compras, recursos humanos e cadeias de suprimentos. Ainda assim, os controles em torno desses agentes continuam herdando pressupostos concebidos para funcionários humanos e aplicações previsíveis.

Essa incompatibilidade cria o problema central de segurança. A governança tradicional de ERP pergunta qual pessoa tem determinada função e quais transações essa função permite. Sistemas agênticos introduzem objetivos delegados, contexto variável, seleção de ferramentas e transferências de máquina para máquina.

Um agente pode ter credenciais válidas e, ainda assim, tomar uma ação insegura. Ele também pode combinar diversas etapas individualmente permitidas em um resultado que nenhum administrador pretendia.

Fornecedores de ERP estão adicionando controles de identidade, etapas de aprovação e recursos de auditoria. Essas medidas são importantes, mas não eliminam o conflito mais profundo entre a autonomia dos agentes e os controles empresariais determinísticos.

O Alerta do Google News É Sobre Autoridade, Não Chatbots

A mudança importante é que os agentes de IA em ERP estão deixando de apenas ler dados corporativos para agir sobre eles.

A reportagem sobre segurança de ERP que apareceu no Google News apresenta o problema como uma corrida entre a expansão das capacidades dos agentes e uma adaptação mais lenta da segurança.

Esse enquadramento é importante porque sistemas de ERP contêm a verdade operacional de uma empresa. Eles armazenam instruções de pagamento, registros de funcionários, condições de fornecedores, posições de estoque, saldos de clientes e aprovações financeiras.

Um chatbot convencional pode produzir uma resposta incorreta. Um agente de ERP com direitos de execução pode transformar uma resposta incorreta em um lançamento contábil registrado ou em uma alteração de fornecedor aprovada.

IA agêntica refere-se a software capaz de interpretar um objetivo, criar um plano, escolher ferramentas e executar diversas etapas com supervisão limitada. Isso difere da automação fixa, que segue um caminho predefinido.

Um fluxo de trabalho tradicional pode rejeitar uma fatura sempre que falta um pedido de compra. Um agente pode investigar a divergência, recuperar correspondências, comparar registros de entrega e recomendar uma exceção.

Essa flexibilidade gera valor porque processos empresariais reais contêm ambiguidades. Ela também reduz a previsibilidade da qual muitos controles de segurança existentes dependem.

As equipes de segurança podem examinar um fluxo de trabalho fixo antes da implantação. Elas sabem quais campos ele lê, quais chamadas de sistema realiza e quais condições acionam uma aprovação.

Um agente pode escolher uma sequência diferente a cada vez. Seu comportamento pode mudar conforme o prompt, as ferramentas disponíveis, os documentos recuperados, a versão do modelo ou a conversa ao redor.

Isso significa que a autorização não pode terminar no login. A segurança precisa avaliar a identidade do agente, a finalidade delegada, o contexto atual, a ferramenta selecionada, os dados solicitados e o efeito pretendido.

O problema se torna mais difícil quando um agente cruza os limites entre aplicações. Um agente financeiro pode consultar e-mails, registros de compras, dados de clientes e um sistema de pagamentos antes de concluir uma única tarefa.

Cada conexão amplia a superfície de ataque. Ela também torna mais difícil atribuir responsabilidades quando diversos componentes contribuem para um resultado inseguro.

Leitores do Google News podem inicialmente interpretar a história como mais um alerta sobre a precisão da IA generativa. A questão subjacente é mais consequente.

As equipes de segurança de ERP precisam governar um software que se comporta menos como uma aplicação passiva e mais como um trabalhador altamente conectado. Esse trabalhador pode operar continuamente, na velocidade das máquinas e além das fronteiras organizacionais.

A mudança pressiona diretores de segurança da informação, administradores de ERP, equipes de identidade, auditores internos e responsáveis pelos processos empresariais. Nenhum desses grupos consegue gerenciar o risco sozinho.

As equipes de segurança entendem de controle de acesso, mas podem não ter um contexto detalhado dos processos. Líderes financeiros entendem as consequências materiais, mas talvez não enxerguem todas as dependências técnicas.

Administradores de ERP entendem funções e transações. Eles podem não controlar modelos externos, frameworks de agentes ou ferramentas de terceiros conectadas ao fluxo de trabalho.

O desafio imediato, portanto, é organizacional e técnico. As empresas precisam de um modelo de controle único que acompanhe um agente desde a instrução inicial até cada ação resultante.

Os Agentes de IA em ERP Quebram o Modelo de Identidade Humana

Uma identidade válida já não prova que uma ação é apropriada quando o software pode reinterpretar objetivos e escolher seu próprio caminho de execução.

Os controles de ERP tradicionalmente se concentram em usuários identificados, funções atribuídas e segregação de funções. A segregação de funções impede que uma única pessoa controle etapas incompatíveis de um processo sensível.

Por exemplo, o funcionário que cria um fornecedor não deve aprovar de forma independente pagamentos a esse fornecedor. A regra limita fraudes e reduz o impacto de credenciais comprometidas.

Os agentes complicam esse modelo porque a autoridade pode passar por diversas camadas. Uma pessoa instrui um agente, o agente chama outro agente, e esse agente aciona uma aplicação empresarial.

O sistema final pode enxergar apenas uma identidade de serviço autenticada. Ele pode não receber o usuário original, a finalidade, as evidências ou os limites associados à solicitação.

Isso cria um problema de cadeia de delegação. Cada sistema reconhece seu chamador imediato, enquanto a origem e a intenção completas da ação se tornam mais difíceis de reconstruir.

Credenciais compartilhadas entre agentes agravam o problema. Se diversos fluxos de trabalho usam uma única conta de serviço, investigadores podem ter dificuldade para distinguir automação legítima de uso indevido.

Credenciais persistentes também permitem que a autoridade sobreviva à sua finalidade original. Um agente criado para um projeto temporário de reconciliação pode manter o acesso depois que esse trabalho termina.

Revisões de acesso humano normalmente giram em torno de eventos empregatícios e funções fixas. Agentes podem surgir, mudar, se duplicar e desaparecer muito mais rápido que funcionários.

Eles também podem ser montados fora dos processos formais de desenvolvimento. Uma equipe de negócios pode conectar um modelo a uma ferramenta aprovada sem perceber que a combinação cria uma nova identidade privilegiada.

O framework de segurança agêntica da OWASP identifica o abuso de identidade e privilégios entre seus riscos centrais. Ele também destaca o sequestro de objetivos, o uso indevido de ferramentas e vulnerabilidades na cadeia de suprimentos agêntica.

O sequestro de objetivos ocorre quando conteúdo malicioso ou não confiável muda o que um agente tenta realizar. A instrução prejudicial pode estar em um documento, mensagem, página da web ou resposta de ferramenta.

Isso é mais perigoso dentro de um ERP do que em um assistente independente. O agente já pode ter acesso a registros confidenciais e funções de transação.

Considere um agente de compras que lê e-mails de fornecedores. Uma mensagem comprometida poderia instruir o modelo a priorizar uma conta bancária controlada por um atacante ou revelar dados internos de compras.

A solicitação poderia conflitar com o objetivo original do usuário. Ainda assim, o agente poderia tratar o texto incorporado como contexto operacional relevante, a menos que proteções separem dados de instruções.

O princípio do menor privilégio continua necessário, mas sua implementação precisa se tornar mais precisa. Um agente deve receber apenas as permissões necessárias para uma finalidade e um período limitados.

As orientações de operações seguras da Oracle deixam essa distinção explícita. Um agente de análise não precisa de direitos de aprovação de compras simplesmente porque ambos participam de um fluxo de trabalho.

O princípio parece familiar, mas os agentes tornam sua aplicação mais difícil. Seus planos podem evoluir depois que uma tarefa começa, e eles podem solicitar ferramentas adicionais durante a execução.

Funções estáticas não conseguem expressar plenamente condições como finalidade, valor da transação, sensibilidade dos dados, nível de confiança ou se outro agente iniciou a solicitação.

Por isso, as empresas precisam de verificações de política no momento da ação. Essas verificações devem avaliar tanto a operação solicitada quanto o contexto ao seu redor.

Ações de alto impacto também exigem evidências mais robustas da intenção humana. Um botão de confirmação é insuficiente se o revisor vê apenas um resumo refinado produzido pelo mesmo agente.

O revisor precisa das evidências originais, das alterações propostas, das exceções de política e do efeito empresarial esperado. Caso contrário, a supervisão humana se torna cerimonial.

A Verdadeira Troca É Entre Autonomia e Controle

Cada aumento na autonomia dos agentes eleva a exigência sobre identidade, aplicação de políticas, observabilidade e recuperação.

Agentes de IA em ERP se tornam úteis quando conseguem lidar com exceções. No entanto, as exceções são exatamente onde os controles determinísticos oferecem menor cobertura.

Uma automação fixa segue caminhos definidos antecipadamente pelos desenvolvedores. Um agente interpreta informações incompletas e decide qual caminho parece apropriado.

Essa distinção cria uma troca de segurança. Restringir demais um agente faz dele uma interface cara para fluxos de trabalho existentes. Conceder autoridade mais ampla faz com que seus erros ganhem consequências operacionais.

O conflito não desaparece quando um agente permanece dentro da nuvem de um fornecedor. Um ambiente controlado pode reduzir a exposição, mas a lógica de negócio ainda determina se uma ação é aceitável.

Um agente pode ter permissão para atualizar registros de fornecedores. Essa permissão não significa que toda atualização de fornecedor atenda a uma finalidade legítima.

Um agente também pode combinar capacidades de baixo risco em uma sequência de alto risco. Ler faturas, criar fornecedores e preparar pagamentos parecem administráveis quando avaliados separadamente.

Juntas, essas capacidades podem reproduzir um caminho completo de fraude. Isso às vezes é chamado de risco composicional, quando componentes aparentemente seguros produzem um resultado combinado inseguro.

Ferramentas de segurança frequentemente inspecionam chamadas individuais de API. Elas podem aprovar cada etapa enquanto deixam de perceber o plano mais amplo que as conecta.

A memória do agente cria outra dificuldade. A memória permite que o software retenha contexto de tarefas, preferências ou observações anteriores entre interações.

Essa continuidade pode melhorar o desempenho. Ela também pode preservar instruções maliciosas, dados sensíveis ou pressupostos incorretos além da sessão em que entraram no sistema.

A geração aumentada por recuperação, ou RAG, fornece a um modelo informações empresariais selecionadas ao responder ou agir. Sua segurança depende da origem, das permissões, da qualidade e da atualidade do material recuperado.

Uma fonte de conhecimento contaminada pode distorcer decisões posteriores sem comprometer diretamente o modelo subjacente. Um documento de política desatualizado pode criar um resultado semelhante por meio de uma falha operacional comum.

Isso torna a governança da informação parte da segurança de agentes de IA. As equipes precisam saber quais fontes um agente utiliza, quem pode alterá-las e como as evidências recuperadas afetam as decisões.

Os funcionários que desenvolvem fluxos de trabalho internos também precisam de documentação confiável. Uma base de conhecimento pesquisável pode ajudar as equipes a preservar decisões de design, modelos de ameaças e requisitos de aprovação relacionados à implementação de agentes.

A documentação não substitui controles técnicos. Ela pode reduzir a chance de que premissas críticas desapareçam quando um agente muda de responsável ou passa do piloto para a produção.

O acesso a ferramentas cria um risco paralelo. As ferramentas traduzem a saída do modelo em ações, como consultar um banco de dados, enviar uma mensagem ou modificar um registro comercial.

O modelo não precisa de credenciais diretas do banco de dados se uma ferramenta conectada já as detém. Portanto, a ferramenta passa a fazer parte do limite efetivo de permissões do agente.

As revisões de segurança precisam examinar esquemas de ferramentas, validação de entrada, armazenamento de credenciais, filtragem de saída e comportamento em caso de falha. Revisar apenas o modelo deixa de fora a maior parte do caminho de execução.

Sistemas multiagente aumentam ainda mais a incerteza. Um agente pode delegar pesquisas, outro pode interpretar políticas e um terceiro pode executar a transação.

Cada transferência pode perder contexto ou introduzir saídas não confiáveis. Ela também pode obscurecer qual componente tomou a decisão que causou o dano.

A arquitetura de segurança publicada pela SAP acompanha solicitações de agentes por meio de verificação de identidade, processamento de IA, execução comercial e registro forense.

Essa visão de ponta a ponta aponta na direção certa. No entanto, diagramas de arquitetura não comprovam que todas as implementações de clientes aplicam os controles de forma consistente.

Ambientes de ERP contêm código personalizado, integrações legadas, sistemas adquiridos, parceiros externos e exceções de longa duração. Essas diferenças podem enfraquecer o modelo de segurança padrão de um fornecedor.

As implementações mais difíceis envolverão ambientes híbridos. Um agente pode começar em um serviço moderno de nuvem, mas atuar por meio de aplicativos mais antigos, com permissões amplas e telemetria limitada.

Nesses ambientes, o componente mais novo pode herdar o controle mais fraco da cadeia. A autonomia do agente então amplia a dívida técnica que as organizações já tinham dificuldade de administrar.

Os Logs de Auditoria Não Conseguem Explicar Todas as Decisões de Agentes

A segurança de ERP precisa de evidências que conectem a intenção do usuário ao raciocínio do agente, às chamadas de ferramentas, às alterações de dados e aos resultados comerciais.

Os logs de auditoria tradicionais respondem a perguntas conhecidas. Eles mostram qual conta acessou um sistema, quando uma transação ocorreu e qual campo foi alterado.

Fluxos de trabalho agênticos exigem uma cadeia de evidências mais longa. Investigadores precisam do usuário iniciador, do objetivo delegado, da versão do modelo, do contexto recuperado, das decisões de política, das chamadas de ferramentas e do resultado final.

Eles também podem precisar saber o que o agente se recusou a fazer. Solicitações negadas repetidamente podem revelar tentativas de sondagem, configuração incorreta ou uma fonte comprometida.

Registrar todos os prompts e respostas não é uma solução simples. Os prompts podem conter registros de folha de pagamento, contratos, dados pessoais, credenciais e outras informações restritas.

Portanto, um log completo pode criar outro repositório sensível. As regras de retenção, acesso, criptografia e redação precisam corresponder aos dados comerciais subjacentes.

O raciocínio do modelo apresenta outra complicação. Uma explicação gerada pode parecer coerente sem representar com precisão como o sistema chegou à sua saída.

As equipes de segurança não devem tratar uma explicação narrativa como prova. Elas precisam de registros verificáveis das entradas, solicitações de ferramentas, avaliações de políticas e alterações de estado resultantes.

Isso muda o significado de observabilidade. O monitoramento deve captar o comportamento em todo o fluxo de trabalho, e não apenas a disponibilidade do modelo ou erros de API.

Sinais úteis incluem seleção inesperada de ferramentas, volume incomum de transações, acessos fora do escopo comercial normal, negações repetidas de políticas e alterações em registros sensíveis.

As linhas de base também precisam refletir a finalidade atribuída ao agente. Um agente de conciliação de folha de pagamento e um agente de compras não devem compartilhar o mesmo perfil de comportamento normal.

Limites de taxa podem reduzir o raio de impacto de erros. Eles não conseguem determinar se um pequeno número de ações de alto valor é legítimo.

Limites de transação fornecem outra camada. Ainda assim, invasores podem dividir a atividade em ações menores ou explorar processos nos quais uma mudança de baixo valor possibilita uma perda posterior.

As empresas precisam de controles em vários pontos. O ambiente de execução do agente deve restringir ferramentas, a camada de identidade deve restringir autoridade e o ERP deve validar regras de negócio.

O monitoramento independente deve então verificar o que realmente ocorreu. Confiar no mesmo agente para agir, avaliar e relatar seu próprio comportamento concentra confiança demais.

A aprovação humana continua valiosa para ações irreversíveis ou materiais. No entanto, os revisores precisam de tempo e contexto suficientes para detectar manipulação.

A fadiga de aprovação pode transformar uma salvaguarda em formalidade. Agentes operando na velocidade das máquinas podem gerar mais solicitações de revisão do que os funcionários conseguem avaliar com cuidado.

A autonomia baseada em níveis de risco oferece um modelo mais viável. Tarefas reversíveis e de baixo impacto podem prosseguir automaticamente, enquanto ações sensíveis exigem validação independente.

Exemplos de trabalho de menor risco incluem redigir explicações, coletar evidências e sinalizar anomalias. Trabalhos de maior risco incluem alterar dados de pagamento, liberar recursos ou modificar acessos.

A reversibilidade deve influenciar o nível de controle. Um relatório equivocado pode ser corrigido, enquanto um pagamento externo ou um registro excluído pode causar danos duradouros.

O perfil de risco do NIST organiza o trabalho de risco de IA em torno de governança, mapeamento, medição e gestão. Essa abordagem de ciclo de vida se adapta melhor a agentes de ERP do que uma aprovação única.

O risco de um agente muda quando suas ferramentas, modelo, fontes de dados, permissões ou finalidade comercial mudam. Cada modificação deve acionar uma reavaliação e testes direcionados.

Os testes devem incluir entradas adversariais e exceções comerciais realistas. Uma demonstração baseada em dados limpos não revelará como um agente se comporta diante de instruções conflitantes.

As equipes também devem testar falhas parciais. Um sistema downstream pode expirar depois que um agente conclui uma etapa, mas antes de registrar a próxima.

Sem idempotência, que impede que a execução repetida produza efeitos duplicados, um agente pode enviar novamente a mesma transação durante a recuperação.

Esses problemas comuns de confiabilidade se tornam questões de segurança quando afetam registros financeiros, direitos de acesso ou dados regulados. A segurança de agentes não pode permanecer separada da engenharia de sistemas.

As Proteções dos Fornecedores Encontram a Realidade dos ERPs Personalizados

SAP e Oracle podem proteger suas próprias plataformas de agentes, mas os clientes ainda controlam as integrações, funções, dados e exceções que determinam o risco prático.

Os fornecedores de ERP têm uma vantagem estrutural. Eles entendem seus modelos de aplicações e podem incorporar agentes ao lado de serviços existentes de identidade, fluxo de trabalho e auditoria.

Agentes nativos podem herdar metadados comerciais que um modelo externo não possui. Eles também podem usar interfaces aprovadas em vez de imitar ações do usuário por meio de uma tela.

A Oracle aconselha os clientes a separar as responsabilidades dos agentes e aplicar o princípio do menor privilégio entre agentes cooperantes. A SAP descreve verificações de identidade, isolamento de locatários, validação de saída e trilhas de auditoria forense.

Esses controles tratam de preocupações reais. Eles também sustentam o argumento dos fornecedores de que agentes incorporados são mais seguros do que automações de terceiros conectadas de forma flexível.

O argumento tem limites. A maioria das grandes organizações não opera um único ambiente de ERP limpo, com configurações padronizadas.

Elas executam processos personalizados em vários sistemas. Alguns aplicativos permanecem on-premises, enquanto outros estão em nuvens públicas ou serviços gerenciados por fornecedores.

Parceiros, contratados, bancos, provedores de logística e unidades de negócio adquiridas podem se conectar ao mesmo processo. Cada limite introduz um modelo diferente de identidade e controle.

Um agente financeiro nativo ainda pode receber conteúdo não confiável por e-mail. Ele pode depender de um analisador de documentos de terceiros ou enviar um resultado para um aplicativo de pagamentos mais antigo.

O fluxo de trabalho geral é confiável apenas na medida em que essas dependências o são. A documentação de segurança do fornecedor não pode contemplar todas as extensões dos clientes.

Agentes externos apresentam uma troca diferente. Eles podem coordenar o trabalho entre plataformas concorrentes de ERP, CRM, comunicações e análises.

Essa independência pode reduzir a dependência de fornecedores e apoiar fluxos de trabalho mais amplos. Ela também coloca outra identidade, camada de orquestração e ecossistema de ferramentas entre os usuários e os registros comerciais.

A escolha prática, portanto, não é entre software nativo seguro e software externo inseguro. Ambas as abordagens criam riscos, mas concentram esses riscos em lugares diferentes.

Agentes nativos concentram a confiança na plataforma, nuvem e modelo de governança do fornecedor de ERP. Agentes externos distribuem a confiança entre conectores, credenciais, modelos e ferramentas de orquestração.

As equipes de segurança devem avaliar o caminho completo da ação em vez de aceitar rótulos de categoria. Um produto nativo pode se tornar inseguro por meio de uma configuração ampla.

Um produto externo pode reduzir o risco se receber autoridade de escopo restrito e curta duração e não puder concluir diretamente transações sensíveis.

As revisões de compras devem refletir essas diferenças. Questionários padrão de software raramente capturam a profundidade da delegação, o comportamento da memória, o tratamento de prompts ou permissões no nível de ferramentas.

Os compradores devem perguntar qual identidade aparece no log de ERP e se ela identifica o usuário original. Também devem perguntar como a política acompanha uma tarefa nas transferências entre agentes.

Outras perguntas essenciais dizem respeito a atualizações de modelo, contexto retido, residência de dados, resposta a incidentes e acesso do cliente à telemetria detalhada.

O fornecedor deve explicar como os administradores podem suspender imediatamente um agente. Esse controle deve revogar credenciais ativas e interromper ações pendentes, não apenas ocultar a interface.

Os clientes também precisam de evidências sobre gestão de mudanças. O comportamento de um agente pode mudar após alterações no modelo, no prompt de sistema, na definição da ferramenta ou na fonte de recuperação.

Uma atualização tradicional de aplicativo geralmente altera código determinístico. Uma atualização de modelo pode mudar decisões mesmo quando o fluxo de trabalho ao redor permanece inalterado.

Portanto, os testes de segurança devem continuar após a implementação. As equipes devem executar tarefas representativas e casos de abuso sempre que um componente relevante mudar.

Elas devem comparar resultados entre versões e preservar evidências suficientes para investigar regressões. Um teste aprovado há seis meses diz pouco sobre um agente modificado.

A pressão competitiva pode minar essa disciplina. Fornecedores de ERP querem que os clientes adotem agentes, enquanto líderes de negócio querem melhorias mensuráveis de produtividade.

As equipes de segurança podem sofrer pressão para aprovar pilotos amplos antes que os sistemas de identidade e monitoramento estejam prontos. Essa sequência transforma a governança em um projeto de reparo.

Uma implantação mais segura começa com tarefas delimitadas e resultados observáveis. A autoridade se expande apenas depois que a organização consegue explicar, detectar e reverter o comportamento do agente.

Três Sinais Mostrarão se a Segurança de ERP Acompanha o Ritmo

A próxima fase será decidida por identidades específicas de agentes, aplicação de regras no nível da ação e evidências de incidentes reais em produção.

O primeiro sinal é se as plataformas de ERP adotam identidades distintas e de curta duração para cada agente e tarefa delegada. Contas de serviço compartilhadas devem se tornar uma exceção.

Um design maduro preservará o usuário original, a identidade do agente, a finalidade e a autoridade em todo o fluxo de trabalho. Aplicativos downstream devem receber esse contexto antes de permitir uma ação.

Isso fortaleceria o argumento de que agentes de IA para ERP podem operar dentro de estruturas estabelecidas de responsabilização. A dependência contínua de credenciais amplas o enfraqueceria.

O segundo sinal é se fornecedores e clientes aplicam políticas no nível da transação. A permissão para usar uma ferramenta não deve se transformar em permissão para todos os resultados possíveis dessa ferramenta.

Os controles devem considerar o tipo de transação, o valor, o destino, as evidências de origem e a reversibilidade. Operações sensíveis devem exigir verificações independentes, fora do modelo que executa a ação.

As equipes de segurança devem acompanhar lançamentos de produtos em busca de recursos concretos de aplicação de regras. Linguagem de marketing sobre IA responsável é menos útil do que controles configuráveis e logs exportáveis.

Também devem examinar se esses controles funcionam em aplicações conectadas. Uma proteção limitada à interface de um único fornecedor não cobrirá um fluxo de trabalho multiplataforma.

O terceiro sinal é a qualidade dos relatos públicos de incidentes. Falhas em produção revelarão onde arquiteturas teóricas se rompem sob condições reais de negócio.

Divulgações úteis identificarão a identidade comprometida, a entrada manipulada, as ferramentas afetadas, as ações não autorizadas e o método de contenção. Referências vagas a um erro de IA não ajudarão os defensores.

Os incidentes também devem esclarecer se havia aprovação humana e por que ela falhou. Essas evidências mostrarão se a supervisão reduz riscos ou apenas transfere responsabilidades.

A tese central por trás do alerta do Google News se fortalecerá se os agentes se expandirem mais rapidamente do que esses três controles. Ela enfraquecerá se identidade, aplicação de regras e evidências amadurecerem juntas.

As organizações não devem esperar uma grande perda antes de mapear sua própria exposição. Elas podem começar listando cada agente conectado a um processo de ERP.

Esse inventário deve incluir responsável, finalidade, modelo, ferramentas, fontes de dados, credenciais, pontos de aprovação e procedimento de desligamento. Entradas desconhecidas merecem investigação imediata.

Em seguida, as equipes devem rastrear alguns fluxos de trabalho de alto impacto, da instrução à transação final. Alterações de pagamento, concessões de acesso, lançamentos contábeis e atualizações de registros de funcionários são bons pontos de partida.

O exercício exporá contextos ausentes entre sistemas. Também revelará onde uma credencial ou ferramenta detém mais autoridade do que a tarefa de negócio exige.

As empresas devem então classificar as ações por impacto e reversibilidade. Pesquisas somente de leitura não precisam dos mesmos controles que a liberação de recursos ou a alteração de dados mestres.

Por fim, os líderes de segurança devem testar como a organização responde quando um agente se comporta incorretamente. A detecção sem contenção deixa a questão mais importante sem resposta.

Os administradores conseguem interromper o agente, revogar sua autoridade, preservar evidências, reverter a ação e identificar registros afetados antes que o dano se espalhe?

A segurança de ERP não precisa eliminar a autonomia. Ela precisa garantir que a autonomia nunca se torne autoridade sem limites.

O próximo passo prático é simples: escolha um fluxo de trabalho de agente ativo ou planejado e rastreie cada identidade, ferramenta, fonte de dados e aprovação que ele utiliza. Se sua equipe não consegue explicar essa cadeia, o agente não está pronto para um acesso mais amplo.

Pergunte quem pode interrompê-lo, quais evidências permanecem e quais ações podem ser revertidas. Essas respostas importam mais do que outra demonstração bem produzida.

O Google News trouxe o alerta à tona. Agora, as equipes empresariais precisam decidir se seus controles de ERP governam agentes com o mesmo cuidado com que governam pessoas.