Introdução: o próximo usuário em seu sistema pode não ser humano
A próxima conta que acessar seus sistemas não poderá pertencer a um funcionário. Pode pertencer – ou deveria pertencer – a um agente de IA.
Um gerente de operações pede a um agente que prepare um relatório semanal. Ele abre um painel, baixa um CSV, lê uma pasta de trabalho do Excel, compara os resultados da semana passada, cria um relatório e retorna o rascunho.
O fluxo de trabalho é bem-sucedido, mas cada log registra alex@company.com. A organização não pode dizer o que Alex executou, se o agente excedeu a sua tarefa ou se o acesso continuou.
Se um agente de IA pode interagir com sistemas como um usuário, deveria continuar emprestando a identidade de um usuário?
É aqui que Identidade Não Humana torna-se central para a governança da IA. As organizações devem separar a entidade que realiza o trabalho da credencial que utiliza e das permissões que recebe.
O que é um Non-Human Identity?
UM Identidade Não Humana é uma identidade digital usada por software, serviços, processos automatizados, dispositivos, cargas de trabalho ou agentes de IA para autenticar e acessar sistemas sem agir como um usuário humano.
Os exemplos incluem contas de serviço, entidades de serviço, identidades gerenciadas, cargas de trabalho, dispositivos, bots, scripts, pipelines de CI/CD, integrações de API e agentes de IA.
Um Non-Human Identity não é automaticamente uma chave de API, senha, token, certificado, máquina, bot ou modelo. Podem ser credenciais, mecanismos de autenticação, entidades de execução ou recursos conectados.
O modelo tem três perguntas:
- Identidade: Quem ou o que está agindo?
- Credencial: Como isso prova essa identidade?
- Permissão: O que ele pode acessar ou alterar?
Identidade, credencial e permissão
| Conceito | Pergunta respondida | Exemplo |
|---|---|---|
| Identidade | Quem ou o que está agindo? | Agente Reportante Semanal |
| Credencial | Como isso prova sua identidade? | Token de acesso de curta duração |
| Permissão | O que ele pode acessar ou alterar? | Ler dados do painel e gravar arquivos de relatório |
| Patrocinador humano | Quem é o responsável pela identidade? | Gerente de operações |
| Vida útil | Quando o acesso deve começar e terminar? | Active para o fluxo de trabalho e revisado trimestralmente |
Uma credencial não é a identidade em si. É uma evidência usada por uma identidade para autenticação.
Os principais tipos de Non-Human Identity
Contas de serviço
Essas contas oferecem suporte a aplicativos, scripts, programações e integrações. Os riscos incluem propriedade compartilhada, senhas estáticas, acesso excessivo e ausência de data de aposentadoria.
Identidades principais de aplicativo e serviço
Representam aplicativos que acessam APIs, serviços em nuvem ou recursos, incluindo SaaS e automação interna.
Identidades gerenciadas e de carga de trabalho
Eles representam cargas de trabalho de software, como máquinas virtuais, contêineres, funções sem servidor, trabalhos de CI/CD e aplicativos em nuvem. As plataformas suportadas podem usá-los sem armazenar segredos permanentes diretamente no código.
Identidades de máquinas e dispositivos
Eles verificam servidores, laptops, equipamentos de rede, sistemas industriais e dispositivos IoT por meio de certificados, chaves ou registros de dispositivos.
Identidades de agentes de IA
Representam agentes que interpretam objetivos, escolhem ferramentas, acessam recursos e executam ações. Os agentes de IA cabem no Non-Human Identity, mas seu comportamento adaptativo os torna mais difíceis de governar do que as contas de serviços fixos.
Non-Human Identity vs máquina Identity vs carga de trabalho Identity
Identidade Não Humana é o amplo guarda-chuva. Machine identity, identidade da carga de trabalho, contas de serviço e identidade do agente são categorias ou padrões de implementação mais restritos.
Non-Human Identity comparado com tipos Identity relacionados
| Tipo Identity | O que representa | Exemplos típicos |
|---|---|---|
| Identidade humana | Uma pessoa real | Funcionário, contratado, parceiro, cliente |
| Identidade Não Humana | Uma entidade baseada em software ou máquina que acessa recursos | Service account, aplicativo, bot, carga de trabalho, agente de IA |
| Identidade da máquina | Uma máquina, dispositivo, servidor ou componente técnico | Certificado de dispositivo, chave de servidor, identidade IoT |
| Identidade da carga de trabalho | Executando software em nuvem ou infraestrutura | Contêiner, máquina virtual, função sem servidor |
| Conta de serviço | Uma conta usada por um aplicativo ou tarefa automatizada | Conta de relatório agendado, integração de banco de dados |
| Identidade do agente | Uma identidade que representa um agente de IA | Agente de pesquisa, agente relator, agente de desktop |
A terminologia difere entre plataformas. A governação deve centrar-se no que a identidade representa, onde funciona, a que pode aceder e quem a possui. Nem todo Non-Human Identity representa uma máquina física.
Por que os agentes de IA mudam o problema Non-Human Identity
Os agentes seguem metas, não apenas instruções fixas
A automação tradicional pode copiar um backup à meia-noite. Um agente solicitado a investigar um desempenho incomum e preparar um relatório pode escolher ações diferentes dependendo do que encontrar.
Os agentes usam várias ferramentas
Um agente pode mover-se entre APIs, arquivos, navegadores, planilhas, bancos de dados, ferramentas de comunicação e subagentes. Cada conexão estende a cadeia de permissões.
As permissões variam de acordo com a tarefa
Os fluxos de trabalho de pesquisa, relatórios e suporte ao cliente não devem receber o mesmo acesso permanente simplesmente porque usam a mesma plataforma.
Os agentes podem delegar
Um agente primário pode chamar uma ferramenta especializada ou outro agente. O acesso deve ser rastreável e herdado sob regras claras ou autorizado separadamente.
Agentes agem em nome de pessoas
Os sistemas devem distinguir ações humanas, ações de agentes solicitadas por humanos, etapas selecionadas por agentes dentro de uma tarefa aprovada e ações delegadas. Agent identity deve preservar o link entre solicitante, executor, credencial e resultado.
Por que os agentes de IA não devem se esconder atrás de contas humanas
Um agente pode usar a sessão do navegador, o token da API, a conta de e-mail ou o login do aplicativo de um funcionário. O fluxo de trabalho pode funcionar, mas a atribuição torna-se fraca.
Os logs mostram apenas a conta do funcionário, enquanto o agente herda tudo o que o funcionário pode alcançar. As equipes de segurança não conseguem separar de forma confiável o comportamento humano da automação, e o acesso pode sobreviver além da tarefa pretendida.
Um modelo de atribuição melhor é:
- Iniciado por: Alex
- Executado por: Agente Reportante Semanal
- Ambiente: Desktop corporativo aprovado
- Aprovado por: Gerente financeiro
O patrocinador permanece responsável pela finalidade, enquanto a identidade do agente mostra quem executou o trabalho. Um agente deve agir em nome de um ser humano sem se tornar indistinguível desse ser humano.
Os principais riscos de identidades não humanas não gerenciadas
Identidades órfãs
O acesso permanece ativo após a saída de um funcionário, o término de um projeto, a substituição de uma integração ou o abandono de um agente.
Permissões excessivas
O amplo acesso é concedido porque políticas restritas causam falhas e a conveniência temporária torna-se um privilégio permanente.
Credenciais de longa duração
Senhas estáticas, chaves de API, certificados e tokens podem permanecer utilizáveis muito depois de a necessidade original ter passado.
Identidades compartilhadas
Vários aplicativos, agentes ou funcionários usam uma conta, enfraquecendo a atribuição e a propriedade.
Expansão de identidade
Service accounts, bots, aplicativos OAuth, tokens, scripts e agentes filhos se acumulam sem um inventário confiável.
Responsabilidade fraca
Após um incidente, a responsabilidade pode ser contestada entre o solicitante, o proprietário do fluxo de trabalho, o proprietário do aplicativo, o aprovador e os fornecedores de tecnologia.
O maior risco muitas vezes não é a existência de uma identidade, mas sim o facto de ninguém saber por que ela existe, o que pode fazer ou quando deve desaparecer.
Um Non-Human Identity Lifecycle de oito etapas
Step 1: Descubra
Contas de serviço de inventário, identidades de aplicativos, aplicativos OAuth, agentes locais e de nuvem, bots, scripts, certificados, programações, integrações de API e ferramentas conectadas.
Step 2: Registrar
Registre um nome exclusivo, tipo, finalidade, criador, patrocinador, departamento, tempo de execução, ferramentas conectadas, dados acessíveis, tipo de credencial e expiração.
Step 3: Atribuir um patrocinador humano
Uma pessoa nomeada deve aprovar a finalidade, revisar o acesso, responder a incidentes, transferir a propriedade e autorizar a aposentadoria.
Step 4: Definir o limite de identidade
Documente sistemas permitidos, pastas, registros, ferramentas, ações e proibições explícitas.
Step 5: Aplicar privilégio mínimo
Conceda apenas o que o fluxo de trabalho atual exige. Evite acesso administrativo permanente adicionado apenas para reduzir falhas.
Step 6: Prefira credenciais de curta duração
Quando houver suporte, use tokens temporários, identidades gerenciadas, federação de carga de trabalho, credenciais com escopo de tarefa, expiração e revogação.
Step 7: Monitorar comportamento
Capture eventos de autenticação, recursos acessados, ferramentas chamadas, arquivos abertos, alterações, transferências, falhas, novas tentativas e delegação.
Step 8: girar, transferir e retirar
Quando o fluxo de trabalho mudar ou terminar, alterne credenciais, transfira propriedade, remova programações, revogue permissões, desconecte ferramentas, retire identidades de crianças e retenha registros de auditoria.
Lista de verificação do ciclo de vida da identidade não humana
| Pergunta Lifecycle | Resposta obrigatória |
|---|---|
| Qual é a identidade? | Nome exclusivo e tipo de identidade |
| Por que isso existe? | Finalidade comercial documentada |
| Quem é o dono? | Nomeado patrocinador humano |
| Onde ele funciona? | Aplicativo, dispositivo ou carga de trabalho conhecido |
| O que ele pode acessar? | Sistemas, arquivos, dados e ferramentas definidos |
| Como ele autentica? | Credencial aprovada e gerenciada |
| Quando o acesso é revisado? | Data de revisão agendada |
| Quando expira? | Expiração definida ou condição de aposentadoria |
| Como a atividade é monitorada? | Logs, alertas e processo de auditoria |
Como dar aos agentes de IA acesso com privilégios mínimos
O privilégio mínimo deve seguir o fluxo de trabalho, não a capacidade máxima do agente.
Um agente relator semanal pode precisar de uma pasta de relatórios, dois painéis, downloads de CSV, um diretório de saída e permissão para preparar um rascunho. Pode não ser necessário todo o disco rígido, todos os perfis de navegador, e-mail pessoal, controles de cobrança, gerenciamento de permissões, exclusão de arquivos de origem ou autoridade para enviar o relatório externamente.
Defina quatro camadas:
- Escopo do recurso: Quais sistemas, pastas, aplicativos e registros?
- Escopo de ação: Ler, escrever, modificar, excluir, publicar ou enviar?
- Escopo de tempo: Permanente, agendado, temporário ou baseado em tarefas?
- Escopo de aprovação: Quais ações precisam de confirmação explícita?
O privilégio mínimo limita o que um agente pode ver, o que pode fazer, por quanto tempo pode fazê-lo e sob a aprovação de quem.
Por que os agentes de IA de desktop precisam de Identity Boundaries claro
Os agentes de desktop podem interagir com arquivos locais, aplicativos instalados, sessões do navegador, credenciais salvas, downloads, capturas de tela, conteúdo da área de transferência, controles do sistema operacional e aplicativos de comunicação. Seu limite de identidade pode, portanto, abranger muito mais de uma API.
Um fluxo de trabalho de desktop pode envolver:
Solicitante humano -> canal de comunicação -> agente de desktop -> dispositivo corporativo -> identidade do navegador -> aplicativo de negócios -> pasta de saída
A organização deve saber quem enviou a tarefa, qual agente a recebeu, qual dispositivo e conta foram usados, quais ações ocorreram, qual saída foi criada e quem a revisou.
A execução local pode reduzir alguma transmissão de dados, dependendo da configuração. Ele não remove o risco de identidade nem responde quem o agente representa e quais permissões ele usa.
EasyClaw ilustra por que os agentes de desktop precisam de limites explícitos entre arquivos, navegadores, aplicativos e saídas.
Como EasyClaw se encaixa em uma estratégia de agente governado Identity
EasyClaw é um agente de fluxo de trabalho de IA nativo de desktop para trabalhos envolvendo arquivos locais, aplicativos, interfaces de navegador, relatórios, revisões e pastas de projetos. Não é uma plataforma de gerenciamento de identidade nem um substituto para IAM, acesso privilegiado, rotação de credenciais ou controles de ameaças.
Sua função prática é ilustrar por que um agente de desktop deve operar dentro de um limite de identidade nomeado, limitado, visível e revisável.
Identifique o solicitante humano
Defina quem pode emitir tarefas EasyClaw, quais canais são aprovados, como os solicitantes são autenticados e quem pode iniciar fluxos de trabalho confidenciais. Cada solicitação deve levar de volta a uma pessoa específica.
Identifique o ambiente EasyClaw em execução
Registre a implantação do EasyClaw, o dispositivo corporativo, a conta do sistema operacional, o perfil do navegador, os aplicativos aprovados e o proprietário do fluxo de trabalho. O solicitante e o ambiente de execução estão conectados, mas não são o mesmo ator.
Limitar o escopo do arquivo e do aplicativo
Um fluxo de trabalho de relatórios pode precisar de uma pasta, uma pasta de trabalho do Excel, painéis selecionados, um modelo PDF e um diretório de saída. Ele não deve acessar automaticamente todos os arquivos locais, contas de navegador, unidades de nuvem, configurações administrativas ou sistemas não relacionados. O escopo claro também reduz a seleção errada de arquivos e substituições acidentais.
Mantenha as ações consequentes atrás da aprovação
Exija aprovação humana para mensagens externas, publicação pública, exclusão ou substituição de arquivos, envio de informações financeiras, alteração de registros de clientes, modificação de permissões, conclusão de pagamentos e alteração de contratos.
EasyClaw pode organizar o trabalho intermediário, preparar pacotes de revisão e retornar resultados utilizáveis. Decisões irreversíveis, visíveis externamente, financeiramente materiais ou com consequências jurídicas devem permanecer com o ser humano responsável.
Documente o ciclo de vida do fluxo de trabalho
Cada fluxo de trabalho deve ter nome, finalidade, patrocinador, entradas aprovadas, ações, destino de saída, data de revisão, condição de parada e procedimento de retirada. Novas contas, canais ou destinos devem desencadear uma revisão.
EasyClaw deve operar como um agente de desktop visível e com escopo dentro de um fluxo de trabalho aprovado – não como um software invisível que toma emprestado acesso ilimitado de uma conta humana.
Example: Fornecendo a um Agente Reportante EasyClaw um Limite Identity claro
Um gerente de operações solicita: “Prepare o relatório de desempenho desta semana, compare-o com o da semana passada e devolva o rascunho para revisão.
O fluxo de trabalho EasyClaw aprovado abre painéis selecionados, baixa as exportações atuais, lê o rastreador semanal do Excel, compara o relatório anterior, prepara um rascunho, salva o pacote e o devolve. EasyClaw lida com a execução de muitos documentos, enquanto os controles de identidade e segurança definem o que ele pode usar.
Identity Boundaries para um fluxo de trabalho de relatórios EasyClaw
| Identity ou componente | Papel | Limite obrigatório |
|---|---|---|
| Gerente de operações | Inicia a tarefa | Pode iniciar o fluxo de trabalho de relatórios aprovados |
| Fluxo de trabalho de relatórios EasyClaw | Executa a tarefa | Limitado a ações de denúncia |
| Computador corporativo | Ambiente de execução | Dispositivo aprovado e gerenciado |
| Identidade do navegador | Lê sistemas de desempenho | Acesso somente leitura aos painéis selecionados |
| Escopo de acesso a arquivos | Lê e escreve materiais de relatório | Somente pastas de relatórios semanais |
| Diretório de saída | Armazena materiais gerados | Pasta de revisão Dedicated |
| Revisor humano | Verifica o relatório | Deve aprovar as conclusões finais |
| Canal de comunicação | Retorna o resultado | Somente solicitante aprovado e caminho de entrega |
A cadeia de atribuição deve permanecer visível:
- Iniciado por: Gerente de operações
- Executado por: Fluxo de trabalho de relatórios EasyClaw
- Dados acessados: Painéis aprovados e pasta de relatórios
- Análiseed by: Gerente de operações
- Distribuído por: Proprietário humano após aprovação
Isso separa solicitação, execução, acesso, aprovação e distribuição. Se os números parecerem errados, a equipe poderá inspecionar as fontes aprovadas, os arquivos usados, os resultados gerados e a decisão do revisor. EasyClaw é a camada de execução do fluxo de trabalho; os sistemas de identidade existentes permanecem responsáveis pela autenticação, credenciais, permissões e políticas.
Conclusão: todo agente precisa de um Identity, um proprietário e uma data de expiração
Non-Human Identity inclui aplicativos, serviços, máquinas, cargas de trabalho, scripts, bots, processos automatizados e agentes de IA.
Os agentes de IA aumentam os riscos porque seu comportamento pode ser adaptativo, delegado e distribuído entre ferramentas. As organizações precisam saber qual agente atua, quem o patrocina, quais credenciais e permissões utiliza, como as ações são registradas, quando a aprovação é necessária e quando o acesso expira.
EasyClaw não é uma plataforma de gerenciamento de identidade. Seu modelo de execução em desktop mostra por que os fluxos de trabalho dos agentes precisam de proprietários nomeados, acesso restrito a arquivos e aplicativos, execução visível, resultados revisáveis e aprovação humana para ações consequentes.
Todo agente de IA precisa de uma identidade, um patrocinador humano, um limite de permissão e uma data de validade.
Perguntas frequentes
P: Uma chave de API é um Non-Human Identity?
R: Não por si só. Uma chave de API geralmente é uma credencial; a identidade é o aplicativo, serviço, carga de trabalho, script ou agente que a utiliza.
P: Uma conta de serviço é igual a Non-Human Identity?
R: Uma conta de serviço é uma forma comum de Identidade Não Humana. A categoria mais ampla também inclui entidades de serviço, identidades gerenciadas, cargas de trabalho, máquinas, dispositivos, bots, aplicativos e agentes.
P: Por que um agente de IA não deveria usar uma conta de funcionário?
R: Uma identidade compartilhada oculta se uma pessoa ou agente agiu e pode conceder acesso excessivo. Um modelo governado registra o solicitante, o executor, o ambiente, o acesso e o revisor.
P: Cada agente de IA precisa de uma identidade separada?
R: Os agentes de produção devem ser suficientemente distinguíveis para apoiar atribuição, política, revisão e revogação. A implementação depende dos recursos da plataforma, do risco, da sensibilidade dos dados e das ações permitidas.
P: Como o EasyClaw se relaciona com o gerenciamento do Non-Human Identity?
R: EasyClaw não é um serviço de substituição ou gerenciamento de credenciais do IAM. Seus fluxos de trabalho de desktop demonstram por que as equipes devem definir solicitante, dispositivo, conta do navegador, escopo do arquivo, ações, aprovações, propriedade, revisão e desativação.
P: O que um fluxo de trabalho EasyClaw deve registrar?
R: Registre seu nome, finalidade, patrocinador, dispositivo, perfil do navegador, arquivos e aplicativos permitidos, ações, aprovações, destino, data de revisão e condição de desativação.
P: Quais ações do agente devem exigir aprovação humana?
R: Os exemplos incluem comunicação externa, publicação pública, exclusão de arquivos, envios financeiros, pagamentos, alterações de registros de clientes, alterações de permissão e ações contratuais.