Modelo de responsabilidade partilhada de agentes de IA

Os agentes de IA estendem a IA generativa para além do padrão de pedido/resposta descrito pelo modelo de responsabilidade partilhada da IA . Ao contrário de um grande modelo de linguagem, um agente não devolve apenas conteúdo para um humano agir. Em vez disso, um agente:

• Age de forma autónoma. Invoca ferramentas, chama APIs, escreve dados e desencadeia fluxos de trabalho sem que um humano aprove cada etapa.
• Planos e ciclos. Decompõe objetivos, razões em detrimento de resultados intermédios, e repete-se várias vezes antes de regressar.
• Armazena estado e memória. Contexto de curto prazo mais memória persistente influenciam o comportamento futuro e podem ultrapassar os limites da sessão ou do utilizador.
• Tem identidade. Autentica-se junto de sistemas a jusante utilizando identidades geridas, tokens de representação ou uma identidade de agente distinta, e tem privilégios próprios.
• Compõe com outros agentes. Na orquestração multiagente, a saída de um agente torna-se a instrução de outro agente, introduzindo um novo limite de confiança.

Cada um destes comportamentos introduz responsabilidades que não existem no modelo de IA de pedido/resposta.

Note

Este artigo utiliza "responsabilidade" no sentido de governação: quem se espera que configure, opere e monitorize cada controlo. É uma orientação ilustrativa e não pretende transmitir conclusões legais nem modificar ou contradizer os termos de qualquer acordo entre si e a Microsoft.

Como os agentes de IA diferem da nuvem e das cargas de trabalho de IA

A tabela seguinte resume como o modelo de agente de IA difere do modelo padrão de cloud e do modelo de IA generativa (LLM).

Preocupação	Modelo padrão de nuvem	Modelo de IA (LLM)	Modelo de agente de IA
Interação primária	API ou interface gráfica	Resposta rápida	Objetivo da ação autónoma em múltiplos passos
Efeitos secundários no mundo real	Código de aplicação, explícito	Ações humanas sobre o resultado	O agente atua diretamente através de ferramentas
Estado	Camada de aplicação e dados	Prompt sem estado	Memória e contexto persistentes do agente
Identity	Identidade do utilizador ou da aplicação	Identidade do utilizador ou da aplicação	Identidade distinta do agente mais tokens delegados
Limite de confiança	Utilizador para aplicação	Utilizador para modelo	Do utilizador para o agente, para as ferramentas, para outros agentes
Risco principal	Má configuração, exposição de dados	Injeção rápida (conteúdo)	Injeção rápida que impulsiona ações; agência excessiva; Deputado confuso

Divisão de responsabilidade

Tal como nos modelos de responsabilidade partilhada na cloud e na IA , a divisão de responsabilidades muda consoante o modelo de implementação que escolher. Para os agentes, as opções relevantes são:

• Agente SaaS. Um agente pronto, como agentes do Microsoft 365 Copilot, Microsoft Security Copilot ou agentes publicados do Microsoft Copilot Studio. A Microsoft opera o orquestrador, modelo, sistemas de segurança e a maioria dos conectores de ferramentas. Tu possuis a configuração, o âmbito do acesso aos dados, a identidade e o uso.
• Agente de PaaS. Constróis um agente numa plataforma gerida de agentes, como o Microsoft Foundry Agent Service, Azure SRE Agent, agentes personalizados do Microsoft Copilot Studio ou o Microsoft Agent Framework num runtime gerido pelo Azure. A Microsoft fornece o tempo de execução, o alojamento do modelo e os controlos de segurança da plataforma. Tu possuís as instruções do agente, a seleção de ferramentas e plugins, permissões de ferramentas, lógica de orquestração, design da memória, e a identidade e autorização do agente.
• Agente IaaS. Constróis e alojas toda a pilha de agentes tu próprio: um orquestrador personalizado em VMs ou containers, um framework autogerido e, possivelmente, modelos auto-hospedados. É dono de quase tudo, exceto da infraestrutura física (e do modelo base, se o consumir como uma API alojada).

A responsabilidade muda para a esquerda, o que significa que assumes mais responsabilidade, à medida que passas de SaaS para PaaS e depois agentes IaaS.

O diagrama seguinte ilustra as áreas de responsabilidade entre si e a Microsoft, de acordo com o tipo de implementação do agente.

Visão geral da camada de agentes de IA

Um sistema agente adiciona três novas camadas sobre e à volta da plataforma de IA, das camadas de aplicação e de utilização existentes. A responsabilidade pela segurança recai sobre quem executa a tarefa, mas um fornecedor pode disponibilizar-lhe controlos como opções de configuração.

Camada de plataforma de IA (herdada)

