Blog do Chesley

Blog Chesley · chesley.com.br | Microsoft 365 · Entra ID · Segurança de Identidade

Introdução — O Novo Perímetro de Identidade: Agentes de IA

Durante anos, o modelo de identidade corporativa girou em torno de dois tipos principais de sujeitos: usuários humanos e aplicações/workloads. O Conditional Access, o ID Protection, o Privileged Identity Management — tudo foi construído pensando nesses dois pilares.

Esse modelo está mudando fundamentalmente.

Organizações estão implantando agentes de IA autônomos em escala — sistemas que percebem o ambiente, tomam decisões e executam ações sem intervenção humana direta. Esses agentes acessam dados corporativos, chamam APIs, interagem com outros agentes e operam com permissões elevadas. Muitas vezes são criados por times de negócio sem supervisão de TI. E, até recentemente, eram praticamente invisíveis para o plano de controle de identidade.

A Microsoft respondeu a esse desafio com o Microsoft Entra Agent ID — uma extensão do Entra ID que trata agentes de IA como identidades de primeira classe (first-class identities), sujeitas às mesmas proteções de Zero Trust que se aplicam a usuários e workloads tradicionais.

Este artigo cobre a arquitetura completa dessa solução, como configurar políticas de Conditional Access específicas para agentes, como o Identity Protection detecta agentes comprometidos, e como construir um modelo de governança sustentável para evitar o agent sprawl.

Status de disponibilidade: As funcionalidades descritas neste artigo estavam em Public Preview no momento da escrita (maio de 2026). Consulte sempre a documentação oficial para verificar o status atual de GA (General Availability).

O Que é o Microsoft Entra Agent ID?

O Microsoft Entra Agent ID é a plataforma de identidade e segurança da Microsoft especificamente projetada para agentes de IA. Ele estende as capacidades existentes do Entra ID — Conditional Access, Identity Protection, ID Governance — para cobrir identidades não-humanas que operam de forma autônoma.

Componentes principais

Como diferem de Service Principals tradicionais

Antes do Agent ID, o padrão era registrar agentes de IA como App Registrations ou Service Principals — mecanismo criado para aplicações, não para sistemas autônomos que tomam decisões dinâmicas. Essa abordagem apresenta lacunas críticas:

• Nenhuma distinção entre “aplicação que executa lógica fixa” e “agente que toma decisões adaptativas”
• Sem visibilidade centralizada sobre o comportamento em tempo real
• Ausência de sinais de risco específicos para padrões de acesso de IA
• Impossibilidade de aplicar políticas de Conditional Access distintas entre agentes e aplicações convencionais

O Agent ID resolve essas lacunas com uma estrutura de identidade nativa para IA, mantendo compatibilidade com toda a infraestrutura existente do Entra ID.

Tipos de Agentes e Seus Padrões de Identidade

A Microsoft categoriza os agentes em quatro padrões distintos, cada um com características de segurança diferentes:

O fluxo de autenticação importa

No fluxo Client Credentials (usado por autonomous agents), o token emitido tem o agent identity como subject — não o usuário. Isso é fundamental para o Conditional Access: as políticas se aplicam à identidade do agente, não ao usuário que eventualmente o criou ou monitora.

No fluxo OBO (On-Behalf-Of) (usado por assistive agents), o subject é o usuário. Nesse caso, políticas de Conditional Access orientadas a usuários continuam se aplicando — mas o agente pode ser um vetor de abuso das permissões do usuário.

Superfície de Ataque e Riscos Específicos de AI Agents

Ao contrário de aplicações que executam lógica predeterminada, agentes de IA tomam decisões dinâmicas e adaptam seu comportamento com base em dados de treinamento, input e condições do ambiente. Essa capacidade adaptativa cria vetores de ataque que não existem em workloads tradicionais:

Categorias de risco

1. Escalada de Permissão (Permission Escalation) Agentes frequentemente são provisionados com permissões amplas para garantir que consigam executar todas as tarefas para as quais foram projetados. Um agente de análise financeira pode receber acesso a todos os registros contábeis, despesas e contratos com fornecedores — muito além do necessário para cada tarefa individual.

2. Prompt Injection Agentes de IA são vulneráveis a ataques que não afetam aplicações tradicionais. Ataques de prompt injection manipulam o comportamento do agente inserindo instruções maliciosas nos dados que o agente processa — por exemplo, em um e-mail que o agente está sumarizando ou em uma página web que está navegando.

