Por que controlar o comportamento de um modelo de inteligência artificial não é o mesmo que controlar suas permissões — e como IAM se torna essencial na segurança da Agentic AI.

A adoção de agentes de inteligência artificial está transformando a maneira como as organizações executam processos, integram sistemas e automatizam decisões. Diferentemente dos chatbots tradicionais, que predominantemente respondem perguntas e produzem conteúdo, agentes de IA podem consultar bases de dados, executar comandos, consumir APIs, modificar registros e desencadear operações em sistemas corporativos.

Essa evolução traz uma questão fundamental para a segurança empresarial: quem controla o que um agente de IA realmente pode fazer?

Grande parte das discussões sobre segurança de inteligência artificial concentra-se nos chamados guardrails: mecanismos projetados para orientar o comportamento dos modelos, identificar solicitações inadequadas e reduzir a probabilidade de respostas ou ações indesejadas.

Embora importantes, esses mecanismos apresentam uma limitação frequentemente negligenciada.

Guardrails não são mecanismos de controle de acesso.

E confundir essas duas capacidades pode criar uma perigosa falsa sensação de segurança nas organizações.

1. O que são guardrails e por que eles não são suficientes?

Guardrails são mecanismos de proteção utilizados para estabelecer limites ao comportamento de sistemas de inteligência artificial.

Eles podem incluir instruções de sistema, filtros de entrada e saída, validação de conteúdo, restrições de utilização de ferramentas e mecanismos de detecção de comportamentos potencialmente perigosos.

Por exemplo, uma organização pode configurar um agente com a seguinte instrução:

“Você pode consultar informações de colaboradores, mas nunca deve eliminar contas de utilizadores ou modificar permissões administrativas.”

Essa instrução estabelece uma expectativa de comportamento. Entretanto, não representa necessariamente uma restrição técnica sobre os privilégios que o agente possui.

Se o agente utiliza uma credencial com permissões administrativas sobre um diretório corporativo, a capacidade de eliminar contas continua existindo.

Uma falha de interpretação, uma instrução maliciosa ou uma vulnerabilidade na cadeia de execução pode levar o agente a realizar uma operação que deveria estar proibida.

O problema não está necessariamente na qualidade do guardrail, mas na utilização de um mecanismo comportamental para tentar resolver um problema de autorização.

Uma instrução dizendo que uma operação não deve ser executada não equivale a uma política que impede tecnicamente sua execução.

2. A diferença entre comportamento e autorização

Para compreender o problema, precisamos separar dois conceitos.

Guardrails procuram responder:

• O modelo deveria executar esta ação?
• A solicitação parece segura?
• A resposta está alinhada às instruções estabelecidas?
• O comportamento é compatível com as políticas de utilização?

Controles de acesso procuram responder:

• Qual identidade está solicitando a operação?
• Qual recurso está sendo acessado?
• Que ação está sendo solicitada?
• Essa identidade possui autorização para executar a operação?
• O contexto atual permite essa ação?

Essa diferença é fundamental.

Considere um agente de IA integrado a uma plataforma de Identity Governance and Administration (IGA).

O agente recebe uma solicitação para consultar os acessos de determinado colaborador. A operação é legítima e está dentro das suas responsabilidades.

Entretanto, a mesma integração utiliza uma credencial técnica capaz de consultar identidades, criar contas, modificar permissões, revogar acessos e executar processos administrativos.

Nesse cenário, o agente possui muito mais privilégios do que necessita.

Mesmo que suas instruções determinem que ele apenas consulte informações, a infraestrutura subjacente permite operações potencialmente destrutivas.

Esse é um exemplo clássico de violação do princípio de Least Privilege, agora aplicado à inteligência artificial.

3. Prompt injection: quando o agente é induzido a ultrapassar seus limites

Um dos riscos mais relevantes da Agentic AI é o prompt injection.

Esse ataque ocorre quando instruções maliciosas são introduzidas em conteúdos processados pelo modelo, como documentos, páginas web, mensagens, respostas de APIs ou resultados de ferramentas.

Imagine um agente responsável por analisar solicitações de acesso.

