A inteligência artificial está mudando a maneira como as empresas executam seus processos. Sistemas que antes dependiam de instruções rígidas já conseguem interpretar solicitações, consultar informações, identificar exceções e coordenar diferentes etapas de uma operação. Com a evolução dos agentes de IA, essa capacidade avança mais um passo: além de produzir respostas, esses sistemas podem utilizar ferramentas, acessar aplicações corporativas e executar ações em nome de usuários ou da própria organização.

Mas existe uma diferença importante entre permitir que uma IA analise uma situação e conceder a ela capacidade para modificar o ambiente empresarial, por exemplo:

Imagine um agente responsável por apoiar o processo de compras. Ele recebe uma solicitação, consulta o fornecedor, verifica condições comerciais e prepara um pedido. Se encontrar uma inconsistência, pode encaminhar o caso para revisão.

Agora considere que o mesmo agente também tenha permissão para alterar cadastros, aprovar solicitações ou iniciar pagamentos. Uma interpretação incorreta, uma permissão excessiva ou uma instrução maliciosa deixa de representar apenas uma resposta inadequada: pode produzir consequências financeiras, operacionais e de segurança.

É nesse cenário que a segurança dos processos assume uma nova dimensão. O desafio não está somente em proteger a inteligência artificial, mas em garantir que sua capacidade de atuação permaneça compatível com as regras, responsabilidades e limites da organização.

Quando o agente passa a fazer parte da operação

Um agente de IA combina um modelo de inteligência artificial com instruções, contexto, memória e ferramentas capazes de participar da execução de uma tarefa orientada a objetivos.

Em um ambiente corporativo, essas ferramentas podem incluir consultas a bancos de dados, APIs, sistemas de gestão, repositórios documentais e serviços internos. A integração amplia a utilidade da IA, mas também muda a superfície de risco.

Em uma aplicação convencional, a organização define de antemão quais operações estão disponíveis para cada usuário ou serviço. Em um processo agêntico, o sistema pode selecionar dinamicamente qual ferramenta utilizar e em que sequência, conforme a tarefa recebida. Essa diferença importa porque a mesma capacidade que torna o agente flexível também pode ampliar o impacto de uma decisão incorreta: uma orientação maliciosa, um dado contaminado ou uma interpretação equivocada pode ser transformada em uma sequência de chamadas a sistemas legítimos.

Essa preocupação já aparece em orientações internacionais de 2026. Órgãos de cibersegurança de cinco países publicaram o documento “Careful Adoption of Agentic Artificial Intelligence (AI) Services”, que recomenda avaliar os riscos antes da adoção de agentes de IA, orientando a começar por tarefas de menor impacto e evitar acesso amplo ou irrestrito a dados sensíveis e sistemas críticos. O agente pode ter autonomia para interpretar e planejar, mas a autoridade para alterar o ambiente empresarial deve ser determinada e aplicada por políticas verificáveis, independentes do modelo.

O risco está no caminho entre a decisão e a execução

Um dos aspectos mais relevantes da segurança de agentes é que uma decisão aparentemente correta não garante, por si só, uma execução segura. Considere:

Um processo de compras com a seguinte política: pedidos de até R$ 5 mil podem ser preparados automaticamente; pedidos acima desse valor exigem aprovação do gestor; alterações nos dados bancários de fornecedores dependem de validação independente.

Um agente recebe uma solicitação de compra de R$ 12 mil. Ele identifica corretamente o fornecedor e o valor, mas interpreta equivocadamente que a aprovação pode ser dispensada. Se a arquitetura permitir que o próprio agente efetive a operação, uma falha de interpretação se transforma em uma ocorrência real.

Uma abordagem mais robusta resolve esse problema ao separar interpretação de autorização:

1. Fase de Interpretação (IA Probabilística): O agente apenas compreende a solicitação do usuário, extrai a intenção e organiza os dados (ex.: “Pedido de R$ 12 mil para o Fornecedor X”).

1. Fase de Validação e Autorização (Regra Determinística):O sistema (e não a IA) aplica a regra de negócio pré-definida. O código verifica que R$ 12 mil excede o limite de R$ 5 mil e bloqueia a execução direta, encaminhando o pedido para a alçada do gestor.

1. Fase de Execução (Ferramenta):A ação só é disparada após a confirmação do sistema determinístico ou da aprovação humana.

Essa separação cria uma fronteira indispensável: o componente probabilístico (a IA) auxilia no entendimento e na preparação da demanda, mas não deve ser a única instância a autorizar operações críticas.

