Mandato, presença e circuit breaker para agentes

Rótulo honesto: esta linha é arquitetura-alvo. Existe em código e em ambiente de teste. Não é oferta comercial, e nada aqui está disponível para contratação.

O problema, sem exagero

Um agente de software que executa ações no mundo, que paga, transfere, cancela ou assina, precisa de alguma forma de autorização. As respostas usuais são duas, e as duas têm o mesmo defeito: a instrução no prompt (“não pague sem aprovação”) e o if dentro do próprio processo que age. Ambas são conselhos. Funcionam enquanto quem as recebe quiser segui-las, e quem não segue não precisa ser malicioso. Basta um retry mal escrito, um caminho de erro esquecido ou um serviço antigo que ninguém atualizou.

O que propomos não é uma trava melhor dentro do agente. É mover a trava de lugar.

A frase inteira

O sistema que executa a ação só executa com o recibo de que uma pessoa específica, viva e presente, viu e autorizou; qualquer um verifica esse recibo sem confiar em ninguém.

As duas metades importam. A primeira põe a decisão em quem executa, não em quem pede. A segunda diz que a verificação é offline, com chave pública: nem nós precisamos estar no caminho para que o recibo valha.

Dois degraus, nunca um

Se toda ação exigir uma pessoa, a pessoa aprova no automático em uma semana e o portão vira teatro. Por isso o desenho tem dois degraus.

Rotina sob mandato. Uma pessoa concede, uma vez só, com presença viva: um mandato com escopo escrito, que diz quais ações, com que limites, até quando, revogável ou não. Depois disso o agente age sozinho dentro daquele escopo, e cada ação gera um ato delegado de nível 0, sem humano novo, com recibo assinado. O que sustenta a ação não é o conteúdo dela, e sim o mandato.

Exceção com presença. O que sai do escopo não é negociado com o agente. Exige uma prova nova, de nível 2, com a pessoa presente, pelo mesmo túnel de verificação que já existe.

A receita do contexto, e por que ela é o centro

O recibo não carrega o que o agente fez. Nós não vemos a ação, e não queremos ver. O que o recibo carrega é o hash do contexto que o cliente declarou, mais os nomes das chaves declaradas:

contexto.hash = "sha256:" + hex(SHA-256(JCS(contexto)))

JCS é a canonicalização do RFC 8785, a mesma do resto do formato. Quem tem o contexto original recomputa o hash sozinho e confere, sem nada nosso. É isso que amarra um recibo a um pedido específico.

Dentro desse contexto vão duas coisas que o executor escolhe: um nonce que ele mesmo emitiu e o identificador dele. Nenhum campo novo entrou no recibo para isso. Nonce, executor e frescor são chaves declaradas no contexto, mais uma janela sobre o instante de conclusão. É o que impede que uma prova legítima de outro pedido, ou do mesmo pedido outra vez, sirva para a ação de agora.

Parar: autoridade, não computação

Ninguém para a computação de um agente que não hospeda, e prometer isso seria mentira. Não há kill switch de infraestrutura neste desenho.

O que se para é a autoridade, nos sistemas que a exigem:

revogar a autoridade do agente em todos os sistemas que a exigem, com um ato humano, e só devolvê-la com outro

Na prática, quatro camadas. Revogar o mandato, que é um ato humano com recibo próprio. Propagar, porque um evento de webhook avisa os executores e um endereço de consulta responde o estado do mandato para quem perdeu o aviso. Parar tudo, com revogação em lote por mandatário ou por cliente, alvo obrigatório e sem padrão, e um recibo por mandato derrubado. E retomar, que não é um botão: é um mandato novo, com presença viva de novo.

Um detalhe que não é detalhe. O recibo de um ato delegado feito antes da revogação continua válido e verdadeiro, porque prova o que provava. O que deixou de existir é a autoridade para o próximo.

O que medimos

Comparamos, num banco de ensaio determinístico, um portão que avisa e executa assim mesmo contra o executor que exige o recibo. Sete formas de chamada, das corretas às erradas, sem modelo de linguagem em nenhuma delas, porque o que se mede é o mecanismo e não o comportamento de um modelo.

O portão advisory deixou passar seis das sete. O exigente, uma, a correta. A leitura que interessa não é a razão entre os números: o advisory parou exatamente um chamador, e foi o único que já ia parar sozinho.

O método e os dados estão na nota Um portão que avisa e um portão que exige.

Limites, declarados

• Isto não decide o que é arriscado. Quem escolhe o que exige prova é o cliente, na política dele. Não há score, limiar nem heurística de risco no desenho, e não vai haver.
• Não substitui controle de acesso. Prova de presença humana não responde quem pode o quê. Responde se uma pessoa viva estava ali e autorizou.
• A presença viva passa hoje por um componente certificado da AWS, fora do país. Fonte nacional é arquitetura-alvo.
• Não provamos que a referência facial enviada pelo cliente é legítima. Provamos que quem está na câmera é a mesma pessoa da referência que ele nos deu.
• Credencial delegada de curta duração não existe hoje, para executores sem rede no momento da ação.
• Nada disto é oferta comercial. Enquanto for arquitetura-alvo, será chamado assim.