3. Agent-to-Agent Propagation Agentes que interagem com outros agentes podem propagar comprometimentos. Se um agente de orquestração é comprometido, ele pode potencialmente direcionar outros agentes a executarem ações maliciosas.

4. Agent Sprawl (Proliferação descontrolada) A proliferação de agentes sem visibilidade, gerenciamento ou controles de ciclo de vida adequados surge quando unidades de negócio criam agentes sem supervisão formal de TI (shadow AI), quando agentes criados para propósitos temporários permanecem em produção indefinidamente, e quando as permissões dos agentes excedem os requisitos reais e nunca são revisadas.

5. Autonomous Decision Risk Agentes comprometidos que tomam decisões autônomas podem executar ações prejudiciais. Um agente de supply chain com autoridade de compra pode fazer pedidos não autorizados. Um agente de gerenciamento de infraestrutura pode deletar sistemas críticos.

Tabela de cenários de risco por tipo de agente

Identity Protection para Agentes

O Microsoft Entra ID Protection para agentes é projetado para identificar e mitigar riscos associados às capacidades dos agentes. O sistema determina uma baseline para a atividade normal de um agente e então o monitora continuamente em busca de anomalias no Microsoft Entra ID. Uma vez que um agente exibe comportamento suspeito, o ID Protection sinaliza a atividade e o marca como de risco.

Detecções de risco disponíveis (Preview)

Todas as detecções de risco para agentes são do tipo offline — processadas em background, não em tempo real:

Relatório de Risky Agents

O relatório de Risky Agents está disponível no portal do Entra ID Protection. A partir dele, os administradores podem:

• Confirm compromise — Eleva o risco para High e cria um evento em Risk Detections; dispara automaticamente políticas de Conditional Access configuradas para bloquear em High Agent Risk
• Confirm safe — Marca como seguro após investigação; limpa o estado de risco ativo
• Dismiss risk — Indica que o risco detectado não é mais relevante (benign true positive) mas mantém a flag para atividades similares futuras
• Disable — Bloqueia todas as autenticações do agente em todo o Entra ID e aplicações conectadas

Consultando Risky Agents via Microsoft Graph

Há duas novas coleções nas APIs de ID Protection para consultar agentes de risco:

http

GET https://graph.microsoft.com/beta/identityProtection/riskyAgents
GET https://graph.microsoft.com/beta/identityProtection/agentRiskDetections

powershell

# Conectar com as permissões necessárias
Connect-MgGraph -Scopes "IdentityRiskyUser.Read.All", "IdentityRiskEvent.Read.All"
# Listar todos os agentes com risco atual
$riskyAgents = Invoke-MgGraphRequest `
    -Uri "https://graph.microsoft.com/beta/identityProtection/riskyAgents" `
    -Method GET
$riskyAgents.value | 
    Select-Object displayName, riskLevel, riskState, riskLastUpdatedDateTime |
    Format-Table -AutoSize
# Filtrar apenas agentes de alto risco
$highRiskAgents = Invoke-MgGraphRequest `
    -Uri "https://graph.microsoft.com/beta/identityProtection/riskyAgents?`$filter=riskLevel eq 'high'" `
    -Method GET
$highRiskAgents.value | Export-Csv "high-risk-agents.csv" -NoTypeInformation -Encoding UTF8
# Listar detecções de risco dos últimos 30 dias
$detections = Invoke-MgGraphRequest `
    -Uri "https://graph.microsoft.com/beta/identityProtection/agentRiskDetections?`$filter=detectedDateTime ge $(((Get-Date).AddDays(-30)).ToString('yyyy-MM-ddTHH:mm:ssZ'))" `
    -Method GET
$detections.value | 
    Select-Object displayName, riskEventType, riskLevel, detectedDateTime |
    Sort-Object detectedDateTime -Descending |
    Format-Table -AutoSize

Conditional Access para Agent Identities

O Conditional Access é um motor de políticas inteligente que ajuda organizações a controlar como usuários e identidades de agentes acessam recursos corporativos. Ele reúne sinais em tempo real como contexto do usuário, dispositivo, localização e informações de risco de sessão para determinar quando permitir, bloquear, ou limitar o acesso, ou exigir etapas adicionais de verificação.

Diferenças fundamentais em relação a políticas de usuário