Quando o próprio contexto pode tentar controlar o agente

Entre os riscos característicos de sistemas baseados em modelos de linguagem está o prompt injection, uma vulnerabilidade em que instruções maliciosas ou manipuladas, inseridas nas entradas de dados (como e-mails, documentos ou mensagens), enganam o modelo e o fazem ignorar suas diretrizes originais.

Em aplicações agênticas, esse problema ganha uma dimensão muito mais grave: a informação manipulada recebida pelo modelo não altera apenas o texto de uma resposta, mas pode induzir a escolha incorreta de ferramentas, o disparo não autorizado de chamadas de API ou a alteração indevida de parâmetros em sistemas críticos. No chamado Indirect Prompt Injection, uma instrução maliciosa pode estar escondida em um e-mail, documento, página web ou retorno de ferramenta que o agente foi autorizado a consultar. O conteúdo não deveria possuir autoridade para modificar as regras do processo, mas pode influenciar o comportamento do modelo.

Imagine:

Um agente que analisa pedidos de fornecedores. Um documento contém dados comerciais legítimos e, no meio do conteúdo, uma instrução tentando direcionar o agente a compartilhar um arquivo interno ou ignorar uma validação. O ataque não depende necessariamente de comprometer o ERP. Basta fazer com que um conteúdo não confiável passe a ser tratado como instrução.

Esses cenários de injeção de instruções conduzem a duas falhas graves de alinhamento, chamadas de:

• Goal Hijacking (Sequestro de Objetivo):Ocorre quando a instrução maliciosa substitui completamente a meta do usuário, fazendo o agente abandonar a tarefa original e passar a perseguir uma agenda diferente ou não autorizada.

• Goal Manipulation (Manipulação de Objetivo):Ocorre quando o objetivo fundamental não é totalmente descartado, mas sua interpretação é distorcida de modo que o agente cumpra a demanda original de forma adulterada ou prejudicial.

Quanto mais capacidades de ação forem concedidas à IA, maior será o impacto dessas falhas. É nesse ponto que surge o Tool Misuse (Uso Indevido de Ferramentas), onde a situação em que o agente, sob o efeito de um objetivo sequestrado ou manipulado, invoca ferramentas legítimas de forma inadequada, desnecessária ou com parâmetros nocivos.

Uma instrução maliciosa limitada a um documento gera apenas um texto incorreto; contudo, quando associada ao Tool Misuse, a mesma instrução passa a acionar ferramentas de escrita, disparar e-mails, modificar registros em bancos de dados ou executar transações financeiras.

Menor privilégio, identidade e autorização por contexto

Na segurança tradicional, o princípio do menor privilégio estabelece que usuários e sistemas devem receber somente as permissões necessárias para suas funções. Em processos agênticos, o mesmo princípio precisa ser estendido também à autonomia e ao contexto da execução.

Essa distinção pode ser resumida assim: Least Privilege, que limita onde e o que o agente pode acessar; e Least Agency, que limita o que ele pode decidir ou executar de forma autônoma.

Em vez de disponibilizar ao agente um acesso amplo ao ERP, uma solução pode expor operações específicas: consultar pedido, consultar fornecedor, verificar política de compras, preparar solicitação e solicitar aprovação. A aprovação de pagamento pode permanecer fora do conjunto de ferramentas autorizado ao agente.

Também importa a duração e a origem da autoridade. Credenciais permanentes e compartilhadas dificultam a atribuição de responsabilidade e podem ampliar o impacto de uma execução comprometida. A direção atual das discussões de segurança é aproximar identidade, delegação e autorização do contexto real da tarefa.

Em setembro de 2026, a síntese de comentários do projeto do NIST sobre identidade e autorização de agentes reforçou um ponto especialmente relevante: políticas determinísticas (motor de regras/políticas imutáveis) e sua aplicação devem permanecer no centro do controle, enquanto capacidades probabilísticas (IA/Agente) podem fornecer contexto adicional para decisões mais granulares.

Runtime Enforcement: segurança no momento da ação

Restringir o catálogo de ferramentas de um agente é uma medida necessária, mas ainda não resolve tudo. Uma ferramenta legítima ainda pode ser acionada em contexto inadequado ou com parâmetros nocivos. Por essa razão, a arquitetura de segurança precisa validar a operação no exato momento de sua execução.

