Empresarial · Governança de Agentes

Seus agentes têm nomes e proprietários
e um interruptor de desligamento.

Até 2027, as frotas — e uma frota de processos anônimos é um passivo. LeanCTX torna cada agente uma identidade registrada: única, propriedade de um humano, gerenciada no ciclo de vida, atestada e revogável — com cada transição no rastreamento de auditoria à prova de adulteração.

O modelo

A identidade é quem responde. O papel é o que executa.

Os papéis permanecem perfis de permissão reutilizáveis. A identidade anexa a responsabilidade por cima: agent_id, owner, status, key binding, attestation, heartbeat. Quatro propriedades tornam uma frota governável.

Identidade registrada

Cada agente é um registro: stable agent_id, role, Ed25519 key binding, data de criação. Não mais adivinhar qual processo fez o quê — o registro é a fonte da verdade sobre quem existe.

Propriedade, sempre

O registro sem um proprietário humano é rejeitado. A responsabilidade é estrutural: cada entrada de auditoria, cada evento do ciclo de vida, cada pacote de evidências rastreia até uma pessoa que responde pelo agente.

Revogável em uma transação

Suspenda um agente ou desvinculando um proprietário e suspendendo toda a sua frota atomicamente — cada suspensão auditada individualmente. O descomissionamento é final e escreve a entrada de fechamento da auditoria.

Atestado, honestamente

Hashes binários e de configuração de papel no registro e em cada heartbeat. O desvio aparece imediatamente (exit code 3) — upgrade, edição de configuração ou adulteração. Documentamos o que isso NÃO protege.

Na prática

Uma frota, cinco comandos.

Tudo é CLI-first e honesto em códigos de saída, para que seus pipelines e seu monitoramento possam agir sobre isso.

$ lean-ctx agent register --id ci-reviewer-1 --role reviewer --owner alice@org
registered: ci-reviewer-1 (role reviewer, owner alice@org)
spiffe id: spiffe://org.example/agent/reviewer/ci-reviewer-1

$ lean-ctx agent heartbeat ci-reviewer-1     # liveness + drift; exit 3 on drift

$ lean-ctx agent offboard-owner alice@org --reason "left company"
suspended 2 agent(s): ci-coder-1, ci-reviewer-1

$ lean-ctx agent check ci-reviewer-1         # enforce-path decision point
ci-reviewer-1: DENIED — suspended: left company   # exit 1

Cada transição escreve uma entrada de auditoria à prova de adulteração — registrados, suspensos, retomados, desativados são tipos de eventos padronizados (OCP Parte 4), então o histórico de identidade cai automaticamente em seus pacotes de evidências. Modelo completo e modelo de ameaças: documentos de identidade do agente.

"O que acontece quando alguém sai?"

Os agentes deles param. Mecanicamente. O desligamento do proprietário suspende todos os agentes ativos desse proprietário em uma transação bloqueada — conectado ao seu fluxo de desprovisionamento SCIM ou executado a partir da lista de verificação de saída. Agentes órfãos são as contas de serviço esquecidas da era dos agentes; LeanCTX torna-os estruturalmente impossíveis.

FAQ

O que as equipes de plataforma perguntam.

Por que os agentes precisam de identidades quando já têm funções?

Uma função diz o que um processo pode fazer; uma identidade diz quem é responsável por isso. Com frotas, as perguntas importantes são operacionais: quem possui este agente, quando foi a última vez que esteve ativo, quem o desligou e por quê, o que acontece com suas permissões quando seu proprietário sai? O registro responde mecanicamente — a identidade (quem) permanece separada da função (o quê), para que as funções permaneçam perfis reutilizáveis.

Qual é o problema do agente órfão?

Um agente cujo proprietário humano saiu da empresa, mas que continua rodando com suas credenciais — a versão da era dos agentes das contas de serviço esquecidas, exceto que ele lê código e executa comandos. LeanCTX fecha isso estruturalmente: os proprietários são obrigatórios no registro, e um único comando (ou seu fluxo de desprovisionamento SCIM) suspende toda a frota ativa de um proprietário em uma única transação bloqueada, cada suspensão auditada.

Como funciona o ciclo de vida?

ativo → suspenso ⇄ ativo → desativado. A suspensão carrega um motivo e é reversível; a desativação é final por design — o registro nunca é excluído nem reativado, porque a identidade faz parte do histórico de auditoria. Cada transição escreve uma entrada de auditoria à prova de adulteração usando tipos de eventos padronizados (agent_registered, agent_suspended, agent_resumed, agent_decommissioned — OCP Parte 4), então as mudanças de identidade aparecem automaticamente nos pacotes de evidências.

O que a atestação realmente prova?

O registro e cada hash de batimento cardíaco criptografa o binário em execução e o arquivo de função ativo. Um hash alterado significa que algo mudou — uma atualização, um edit de configuração ou adulteração — e aparece como desvio com um código de saída não nulo que seu monitoramento pode alertar. É detecção de desvio, não atestação remota: um atacante com controle total do host pode falsificar hashes, e nosso modelo de ameaças diz isso explicitamente. Complementa, mas não substitui, o endurecimento do host e a assinatura de código.

Como isso se integra ao nosso IAM?

Três ganchos. SPIFFE: cada registro mapeia para spiffe://<trust-domain>/agent/<role>/<agent_id>, então a identidade do workload K8s (SPIRE) e a identidade LeanCTX são o mesmo nome. SCIM: conecte seu fluxo de desprovisionamento à chamada de desligamento do proprietário. Modo de aplicação: a API de verificação é um único ponto de decisão — agentes não registrados ou suspensos são negados; comece no modo monitor, mude para aplicar assim que a frota for registrada.

Governe a força de trabalho dos agentes.

Registre seu primeiro agente em um minuto, localmente e gratuitamente — ou converse conosco sobre o rollout da frota com SCIM e SPIFFE envolvidos.