O Conditional Access para agentes funciona de forma diferente das políticas de usuário. Você não pode pedir a um agente para realizar MFA ou verificar a conformidade do seu dispositivo. Em vez disso, o motor de políticas avalia a identidade do agente, seus atributos, e o recurso que o agente tenta acessar.

Os controles disponíveis para agentes são:

Como o token funciona para agentes

O Microsoft Entra ID emite um access token para um subject direcionado a um audience específico (recurso). Cada token tem exatamente um subject e um audience. O “subject” identifica para quem o token foi emitido: quando uma aplicação ou agente solicita um token em nome de um usuário, o usuário é o subject. Quando uma aplicação ou agente solicita um token para si mesmo, a aplicação ou o agente é o subject.

Isso significa que políticas de Conditional Access voltadas a agentes são avaliadas no momento da aquisição de token, não no momento do login do usuário.

Requisitos de licença e função

Cenário 1 — Apenas Agentes Aprovados Acessam Recursos (Custom Security Attributes)

Este cenário implementa um modelo de allowlist por aprovação departamental: apenas agentes explicitamente aprovados podem acessar recursos específicos. É ideal para organizações que precisam controlar quais agentes acessam dados sensíveis por departamento (RH, Financeiro, TI).

Arquitetura da solução

Todos os agentes → Bloqueados por padrão
Agentes com atributo HR_Approved → Permitidos em recursos com atributo HR
Agentes com atributo Finance_Approved → Permitidos em recursos com atributo Finance

Passo 1 — Criar os Attribute Sets e atributos

powershell

Connect-MgGraph -Scopes "CustomSecAttributeDefinition.ReadWrite.All", "Policy.ReadWrite.ConditionalAccess"
# Criar Attribute Set para agentes
$agentAttrSet = @{
    id = "AgentAttributes"
    description = "Atributos de aprovação para Agent Identities"
    maxAttributesPerEntity = 25
}
New-MgDirectoryAttributeSet -BodyParameter $agentAttrSet
# Criar atributo de aprovação para agentes
$approvalAttr = @{
    name = "AgentApprovalStatus"
    description = "Status de aprovação departamental do agente"
    attributeSet = "AgentAttributes"
    type = "String"
    isMultiValued = $true
    isSearchable = $true
    allowedValues = @(
        @{ id = "New"; isActive = $true }
        @{ id = "In_Review"; isActive = $true }
        @{ id = "HR_Approved"; isActive = $true }
        @{ id = "Finance_Approved"; isActive = $true }
        @{ id = "IT_Approved"; isActive = $true }
    )
}
New-MgDirectoryCustomSecurityAttributeDefinition -BodyParameter $approvalAttr
# Criar Attribute Set para recursos
$resourceAttrSet = @{
    id = "ResourceAttributes"
    description = "Atributos departamentais para recursos acessados por agentes"
    maxAttributesPerEntity = 25
}
New-MgDirectoryAttributeSet -BodyParameter $resourceAttrSet
# Criar atributo departamental para recursos
$deptAttr = @{
    name = "Department"
    description = "Departamento proprietário do recurso"
    attributeSet = "ResourceAttributes"
    type = "String"
    isMultiValued = $true
    isSearchable = $true
    allowedValues = @(
        @{ id = "Finance"; isActive = $true }
        @{ id = "HR"; isActive = $true }
        @{ id = "IT"; isActive = $true }
        @{ id = "Marketing"; isActive = $true }
        @{ id = "Sales"; isActive = $true }
    )
}
New-MgDirectoryCustomSecurityAttributeDefinition -BodyParameter $deptAttr

Passo 2 — Atribuir atributos a um agente

powershell

# Atribuir status de aprovação a um agente específico
$agentId = "<agent-object-id>"
$attrAssignment = @{
    "AgentAttributes" = @{
        "AgentApprovalStatus" = @("HR_Approved")
    }
}
# Via Graph API (agentes usam o endpoint de service principals ou agents)
$uri = "https://graph.microsoft.com/beta/servicePrincipals/$agentId"
$body = @{
    customSecurityAttributes = $attrAssignment
} | ConvertTo-Json -Depth 5
Invoke-MgGraphRequest -Uri $uri -Method PATCH -Body $body -ContentType "application/json"

Passo 3 — Criar a política de Conditional Access

powershell