O Runtime Enforcement(aplicação de políticas em tempo de execução) consolida essa camada dinâmica de defesa. Antes que a requisição do agente alcance o sistema transacional, esse mecanismo intercepta a chamada e valida critérios fundamentais, como: identidade, autoridade delegada, escopo, precisão dos parâmetros, nível de criticidade, estado atual do processo e necessidade de aprovação humana.

Em setembro de 2026, o OWASP (Open Worldwide Application Security Project, comunidade global de referência em segurança de software) passou a incorporar o Agent Control Standard (ACS), uma proposta que tem como foco estabelecer uma especificação padronizada para interceptar requisições de agentes, aplicando pontos de integração para que políticas declarativas possam ser aplicadas em runtime, com visibilidade e capacidade de controle ao longo da execução. O valor dessa abordagem não está em adicionar mais uma camada de software, mas em separar responsabilidades. O agente interpreta, planeja e solicita. A política autoriza ou bloqueia. A ferramenta executa apenas o que foi autorizado.

Em processos de maior criticidade, essa fronteira pode incluir checagens independentes do modelo, como limites financeiros, estado do pedido, combinação de aprovadores, segregação de funções, validação de campos e regras de integridade. Isso também vale para ecossistemas de ferramentas e protocolos. O MCP (Model Context Protocol) é um padrão aberto que padroniza a conexão de aplicações de IA com fontes de dados e ferramentas externas. Uma integração via MCP, porém, não deve ser tratada como confiável apenas porque está tecnicamente disponível: o servidor, as ferramentas expostas, os privilégios e os fluxos de autorização continuam fazendo parte da superfície de ataque.

Contudo, vale frisar que a superfície de exposição de um agente não se encerra ao final do ciclo de execução. Quando a arquitetura utiliza RAG (Retrieval-Augmented Generation, ou geração aumentada por recuperação), técnica que busca documentos relevantes em fontes externas para fornecer contexto ao modelo, memória de longo prazo ou bases de conhecimento compartilhadas, a segurança do runtime precisa supervisionar também o estado persistente. Existe o risco de Memory Poisoning(envenenamento de memória), que ocorre quando dados maliciosos ou incorretos são gravados no histórico do sistema, perpetuando a influência de uma injeção pontual em interações futuras.

Para mitigar esse risco em fluxos corporativos, o sistema não deve tratar dados capturados pela IA como “verdade operacional” automática. A arquitetura de segurança deve categorizar e isolar o ciclo de vida da informação em três estágios claros: informação observada (leitura bruta), informação validada (checagem determinística de regras) e informação autorizada para persistência(gravação permitida no estado do agente). Dessa forma, garante-se a integridade do ecossistema agêntico tanto na chamada de ferramentas em tempo real quanto no conhecimento acumulado pelo sistema.

Segurança também significa saber quando interromper e recuperar

Mesmo com identidade, permissões e políticas bem definidas, uma execução pode apresentar comportamento anômalo. O agente pode entrar em um ciclo de tentativas, repetir chamadas, consumir recursos acima do previsto ou encontrar uma dependência que deixou de responder corretamente. Por isso, processos agênticos precisam de limites operacionais e mecanismos de recuperação bem definidos.

Para limitar o raio de propagação de falhas, a infraestrutura deve aplicar controles operacionais como:

• Circuit Breakers:interrompem automaticamente sequências de chamadas ao detectar padrões repetidos de falha;

• Orçamentos de Execução:estipulam tetos de tempo, contagem de chamadas ou custo computacional por ciclo;

• Rate Limits:contêm rajadas não planejadas de requisições sobre ferramentas externas.

Contudo, interromper o processo nem sempre resolve o problema. Se o agente já tiver disparado uma ação no mundo real (como efetuar um pagamento ou enviar uma mensagem), abortar a execução não desfaz o impacto externo. Nesses casos, o processo pode exigir ações de rollback,transações compensatórias ou reconciliação de estado.

Essa distinção é importante em falhas de comunicação (como um timeout), nas quais o estado final da operação torna-se incerto. Reexecutar a chamada (retry) de forma cega pode duplicar a transação. Por isso, operações críticas exigem mecanismos de proteção contra duplicação ou, na impossibilidade de reversão segura, a imediata interrupção da execução, preservação de evidências e transição para intervenção humana.

O objetivo não é garantir que o agente nunca falhe. É garantir que, mesmo quando uma decisão estiver errada ou uma ferramenta for utilizada de forma incorreta, o processo consiga limitar o impacto e recuperar o estado de forma controlada.

Antes de automatizar, é preciso redesenhar os limites do processo

A segurança de agentes não é apenas um problema do modelo. Ela é também um problema de engenharia de processos.

