Autorize o efeito, não só o acesso à ferramenta.
O controle de acesso limita até onde o software pode chegar. Execution Authorization delimita o efeito exato que ele pode causar. O Action Proof é o protocolo que produz a cadeia verificável: um grant assinado e de uso único para uma operação canônica, aplicado num ponto que você controla e fechado com evidência que qualquer um confere offline.
Prova criptográfica da autorização. Evidência assinada do resultado da execução. Um Execution Grant prova o que foi autorizado; um Action Receipt preserva evidência assinada do resultado que o Guardian inscrito conseguiu estabelecer.
A nuvem autoriza, o seu Guardian executa
Chaves por tenant, credenciais de privilégio mínimo
Recibos assinados, verificáveis offline
POST https://mcp.securestamp.online/mcp
Authorization: Bearer ss_live_...
{ "jsonrpc":"2.0", "id":1, "method":"tools/list" }Acesso não é autorização para agir
Ter acesso à processadora de pagamentos não é o mesmo que estar autorizado a fazer um reembolso específico.
Acesso
O agente pode chamar as APIs de reembolso da processadora de pagamentos
Execution Authorization
refund.create charge ch_89172 amount USD 1.427,00 destination original_payment_method maxUses 1 expires 14:02 UTC
A autorização de recursos responde a que um principal pode acessar. Execution Authorization responde a qual efeito, específico de uma transação, ele pode causar. Um acesso fine-grained ainda deixa a transação em si indefinida: qual recurso, qual valor, qual destino, quantas vezes.
Três passos
Definir
Qual efeito exato está sendo pedido? O Guardian — não o modelo — lê o estado do provedor e o normaliza numa operação canônica com parâmetros explícitos.
Autorizar
Vincule esse efeito a um Execution Grant assinado e de uso único dentro da sua política, na autoridade que o protocolo exige para aquela operação.
Verificar
Execute num ponto que você controla e guarde um Action Receipt assinado que se recalcula offline.
read_message_request
Retorna o que uma mensagem está pedindo, apenas a partir de sinais. O corpo nunca sai do dispositivo.
analyze_message_intent
Mapeia sinais abstratos para intenções de ação sensível. Apenas sinais, nunca texto bruto.
verify_counterparty
Verifica se um remetente ou contraparte confere com o registro do tenant.
get_safe_next_step
Calcula o próximo passo mais seguro a partir de fatos declarados no registro.
authorize_action
Retorna um Action Verdict, um Safe Next Step e um recibo antes de uma ação sensível.
create_action_challenge
Cria uma verificação manual de duplo controle para uma contraparte conhecida.
issue_action_receipt
Emite um Action Receipt assinado sobre fatos já calculados.
get_source_envelope
Recupera o envelope assinado no dispositivo que uma pessoa realmente viu e aprovou.
request_execution_grant
Pede um grant de uso único para executar um efeito exato. Retorna um HOLD até que a autoridade humana ou o quórum exigido aprove.
get_execution_status
Informa em que ponto está uma execução, incluindo resultados que seguem genuinamente indeterminados.
Camada de execução
O grant não é permissão para improvisar
Um Execution Grant fica vinculado a um digest de efeito e à versão de política em vigor, vence e pode ser usado exatamente uma vez. Seu Guardian relê o estado do provedor imediatamente antes de mutar, reivindica o grant contra o próprio ledger e assina o resultado — inclusive resultados ambíguos. Um grant reproduzido nunca chega a um provedor.
- Grants são de uso único e vinculados a um único digest de efeito exato. maxUses é 1, sempre.
- A autoridade exigida é fixada pelo protocolo; quem chama não pode rebaixá-la.
- Toda concessão de privilégio exige quórum M-de-N, e quem pede nunca pode aprovar o próprio pedido.
- Perfis de quórum são snapshots de política assinados, não valores de autoridade: a prova se apoia no threshold, na lista de aprovadores e no hash da política.
- Os resultados são succeeded, failed_no_effect ou indeterminate — a ambiguidade nunca é arredondada para cima.
- Os proof bundles se verificam offline, sem nenhuma chamada de volta ao SecureStamp.
Parábola 3
O agente para antes de mudar uma conta
Um workflow recebe um pedido de mudança de conta bancária de um fornecedor. Em vez de atualizar a conta, ele chama authorize_action pelo MCP Guard remoto com um hash e sinais abstratos. O SecureStamp devolve needs_confirmation e um Safe Next Step: questionar a contraparte. Nada é executado até uma pessoa responder.
O agente detecta uma ação sensível
Ele identifica uma troca de dados bancários e envia apenas sinais estruturados mais um sourceMessageHash.
O SecureStamp confere fatos do tenant
A chave de API restringe a consulta a um único owner graph, às políticas declaradas e às instruções registradas.
O agente recebe um veredito
A resposta é um registro de decisão com Safe Next Step e receiptId, não permissão para executar.
Pessoas ou contrapartes confirmam
Se preciso, create_action_challenge abre um caminho de confirmação manual antes de a operação seguir.
Teto de autorização local
A autorização na nuvem é necessária, mas nunca suficiente sozinha.
Um grant só vira execução se também couber na política que sua organização assinou e instalou ao lado do Guardian. Essa política é deny-only: ela fixa tenant, gateway, operações, manifests de adaptador, autoridades e versões de política aceitas, recursos, parâmetros, limites monetários, concorrência e destinos de rede. O modo produtivo se recusa a subir sem ela.
permissão efetiva =
grant da nuvem
∩ política local assinada
∩ restrições do adaptador
∩ kill switchesO SecureStamp Cloud pode tornar uma autorização mais estreita. Não pode torná-la mais ampla do que sua organização permitiu localmente.
Contratos
O que o verificador recalcula
ExecutionGrantV1O artefato de autorização. Carrega o digest do efeito, a autoridade, a versão de política (apol_v1:) e o vencimento. maxUses é 1.
ActionReceiptV2 / V3O artefato de evidência. A V3 acrescenta a versão de política e o digest da política local assinada (gpol_v1:) que delimitou a execução. A V2 segue compatível byte a byte para o histórico.
ActionProofBundleV1 / V2Tudo o que um terceiro precisa para recalcular a cadeia. A V2 acrescenta a política local assinada e o descritor de assurance do conector.
AdapterManifestV1Um descritor autocontido e imutável de uma única operação de conector. O verificador confere o manifest que está no bundle em vez de regerá-lo, então operações novas nunca invalidam provas antigas.
Verificar um receipt offline
O verificador é um pacote publicado à parte, sem acesso à rede, e sai antes dos artefatos que verifica. Os receipts se verificam offline sem contatar o SecureStamp, e a verificação não depende de um serviço SecureStamp no ar.
npx --package @securestamp/action-proof-verify action-proof-verify bundle.json
Limites da evidência
Um Action Receipt prova o que passou por um Guardian inscrito e o resultado que esse Guardian conseguiu estabelecer. Não prova que nenhuma ação ocorreu fora do SecureStamp, nem estabelece a propriedade legal da conta do provedor. O limite da evidência é o caminho de execução inscrito.