# Política: bloquear todos os agentes EXCETO os com atributo HR_Approved
$caPolicy = @{
    displayName = "CA-AGENTS-001: Block Unapproved Agent Identities"
    state = "enabledForReportingButNotEnforced"  # Report-only primeiro
    conditions = @{
        users = @{
            includeGuestsOrExternalUsers = $null
        }
        # Alvo: agent identities
        clientApplications = @{
            includeServicePrincipals = @()
        }
        # Configuração de agentes (Preview)
        agents = @{
            includeAgents = @("All")
            excludeAgents = @(
                @{
                    # Excluir agentes com atributo HR_Approved
                    filterMode = "exclude"
                    filter = @{
                        mode = "exclude"
                        rule = "AgentAttributes.AgentApprovalStatus Contains 'HR_Approved'"
                    }
                }
            )
        }
        applications = @{
            includeApplications = @("All")
        }
    }
    grantControls = @{
        operator = "OR"
        builtInControls = @("block")
    }
}
# Nota: use o portal do Entra para criar políticas de agentes em Preview
# A API de CA para agentes ainda está em fase de estabilização
# Acesse: Entra ID > Conditional Access > Policies > New Policy
# Em Assignments > Users, agents or workload identities > Agents (Preview)

Recomendação: Enquanto a API de Conditional Access para agentes está em Preview, prefira criar as políticas via portal do Entra admin center para garantir que todos os campos de Preview sejam corretamente aplicados. Exporte depois via Graph para documentação.

Cenário 2 — Bloqueando Agentes de Alto Risco Automaticamente

Este é o cenário mais crítico para resposta automática a incidentes: agentes detectados como alto risco pelo Identity Protection são bloqueados imediatamente, sem necessidade de intervenção manual.

Configuração via Portal (recomendado para Preview)

1. Acesse o Microsoft Entra admin center → Entra ID → Conditional Access → Policies
2. Selecione New policy

1. Nome sugerido: CA-AGENTS-002: Block High-Risk Agent Identities
2. Em Assignments → Users, agents (Preview) or workload identities
   • Em What does this policy apply to? → selecione Agents (Preview)
   • Em Include → selecione All agent identities (Preview)

1. Em Target resources
   • Select what this policy applies to → Resources (formerly cloud apps)
   • Include → All resources (formerly ‘All cloud apps’)

1. Em Conditions → Agent risk (Preview)
   • Configure → Yes
   • Selecione High
2. Em Access controls → Grant → Block
3. Enable policy → Report-only (validar primeiro)
4. Create

Após validar o impacto no modo Report-only, altere para On.

Template Microsoft Managed Policy

A Microsoft disponibiliza um template de política gerenciada que bloqueia agentes de alto risco automaticamente. Ele pode ser acessado diretamente via:

https://aka.ms/CreateAgentRiskPolicy

Esse template é a baseline recomendada pela Microsoft para todos os tenants que implantam agentes de IA.

Verificando o impacto antes de ativar

powershell

# Verificar quais agentes seriam afetados pela política em Report-only
# Consultar sign-in logs filtrando por tipo de agente
$filter = "signInEventTypes/any(t: t eq 'servicePrincipal') and conditionalAccessStatus eq 'reportOnlyFailure'"
$uri = "https://graph.microsoft.com/beta/auditLogs/signIns?`$filter=$filter&`$top=50"
$impactedSignIns = Invoke-MgGraphRequest -Uri $uri -Method GET
$impactedSignIns.value | 
    Select-Object appDisplayName, conditionalAccessStatus, 
                  @{N="AgentRisk";E={$_.riskLevelDuringSignIn}},
                  createdDateTime |
    Format-Table -AutoSize

Configuração via Microsoft Graph e PowerShell

Desabilitando um agente comprometido via Graph

powershell

# Confirmar comprometimento de um agente (eleva risco para High e dispara CA policies)
$agentId = "<risky-agent-object-id>"
$confirmBody = @{
    agentIds = @($agentId)
} | ConvertTo-Json
Invoke-MgGraphRequest `
    -Uri "https://graph.microsoft.com/beta/identityProtection/riskyAgents/confirmCompromised" `
    -Method POST `
    -Body $confirmBody `
    -ContentType "application/json"
Write-Host "Agente $agentId marcado como comprometido. CA policies de bloqueio já estão ativas."

Desabilitando todas as autenticações de um agente

powershell

