Um protocolo de confiança para
a autorização do efeito exato.
O SecureStamp estende a confiança digital da origem e da intenção até a execução. Decisões aprovadas se tornam autoridades de execução delimitadas, restringidas por uma política controlada pelo cliente e seguidas de evidência verificável de forma independente.
Gmail, Outlook e Apple Mail, com evidência de origem na caixa de entrada
Canais oficiais
WhatsApp, Telegram e o perímetro que uma marca declara
Agentes e APIs
Ferramentas MCP, APIs e workflows autônomos
Arquitetura do protocolo
Confiança antes de agir. Evidência depois de executar.
Uma só pilha de confiança, aplicada em todas as superfícies.
O SecureStamp não é um verificador de e-mail com um recurso de agente parafusado por cima. Origem, intenção, autorização de execução e evidência de execução são quatro camadas de uma mesma cadeia — e essa cadeia funciona igual, quer a instrução chegue numa caixa de entrada, num mensageiro ou por uma chamada de ferramenta MCP.
O SecureStamp estende a confiança da instrução até a consequência.
Pilha de confiança
Origem
De onde veio isto? Domínios, headers, assinaturas, identidade declarada e perímetro do canal. Evidência de apoio — necessária, e nunca a manchete.
Intenção
O que está sendo pedido? A ação solicitada é lida e declarada primeiro: pagar, aprovar, entregar credenciais, invocar uma ferramenta. Um sinal de entrada, não uma prova.
Execution Authorization
Qual efeito exato pode ser causado? Uma decisão aprovada vira uma autoridade delimitada e de uso único para uma operação canônica sob restrições explícitas.
Evidência de execução
Qual autorização foi consumida e qual resultado o ponto de execução conseguiu estabelecer? Um recibo assinado que qualquer um verifica offline.
Aplicado em
Gmail · Outlook · Apple Mail
Canais oficiais
WhatsApp · Telegram · perímetros declarados
Agentes
Clientes MCP e copilotos
APIs
Integrações diretas
Workflows
Automações e serviços delegados
Execution Authorization vale onde quer que a autoridade seja delegada a software, não só a agentes de IA. Uma automação, um workflow ou um serviço delegado agindo em nome de outra pessoa levanta a mesma pergunta: qual efeito exato foi aprovado?
Tese do protocolo
O novo perímetro é a ação.
Primeiro defendemos dispositivos contra malware e trojans. Depois defendemos caixas de entrada contra phishing. Agora o software age em nosso nome, e a pergunta não é mais só o que ele pode alcançar — é o que ele pode mudar.
Mensagens, eventos e prompts podem disparar APIs, chamadas de ferramenta, workflows e operações de dinheiro digital. O SecureStamp propõe sinais verificáveis antes que uma comunicação vire uma ação.
A identidade controla quem pode acessar um sistema. O SecureStamp delimita o efeito exato que o software autônomo tem permissão de causar.
Quatro camadas
A autenticação estabelece identidade. O controle de acesso limita o alcance. Execution Authorization delimita o efeito.
Autenticação
Quem ou o que está agindo?
Autorização de acesso
A quais recursos ele pode chegar?
Execution Authorization
Qual efeito exato ele pode causar?
Evidência de execução
Qual autorização foi consumida e qual resultado o ponto de execução conseguiu estabelecer?
A quarta pergunta é redigida de propósito. Um resultado que não pode ser estabelecido permanece indeterminado, e nenhuma camada desta pilha finge o contrário.
Onde nos situamos
O SecureStamp começa onde a decisão termina.
Sistemas de identidade, política e aprovação decidem se uma ação deve prosseguir. O SecureStamp vincula essa decisão aprovada ao efeito exato que pode ser executado.
Decidir
O que deveria ser permitido? Quem responde isso são identidade, policy engines, aprovações e pessoas.
Autorizar
Qual efeito exato é permitido? Essa é a camada que o SecureStamp acrescenta.
Executar
Aplicar esse efeito dentro das restrições do cliente, num ponto que o cliente controla.
Verificar
Qual autorização foi consumida e qual resultado o ponto de execução conseguiu estabelecer?
O SecureStamp não substitui identidade, policy engines, fluxos de aprovação nem APIs de provedores. Ele vincula as decisões aprovadas deles a efeitos executáveis exatos.
O SecureStamp fornece sinais verificáveis e autorizações delimitadas. Ele não substitui políticas internas, permissões, sandboxing, aprovação humana nem controles de segurança existentes.
Dispositivos
O primeiro perímetro moderno foi o dispositivo: malware, trojans, arquivos perigosos e comportamento local.
Caixas de entrada
Depois o risco migrou para as mensagens: domínios sósias, links falsos, anexos, urgência de pagamento e falsidade ideológica.
Ações
Hoje uma instrução pode abrir ferramentas, chamar APIs, processar faturas, mover dados ou preparar pagamentos.
Trust checks
O SecureStamp lê o que uma mensagem pede — pagar, aprovar, entregar credenciais, invocar uma ferramenta — e sustenta isso com evidência de origem, canal e contexto antes de responder, pagar, compartilhar dados ou executar workflows.
Agnóstico de canal
Um padrão agnóstico de canal
O SecureStamp não foi feito para uma caixa de entrada, um app ou um setor. O protocolo organiza sinais em torno de origem, canal, intenção declarada e ação. Pode se aplicar a e-mail, mensageria, QR, sites, faturas, tickets, APIs, agentes e operações de dinheiro digital.
Autoridade delegada
Onde quer que a autoridade seja delegada a software.
Um agente, uma automação, um workflow ou um serviço delegado agindo em nome de outra pessoa levantam todos a mesma pergunta. A permissão de acesso diz o que eles alcançam; ela não define o efeito exato aprovado para esta transação.
MCP para agentes
SecureStamp MCP Server
O MCP é como aplicações de IA alcançam ferramentas, dados e workflows. O SecureStamp fica na frente desse alcance: o software pergunta o que uma instrução está realmente pedindo, quem é a contraparte e qual efeito exato ela pode causar — antes de qualquer coisa rodar.
O SecureStamp autoriza; ele nunca guarda as credenciais do seu provedor downstream. Quando uma operação precisa mesmo executar, o grant assinado viaja até um Execution Guardian que você opera, e só esse daemon toca o provedor.
read_message_request(...)analyze_message_intent(...)verify_counterparty(...)get_safe_next_step(...)authorize_action(...)create_action_challenge(...)issue_action_receipt(...)get_source_envelope(...)request_execution_grant(...)get_execution_status(...)Fluxo conceitual
agent → read_message_request → analyze_message_intent → get_safe_next_step → request_execution_grant → Execution Guardian → ActionReceiptV3Signal Framework
SSF: SecureStamp Signal Framework
O SSF organiza primeiro a ação solicitada e depois os sinais de conteúdo, origem, autenticação, canal e contexto, para produzir uma saída simples, auditável e legível por pessoas, sistemas e agentes.
Requested Action
Responder, abrir, pagar, transferir, aprovar, compartilhar dados, invocar ferramentas ou rodar workflows.
Content Signals
Urgência, links, anexos, credenciais, instruções de pagamento e troca de dados bancários.
Origin Signals
Domínio, organização, identidade declarada, remetente.
Technical Signals
SPF, DKIM, DMARC, DNS TXT, headers, assinaturas, chaves e receipts.
Channel Signals
E-mail, web, WhatsApp, Telegram, QR, API, suporte, cobrança e tickets.
Verdict Layer
Trust, Signal e Action Verdict: uma saída legível e auditável que informa primeiro o que é pedido e mostra a evidência de origem abaixo.
Três sinais de entrada, depois a autorização
O Proof of Origin responde de onde veio uma instrução. O Proof of Intent declara o que ela está pedindo. O Action Verdict recomenda se ela deve prosseguir. Os três são sinais que alimentam uma decisão — e uma decisão ainda não é uma autorização.
Proof of Intent
O que está sendo pedido? Um sinal de entrada que declara primeiro a ação solicitada. Não é prova do que foi autorizado.
Proof of Origin
De onde veio? Domínio, organização, canal, remetente, estampilha e sinais técnicos. Evidência de apoio.
Action Verdict
Isso deve prosseguir? Um sinal de decisão. O que acontece depois dessa decisão é Execution Authorization.
Camada de execução
Public Beta · acesso produtivo controladoUm veredito não é uma prova.
Um veredito pode recomendar se uma ação deve prosseguir. Por si só, ele não prova o efeito exato que foi autorizado, a autoridade por trás dele, se a autorização foi reutilizada, nem o resultado observado na execução.
O Action Proof cria essa cadeia de evidências. Uma decisão aprovada vira autoridade executável delimitada: um efeito exato, uma autoridade, um vencimento, um uso — verificável offline, por qualquer pessoa.
Acesso não é autorização para agir
O acesso controla até onde o software pode chegar. Execution Authorization delimita o efeito exato que ele pode causar.
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.
Autorize o efeito, não só o acesso à ferramenta.
Teto controlado pelo cliente
Sua política é o teto.
O SecureStamp Cloud pode tornar uma autorização mais estreita. Não pode torná-la mais ampla que a política que sua organização assinou e instalou localmente. A autorização na nuvem é necessária, mas nunca suficiente sozinha.
Permissão efetiva
permissão efetiva =
grant da nuvem
∩ política local assinada
∩ restrições do adaptador
∩ kill switches- A política local é um documento que sua organização assina com a própria chave e instala ao lado do Guardian. 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.
- Ela é deny-only por construção. Não tem nenhum campo capaz de conceder algo que a nuvem não concedeu.
- Subir em modo produtivo sem uma política local assinada e válida não gera aviso: é recusado na inicialização.
- Os kill switches existem no nível global e por provedor, operação, tenant e gateway — e de novo dentro da própria política local. Eles param grants já emitidos.
- As políticas trazem uma data de revisão obrigatória e um vencimento opcional. Uma política vencida bloqueia novas mutações e deixa intactos estado, prova, releitura e reconciliação.
- A recuperação de chaves é M-de-N e offline. O suporte do SecureStamp não pode substituir esse controle, e esse é justamente o ponto.
- Um control plane de nuvem comprometido continua sem poder exceder a autoridade permitida localmente.
Hospedado pelo cliente
Nós autorizamos. Você executa.
O Guardian roda no seu ambiente e guarda as credenciais do provedor. O SecureStamp Cloud não recebe credenciais do provedor e nunca chama o seu provedor.
- As credenciais do provedor são montadas como arquivos de propriedade do root, nunca como variáveis de ambiente nem configuração inline.
- O bridge MCP — o processo mais próximo do modelo — não precisa de credenciais do provedor nem de SDKs de nuvem.
- O efeito é resolvido a partir do estado que o próprio daemon lê, nunca de parâmetros fornecidos pelo modelo.
- O estado anterior é relido imediatamente antes da mutação; uma mudança material invalida o grant em vez de sobrescrevê-lo.
Cadeia de prova
Cinco elos, cada um assinado por uma parte diferente
Prova criptográfica da autorização. Evidência assinada do resultado da execução.
Source Envelope
O plugin assina o que a pessoa realmente viu, no dispositivo, com uma chave que nunca sai dele. O corpo das mensagens nunca é transmitido.
Action Effect
O Guardian — não o modelo — lê o estado do provedor e normaliza o efeito exato: provedor, operação, recursos, parâmetros e um digest do estado anterior.
Execution Grant
O SecureStamp Cloud assina um grant de uso único vinculado a esse digest do efeito, à autoridade que o aprovou, à versão de política em vigor e a um vencimento. maxUses é 1, sempre.
Execution Claim
Seu Guardian reivindica o grant contra o próprio ledger. Um grant reproduzido é rejeitado antes de qualquer provedor ser contatado.
Action Receipt
O Guardian assina a autorização consumida, o contexto de execução e o resultado que conseguiu estabelecer, junto com o digest da política local que o delimitou.
Autoridade
Nenhuma requisição carrega a própria permissão.
A autoridade que uma operação exige é fixada pelo protocolo. Quem chama não pode escolhê-la, o modelo não pode argumentar a favor dela, e ela não pode ser rebaixada dentro da mesma requisição que precisa dela. Perfis de quórum são snapshots de política assinados, não valores de autoridade: standard e elevated são rótulos para pessoas, enquanto a prova se apoia no threshold, na lista de aprovadores e no hash da política.
noneNunca concede execução. Existe para que sua ausência seja explícita em vez de implícita.
policy_delegatedAutonomia dentro de uma política que a organização definiu de antemão, e só para uma requisição assinada no dispositivo. Nunca para uma correlacionada.
human_mfaUma pessoa identificada aprova contra uma sessão MFA viva. Usado onde o efeito é delimitado e reversível na prática.
quorumM-de-N aprovadores independentes, cada um com sua própria sessão MFA, contra uma política definida de antemão. Quem pede nunca pode aprovar o próprio pedido. Obrigatório para toda concessão de privilégio.
Segurança na falha
O desconhecido continua desconhecido.
Uma resposta ambígua do provedor permanece indeterminada até a reconciliação. Operações que mutam não são repetidas às cegas.
Uma API de pagamentos dá timeout depois de receber uma mutação. Repeti-la pode duplicar o efeito. O SecureStamp não presume falha e tenta de novo: o Guardian reconcilia o estado do provedor e pode devolver indeterminate. A ambiguidade é um resultado de primeira classe e nunca é arredondada para sucesso.
Verificação independente
Confira a cadeia sem nos perguntar.
O verificador é um pacote publicado sem acesso à rede. Ele recalcula offline cada digest e cada assinatura de um proof bundle, incluindo o hash do snapshot de política e o digest da política local assinada. 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.jsonO verificador sai antes dos artefatos que verifica. Uma nova versão de receipt ou de bundle nunca é emitida antes de um verificador já lançado aceitá-la.
Conectores
Traga o ponto de execução que você já usa.
O modelo de autorização do SecureStamp é independente de provedor. Estes são conectores de referência, não um catálogo fechado. Como um conector se integra e o quanto o SecureStamp responde por ele são duas perguntas distintas, e as mantemos separadas de propósito.
Como se conecta
Adaptador certificado
Um módulo que escrevemos, revisamos e vinculamos a evidências de certificação publicadas.
Adaptador HTTPS declarativo
Origem, método e path fixados na instalação. Sem URL, método ou headers arbitrários vindos do modelo, sem redirects, schema estrito, idempotência determinística.
SDK / sidecar
Para protocolos que não conseguem satisfazer o contrato declarativo, sobre um socket Unix.
Como a garantia é declarada
SecureStamp Certified
Nós escrevemos, revisamos e publicamos as evidências.
Partner Attested
Um parceiro identificado responde por ele, e o bundle diz isso.
Customer Defined
Você construiu. A cadeia verifica do mesmo jeito, e o bundle declara com todas as letras que o SecureStamp não certificou o código do conector.
Adaptadores traduzem um efeito autorizado em execução específica do provedor. Eles não redefinem a autoridade concedida.
Stripe
refund.createhuman_mfaOkta
group.add_userhuman_mfaAWS
iam.attach_role_policyquorumGoogle Cloud
iam.project_binding.addquorumAzure
rbac.role_assignment.createquorumMicrosoft Entra
pim.directory_role_assignment.createquorumEncaixa no control plane que você já tem
Funciona com os controles que você já tem.
O SecureStamp não substitui identidade, policy engines, fluxos de aprovação nem APIs de provedores. Ele vincula as decisões aprovadas deles a efeitos executáveis exatos.
Limites da evidência
O que um receipt estabelece e o que não estabelece.
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.
Ações feitas fora desse caminho estão fora do escopo do receipt.
Status da release
Por que esses pacotes ainda dizem beta.
O protocolo, o código e o verificador estão completos e auditáveis hoje. Mas não chamamos um conector de estável até publicar evidência de 100 execuções reais contra um provedor ao vivo — incluindo injeção de falhas, rejeição de replay e prova de que a credencial não poderia ter feito mais — vinculada ao commit exato que as produziu. Execução em produção exige opt-in explícito e elegibilidade do conector, e enquanto um conector não passar por esse gate seu Guardian se recusa a rodar fora do modo sandbox. Um produto de confiança que pede para você acreditar na palavra dele já falhou.
Pacotes
@securestamp/action-proof-verifyO verificador offline e seus contratos de verificação. Publicado antes de tudo o que verifica.
@securestamp/action-proofContratos, assinatura e proof bundles.
@securestamp/execution-guardianO daemon hospedado pelo cliente e seus conectores de provedor.
@securestamp/execution-guardian-mcpO bridge MCP. Sem credenciais, sem SDKs de nuvem, por construção.
Trust Levels
Trust Level explica a origem. Action Verdict ajuda a decidir a ação.
Os níveis L1-L5 classificam a evidência de origem verificável. Não afirmam que o conteúdo é verdadeiro nem que uma ação deve ser executada automaticamente.
L1
Registrado
O domínio ou a organização está registrado no SecureStamp.
L2
Alinhado
Sinais técnicos como SPF, DKIM, DMARC ou DNS estão alinhados.
L3
Assinado
A mensagem, o canal ou o evento inclui um token assinado e verificável.
L4
Notarizado
Existe uma referência de integridade ou recibo verificável para auditoria posterior.
L5
Certificado
A identidade organizacional por trás da origem foi revisada com evidência adicional.
Origem verificada não significa ação aprovada
Trust Level descreve a força da evidência de origem. Action Verdict avalia uma ação concreta usando SSF, contexto e política. Uma origem legítima ainda pode pedir uma ação que exige revisão.
Pontos de integração
Quatro formas de declarar e consultar confiança
DNS TXT record
Publique um registro TXT em _securestamp.[domain]. Os verificadores resolvem o subdomínio e validam a origem declarada sem inspecionar conteúdo privado.
- —v=1 — versão do protocolo
- —id=<stamp_id> — identificador verificável
- —url=<verify_url> — URL canônica de verificação
_securestamp.example.com. 3600 IN TXT
"securestamp=v=1;
id=f47ac10b-58cc-4372-a567-0e02b2c3d479;
url=https://securestamp.org/verify/eyJhbG..."Email header
Injete X-SecureStamp nas mensagens de saída para que clientes, plugins e gateways consultem origem e status com sinais assinados.
- —Token assinado pelo remetente ou por nó autorizado
- —Claims mínimos: stampId, domain, orgId, score, exp
- —Chave pública ou referência verificável para validação
X-SecureStamp: v=1;
token=eyJhbGciOiJFUzI1NiJ9.eyJzdGFtcElkIjoiZjQ3YWMxM...;
verify=https://securestamp.org/verify/eyJhbG...REST API
Consulte domínios, canais ou ações sem guardar instruções sensíveis em texto claro. As respostas podem incluir sinais, reasons e Trust Receipts.
- —Trust checks para domínios e canais
- —Action Verdict para ações sensíveis
- —Receipts verificáveis para auditoria
- —Verificador público e registry quando aplicável
GET https://securestamp.org/v1/trust/example.com{
"domain": "example.com",
"trustLevel": "L3",
"signals": { "spf": "pass", "dkim": "pass", "dmarc": "pass" },
"actionVerdict": "needs_confirmation",
"receiptRef": "tr_01h..."
}MCP Server
Camada ativa de Agent Trust para agentes consultarem trust checks antes de tool calls, APIs, workflows e operações sensíveis.
- —SecureStamp MCP Server
- —Tool call checks
- —Action Verdict antes de executar
- —Aprovação humana quando a política exigir
securestamp.get_action_verdict({
origin: "billing@example.com",
action: "payment_request",
amount: "1200.00",
destination: "acct_..."
})Official Channel Signal
Verificação de canais oficiais nas superfícies conversacionais
O Signal permite consultar se um número, bot, handle, link, conta ou ponto de contato pertence ao perímetro oficial declarado por uma entidade. É a camada para WhatsApp, Telegram, web, QR, suporte, cobrança e outros canais onde uma pessoa ou agente pode receber instruções sensíveis.
Perímetro oficial
Confere canais de e-mail, WhatsApp, Telegram, web, QR, suporte e cobrança contra registros verificáveis.
Conectado ao SSF
Sinais de canal alimentam Trust, Action Verdict e receipts sem transformar uma marca em garantia absoluta.
Limite honesto
O Signal verifica pertencimento ao perímetro oficial. Não prova que toda mensagem seja verdadeira.
Receipts, registry e auditoria
Evidência auditável sem depender de prints
Cada consulta ou declaração relevante pode gerar um receipt verificável. Os receipts ajudam a auditar origem, canal, intenção declarada e Action Verdict sem confiar cegamente numa interface.
Trust Receipts
Receipts assinados resumindo sinal, contexto permitido, timestamp e referência verificável.
Registry
Tokens, receipts e referências públicas podem ser verificados sem autenticação quando o fluxo permite.
Auditoria
Organizações podem combinar receipts com políticas internas, aprovações e controles de conformidade.
Glossário público
Uma linguagem comum para usuários, suporte e integradores
The glossary explains SecureStamp, email, cryptography, Signal, E2EE, API and infrastructure terms so a non-technical person or junior developer can understand what they are reading.
Abrir glossárioSecureStamp Terms
Concepts created or defined by SecureStamp to explain trust, stamps, receipts and verifiable perimeters.
Email, Domains and Authentication
Classic abbreviations used when SecureStamp explains whether a sender or domain is properly authenticated.
Cryptography and Security
Terms needed to understand signatures, encryption, keys, verifiable logs and enterprise recovery.
Protocols, APIs and Infrastructure
Common language for junior developers and integrators reading APIs, plugins, dashboards or runbooks.
Rede federada
Rede federada e nós aprovados
A SecureStamp Foundation coordena uma rede de nós aprovados para escrever e verificar registros compartilhados. Operar um nó exige revisão técnica, SLA e alinhamento com os princípios de governança.
Enviar solicitação
Inclua organização, região, capacidade operacional, SLA previsto, superfície técnica e caso de uso declarado.
Revisão técnica
A fundação avalia capacidade, segurança operacional, cobertura e potenciais conflitos de interesse.
Credenciais emitidas
Se aprovado, o operador recebe credenciais e requisitos de integração para participar da rede.
Operação auditada
O nó deve manter disponibilidade, health pública, rastreabilidade operacional e processos de resposta a incidentes.
Obrigações do nó
Registro verificável
Verifique estampilhas, receipts e referências públicas
Toda estampilha, receipt ou referência pública emitida pelo SecureStamp pode ser verificada sem transformar este site numa landing comercial. A fundação mantém o padrão e os pontos de consulta.
securestamp.org/verify/[token]FAQ técnico
Perguntas frequentes de desenvolvedores e integradores
O que é a SecureStamp Foundation?
A entidade que publica e governa o padrão aberto SecureStamp para verificar origem, intenção, canal e ação antes de operar.
Que problema o protocolo resolve?
Ajuda pessoas, sistemas e agentes a consultar sinais verificáveis antes de responder, pagar, compartilhar dados, invocar APIs ou executar workflows.
Como a pilha de confiança se relaciona com as superfícies?
A pilha de confiança é Origem, Intenção, Execution Authorization e Evidência de execução. As superfícies são e-mail, canais oficiais, agentes, APIs e workflows. São dois eixos independentes: a mesma pilha se aplica a cada superfície, e Execution Authorization é uma camada, nunca uma superfície própria.
O que é Proof of Origin?
Evidência verificável de que um domínio, canal, remetente ou organização corresponde a uma origem registrada.
O que é Execution Authorization?
O processo de vincular uma decisão aprovada a uma autoridade delimitada e específica de uma transação, que permite ao software causar um efeito definido sob restrições explícitas. O controle de acesso limita o que o software alcança; Execution Authorization delimita o efeito exato que ele pode causar.
O que é Action Verdict?
Uma avaliação de uma ação concreta antes da execução. Pode recomendar permitir, revisar, negar ou exigir aprovação humana conforme sinais e política.
O que é SSF?
SecureStamp Signal Framework: uma linguagem comum para sinais de origem, autenticação, canal, conteúdo, contexto, ação e veredito.
O que é o SecureStamp MCP Server?
Uma direção em developer preview para que agentes consultem trust checks antes de chamadas de ferramenta sensíveis, via Model Context Protocol.
Docs e especificação
Documentação do protocolo
A especificação cobre Proof of Origin, Proof of Intent, SSF, Action Verdict, pontos de integração, receipts, limites honestos e a direção MCP para agentes.
Dúvidas sobre a especificação ou o design do protocolo? protocol@securestamp.org
Contato
Fale com a gente
Cada endereço vai direto para o time certo. Sem sistema de tickets — pessoas de verdade.