commonguy25/authproof-sdkRecibos de delegação criptograficamente assinados para agentes de IA. Defina exatamente o que uma IA pode e não pode fazer — assinado, verificável, à prova de adulteração.
AuthProof é uma camada de auditoria e atribuição para agentes de IA. Ele permite provar o que um usuário autorizou antes de o agente agir, e registra o que o agente realmente fez em relação a essa autorização.
O mecanismo é simples. O usuário assina um recibo de delegação com sua própria chave privada. O recibo carrega escopo, limites, instruções do operador (com hash) e uma janela de tempo. Um verificador de pré-execução checa cada ação proposta contra o recibo, e um log de ações somente-anexação registra o que foi executado. O resultado é evidência: o que foi autorizado, comparado com o que aconteceu.
Isso não é um controle de segurança contra um operador malicioso. O verificador roda no mesmo processo que o agente, e um operador desonesto pode simplesmente não chamá-lo. Nenhuma propriedade criptográfica pode corrigir isso de dentro do mesmo runtime. O AuthProof prova autorização para implantações que executam o gate, e dá a auditores, reguladores e usuários um registro que eles podem verificar após o fato.
O que o torna diferente:
O usuário é a autoridade de assinatura. O objeto de autorização é assinado com a chave privada do usuário, não escrito em uma política gerenciada pelo operador. O escopo assinado e o hash do programa no recibo sempre prevalecem sobre os metadados de log do operador. Se os metadados do operador conflitarem com o recibo assinado, o gate nega a ação em vez de seguir os metadados.
Compromisso de estado do modelo em duas fases. O modelo é medido no momento da autorização e medido novamente antes da execução. Essas medições são computadas por software e auto-atestadas, não enraizadas em hardware. Elas são evidência de adulteração para implantações honestas, não prova contra um host hostil.
Atualização do provedor versus substituição maliciosa, distinguidas. Mudanças no estado do modelo se classificam em atualizações legítimas do provedor (PROVIDER_UPDATE_REQUIRES_REAUTH) e trocas não autorizadas (MALICIOUS_MODEL_SUBSTITUTION). Cada uma produz um código de motivo de negação legível por máquina identificando quais componentes mudaram.
O gate que roda antes de qualquer ação do agente ser executada.
PreExecutionVerifier.check() verifica cada ação proposta contra o recibo de delegação assinado. Encaminhe cada ação através dele no processo do seu agente, antes de a ação rodar. O verificador assina suas próprias decisões de permitir/negar em um log de auditoria, então cada resultado faz parte do registro.
Uma verdade dura para se construir em torno: o verificador é do mesmo processo. Ele verifica prova; ele não pode impedir um operador que se recusa a chamá-lo. Use-o onde você quer evidência, não onde você precisa de imposição contra o operador que executa o código.
A maior parte da autorização de agentes hoje é a palavra do operador: uma política que o operador escreveu, imposta por código que o operador controla. Quando algo dá errado, não há registro do que o usuário realmente autorizou, apenas a reconstrução do operador disso. O AuthProof inverte isso. O recibo assinado do usuário antecede a execução, e o log de ações registra o que rodou contra ele. A pergunta "o usuário autorizou isso?" torna-se verificável em vez de discutível.
import { PreExecutionVerifier, DelegationLog } from 'authproof-sdk/pre-execution-verifier'
import { RevocationRegistry } from 'authproof-sdk'
// 1. Set up the gate
const delegationLog = new DelegationLog()
const revocationRegistry = new RevocationRegistry()
await revocationRegistry.init({ privateKey, publicJwk })
const verifier = new PreExecutionVerifier({ delegationLog, revocationRegistry })
await verifier.init({ privateKey: verifierKey, publicJwk: verifierPub })
// 2. Register your delegation receipt
delegationLog.add(receiptHash, receipt)
// 3. Gate every action â before the agent runs
const result = await verifier.check({
receiptHash,
action: { operation: 'read', resource: 'calendar' },
operatorInstructions: 'Summarize meetings. Stay within scope.',
programHash, // optional: prevents code substitution attacks
})
if (!result.allowed) {
throw new Error(`Blocked: ${result.blockedReason}`)
}
// Agent runtime only reaches here after all thirteen checks pass
| # | Verificação | Bloqueia quando |
|---|---|---|
| 1 | Assinatura do recibo | Assinatura ECDSA P-256 inválida ou recibo adulterado |
| 2 | Revogação | O recibo foi revogado via RevocationRegistry (cascata: um ancestral revogado nega os seus descendentes) |
| 3 | Janela temporal | Recibo expirado ou ainda não válido (oráculo de timestamp do log, não o relógio do cliente) |
| 4 | Âmbito | Ação não está em ScopeSchema.allowedActions; sem um esquema estruturado, a correspondência por palavras-chave é apenas consultiva e nunca bloqueia |
| 5 | Instruções do operador | As instruções fornecidas não correspondem ao hash bloqueado no recibo no momento da emissão; ignorado com um aviso quando o chamador as omite |
| 6 | Hash do programa | O programHash fornecido não corresponde ao hash executes comprometido (opcional) |
| 7 | Risco de sessão | Limiares de confiança/risco excedidos (opcional) |
| 8 | Integridade do esquema da ferramenta | toolSchemaHash não corresponde ao recibo (opcional) |
| 9 | Estado do modelo | Deriva do modelo detetada (opcional; medição calculada por software e auto-atestada) |
| 10 | Vinculação do hash de saída da ferramenta | O hash de saída não corresponde ao recibo (opcional) |
| 11 | Proveniência da instrução | A fonte da instrução não está nas trustedSources do recibo (opcional) |
| 14 | Contenção do âmbito do progenitor | O sub-recibo excede o âmbito do progenitor (apenas sub-recibos); revogar qualquer ancestral nega o filho no momento da verificação |
| 15 | Deriva do estado de autoridade | authorityStateCommitment sofreu deriva desde a emissão (opcional) |
Os espaços 12 e 13 nunca foram implementados; a lacuna na numeração é histórica. O gate para na primeira verificação falhada. O consumo de uso único é executado por último, depois de todas as verificações passarem, para que um espaço de consumo nunca seja queimado num recibo que seria negado por outro motivo.
Cada resultado de verificação, aprovado ou reprovado, é automaticamente registado num ActionLog imutável assinado com a própria chave do verificador.
Os dados assinados prevalecem. O âmbito e o hash do programa do recibo assinado prevalecem sempre sobre os metadados do log do operador. Se os metadados não assinados do DelegationLog estiverem em desacordo com o recibo assinado, o gate nega a ação (SCOPE_METADATA_MISMATCH / PROGRAM_METADATA_MISMATCH). Os metadados do log são apenas um fallback quando o recibo não contém um âmbito estruturado ou um valor executes assinado.
A delegação guiada é guiada pela observação. ScopeDiscovery.guided() e AuthProofClient.delegateGuided() executam observe → generateScope → approve → finalize numa única chamada, e o rascunho completo do âmbito observado é aprovado automaticamente sem revisão humana. Para um verdadeiro momento de autorização humana, passe o hook reviewDraft (aprovar, modificar ou recusar o rascunho antes da emissão) ou execute os passos separadamente com um approve() explícito.
Wrappers drop-in para frameworks comuns. Cada wrapper faz o gate de cada chamada através do PreExecutionVerifier antes de o código envolvido ser executado.