A camada da plataforma de IA aloja e protege o modelo, os dados de treino, os pesos e as APIs de inferência, e fornece sistemas de segurança integrados para entrada e saída. A responsabilidade nesta camada é herdada do modelo de responsabilidade partilhada da IA.

Camada de orquestração de agentes

A camada de orquestração é o "centro nevrálgico": planeamento, raciocínio, seleção de ferramentas, o pedido de sistema e as instruções do agente, e a coordenação entre múltiplos agentes. É nesta camada que residem os riscos de agência excessiva e de injeção rápida para ação .

Considerações de segurança:

• Restringe as instruções e o âmbito do agente (menor funcionalidade).
• Valide e higienize qualquer conteúdo não confiável que entre no ciclo, incluindo documentos recuperados, saídas de ferramentas e mensagens de outros agentes. Trata tudo como entrada não confiável, não como instruções de confiança.
• Impor restrições de planeamento: limites de etapas e de iterações, deteção de ciclos, limites máximos de orçamento e de custo, e listas de permissões das ferramentas que podem ser encadeadas.
• Para sistemas multi-agente, trate cada mensagem interagente como um limite de confiança e reaplique a segurança de entrada.

Camada de ferramentas e ações

A camada de ferramentas e ações contém os conectores, plugins, funções, servidores Model Context Protocol (MCP) e APIs que o agente pode invocar para ler e alterar o estado no mundo real. Esta camada é a maior diferença em relação ao modelo LLM.

Considerações de segurança:

• Privilégio mínimo por ferramenta. Cada ferramenta ou conector deve conter apenas as permissões necessárias. Não atribua ao agente uma identidade permanente com permissões amplas.
• Autorização em cada ação, não só no início da sessão. Verifique novamente se esta ação, neste recurso, é permitida. Esta verificação mitiga os riscos de «deputado confuso» e de delegação demasiado ampla.
• Controlos com intervenção humana. Exija-os para ações de elevado impacto, irreversíveis ou sensíveis, como operações de escrita, eliminações, pagamentos, alterações no ambiente de produção e envios externos.
• Auditoria de ações. Registar cada invocação de ferramenta com entradas, saídas, a identidade usada e a justificativa de decisão.
• Sandboxing e controlo de saída. Aplique-as a ferramentas de execução de código e navegação.

Camada de memória e estado do agente

A camada de memória do agente abrange o contexto de conversa de curto prazo, bem como a memória persistente, as bases de dados vetoriais e os blocos de notas temporários que influenciam o comportamento futuro.

Considerações de segurança:

• Defina o âmbito e isole a memória por utilizador e locatário. Evite fugas de memória entre utilizadores ou entre sessões.
• Protege contra o envenenamento da memória. O conteúdo injetado pode persistir e voltar a ser ativado mais tarde.
• Classificar, reter e apagar memória armazenada. Aplicar classificação de dados, retenção e direito de eliminação.
• Cifre as áreas de memória e imponha o controlo de acesso. Trate a memória como dados sensíveis.

Camada de aplicação de IA (herdada)

A camada de aplicação da IA é a aplicação ou interface que o utilizador utiliza, juntamente com a ancoragem, as extensões e o sistema de segurança da aplicação.

Camada de utilização de IA (herdada, estendida)

A camada de utilização da IA descreve como os utilizadores e aplicações consomem o agente. Com os agentes, a responsabilização pelas ações autónomas torna-se central: políticas de uso aceitável, educação do utilizador sobre riscos específicos do agente e clara responsabilidade das ações que o agente toma em nome do utilizador.

Matriz de responsabilidades

A matriz seguinte resume a responsabilidade entre os modelos de implementação. C = Cliente, M = Microsoft, S = Partilhado. A matriz é um guia geral; As responsabilidades específicas para um dado serviço podem variar consoante os termos e a configuração do serviço.

Responsabilidades herdadas na cloud e IA

Área de responsabilidade	Agente IaaS	Agente PaaS	Agente SaaS
Dados do cliente (incluindo o contexto de fundamentação e o conteúdo da memória)	C	C	C
Identidades e utilizadores	C	C	C
Gestão de acessos (RBAC, MFA, Acesso Condicional)	C	C	C
Dispositivos cliente e pontos terminais	C	C	S
Alojamento e pesos do modelo base	C/M1	M	M
Segurança do conteúdo de entrada/saída do modelo	C/M1	S	M
Infraestrutura física (hosts, rede, centro de dados)	M	M	M

Responsabilidades específicas do agente

