Fusion AI Agents: Práticas de Secure by Design para Empresas Brasileiras

Fusion AI Agents: Práticas de Secure by Design para Empresas Brasileiras

TL;DR: Este artigo analisa as práticas de Secure by Design para agentes de IA em Oracle Fusion, defendendo que eles sejam tratados como atores de negócio com contratos de segurança claros. A conclusão principal é que times brasileiros devem classificar agentes por risco de impacto, vincular ações a contextos de identidade e separar instruções confiáveis de conteúdo não confiável para evitar riscos como prompt injection e conflitos de segregação de funções (SoD).

Este artigo é uma análise de liderança de pensamento e considerações de melhores práticas de segurança para organizações que projetam aplicações de agentes em ambientes Oracle Fusion. As considerações descritas oferecem um framework para avaliar e planejar aspectos de segurança para Fusion AI Agents e aplicações agentic. A aplicabilidade depende do caso de uso do agente, capacidade do produto, licenciamento, modelo de implantação e dos processos de segurança e governança de cada organização.

À medida que as organizações avaliam agentes de inteligência artificial (IA) em fluxos de trabalho empresariais, a conversa sobre segurança se torna mais ampla do que a saída do modelo. Em ambientes Oracle Fusion, os agentes de IA podem ajudar a resumir, recomendar próximos passos e, dependendo do caso de uso e das capacidades disponíveis, iniciar ações nos fluxos de trabalho do Oracle Fusion Cloud Applications. Essa capacidade é valiosa, mas também introduz considerações importantes de design de segurança: um agente pode interagir com identidade corporativa, dados de negócio, APIs e processos de negócio.

Esta série de artigos está estruturada em três áreas de segurança: design, enforcement e operações. Esta Parte 1 foca em considerações de design-time que podem ajudar as organizações a avaliar riscos, esclarecer autoridade e criar uma base mais clara para controles posteriores. Quando as premissas de design são vagas, as guardrails de runtime podem se tornar mais difíceis de avaliar, explicar, justificar e operar.

Como tratar o agente como um ator de negócio, e não como um chatbot?

Um ponto de partida prático é pensar em um agente de IA como um ator de negócio com um "contrato de trabalho" orientado à segurança. Esse contrato pode ajudar a esclarecer o propósito, o escopo e o modelo de autoridade do agente antes de conectá-lo a ferramentas, dados ou fluxos de trabalho de negócio.

O contrato de trabalho pode incluir:

• Resultados pretendidos: o valor de negócio que o agente deve apoiar
• Resultados proibidos: ações ou decisões que o agente não deve tentar
• Ferramentas e domínios de dados permitidos: os sistemas, integrações e fontes de informação que o agente pode usar
• Pontos de verificação humana: pontos de revisão ou aprovação necessários para ações de maior risco

As organizações também podem considerar classificar agentes por impacto nos negócios, usando categorias alinhadas com sua metodologia de risco, como:

• Baixo risco: recuperação informacional, como FAQ sobre política de férias
• Médio risco: recomendações sem atualizações diretas no sistema
• Alto risco: ações de criar ou atualizar objetos transacionais
• Risco crítico: ações de pagamento, folha de pagamento, dados bancários de fornecedores ou ações regulatórias

Em um contexto Fusion, essa classificação pode ajudar a orientar o design de papéis, escopo de dados, necessidades de aprovação e expectativas de logging. O objetivo não é sugerir que todo agente já esteja sujeito a um processo universal de threat modeling, mas sim fornecer um framework para as equipes avaliarem o risco introduzido pela autonomia do agente e decidirem quais considerações de design se aplicam.

Como consideração de implementação, quando um novo binding de ferramenta é adicionado (como uma API REST, fluxo de integração ou fonte de documento), as equipes podem avaliar se o perfil de risco do agente mudou antes de promover essa capacidade para uso mais amplo.

Como vincular ações do agente a identidade e contexto de autoridade?

Nem todos os agentes de IA carregam o mesmo nível de risco de negócio, e nem todas as ações do agente exigem o mesmo nível de autoridade. Quando a implementação suporta, as ações do agente podem ser mais fáceis de avaliar quando atribuíveis a um solicitante, a um principal de execução e à decisão de autorização ou aprovação relevante.

Se um agente usa uma conta técnica superprivilegiada sem preservar o contexto do requisitante, as trilhas de auditoria podem mostrar o que aconteceu, mas não se a ação era apropriada para a autoridade do usuário. As considerações de design incluem:

• Identificar o usuário chamador e o contexto de sessão
• Vincular requisições a autoridade delegada, quando apropriado
• Capturar decisões de política ou aprovação usadas no momento da execução
• Registrar o principal usado para chamadas de API downstream

Em ambientes Oracle, os domínios de identidade do OCI IAM e legados do Oracle Identity Cloud Service (IDCS) podem fazer parte do plano de controle de identidade. O design de papéis do Fusion Security Console, incluindo duty roles e data roles, pode então ajudar a alinhar as capacidades do agente com os modelos de entitlement existentes.

Para implementações Fusion, o Oracle AI Agent Studio for Fusion Applications pode suportar a orquestração de agentes. Integrações de ferramentas personalizadas podem ainda precisar de design explícito para preservar o contexto de identidade entre os limites agente-para-API. Isso é uma consideração de implementação, não uma garantia de plataforma.

Por que separar instruções confiáveis de conteúdo não confiável?

O risco de prompt injection pode ser visto como um problema de trust boundary. Aplicações agentic podem ingerir prompts de usuário, documentos, texto de e-mail, payloads de API ou conteúdo web. Essas fontes podem fornecer contexto útil, mas também podem conter instruções adversárias que entram em conflito com a política intencional, objetivo de negócio ou limite de workflow. As considerações de design podem incluir:

• Manter a política do sistema e as instruções de runtime separadas do conteúdo controlado pelo usuário
• Tratar conteúdo externo como dado, não como autoridade
• Definir regras de resolução de conflitos, como política antes de saída de ferramenta antes de requisição do usuário
• Reduzir o risco de que conteúdo não confiável seja tratado como capaz de alterar silenciosamente o objetivo do agente

Por exemplo, um agente de service desk pode ler um e-mail de cliente e recuperar uma política de escalonamento interna. Manter essas entradas logicamente segmentadas pode ajudar a evitar que texto externo substitua a política interna.

Para implementações Fusion, equipes que constroem orquestração personalizada podem considerar segmentação explícita de contexto. Se texto externo, política interna e respostas de ferramentas forem mesclados em um único prompt indiferenciado, a resistência a injection pode se tornar mais difícil de avaliar e validar.

Como avaliar segregação de funções (SoD) antes de compor fluxos de trabalho?

Problemas de SoD podem surgir quando fluxos de trabalho de múltiplas etapas são comprimidos em uma única experiência conversacional. A questão de design não é apenas se um agente pode completar o processo, mas se um único ator (humano ou agentic) é apropriado para cada etapa desse processo.

Por exemplo, o onboarding de fornecedores e a aprovação de pagamentos podem precisar permanecer separados, mesmo que um fluxo conversacional possa tecnicamente conectar ambas as ações. Considerar essas restrições durante o design pode ajudar a dar ao enforcement de runtime uma intenção de política mais clara a seguir.

Para implementações Fusion, onde Oracle Risk Management, Oracle Access Governance ou controles empresariais equivalentes estão em uso, as equipes podem considerar mapear as capacidades do agente para o mesmo modelo de SoD usado para funções humanas. Se um fluxo humano geraria um conflito, o fluxo análogo habilitado por agente pode merecer avaliação sob uma lente de risco similar.

Como construir um mapa de controles antes do uso mais amplo?

Antes do uso mais amplo, as equipes podem criar um mapa de controles leve que ligue as capacidades do agente a considerações concretas de governança e segurança. O objetivo é esclarecer quais controles podem se aplicar a um caso de uso agentic específico.

• Identidade: domínios de identidade OCI IAM, federação e políticas de token, quando aplicável
• Entitlements: papéis do Fusion Security Console e data roles
• Controles transacionais: roteamento de aprovação Fusion ou aprovações baseadas em BPM, quando disponíveis
• SoD e governança de acesso: Oracle Risk Management e Oracle Access Governance, se implementados
• Auditoria: registros de auditoria Fusion e integração com monitoramento empresarial ou SIEM, quando aplicável

Esse tipo de artefato ajuda a evitar "segurança por suposição". Ele dá aos revisores uma visão mais clara de quais recomendações estão implementadas, quais são tratadas por controles empresariais existentes e quais permanecem como considerações de estado futuro.

Conclusão

Considerações de design focadas em segurança podem fornecer uma base prática para avaliar aplicações agentic. Em ambientes Fusion, as equipes podem considerar classificação de risco de negócio, execução ciente de identidade, segmentação de contexto e limites de workflow cientes de SoD; depois mapear essas considerações de design para os controles Fusion e OCI disponíveis em seu ambiente.

Na Parte 2, passamos da intenção de design para o enforcement de runtime, incluindo least privilege, padrões de autorização just-in-time (JIT), restrições de invocação de ferramentas, defesas contra prompt injection e controles de aprovação humana que podem ajudar a suportar o alinhamento com os limites de workflow pretendidos.

Perguntas Frequentes

• O que significa tratar um agente de IA como 'ator de negócio'?

  • Significa definir um 'contrato de trabalho' de segurança que especifique objetivos permitidos, resultados proibidos, ferramentas e dados autorizados, e pontos de verificação humana. Isso evita ambiguidades que dificultam a avaliação de riscos e a definição de controles de runtime.

• Como evitar prompt injection em agentes de IA no Fusion?

  • Mantendo instruções de sistema e políticas de runtime separadas do conteúdo controlado pelo usuário (texto de e-mails, documentos, payloads de API). Trate conteúdo externo como dado, não como autoridade, e defina regras de resolução de conflitos (ex.: política antes de saída de ferramenta antes de requisição do usuário).

• Devo mapear agentes de IA para o mesmo modelo de SoD usado para funções humanas?

  • Sim. Se um fluxo humano geraria um conflito de segregação de funções (SoD), o fluxo equivalente habilitado por agente merece ser avaliado com a mesma lente de risco. Use Oracle Risk Management ou Access Governance para mapear capacidades do agente ao modelo de SoD existente.

• Qual a importância de vincular ações do agente a um contexto de identidade?

  • Ações atribuíveis a um solicitante, a um principal de execução e a uma decisão de autorização facilitam auditoria e governança. Evitar contas técnicas superprivilegiadas sem contexto do requisitante impede saber se a ação era apropriada para a autoridade do usuário.

• O que deve constar em um 'mapa de controles' antes de implantar agentes em produção?

  • O mapa deve ligar capacidades do agente a controles concretos: identidade (OCI IAM), entitlements (roles Fusion), controles transacionais (aprovações BPM), SoD (Oracle Risk Management) e auditoria (logs Fusion + SIEM). Isso evita 'segurança por suposição' e documenta quais controles estão implementados ou são futuros.

---

Artigo originalmente publicado em cloud-infrastructure.