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. A mesma pilha se aplica a cada superfície; Execution Authorization é uma camada, nunca uma superfície.

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 é o SecureStamp MCP Server?

Uma camada Agent Trust ativa para o Model Context Protocol: agentes consultam o SecureStamp antes de chamadas de ferramenta sensíveis e recebem um Action Verdict, um Safe Next Step e um recibo.

SecureStamp.org Docs

Glossário

Glossário SecureStamp de confiança digital

Termos de produto, criptografia, email, protocolos e infraestrutura explicados para usuários, suporte e devs júnior.

How to read this glossary

Terms marked as SecureStamp-specific have a product or protocol meaning defined by the foundation. The rest are standards, industry concepts or infrastructure used across .org, .online and .store.

Tip: use page search to jump to acronyms such as DKIM, E2EE, BYOK or Trust Receipt.

SecureStamp Terms

Concepts created or defined by SecureStamp to explain trust, stamps, receipts and verifiable perimeters.

SecureStampSecureStamp-specific: Digital trust platform for verifying senders, domains, identities and communications. It does not replace email or messaging apps; it adds a visible, verifiable layer for deciding whether a communication deserves trust.
StampSecureStamp-specific: A visual and verifiable seal representing SecureStamp evidence. A valid stamp is not just an image: it must be backed by a token, domain or recognized issuer.
No stampSecureStamp-specific: Visual state for a communication without a valid SecureStamp seal. It does not automatically mean fraud; it may mean an unenrolled company, unregistered domain, old email or unsupported provider.
Trust CheckSecureStamp-specific: Trust query about an email, domain, sender or channel. It returns state, score, signals and reasons so the user can decide whether to reply, click or stop.
Trust ScoreSecureStamp-specific: A 0-100 score summarizing technical, reputational, semantic and identity signals. It is a decision aid, not an absolute guarantee.
SecureStamp RegistrySecureStamp-specific: Registry of domains and organizations that completed verification. It shows whether a domain is enrolled, what evidence exists and which channels a brand can declare.
Domain enrollmentSecureStamp-specific: Process where an organization registers a domain and proves control, usually through DNS or equivalent steps. Until enrolled, a domain should not issue valid stamps.
SecureStamp SignalSecureStamp-specific: Product and protocol for channel trust on WhatsApp, Telegram and similar channels. It verifies whether a channel, account, phone, link or domain belongs to a brand-declared perimeter.
Trust ReceiptSecureStamp-specific: Verifiable receipt summarizing what was checked, when, with which evidence and under what boundary. Useful for support, audit and user evidence.
Brand Claim BoundarySecureStamp-specific: Explicit limit of a brand claim. It prevents over-promising: SecureStamp can certify official-perimeter membership, not intent or content truth.
Confidential MailSecureStamp-specific: End-to-end encrypted email between verified identities. Content is encrypted client-side so SecureStamp and mail providers do not read plaintext.
L1-L5SecureStamp-specific: Notarial evidence levels. L1 is basic evidence; L5 combines business identity, origin and integrity verification. The scale does not certify that content is true.
Execution AuthorizationSecureStamp-specific: SecureStamp’s category: the process of binding an approved decision to a bounded, transaction-specific authority that permits software to cause one defined effect under explicit constraints. Access control limits what software can reach; Execution Authorization bounds the exact effect it may cause. It applies wherever authority is delegated to software, not only to AI agents.
Action ProofSecureStamp-specific: The protocol that produces the verifiable chain behind Execution Authorization: SourceEnvelope, ActionEffect, ExecutionGrant, ExecutionClaim and ActionReceipt. Action Proof is the mechanism; Execution Authorization is the control capability. They are not synonyms.
Execution GrantSecureStamp-specific: A signed, single-use authorization artifact bound to the digest of one exact effect, to the authority that approved it and to an expiry. An Execution Grant provides cryptographic proof of what was authorized, and never becomes a reusable permission.
Action ReceiptSecureStamp-specific: A signed evidence artifact describing the authorization consumed, the execution context and the outcome the enrolled Guardian was able to establish. A receipt does not prove that the external world changed exactly as intended.
Execution GuardianSecureStamp-specific: A daemon running in the customer environment that holds the downstream provider credentials and applies the grant within the limits of the local policy. SecureStamp authorizes; your Guardian executes.
Protected ActionSecureStamp-specific: The billable unit: one successfully evaluated SecureStamp guard call, charged against the plan quota. A single executed effect may consume several protected actions. The effect executed through an enrolled Guardian is described as a protected execution.
Exact effectSecureStamp-specific: The canonical operation and parameters that the authorization binds, not every downstream consequence that may follow from execution. SecureStamp does not claim to know the future economic or physical consequences of an operation.
Local Authorization CeilingSecureStamp-specific: Effective permission is the intersection of the cloud grant with the signed local policy, the adapter constraints and the kill switches. Cloud authorization is necessary but never sufficient on its own: it can narrow an authorization, never broaden it beyond what the organization allowed locally.
Guardian Local PolicySecureStamp-specific: A customer-signed document that sets the Guardian’s local ceiling: operations, manifests, accounts, resources, parameters, accepted authorities and policy versions, monetary and concurrency limits, network destinations, kill switches, mandatory review and expiry. It is required to operate in production mode.
Connector AssuranceSecureStamp-specific: The declared, signed assurance level of a connector: securestamp_certified, partner_attested or customer_defined. It is a separate dimension from how the connector integrates (certified adapter, declarative HTTPS adapter, or SDK/sidecar). SecureStamp never signs claims about connector code it did not certify.
Adapter ManifestSecureStamp-specific: A self-contained, immutable descriptor of one connector operation, with its digest and registry snapshot. The verifier checks the manifest included in the bundle rather than regenerating it, so adding operations or providers never invalidates historical proofs.
Policy VersionSecureStamp-specific: The authorization-policy snapshot hash, formatted apol_v1:<sha256-jcs>. It binds a grant and its receipt to the exact policy in force. Two quorum profiles with different thresholds or approver rosters produce different versions.
Kill SwitchSecureStamp-specific: A deny-only stop that halts already-authorized executions. It exists globally and per provider, operation, tenant, gateway, and inside the Guardian’s own local policy. A kill switch never grants authority: it only withdraws it.
Account Control EvidenceSecureStamp-specific: How control of a provider account was demonstrated: credential_possession_only, provider_challenge_verified or customer_attested. Money, IAM, privilege and identity operations cannot execute on credential possession alone.
indeterminateSecureStamp-specific: An execution outcome where it could not be established whether the mutation took effect. With succeeded and failed_no_effect it is one of the three possible results. An ambiguous provider response remains indeterminate until reconciliation, and mutations are never blindly retried.

