SecureStamp Foundation이란?

행동하기 전에 출처, 의도, 채널, 행동을 검증하기 위한 개방형 SecureStamp 표준을 발행하고 관리하는 주체입니다.

이 프로토콜은 어떤 문제를 해결하나요?

사람과 시스템, 에이전트가 답장·결제·데이터 공유·API 호출·워크플로 실행 전에 검증 가능한 신호를 조회하도록 돕습니다.

신뢰 스택과 표면은 어떤 관계인가요?

신뢰 스택은 출처, 의도, Execution Authorization, 실행 증거입니다. 표면은 이메일, 공식 채널, 에이전트, API, 워크플로입니다. 같은 스택이 모든 표면에 적용되며, Execution Authorization은 계층이지 표면이 아닙니다.

실행 전에 구체적인 행동을 평가하는 것입니다. 신호와 정책에 따라 허용, 검토, 거부 또는 사람 승인을 권고할 수 있습니다.

SecureStamp MCP Server란?

Model Context Protocol을 위한 능동적 Agent Trust 계층입니다. 에이전트는 민감한 도구 호출 전에 SecureStamp에 조회하고 Action Verdict, Safe Next Step, 영수증을 받습니다.

SecureStamp.org Docs

용어집

SecureStamp 디지털 신뢰 용어집

제품, 암호화, 이메일, 프로토콜, 인프라 용어를 사용자, 지원팀, 주니어 개발자에게 설명합니다.

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.