# Desabilitar completamente o agente (bloqueia todos os sign-ins)
$disableBody = @{
    accountEnabled = $false
} | ConvertTo-Json
Invoke-MgGraphRequest `
    -Uri "https://graph.microsoft.com/beta/servicePrincipals/$agentId" `
    -Method PATCH `
    -Body $disableBody `
    -ContentType "application/json"
Write-Host "Agente $agentId desabilitado. Todas as autenticações bloqueadas."

Relatório de inventário completo de agentes

powershell

# Listar todos os agentes registrados no tenant
$agentsUri = "https://graph.microsoft.com/beta/servicePrincipals?`$filter=servicePrincipalType eq 'agent'&`$select=id,displayName,appId,createdDateTime,accountEnabled,customSecurityAttributes"
$allAgents = @()
$uri = $agentsUri
do {
    $response = Invoke-MgGraphRequest -Uri $uri -Method GET
    $allAgents += $response.value
    $uri = $response.'@odata.nextLink'
} while ($uri)
$allAgents | 
    Select-Object id, displayName, appId, createdDateTime, accountEnabled |
    Export-Csv "agent-inventory-$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation -Encoding UTF8
Write-Host "Total de agentes encontrados: $($allAgents.Count)"
Write-Host "Agentes desabilitados: $(($allAgents | Where-Object { -not $_.accountEnabled }).Count)"

Auditando agentes sem sponsor atribuído (orphaned agents)

powershell

# Identificar agentes sem sponsor — risco de agent sprawl
$orphanedAgents = $allAgents | Where-Object {
    $_.sponsors -eq $null -or $_.sponsors.Count -eq 0
}
Write-Host "Agentes sem sponsor atribuído (orphaned): $($orphanedAgents.Count)"
$orphanedAgents | 
    Select-Object displayName, id, createdDateTime |
    Export-Csv "orphaned-agents.csv" -NoTypeInformation -Encoding UTF8

Monitoramento contínuo com Azure Monitor / Sentinel

powershell

# KQL Query para o Microsoft Sentinel — detectar agentes com sign-in spike
// Tabela: AADServicePrincipalSignInLogs (filtra por agent identities)
AADServicePrincipalSignInLogs
| where ServicePrincipalType == "agent"
| summarize SignInCount = count() by ServicePrincipalName, bin(TimeGenerated, 1h)
| join kind=inner (
    AADServicePrincipalSignInLogs
    | where ServicePrincipalType == "agent"
    | summarize AvgSignIns = avg(count()) by ServicePrincipalName, bin(TimeGenerated, 1d)
) on ServicePrincipalName
| where SignInCount > AvgSignIns * 5  // 5x acima da média horária
| project TimeGenerated, ServicePrincipalName, SignInCount, AvgSignIns
| order by SignInCount desc

Investigando com Sign-in Logs

Admins podem usar os Sign-in logs para investigar por que uma política de Conditional Access se aplicou ou não, como explicado nos eventos de sign-in do Microsoft Entra. Esses eventos aparecem nos Service principal sign-ins. Você também pode filtrar por Agent type igual a agent identity.

Filtros úteis nos Sign-in Logs para agentes

powershell

# Filtrar sign-ins de agentes bloqueados por CA policies
$blockedUri = "https://graph.microsoft.com/beta/auditLogs/signIns?`$filter=signInEventTypes/any(t: t eq 'servicePrincipal') and conditionalAccessStatus eq 'failure'&`$top=100"
$blockedSignIns = Invoke-MgGraphRequest -Uri $blockedUri -Method GET
$blockedSignIns.value | 
    Select-Object appDisplayName, 
                  conditionalAccessStatus,
                  @{N="PolicyName";E={$_.appliedConditionalAccessPolicies[0].displayName}},
                  @{N="PolicyResult";E={$_.appliedConditionalAccessPolicies[0].result}},
                  createdDateTime |
    Format-Table -AutoSize

Governança e Agent Sprawl

A governança de identidades de agentes vai além do bloqueio de riscos — ela aborda o ciclo de vida completo do agente, do registro à descomissionamento.

Componentes de governança disponíveis

Boas práticas de ciclo de vida

1. Registro → Atribuir sponsor + custom security attributes no momento da criação
2. Aprovação → Processo formal de review antes de mover de "New" para "Approved"
3. Operação → Monitoramento contínuo via ID Protection; revisão semestral de permissões
4. Renovação → Access packages com prazo de validade; exige renovação ativa
5. Descomissionamento → Disable imediato + revogação de tokens + arquivamento de logs

Configurando Access Package para agentes