Email, Domains and Authentication

Classic abbreviations used when SecureStamp explains whether a sender or domain is properly authenticated.

DNSStandard: Domain Name System. Publishes records that resolve domains and prove control. SecureStamp uses DNS for domain verification and signals such as SPF or DMARC.
DNS TXTStandard: Text record in DNS. Used for control proofs, SPF policies, DMARC policies and public data that a verifier can read without private access.
SPFStandard: Sender Policy Framework. Lists which servers may send mail for a domain. Useful against technical spoofing, but it validates the envelope sender, not always the visible From.
DKIMStandard: DomainKeys Identified Mail. A cryptographic email signature proving selected parts were not changed and a DNS-published key belongs to the signing domain.
DMARCStandard: Policy connecting SPF/DKIM with the visible From domain. It tells receivers whether authentication failures should be monitored, quarantined or rejected.
DMARC alignmentStandard: Match between the visible domain and the domain authenticated by SPF or DKIM. Critical because attackers can pass one technical control with a different domain.
BIMIStandard: Brand Indicators for Message Identification. Lets some clients show brand logos when DMARC enforcement is configured. It is visual help, not a replacement for a verifiable stamp.
MIMEStandard: Email format for text, HTML, attachments and images. Security tools care because visible content and real HTML can tell different stories.
TyposquattingIndustry: Registering domains that look like a brand by changing letters or adding words. SecureStamp treats it as a semantic risk signal.
Business Email Compromise (BEC)Industry: Targeted business fraud involving transfers, fake invoices or bank-account changes. It may come from fake domains or compromised legitimate accounts.

Cryptography and Security

Terms needed to understand signatures, encryption, keys, verifiable logs and enterprise recovery.

E2EEIndustry: End-to-end encryption. Only sender and recipients should read content; the server transports ciphertext, not plaintext.
ES256Standard: Digital signature algorithm based on ECDSA P-256 and SHA-256. SecureStamp uses it for tokens and evidence where origin and integrity matter.
ECDHStandard: Elliptic Curve Diffie-Hellman. Lets two parties agree on a shared secret without sending that secret directly.
AES-256-GCMStandard: Authenticated symmetric encryption. It protects confidentiality and integrity, detecting tampering as well as keeping content private.
HKDF-SHA256Standard: Key derivation function that turns shared secrets into safe-purpose keys. It helps avoid dangerous key reuse.
PQCIndustry: Post-Quantum Cryptography. Algorithms designed to resist future relevant quantum computers. It means resistant to that attack class, not invulnerable.
ML-KEM-768Standard: Post-quantum key encapsulation mechanism. SecureStamp uses it in hybrid suites when recipients support compatible keys.
M-de-NIndustry: Quorum rule: M approvers out of N are required. For example, 2-of-3 prevents one person from recovering or abusing a critical secret alone.
BYOKIndustry: Bring Your Own Key. The organization supplies its own key or public key material for a cryptographic flow. Requires permissions, audit and rotation design.
Transparency logIndustry: Verifiable log where third parties can prove inclusion and consistency. It reduces the risk of rewriting trust-event history.

Protocols, APIs and Infrastructure

Common language for junior developers and integrators reading APIs, plugins, dashboards or runbooks.

APIIndustry: Application Programming Interface. Stable way for software to talk to software. SecureStamp exposes APIs for trust checks, stamps, Signal, E2EE, billing and administration.
RESTIndustry: API style based on resources, URLs, HTTP methods and JSON. Easy to consume from web, CLI, Postman or SDKs.
WebhookIndustry: Automatic call from one system to another when an event happens. It should be verified with signatures or secrets to prevent fake events.
OAuthStandard: Authorization protocol for granting account access without sharing a password. It supports limited, revocable permissions through scopes.
RBACIndustry: Role-Based Access Control. Permissions based on roles such as owner, admin, member or viewer. Prevents excessive privileges.
MFAIndustry: Multi-Factor Authentication. Requires more than one proof to sign in or approve sensitive actions.
DynamoDBInfra: AWS NoSQL database used by SecureStamp for product data, events and logs. It is designed around access patterns, not like a traditional relational database.
PK / SKInfra: Partition Key and Sort Key in DynamoDB. They define how data is grouped, ordered and queried. Poor design can force expensive scans.
GSIInfra: Global Secondary Index. Additional DynamoDB index for querying by another key. It adds cost but avoids inefficient searches.
CIIndustry: Continuous Integration. Automated pipeline that runs typecheck, tests and validation before trusting a change.