Durante o processamento, ele recebe um documento contendo instruções maliciosas que tentam convencê-lo a ignorar suas regras anteriores e executar uma operação administrativa.

Se o agente possuir permissões excessivas e não houver controles independentes de autorização, a tentativa de manipulação poderá resultar em ações indevidas.

O ponto mais importante é que o atacante não precisa necessariamente comprometer diretamente a API ou roubar credenciais.

Ele pode tentar manipular o comportamento do agente para utilizar permissões que já estão disponíveis.

Esse cenário cria uma combinação particularmente perigosa:

Prompt Injection + Excessive Privileges = Potencial comprometimento de sistemas corporativos.

Guardrails podem reduzir a probabilidade de sucesso desses ataques, mas não eliminam a necessidade de controles técnicos capazes de bloquear operações não autorizadas.

4. Agentes de IA precisam ser tratados como identidades digitais

Durante décadas, IAM concentrou-se principalmente na gestão de identidades humanas e contas técnicas.

Com a evolução dos ambientes cloud, surgiram desafios relacionados a workloads, service accounts, identidades de máquinas e outras Non-Human Identities (NHI).

Agora, agentes de inteligência artificial introduzem uma nova dimensão.

Um agente pode operar autonomamente, utilizar múltiplas ferramentas, executar processos em nome de utilizadores e interagir com diferentes aplicações empresariais.

Por isso, não deveria ser tratado apenas como uma funcionalidade de software.

Um agente de IA que executa operações em sistemas corporativos precisa estar sujeito a controles de identidade, autenticação, autorização e governança.

Isso envolve capacidades como:

• Identidade individual e rastreável para cada agente.
• Permissões proporcionais às suas responsabilidades.
• Separação entre a identidade do agente e a identidade do utilizador.
• Credenciais protegidas e, sempre que possível, de curta duração.
• Autorização contextual para operações sensíveis.
• Registros de auditoria das ações executadas.
• Revisões periódicas dos acessos concedidos.
• Revogação de permissões quando o agente deixa de ser necessário.

Esses princípios não são novos para IAM.

A novidade está na necessidade de aplicá-los a entidades capazes de interpretar informações, tomar decisões e iniciar ações com diferentes graus de autonomia.

5. Authorization at Runtime: a camada que realmente impõe limites

Uma abordagem mais robusta para segurança de agentes de IA consiste em implementar controles de autorização independentes do modelo.

Nesse modelo, o agente pode interpretar uma solicitação e decidir qual operação pretende executar, mas a autorização efetiva acontece fora do LLM.

Considere o seguinte fluxo:

Utilizador → Agente de IA → Ferramenta/API → Motor de Autorização → Sistema Corporativo

Antes de uma operação sensível ser executada, um componente de autorização verifica elementos como:

• Subject: qual agente está solicitando a ação e em nome de quem está atuando.
• Action: qual operação será realizada.
• Resource: qual sistema, conta ou informação será afetado.
• Context: quais condições de segurança e de negócio se aplicam.

Imagine que um agente solicite a exclusão de 10 mil contas de utilizadores.

Mesmo que o modelo considere a operação apropriada, o mecanismo de autorização pode bloquear a execução porque o agente não possui esse privilégio, a operação excede os limites estabelecidos ou exige aprovação humana.

Nesse cenário, a segurança não depende exclusivamente da capacidade do modelo de interpretar corretamente suas instruções.

Ela passa a ser aplicada por um mecanismo externo, verificável e auditável.

Essa arquitetura também facilita a utilização de políticas baseadas em RBAC, ABAC e modelos mais granulares de autorização.

É importante, porém, que a validação seja efetivamente aplicada no ponto de execução. Um motor de políticas que apenas recomenda decisões, sem capacidade de impedir chamadas não autorizadas, não resolve o problema.

6. MCP: uma nova superfície de risco para IAM

O Model Context Protocol (MCP) está ampliando as possibilidades de integração entre agentes de IA, ferramentas e fontes de dados.

Por meio de servidores MCP, agentes podem descobrir e utilizar capacidades disponibilizadas por sistemas externos.

Isso cria oportunidades importantes de automação, mas também amplia a superfície de ataque.