powershell

# Criar um Access Package dedicado a agentes de RH
$accessPackageParams = @{
    displayName = "Agent Access — HR Resources"
    description = "Permissões para agentes aprovados pelo time de RH"
    catalog = @{ id = "<catalog-id>" }
    isHidden = $false
}
$newPackage = New-MgEntitlementManagementAccessPackage -BodyParameter $accessPackageParams
Write-Host "Access Package criado: $($newPackage.Id)"
# Configurar política de expiração (180 dias, renovação obrigatória)
$assignmentPolicyParams = @{
    accessPackageId = $newPackage.Id
    displayName = "HR Agent Assignment Policy"
    expiration = @{
        type = "afterDuration"
        duration = "P180D"  # 180 dias
    }
    requestorSettings = @{
        scopeType = "NoSubjects"  # Apenas admins podem atribuir
        allowExistingAccessPackageAssigneesToRenew = $true
    }
    requestApprovalSettings = @{
        isApprovalRequiredForAdd = $true
        isApprovalRequiredForUpdate = $false
        approvalStages = @(
            @{
                approvalStageTimeOutInDays = 14
                isApproverJustificationRequired = $true
                primaryApprovers = @(
                    @{
                        "@odata.type" = "#microsoft.graph.groupMembers"
                        groupId = "<hr-managers-group-id>"
                    }
                )
            }
        )
    }
}
New-MgEntitlementManagementAccessPackageAssignmentPolicy -BodyParameter $assignmentPolicyParams

Mitos e Correções

❌ Mito 1: “Service Principals existentes já cobrem agentes de IA”

Correção: Service Principals foram projetados para aplicações que executam lógica determinística, não para sistemas autônomos com comportamento adaptativo. O Agent ID introduz uma construção de identidade própria com metadados específicos (sponsors, blueprints, capabilities), sinais de risco específicos (unfamiliar resource access, sign-in spike), e integração nativa com as políticas de Conditional Access orientadas a agentes. Registrar um agente de IA como Service Principal tradicional é equivalente a gerenciar uma frota de veículos autônomos com a carteira de habilitação de um motorista humano — funcionalmente incompleto.

❌ Mito 2: “Conditional Access para agentes funciona igual ao de usuários”

Correção: A diferença é fundamental. Para usuários, o CA pode exigir MFA, dispositivo compliant, localização específica, e uma série de controles interativos. Para agentes, nenhum controle interativo se aplica — o agente não pode completar um desafio de MFA. Os controles disponíveis para agentes são: bloquear acesso, filtrar por risco de agente e filtrar por custom security attributes. Tentar aplicar políticas de usuário a agentes sem considerar isso pode resultar em quebra silenciosa de workflows.

❌ Mito 3: “MFA no usuário protege automaticamente os agentes que ele cria”

Correção: No fluxo Client Credentials (autonomous agents), o subject do token é a identidade do agente — não o usuário. O MFA do usuário não é avaliado nesse fluxo. Um usuário com MFA forte pode criar um agente que, se comprometido, opera completamente fora do contexto do MFA do usuário. É necessário configurar políticas específicas para agent identities.

❌ Mito 4: “Desabilitar o agente no portal é suficiente como resposta a incidente”

Correção: Desabilitar o objeto no Entra ID (accountEnabled = false) bloqueia novas autenticações, mas não revoga tokens já emitidos. Em um cenário de comprometimento, tokens ativos podem continuar sendo usados até a expiração natural. O fluxo correto de resposta a incidente inclui: (1) confirmar comprometimento via ID Protection para disparar CA policies imediatamente, (2) desabilitar o agente para bloquear novas autenticações, (3) revogar todos os tokens ativos via revokeSignInSessions, e (4) realizar análise forense nos logs antes de decommission.

❌ Mito 5: “Agent sprawl é um problema de TI, não de segurança”

Correção: Agent sprawl é um risco de segurança crítico. Agentes sem sponsor, sem revisão de permissões e sem lifecycle definido são equivalentes a service accounts abandonados com permissões amplas — um dos vetores de ataque mais comuns em ambientes corporativos. A diferença é que agentes de IA tomam decisões autônomas, amplificando o impacto potencial de um comprometimento.

Boas Práticas de Segurança e Governança

1. Comece com Report-only, sempre