Área de responsabilidade	Agente IaaS	Agente PaaS	Agente SaaS
Instruções do agente, prompt do sistema e escopo	C	C	S
Seleção de ferramentas, plugins e conectores	C	C	S
Permissões por ferramenta (privilégio mínimo)	C	C	S
Identidade do agente e gestão de tokens delegados	C	S	S
Verificações de autorização por ação	C	S	S
Aprovação com intervenção humana para ações de alto impacto	C	C	C
Limites de segurança da orquestração (limites de ciclo, passo e custo)	C	S	M
Controlos de limite de confiança multiagente	C	S	S
Design da memória, isolamento e defesa contra envenenamento	C	S	M
Sandboxing de ferramentas e ações e controlo de saída	C	S	M
Registo e monitorização da auditoria de ações	C	S	S
Plataforma de ambiente de execução e orquestração de agentes	C	M	M
Política de uso aceitável e responsabilização pelas ações	C	C	C

¹ Cliente se hospedar o modelo em IaaS; Microsoft, se consumir uma API de modelo alojada a partir do seu agente alojado em IaaS.

Responsabilidades que mantém sempre

Independentemente do modelo de implementação, é sempre responsável por:

• Dados, incluindo tudo o que foi escrito na memória do agente e passado para ferramentas.
• Identidade e privilégio mínimo: a identidade do próprio agente e o âmbito de cada credencial ou token que pode utilizar.
• Autorização de ações: o que o agente pode fazer, especialmente operações irreversíveis ou sensíveis.
• Supervisão humana: que ações requerem aprovação e quem é responsável pelo comportamento do agente.
• Utilização e governação aceitáveis: políticas, educação do utilizador e conformidade para comportamento autónomo.

Principais riscos específicos dos agentes a mitigar na conceção

Estes riscos correspondem ao Top 10 OWASP para Aplicações LLM, ao OWASP Top 10 para IA Agente, ao MITRE ATLAS e à classificação de gravidade de vulnerabilidades do Centro de Resposta de Segurança da Microsoft (MSRC) para sistemas de IA. Eles enfatizam a dimensão da ação que é exclusiva dos agentes.

Risco	Mitigation
Injeção rápida para a ação. Conteúdos não confiáveis, como uma página web, documento, email ou outro agente, desviam o agente para invocar ferramentas de forma maliciosa.	Trate todos os resultados das ferramentas, da recuperação e dos agentes como não fidedignos. Isolar instruções dos dados. Restringir o acesso a ações de alto impacto.
Autonomia excessiva. O agente tem mais ferramentas, permissões ou autonomia do que a tarefa precisa.	Aplicar o mínimo de funcionalidades e o mínimo de privilégios a cada ferramenta, e delimitar o âmbito das instruções.
Deputado confuso ou delegação demasiado ampla. O agente usa a sua identidade privilegiada para fazer algo que o utilizador solicitante não consegue.	Utilize tokens em nome de outrem e autorização por ação. Evite uma identidade ampla e permanente.
Envenenamento da memória. O conteúdo injetado persiste e reativa-se mais tarde ou entre sessões.	Isolar e validar a memória, monitorizar a proveniência e impor a retenção.
Ciclos ilimitados, custo e esgotamento de recursos. Planeamento fora de controlo.	Impor limites de etapas, iterações e orçamentos, e detetar ciclos.
Falhas de confiança em sistemas multiagente. Um agente comprometido ou alucinante contamina os colaboradores.	Reaplique a segurança das entradas em cada fronteira entre agentes. Verifica, não confies.
Agentes descontrolados ou suplantados. Um agente não autorizado age no ambiente, ou a identidade do agente é falsificada.	Impor uma identidade forte do agente, atestação e deteção e monitorização.

Configure antes de personalizar

O mesmo princípio que a Microsoft recomenda para IA aplica-se aos agentes, e é mais forte para os agentes porque a autonomia multiplica o custo de errar.

1. Comece com agentes SaaS (Microsoft 365 Copilot, Microsoft Security Copilot, ou agentes publicados do Microsoft Copilot Studio). A Microsoft é responsável pela orquestração, segurança e a maior parte da segurança das ferramentas. Configuras o âmbito dos dados e a identidade.
2. Mude para agentes PaaS (Microsoft Foundry Agent Service, Azure SRE Agent, agentes personalizados do Microsoft Copilot Studio ou o Microsoft Agent Framework num tempo de execução gerido) apenas quando o disponível para a prateleira não encaixar. Assumes a lógica do agente, ferramentas, permissões, memória e identidade.
3. Crie apenas agentes IaaS com profunda experiência em segurança de IA, identidade e risco de sistemas autónomos. Tu possuis quase toda a pilha.

Regra geral: quanto mais autonomia e mais amplo for o conjunto de ferramentas e permissões que concede a um agente, mais a matriz de responsabilidades passa para si, independentemente do modelo de implementação. A autonomia nunca reduz a responsabilidade.

Passos seguintes

• Saiba mais sobre responsabilidades compartilhadas para computação em nuvem.
• Saiba mais sobre o modelo de responsabilidade partilhada da IA.
• Saiba mais sobre as melhores práticas de segurança em IA no Azure.