Um servidor MCP pode disponibilizar ferramentas para consultar dados financeiros, administrar recursos cloud, interagir com repositórios de código ou executar operações em plataformas corporativas.

A existência dessas ferramentas não significa que todos os agentes devam possuir autorização para utilizá-las indiscriminadamente.

É necessário diferenciar três conceitos:

Tool Discovery: o agente consegue descobrir que uma ferramenta existe.

Tool Invocation: o agente consegue solicitar a execução dessa ferramenta.

Tool Authorization: a identidade e o contexto da solicitação possuem permissão para executar a operação específica.

Essas capacidades não devem ser confundidas.

Um agente pode conhecer a existência de uma ferramenta administrativa sem possuir autorização para utilizá-la.

Da mesma forma, o acesso a uma ferramenta não deveria representar autorização irrestrita sobre todos os recursos disponibilizados por ela.

Isso reforça a importância de mecanismos como gateways de autorização, políticas granulares, validação contextual e segregação de privilégios.

Em ambientes MCP, também é necessário avaliar o risco de servidores ou ferramentas maliciosas, alterações inesperadas nas capacidades expostas e utilização indevida de credenciais delegadas.

O protocolo facilita a integração. A arquitetura de segurança precisa determinar os limites dessa integração.

7. O papel de IAM, IGA e PAM na governança de agentes

A segurança de agentes de IA não deveria ser desenvolvida como uma disciplina completamente isolada das práticas tradicionais de Identity and Access Management.

Pelo contrário, grande parte dos controles necessários já existe no universo IAM.

Identity Governance and Administration (IGA) pode contribuir para o inventário de agentes, definição de responsáveis, atribuição de acessos, revisões periódicas, identificação de privilégios excessivos e processos de desativação.

Privileged Access Management (PAM) pode proteger operações administrativas, controlar o uso de credenciais privilegiadas, estabelecer acessos temporários e exigir aprovações adicionais para ações críticas.

Authorization Management permite implementar decisões granulares sobre quais operações podem ser executadas, em quais recursos e sob quais condições.

Identity Threat Detection and Response (ITDR) pode contribuir para a identificação de comportamentos anômalos relacionados ao uso de identidades, credenciais e privilégios.

Entretanto, aplicar esses conceitos exige adaptações.

Um agente pode executar milhares de operações em poucos minutos, alternar entre ferramentas e atuar em nome de diferentes utilizadores.

Isso exige controles capazes de preservar o contexto da delegação, correlacionar ações e distinguir o comportamento autorizado de atividades suspeitas.

Também exige evitar um erro comum: permitir que vários agentes compartilhem uma única identidade técnica altamente privilegiada.

Esse modelo compromete a rastreabilidade e amplia significativamente o impacto potencial de uma falha.

8. O cenário prático: um agente de IA integrado ao IAM

Imagine uma organização que desenvolveu um assistente de IA para apoiar sua equipe de Service Desk.

O agente consegue consultar identidades, verificar acessos existentes e responder perguntas sobre permissões.

Posteriormente, a organização decide ampliar suas capacidades para permitir solicitações de acesso e execução de determinadas operações de provisionamento.

Existem duas formas bastante diferentes de implementar essa solução.

Arquitetura baseada principalmente em guardrails

O agente utiliza uma conta técnica com privilégios amplos.

Suas instruções determinam que operações administrativas só devem ocorrer em situações específicas.

O modelo interpreta a solicitação e executa diretamente as chamadas disponíveis.

Nesse cenário, grande parte da proteção depende do comportamento esperado do agente.

Arquitetura baseada em identidade e autorização

O agente possui uma identidade própria e permissões delimitadas.

As operações são expostas por ferramentas com escopos específicos.

Cada solicitação sensível passa por validações de autorização, considerando a identidade do agente, o utilizador representado, o recurso e o contexto.

Operações privilegiadas exigem controles adicionais, como aprovação humana, elevação temporária de privilégios ou políticas específicas.

Todas as ações são registradas para auditoria.

Nessa segunda arquitetura, mesmo que o agente interprete incorretamente uma instrução, ele não consegue ultrapassar os limites técnicos de autorização estabelecidos.

