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.
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.
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.
Aprofundar · Official Channel Signal
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.
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.
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.
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.
Aprofundar · Quatro camadas
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.
Signal 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.
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.
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.
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.
Agentes e harnesses · Beta
Um laboratório reproduzível tenta romper os limites declarados de um agente de código — pelo MCP, pelo shell, por um script ou por uma chamada direta à API —, observa o resultado de fora do agente e depois executa a tarefa real sob o mesmo perfil. Só sai a mudança exata que foi revisada, por meio do Execution Guardian.
Aprofundar · Camada de execução
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.
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.
For the single-grant chain, the protocol, the code and the verifier are complete and auditable today. Bounded delegation — one approval for several exact steps — is a separate profile still in design and simulation, and its known gaps are published. We do not call a connector stable until we have published evidence of 100 real executions against a live provider — including fault injection, replay rejection and proof that the credential could not have done more — bound to the exact commit that produced them. Production execution requires explicit opt-in and connector eligibility, and until a connector clears that gate its Guardian refuses to run outside sandbox mode. A trust product that asks you to take its word for it has already failed.
Pacotes
@securestamp/action-proof-verifyO verificador offline e seus contratos de verificação. Publicado antes de tudo o que verifica.
@securestamp/action-proof-verify@securestamp/execution-guardianO daemon hospedado pelo cliente e seus conectores de provedor.
@securestamp/execution-guardian@securestamp/execution-guardian-mcpO bridge MCP. Sem credenciais, sem SDKs de nuvem, por construção.
@securestamp/execution-guardian-mcpAutoridade 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 → ActionReceiptV3Action Proof — Execution Authorization
Autorize o efeito, não só o acesso à ferramenta: o exemplo canônico, os três passos, o teto de autorização local, os contratos que o verificador recalcula e como verificar um receipt offline.
Bounded delegation — Task Contract
The specification for a signed, revisable mandate: tenant, actors, Guardian, revision, steps, budget, validity window, policy and revocation — plus the deliberate exclusions and the known gaps of the local runtime, listed until they close.
Laboratório de agentes e harnesses
Perfis HP0–HP2 e níveis de laboratório LR0–LR2, as famílias de falhas por trás dos testes, a aplicabilidade da evidência por rota, a exportação exata por meio do Execution Guardian, a parada e o orçamento de campanha — e o que o laboratório não prova.
Qual autorização foi consumida e qual resultado o ponto de execução conseguiu estabelecer? Um recibo assinado que qualquer um verifica offline.
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.
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]Evidence and coverage
What is proven, and what is not. The four evidence levels, the rules that make a coverage claim refutable, the named threats with their open gaps, and everything that sits outside the guarantee.
Camada de execução no whitepaper
A mesma camada na profundidade da especificação: a cadeia de prova de cinco elos, grants de uso único, perfis de quórum como snapshots de política assinados, a plataforma aberta de adaptadores e os limites da evidência.
Aplicado em
Gmail · Outlook · Apple Mail
Canais oficiais
WhatsApp · Telegram · perímetros declarados
Agentes
Clientes MCP e assistentes
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?
Por onde começar
Quatro caminhos, conforme o que precisa ser feito.
Declarar e consultar confiança a partir do DNS, dos headers de e-mail, da API REST ou do servidor MCP. Cada forma vem com seu exemplo e sua documentação.
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.
Email header
Injete X-SecureStamp nas mensagens de saída para que clientes, plugins e gateways consultem origem e status com sinais assinados.
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.
MCP Server
Camada ativa de Agent Trust para agentes consultarem trust checks antes de tool calls, APIs, workflows e operações sensíveis.
Aprofundar · Pontos de integraçã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_..."
})Delimitar o que um software delegado pode causar: Action Proof para um efeito exato, delegação delimitada para várias etapas e o Safe Defaults Kit para revisar uma configuração antes de conceder autonomia.
Action Proof — Execution Authorization
Autorize o efeito, não só o acesso à ferramenta: o exemplo canônico, os três passos, o teto de autorização local, os contratos que o verificador recalcula e como verificar um receipt offline.
Bounded delegation — Task Contract
The specification for a signed, revisable mandate: tenant, actors, Guardian, revision, steps, budget, validity window, policy and revocation — plus the deliberate exclusions and the known gaps of the local runtime, listed until they close.
Laboratório de agentes e harnesses
Perfis HP0–HP2 e níveis de laboratório LR0–LR2, as famílias de falhas por trás dos testes, a aplicabilidade da evidência por rota, a exportação exata por meio do Execution Guardian, a parada e o orçamento de campanha — e o que o laboratório não prova.
Safe Defaults Kit
A local kit that reads the config files you point it at, names what it found — an inline secret, a shell launch, an unpinned package — and proposes a minimal corrected version on a copy. No account, no data leaving the machine.
Evidence and coverage
What is proven, and what is not. The four evidence levels, the rules that make a coverage claim refutable, the named threats with their open gaps, and everything that sits outside the guarantee.
Verificar estampilhas, receipts e referências públicas — os receipts também se verificam offline — com um vocabulário comum para usuários, suporte e integradores.
Aprofundar · Glossário público
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.
Evidence and coverage
What is proven, and what is not. The four evidence levels, the rules that make a coverage claim refutable, the named threats with their open gaps, and everything that sits outside the guarantee.
Modelo notarial e L5
Como o SecureStamp chega ao L5 Certified: um registro notarial assinado em ES256 do envelope da mensagem mais revisão de identidade empresarial (KYB). Os cinco níveis e o limite honesto: certifica origem e integridade, não a veracidade do conteúdo.
Adicionar um nó à rede federada: candidatura, revisão técnica, credenciais e operação auditada.
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ó
Operar um nó
Guia para entrar na rede federada do SecureStamp: requisitos, setup, configuração e obrigações do operador do nó.
Whitepaper
Especificação técnica e racional de design do protocolo SecureStamp: modelo de confiança de cinco níveis, camada notarial, Action Verdict, a cadeia de execução Action Proof, sinais, scoring e arquitetura.
Docs e especificação
Documentação do protocolo
Documentação para desenvolvedores e instituições que delegam trabalho a software autônomo. Cobre como proteger servidores MCP, agentes e harnesses com Break the Mandate — Doctor nos seus arquivos nativos, um laboratório reproduzível, Exact Export e controle de execução; Action Proof para autorizar o efeito exato, com recibos que se verificam offline; delegação limitada com o Task Contract; Proof of Origin, Proof of Intent, SSF e Action Verdict para mensagens, com os plugins do Gmail e do Outlook já publicados; o nível de evidência de cada perfil; e os limites honestos de tudo isso.
Dúvidas sobre a especificação ou o design do protocolo? protocol@securestamp.org
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.
Contato
Fale com a gente
Cada endereço vai direto para o time certo. Sem sistema de tickets — pessoas de verdade.