Antes de ativar qualquer política de Conditional Access para agentes em modo enforced, valide o impacto em Report-only por pelo menos 2 semanas. Agentes falham silenciosamente quando o acesso é negado — sem uma mensagem de erro óbvia para o usuário. O Report-only permite identificar quais workflows seriam quebrados antes de causar impacto.

2. Implante o template Microsoft Managed Policy como baseline

A Microsoft disponibiliza um template gerenciado que bloqueia agentes de alto risco automaticamente. Este é o ponto de partida mínimo para qualquer tenant que implante agentes:

https://aka.ms/CreateAgentRiskPolicy

3. Nunca use uma Service Principal compartilhada para múltiplos agentes

Cada agente deve ter sua própria agent identity. Compartilhar identidades impossibilita atribuir risco, rastrear atividade individual, e descomissionar um único agente sem impactar os demais.

4. Atribua sponsors obrigatoriamente no registro

Nenhum agente deve existir no tenant sem um sponsor humano responsável. Automatize essa verificação:

powershell

# Alerta: agentes criados sem sponsor nas últimas 24h
$yesterday = (Get-Date).AddDays(-1).ToString("yyyy-MM-ddTHH:mm:ssZ")
$newAgentsUri = "https://graph.microsoft.com/beta/servicePrincipals?`$filter=servicePrincipalType eq 'agent' and createdDateTime ge $yesterday"
$newAgents = Invoke-MgGraphRequest -Uri $newAgentsUri -Method GET
$agentsWithoutSponsor = $newAgents.value | Where-Object { 
    $_.sponsors -eq $null -or $_.sponsors.Count -eq 0 
}
if ($agentsWithoutSponsor.Count -gt 0) {
    Write-Warning "ALERTA: $($agentsWithoutSponsor.Count) agentes criados sem sponsor nas últimas 24h"
    $agentsWithoutSponsor | Select-Object displayName, id, createdDateTime
}

5. Use Custom Security Attributes para classificação e controle de acesso

Não dependa apenas de listas manuais de agentes aprovados. Use atributos para escalar o controle:

AgentAttributes.AgentApprovalStatus = HR_Approved → acessa recursos HR
AgentAttributes.AgentApprovalStatus = Finance_Approved → acessa recursos Finance
AgentAttributes.Environment = Production → sujeito a políticas mais restritivas
AgentAttributes.DataSensitivity = High → exige log de todas as ações

6. Configure alertas no Sentinel para os 6 tipos de detecção de risco

Todos os riskEventType do ID Protection para agentes devem gerar alertas no SIEM:

unfamiliarResourceAccess → Severidade: Alta
signInSpike             → Severidade: Média
failedAccessAttempt     → Severidade: Alta
riskyUserSignIn         → Severidade: Crítica
adminConfirmedAgentCompromised → Severidade: Crítica
threatIntelligenceAccount → Severidade: Crítica

7. Inclua agentes nas Access Reviews semestrais

Estenda o processo existente de Access Review para incluir agent identities. Perguntas-chave a responder em cada ciclo:

• O agente ainda está em uso ativo?
• As permissões atribuídas ainda são necessárias?
• O sponsor original ainda é responsável por este agente?
• As permissões sofreram permission creep desde o último review?

8. Documente a estratégia de AI Identity Governance formalmente

Crie e mantenha um documento de AI Identity Governance Policy que cubra:

• Processo de aprovação para registro de novos agentes
• Matriz de aprovação por departamento (HR_Approved, Finance_Approved etc.)
• SLA de resposta a incidentes envolvendo agent identities comprometidas
• Processo de descomissionamento e arquivamento de logs
• Responsabilidades: quem pode criar, quem aprova, quem monitora

Referências do Microsoft Learn

• Microsoft Entra security for AI overview
• What is Microsoft Entra Agent ID?
• Conditional Access for agent identities
• Conditional Access for autonomous agents (Preview)
• Block access for high-risk agent identities (CA Template)
• ID Protection for agents (Preview)
• Manage agent identities in your organization
• Identity governance for agents
• What are agent identities?
• Secure Web and AI Gateway for agents (Global Secure Access)
• Custom security attributes overview
• Conditional Access: Users, groups, agents, and workload identities
• Microsoft Entra ID Protection overview
• What is Microsoft Entra ID Governance?
• ID Protection APIs — Microsoft Graph

Artigo publicado no Blog Chesley · chesley.com.br Chesley Fernandes — Especialista em Microsoft 365, Entra ID e Segurança de Identidade