Naturalmente, os controles de autorização também precisam ser corretamente projetados, implementados e testados. Nenhuma camada isolada garante segurança absoluta.

A diferença é que o modelo deixa de ser o único responsável por respeitar os limites operacionais.

9. De AI Safety para AI Identity Security

A discussão sobre segurança de inteligência artificial frequentemente mistura conceitos diferentes.

AI Safety procura reduzir comportamentos perigosos ou indesejados dos sistemas de IA.

AI Security inclui a proteção dos modelos, aplicações, integrações, dados e infraestrutura contra ataques e utilização indevida.

AI Identity Security concentra-se na identidade, nos privilégios, nas delegações e nas ações autorizadas dos componentes de IA.

Essas disciplinas são complementares.

Uma arquitetura madura precisa combinar proteção comportamental, controles de segurança da aplicação e mecanismos efetivos de identidade e autorização.

O avanço dos agentes autônomos torna essa convergência ainda mais importante.

Quanto maior a autonomia concedida a um agente, maior a necessidade de compreender quais recursos ele pode acessar, quais operações pode executar e quem responde pelas decisões e ações realizadas.

Isso também coloca a governança de identidades de agentes no centro das discussões sobre Zero Trust.

O princípio de nunca confiar implicitamente e verificar explicitamente continua válido, independentemente de a solicitação partir de uma pessoa, aplicação, workload ou agente de inteligência artificial.

10. O futuro da segurança de agentes passa pelo IAM

A próxima fase da adoção corporativa de inteligência artificial não será definida apenas pela capacidade dos modelos de raciocinar ou executar tarefas complexas.

Será definida também pela capacidade das organizações de permitir essa autonomia sem perder controle, visibilidade e responsabilidade.

Agentes de IA precisarão de identidades próprias, permissões governadas, mecanismos de autorização e processos de auditoria compatíveis com o impacto das operações que executam.

Isso representa uma oportunidade importante para a evolução das arquiteturas IAM.

Plataformas de IGA, PAM, autorização e segurança de identidades poderão desempenhar papéis cada vez mais relevantes na governança de ecossistemas de agentes.

Mas essa evolução não será simplesmente uma questão de conectar agentes às ferramentas tradicionais.

Será necessário repensar modelos de delegação, autorização contextual, privilégios temporários, rastreabilidade e segregação de responsabilidades em ambientes nos quais decisões são tomadas e executadas por software autônomo.

A pergunta deixa de ser apenas se um agente é suficientemente inteligente para executar uma tarefa.

Passa a ser também se ele possui autorização para executá-la — e se a organização consegue demonstrar isso.

Conclusão: guardrails orientam, IAM controla

Guardrails são componentes importantes da segurança de inteligência artificial. Eles ajudam a reduzir comportamentos inadequados, identificar solicitações perigosas e estabelecer limites operacionais.

Entretanto, não substituem mecanismos de autenticação, autorização e governança de identidades.

Uma organização não deveria depender exclusivamente de instruções fornecidas a um modelo para proteger sistemas críticos.

Se um agente possui uma credencial capaz de executar operações administrativas, essa capacidade precisa ser controlada por políticas técnicas independentes do seu comportamento.

A verdadeira maturidade em Agentic AI Security começa quando as organizações deixam de perguntar apenas o que seus agentes foram instruídos a fazer e passam a controlar aquilo que estão efetivamente autorizados a executar.

Guardrails orientam o comportamento. IAM determina o poder. E segurança exige que nenhum agente tenha mais poder do que realmente necessita.

Referências e leitura complementar

• Broadcom: Guardrails Aren’t Access Control — webinar que inspirou a discussão central deste artigo. https://www.broadcom.com/video/6407239332112
• OWASP: Top 10 for Large Language Model Applications — riscos de segurança em aplicações com modelos de linguagem. https://genai.owasp.org/
• NIST: AI Risk Management Framework — princípios para gestão de riscos em sistemas de inteligência artificial. https://www.nist.gov/itl/ai-risk-management-framework
• Model Context Protocol: documentação oficial do protocolo. https://modelcontextprotocol.io/
• NIST: Zero Trust Architecture — SP 800-207. https://csrc.nist.gov/pubs/sp/800/207/final