Antes de delegar uma etapa a um agente, é necessário entender quais dados são utilizados, quais decisões possuem impacto, quais operações mudam o estado do processo, quais exceções exigem intervenção e quais ações são reversíveis. Essa análise permite distribuir autonomia de maneira proporcional ao risco. Uma consulta a informações públicas é diferente da atualização de um cadastro. Preparar uma ordem é diferente de confirmá-la. Sugerir uma decisão é diferente de executá-la.

Em uma arquitetura que combine BPM com capacidades agênticas, essa classificação pode orientar onde o agente atua, quais ferramentas recebe, quando precisa de aprovação e em quais pontos o processo deve exigir controles determinísticos.

A gestão de processos, a engenharia de software e a segurança deixam de ser frentes separadas: elas passam a construir juntas a fronteira operacional da IA.

Nota: A literatura recente de BPM já utiliza o conceito de Agentic Business Process Management Systems (A-BPMS) para descrever plataformas que integram autonomia, raciocínio e aprendizagem à gestão e execução de processos. Neste artigo, o termo é usado em alinhamento com essa linha de pesquisa, com foco adicional na fronteira de autoridade e nos controles de segurança.

Um caminho prático para adoção segura

1. Mapear a execução. Identifique dados, ferramentas, integrações, decisões e efeitos de cada etapa.

2. Classificar a criticidade. Separe operações de baixo, médio e alto impacto e defina níveis de autonomia.

3. Definir identidade e privilégio. Associe ações a identidades e permissões específicas, evitando credenciais amplas e permanentes.

4. Aplicar políticas em runtime. Valide operações no momento da chamada, antes que produzam efeitos transacionais.

5. Instrumentar e medir. Crie rastreabilidade para execução, ferramentas, políticas, resultado, latência, tokens e custo.

6. Testar abuso e falhas. Inclua prompt injection, uso indevido de ferramentas, dados contaminados, retries, indisponibilidade e perda de controle.

7. Começar pequeno e ampliar. Aumente a autonomia somente depois de validar controles, recuperação e responsabilidade operacional.

Inteligência com limites bem definidos

A evolução dos agentes de IA abre possibilidades importantes para a automação empresarial. Consultas, análises, preparação de operações e coordenação de tarefas podem se tornar mais dinâmicas e adaptáveis. Entretanto, quanto mais próxima a IA chega da execução real, menos adequada se torna uma segurança baseada somente em prompts, respostas ou recomendações do modelo.

Processos agênticos precisam de identidade, menor privilégio, validação, autorização por contexto, observabilidade e mecanismos de contenção. Precisam também de uma definição clara de responsabilidade: quem solicitou, quem delegou, qual componente autorizou, qual componente executou e qual foi o resultado.

A principal mudança, portanto, não é simplesmente permitir que a IA faça mais. É construir uma arquitetura em que a organização consiga definir, observar e limitar o que ela pode fazer.

O agente pode interpretar. A política autoriza. A ferramenta executa. A observabilidade registra. E a arquitetura interrompe quando necessário.

Esse é o ponto em que segurança deixa de ser um complemento da inteligência artificial e passa a fazer parte da própria engenharia do processo.

Fontes consultadas

[1] CYBERSECURITY AND INFRASTRUCTURE SECURITY AGENCY (CISA) et al. Careful Adoption of Agentic AI Services: Joint Cybersecurity Guidance. Washington, DC: CISA, 2026. Disponível em: https://www.cisa.gov/resources-tools/resources/careful-adoption-agentic-si-services.

[2] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST). National Cybersecurity Center of Excellence (NCCoE). Summary of Comments on the Software and Agentic AI Identity and Authorization Concept Paper. Gaithersburg: NIST, 2026. Disponível em: https://pages.nist.gov/nccoe-ai-identity/summary-of-comments.html

[3] OWASP. OWASP Top 10 for Low-Code/No-Code and GenAI Security Project: Agent Control Standard (ACS). Open Web Application Security Project, 2026. Disponível em: https://genai.owasp.org/.

[4] DUMAS, Marlon; MILANI, Fredrik; CHAPELA-CAMPA, David. Agentic Business Process Management Systems. In: Business Process Management Workshops. Springer Nature Switzerland, 2026. Disponível em: https://arxiv.org/abs/2601.18833.

[6] NSA. Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation (2026). Disponível em: https://media.defense.gov/2026/Jun/02/2003943289/-1/-1/0/CSI_MCP_SECURITY.PDF