정확한 효과를 승인하기 위한
신뢰 프로토콜.
SecureStamp는 디지털 신뢰를 출처와 의도에서 실행까지 확장합니다. 승인된 결정은 고객이 통제하는 정책으로 제한된 한정적 실행 권한이 되고, 독립적으로 검증 가능한 증거가 뒤따릅니다.
Gmail, Outlook, Apple Mail — 받은편지함에 출처 증거 표시
공식 채널
WhatsApp, Telegram, 그리고 브랜드가 선언한 경계
에이전트와 API
MCP 도구, API, 자율 워크플로
프로토콜 아키텍처
행동하기 전에 신뢰를. 실행한 뒤에 증거를.
하나의 신뢰 스택을 모든 표면에 적용합니다.
SecureStamp는 에이전트 기능을 덧붙인 이메일 검사기가 아닙니다. 출처, 의도, 실행 승인, 실행 증거는 하나의 사슬을 이루는 네 계층이며, 그 사슬은 지시가 받은편지함으로 오든, 메신저로 오든, MCP 도구 호출로 오든 똑같이 작동합니다.
SecureStamp는 신뢰를 지시에서 결과까지 확장합니다.
신뢰 스택
출처
이건 어디에서 왔는가? 도메인, 헤더, 서명, 선언된 신원, 채널 경계. 뒷받침하는 증거이며, 결코 머리기사가 아닙니다.
의도
무엇을 요구하는가? 요청된 행동을 먼저 읽고 먼저 밝힙니다. 결제, 승인, 자격 증명 전달, 도구 호출. 입력 신호이지 증명이 아닙니다.
Execution Authorization
정확히 어떤 효과를 일으켜도 되는가? 승인된 결정은 명시적 제약 아래 하나의 정규 작업에 대한 한정적 일회성 권한이 됩니다.
실행 증거
어떤 승인이 소비되었고, 실행 지점은 어떤 결과를 확인할 수 있었는가? 누구나 오프라인에서 검증할 수 있는 서명된 영수증입니다.
적용 범위
Gmail · Outlook · Apple Mail
공식 채널
WhatsApp · Telegram · 선언된 경계
에이전트
MCP 클라이언트와 코파일럿
APIs
직접 연동
Workflows
자동화와 위임된 서비스
Execution Authorization은 AI 에이전트뿐 아니라 권한이 소프트웨어에 위임되는 모든 곳에 적용됩니다. 남을 대신해 움직이는 자동화, 워크플로, 위임된 서비스도 같은 질문을 남깁니다. 정확히 어떤 효과가 승인되었는가?
프로토콜 테제
새로운 경계는 행동입니다.
처음에는 악성코드와 트로이 목마로부터 기기를 지켰습니다. 그다음에는 피싱으로부터 받은편지함을 지켰습니다. 이제는 소프트웨어가 우리를 대신해 행동하고, 질문은 더 이상 무엇에 닿을 수 있는가만이 아닙니다. 무엇을 바꿀 수 있는가입니다.
메시지와 이벤트, 프롬프트는 API와 도구 호출, 워크플로, 디지털 화폐 거래를 촉발할 수 있습니다. SecureStamp는 커뮤니케이션이 행동이 되기 전에 검증 가능한 신호를 제안합니다.
신원은 누가 시스템에 접근할 수 있는지를 통제합니다. SecureStamp는 자율 소프트웨어가 일으켜도 되는 정확한 효과를 한정합니다.
네 개의 계층
인증은 신원을 확립합니다. 접근 제어는 도달 범위를 제한합니다. Execution Authorization은 효과를 한정합니다.
인증
누가, 또는 무엇이 행동하고 있는가?
접근 승인
어떤 리소스에 닿을 수 있는가?
Execution Authorization
정확히 어떤 효과를 일으킬 수 있는가?
실행 증거
어떤 승인이 소비되었고, 실행 지점은 어떤 결과를 확인할 수 있었는가?
네 번째 질문은 의도적으로 이렇게 썼습니다. 확인할 수 없는 결과는 미확정으로 남고, 이 스택의 어떤 계층도 그렇지 않은 척하지 않습니다.
우리의 자리
SecureStamp는 결정이 끝나는 곳에서 시작합니다.
신원, 정책, 승인 시스템이 어떤 행동을 진행해도 되는지 결정합니다. SecureStamp는 그 승인된 결정을 실행해도 되는 정확한 효과에 묶습니다.
결정
무엇을 허용해야 하는가? 아이덴티티, 정책 엔진, 승인 절차, 그리고 사람이 답합니다.
승인
정확히 어떤 효과가 허용되는가? SecureStamp가 더하는 계층이 바로 이것입니다.
실행
고객의 제약 안에서, 고객이 통제하는 지점에서 그 효과를 적용합니다.
검증
어떤 승인이 소비되었고, 실행 지점은 어떤 결과를 확인할 수 있었는가?
SecureStamp는 아이덴티티, 정책 엔진, 승인 워크플로, 공급자 API를 대체하지 않습니다. 그들이 승인한 결정을 정확한 실행 가능 효과에 묶습니다.
SecureStamp는 검증 가능한 신호와 한정된 승인을 제공합니다. 내부 정책, 권한 설정, 샌드박싱, 사람의 승인, 기존 보안 통제를 대체하지 않습니다.
기기
최초의 현대적 경계는 기기였습니다. 악성코드, 트로이 목마, 위험한 파일, 로컬 동작이 문제였습니다.
받은편지함
이후 위험은 메시지로 옮겨 갔습니다. 비슷해 보이는 도메인, 가짜 링크, 첨부파일, 결제 재촉, 사칭입니다.
행동
이제 지시 하나가 도구를 열고, API를 호출하고, 청구서를 처리하고, 데이터를 옮기고, 결제를 준비할 수 있습니다.
Trust checks
SecureStamp는 메시지가 무엇을 요구하는지(결제, 승인, 자격 증명 제공, 도구 호출) 읽고, 답장·결제·데이터 공유·워크플로 실행 전에 출처·채널·맥락 증거로 뒷받침합니다.
채널 비의존
채널에 얽매이지 않는 표준
SecureStamp는 하나의 받은편지함이나 앱, 업종을 위해 설계되지 않았습니다. 프로토콜은 출처, 채널, 선언된 의도, 행동을 축으로 신호를 정리합니다. 이메일, 메시징, QR, 웹사이트, 청구서, 티켓, API, 에이전트, 디지털 화폐 거래에 적용할 수 있습니다.
위임된 권한
권한이 소프트웨어에 위임되는 모든 곳에서.
에이전트, 자동화, 워크플로, 남을 대신해 움직이는 위임된 서비스 — 모두 같은 질문을 남깁니다. 접근 권한은 그것들이 무엇에 닿을 수 있는지를 말할 뿐, 이번 거래에서 승인된 정확한 효과를 정의하지 않습니다.
에이전트를 위한 MCP
SecureStamp MCP Server
MCP는 AI 애플리케이션이 도구와 데이터, 워크플로에 닿는 방식입니다. SecureStamp는 그 앞에 섭니다. 무엇이 실행되기 전에, 소프트웨어가 그 지시가 실제로 무엇을 요구하는지, 상대방이 누구인지, 어떤 효과를 정확히 일으킬 수 있는지를 묻습니다.
SecureStamp는 승인합니다. 당신의 다운스트림 공급자 자격 증명을 보관하지는 않습니다. 어떤 작업이 실제로 실행되어야 할 때, 서명된 grant는 당신이 운영하는 Execution Guardian으로 전달되고, 공급자에 닿는 것은 그 daemon뿐입니다.
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(...)개념 흐름
agent → read_message_request → analyze_message_intent → get_safe_next_step → request_execution_grant → Execution Guardian → ActionReceiptV3Signal Framework
SSF: SecureStamp Signal Framework
SSF는 요구된 행동을 먼저, 이어서 내용·출처·인증·채널·맥락 신호를 정리해 사람과 시스템, 에이전트가 읽을 수 있는 간단하고 감사 가능한 결과를 만듭니다.
Requested Action
답장, 열람, 결제, 이체, 승인, 데이터 공유, 도구 호출, 워크플로 실행.
Content Signals
긴급함, 링크, 첨부파일, 자격 증명, 결제 지시, 계좌 변경.
Origin Signals
도메인, 조직, 선언된 신원, 발신자.
Technical Signals
SPF, DKIM, DMARC, DNS TXT, 헤더, 서명, 키, receipts.
Channel Signals
이메일, 웹, WhatsApp, Telegram, QR, API, 고객지원, 청구, 티켓.
Verdict Layer
Trust, Signal, Action Verdict: 요구된 행동을 먼저 밝히고 그 아래에 출처 증거를 보여 주는, 읽기 쉽고 감사 가능한 결과.
세 가지 입력 신호, 그다음 승인
Proof of Origin은 지시가 어디에서 왔는지에 답합니다. Proof of Intent는 그것이 무엇을 요구하는지 밝힙니다. Action Verdict는 진행해도 되는지 권고합니다. 셋 다 결정에 입력되는 신호이며, 결정은 아직 승인이 아닙니다.
Proof of Intent
무엇을 요구하는가? 요청된 행동을 먼저 밝히는 입력 신호입니다. 무엇이 승인되었는지에 대한 증명은 아닙니다.
Proof of Origin
어디에서 왔는가? 도메인, 조직, 채널, 발신자, 우표, 기술 신호. 뒷받침하는 증거입니다.
Action Verdict
진행해야 하는가? 결정 신호입니다. 그 결정 이후에 일어나는 것이 Execution Authorization입니다.
실행 계층
Public Beta · 운영 접근 통제됨판정은 증명이 아닙니다.
verdict는 어떤 행동을 진행해도 되는지 권고할 수 있습니다. 그러나 그 자체로는 무엇이 정확히 승인되었는지, 그 뒤의 권한이 무엇인지, 승인이 재사용되었는지, 실행에서 관찰된 결과가 무엇인지 증명하지 않습니다.
Action Proof가 그 증거 사슬을 만듭니다. 승인된 결정은 한정된 실행 권한이 됩니다. 정확한 효과 하나, 권한 하나, 만료 하나, 사용 한 번 — 누구나 오프라인에서 검증할 수 있습니다.
접근은 행동할 권한이 아닙니다
접근은 소프트웨어가 닿을 수 있는 범위를 통제합니다. Execution Authorization은 일으킬 수 있는 정확한 효과를 한정합니다.
리소스 권한은 principal이 무엇에 접근할 수 있는지에 답합니다. Execution Authorization은 거래별로 어떤 효과를 일으킬 수 있는지에 답합니다. fine-grained 접근도 거래 자체는 정의되지 않은 채로 둡니다. 어떤 리소스인지, 얼마인지, 어디로 가는지, 몇 번인지.
도구 접근만이 아니라 효과를 승인하세요.
고객이 통제하는 상한
상한은 당신의 정책입니다.
SecureStamp Cloud는 승인을 더 좁게 만들 수 있습니다. 조직이 서명해 로컬에 설치한 정책보다 넓게 만들 수는 없습니다. 클라우드 승인은 필요하지만, 그것만으로는 결코 충분하지 않습니다.
실효 권한
실효 권한 =
클라우드 grant
∩ 서명된 로컬 정책
∩ 어댑터 제약
∩ kill switches- 로컬 정책은 조직이 자체 키로 서명해 Guardian 옆에 설치하는 문서입니다. tenant, gateway, 작업, 어댑터 manifest, 허용되는 권한과 정책 버전, 리소스, 파라미터, 금액 한도, 동시성, 네트워크 목적지를 고정합니다.
- 구조상 deny-only입니다. 클라우드가 주지 않은 것을 줄 수 있는 필드가 하나도 없습니다.
- 유효한 서명 로컬 정책 없이 운영 모드로 기동하는 것은 경고가 아니라 시작 시 거부됩니다.
- kill switch는 전역 수준과 공급자·작업·tenant·gateway 단위로 존재하며, 로컬 정책 안에도 다시 존재합니다. 이미 발급된 grant를 멈춥니다.
- 정책에는 필수 검토일과 선택적 만료일이 있습니다. 만료된 정책은 새 뮤테이션을 막고 상태, 증명, 재확인, 대사(對査)는 그대로 둡니다.
- 키 복구는 M-of-N이며 오프라인입니다. SecureStamp 지원이 그 통제를 대신할 수 없고, 바로 그 점이 핵심입니다.
- 클라우드 컨트롤 플레인이 침해되어도 로컬에서 허용된 권한을 넘어설 수는 없습니다.
고객 호스팅
저희가 승인하고, 고객이 실행합니다.
Guardian은 당신의 환경에서 실행되며 공급자 자격 증명을 보관합니다. SecureStamp Cloud는 공급자 자격 증명을 받지 않으며 당신의 공급자를 호출하지 않습니다.
- 공급자 자격 증명은 root 소유 파일로 마운트됩니다. 환경 변수나 인라인 설정으로는 결코 두지 않습니다.
- 모델에 가장 가까운 프로세스인 MCP bridge는 공급자 자격 증명도 클라우드 SDK도 필요로 하지 않습니다.
- 효과는 daemon이 직접 읽은 상태에서 해석됩니다. 모델이 제공한 파라미터에서가 아닙니다.
- 직전 상태는 뮤테이션 바로 전에 다시 읽습니다. 실질적인 변화가 있으면 grant를 덮어쓰지 않고 무효화합니다.
증명 체인
다섯 개의 고리, 각각 다른 주체가 서명
승인의 암호학적 증명. 실행 결과의 서명된 증거.
Source Envelope
플러그인은 사람이 실제로 본 것을, 기기 밖으로 나가지 않는 키로 기기에서 서명합니다. 메시지 본문은 절대 전송되지 않습니다.
Action Effect
모델이 아니라 Guardian이 공급자 상태를 읽고 정확한 효과를 정규화합니다. 공급자, 작업, 리소스, 파라미터, 그리고 직전 상태의 digest입니다.
Execution Grant
SecureStamp Cloud는 그 효과 digest, 승인한 권한, 유효한 정책 버전, 만료에 묶인 일회용 grant에 서명합니다. maxUses는 항상 1입니다.
Execution Claim
당신의 Guardian이 자체 ledger에 대해 grant를 청구합니다. 재생된 grant는 어떤 공급자와도 접촉하기 전에 거부됩니다.
Action Receipt
Guardian은 소비된 승인, 실행 맥락, 확인할 수 있었던 결과를, 그것을 한정한 로컬 정책의 digest와 함께 서명합니다.
권한
어떤 요청도 자신의 허가를 함께 가져오지 않습니다.
어떤 작업이 요구하는 권한은 프로토콜이 정합니다. 호출자는 고를 수 없고, 모델은 그것을 주장할 수 없으며, 그 권한이 필요한 요청 안에서 낮출 수도 없습니다. quorum 프로필은 서명된 정책 스냅샷이지 권한 값이 아닙니다. standard와 elevated는 사람을 위한 라벨이고, 증명은 threshold와 승인자 명단, 정책 hash에 기댑니다.
none실행을 결코 허용하지 않습니다. 그 부재가 암묵이 아니라 명시가 되도록 존재합니다.
policy_delegated조직이 미리 정한 정책 안에서의 자율성이며, 기기에서 서명된 요청에 한합니다. 상관된 요청에는 결코 적용하지 않습니다.
human_mfa신원이 확인된 사람이 살아 있는 MFA 세션에 대해 승인합니다. 효과가 한정적이고 실무상 되돌릴 수 있는 곳에 사용합니다.
quorum각자 자신의 MFA 세션을 가진 M-of-N 독립 승인자가, 미리 정한 정책에 대해 승인합니다. 요청자는 자신의 요청을 결코 승인할 수 없습니다. 모든 권한 부여에 필수입니다.
실패 안전성
모르는 것은 모르는 채로 둡니다.
공급자의 모호한 응답은 대사가 끝날 때까지 미확정으로 남습니다. 상태를 바꾸는 작업을 맹목적으로 재시도하지 않습니다.
결제 API가 뮤테이션을 받은 뒤 타임아웃이 났다고 합시다. 반복하면 효과가 중복될 수 있습니다. SecureStamp는 실패로 단정하고 재시도하지 않습니다. Guardian이 공급자 상태를 대사하고 indeterminate를 반환할 수 있습니다. 모호함은 일급 결과이며 결코 성공으로 올려 잡지 않습니다.
독립 검증
저희에게 묻지 않고 체인을 확인하세요.
검증기는 네트워크 접근이 없는 공개 패키지입니다. proof bundle 안의 모든 digest와 서명을, 정책 스냅샷 hash와 서명된 로컬 정책의 digest까지 포함해 오프라인에서 다시 계산합니다. receipts는 SecureStamp에 접속하지 않고 오프라인으로 검증할 수 있으며, 검증은 살아 있는 SecureStamp 서비스에 의존하지 않습니다.
npx --package @securestamp/action-proof-verify action-proof-verify bundle.json검증기는 그것이 검증하는 산출물보다 먼저 나옵니다. 새 receipt나 bundle 버전은 이미 배포된 검증기가 받아들이기 전에는 결코 발행되지 않습니다.
커넥터
이미 쓰고 있는 실행 지점을 가져오세요.
SecureStamp의 승인 모델은 공급자에 독립적입니다. 이것들은 참조 커넥터이지 닫힌 카탈로그가 아닙니다. 커넥터가 어떻게 연동되는지와 SecureStamp가 어디까지 책임지는지는 별개의 질문이고, 우리는 의도적으로 분리해 둡니다.
연결 방식
인증된 어댑터
우리가 작성하고 검토했으며 공개된 인증 증거에 묶은 모듈입니다.
선언형 HTTPS 어댑터
origin, 메서드, path를 설치 시점에 고정합니다. 모델이 주는 임의의 URL·메서드·헤더가 없고, 리다이렉트도 없으며, 엄격한 schema와 결정적 멱등성을 씁니다.
SDK / sidecar
선언형 계약을 만족할 수 없는 프로토콜을 위해, Unix 소켓 위에서.
보증을 선언하는 방식
SecureStamp Certified
우리가 작성하고, 검토하고, 증거를 공개했습니다.
Partner Attested
이름이 명시된 파트너가 보증하며, bundle에도 그렇게 적힙니다.
Customer Defined
당신이 만들었습니다. 사슬은 그대로 검증되며, bundle은 SecureStamp가 그 커넥터 코드를 인증하지 않았다고 분명히 밝힙니다.
어댑터는 승인된 효과를 공급자별 실행으로 옮깁니다. 부여된 권한을 다시 정의하지는 않습니다.
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.createquorum기존 컨트롤 플레인에 들어맞습니다
이미 가진 통제와 함께 동작합니다.
SecureStamp는 아이덴티티, 정책 엔진, 승인 워크플로, 공급자 API를 대체하지 않습니다. 그들이 승인한 결정을 정확한 실행 가능 효과에 묶습니다.
증거의 경계
receipt가 입증하는 것과 입증하지 않는 것.
Action Receipt는 등록된 Guardian을 통과한 것과 그 Guardian이 확인할 수 있었던 결과를 증명합니다. SecureStamp 밖에서 아무 행동도 없었음을 증명하지 않으며, 공급자 계정의 법적 소유권을 확립하지도 않습니다.
증거의 경계는 등록된 실행 경로입니다.
그 경로 밖에서 이루어진 행동은 receipt의 범위 밖입니다.
릴리스 상태
이 패키지들이 아직 베타라고 표기된 이유.
프로토콜과 코드, 검증기는 오늘 기준으로 완성되어 있고 감사할 수 있습니다. 다만 우리는 살아 있는 공급자를 상대로 한 실제 실행 100회의 증거를 — 장애 주입, 재생 거부, 그 자격 증명으로는 더 할 수 없었다는 증명까지 포함해 — 그것을 만든 정확한 커밋에 묶어 공개하기 전까지는 커넥터를 stable이라고 부르지 않습니다. 운영 실행에는 명시적 옵트인과 커넥터 적격성이 필요하며, 커넥터가 그 관문을 통과하기 전까지 해당 Guardian은 샌드박스 밖에서 실행되기를 거부합니다. 그냥 믿어 달라고 말하는 신뢰 제품은 이미 실패한 것입니다.
패키지
@securestamp/action-proof-verify오프라인 검증기와 그 검증 계약. 검증 대상 전부보다 먼저 배포됩니다.
@securestamp/action-proof계약, 서명, proof bundle.
@securestamp/execution-guardian고객이 호스팅하는 daemon과 그 공급자 커넥터.
@securestamp/execution-guardian-mcpMCP bridge. 구조상 자격 증명도, 클라우드 SDK도 없습니다.
Trust Levels
Trust Level은 출처를 설명합니다. Action Verdict는 행동 결정을 돕습니다.
L1-L5 등급은 검증 가능한 출처 증거를 평가합니다. 내용이 사실이라거나 행동을 자동으로 실행해야 한다고 주장하지 않습니다.
L1
등록됨
해당 도메인 또는 조직이 SecureStamp에 등록되어 있습니다.
L2
정렬됨
SPF, DKIM, DMARC, DNS 같은 기술 신호가 정렬되어 있습니다.
L3
서명됨
메시지, 채널 또는 이벤트에 서명되고 검증 가능한 토큰이 포함되어 있습니다.
L4
공증됨
이후 감사를 위한 검증 가능한 무결성 참조 또는 영수증이 존재합니다.
L5
인증됨
출처 뒤의 조직 신원을 추가 증거로 검토했습니다.
출처가 검증되었다고 행동이 승인된 것은 아닙니다
Trust Level은 출처 증거의 강도를 설명합니다. Action Verdict는 SSF, 맥락, 정책으로 구체적인 행동을 평가합니다. 정당한 출처도 검토가 필요한 행동을 요청할 수 있습니다.
통합 지점
신뢰를 선언하고 조회하는 네 가지 방법
DNS TXT record
_securestamp.[domain] 아래에 TXT 레코드를 게시하세요. 검증자는 서브도메인을 확인하고, 비공개 콘텐츠를 들여다보지 않은 채 선언된 출처를 검증합니다.
- —v=1 — 프로토콜 버전
- —id=<stamp_id> — 검증 가능한 식별자
- —url=<verify_url> — 표준 검증 URL
_securestamp.example.com. 3600 IN TXT
"securestamp=v=1;
id=f47ac10b-58cc-4372-a567-0e02b2c3d479;
url=https://securestamp.org/verify/eyJhbG..."Email header
보내는 메시지에 X-SecureStamp를 삽입하면 클라이언트, 플러그인, 게이트웨이가 서명된 신호로 출처와 상태를 조회할 수 있습니다.
- —발신자 또는 승인된 노드가 서명한 토큰
- —최소 클레임: stampId, domain, orgId, score, exp
- —검증용 공개 키 또는 검증 가능한 참조
X-SecureStamp: v=1;
token=eyJhbGciOiJFUzI1NiJ9.eyJzdGFtcElkIjoiZjQ3YWMxM...;
verify=https://securestamp.org/verify/eyJhbG...REST API
민감한 지시를 평문으로 저장하지 않고 도메인, 채널, 행동을 조회합니다. 응답에는 신호, reasons, Trust Receipts를 포함할 수 있습니다.
- —도메인과 채널에 대한 trust check
- —민감한 행동에 대한 Action Verdict
- —감사를 위한 검증 가능한 receipts
- —해당하는 경우 공개 검증기와 registry
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
에이전트가 도구 호출, API, 워크플로, 민감한 작업 전에 trust check를 조회할 수 있는 활성 Agent Trust 레이어입니다.
- —SecureStamp MCP Server
- —Tool call checks
- —실행 전 Action Verdict
- —정책이 요구할 때의 사람 승인
securestamp.get_action_verdict({
origin: "billing@example.com",
action: "payment_request",
amount: "1200.00",
destination: "acct_..."
})Official Channel Signal
대화형 표면 전반의 공식 채널 검증
Signal로 번호, 봇, 핸들, 링크, 계정 또는 연락 지점이 어떤 주체가 선언한 공식 경계에 속하는지 조회할 수 있습니다. WhatsApp, Telegram, 웹, QR, 고객지원, 청구 등 사람이나 에이전트가 민감한 지시를 받을 수 있는 채널을 위한 계층입니다.
공식 경계
이메일, WhatsApp, Telegram, 웹, QR, 고객지원, 청구 채널을 검증 가능한 레코드와 대조합니다.
SSF에 연결됨
채널 신호는 브랜드를 절대적 보증으로 만들지 않으면서 Trust, Action Verdict, receipts에 반영됩니다.
정직한 한계
Signal은 공식 경계에 속하는지를 검증합니다. 모든 메시지가 사실임을 증명하지는 않습니다.
Receipts, registry, 감사
스크린샷에 의존하지 않는 감사 가능한 증거
관련된 조회나 선언마다 검증 가능한 receipt를 생성할 수 있습니다. receipt는 인터페이스를 맹신하지 않고 출처, 채널, 선언된 의도, Action Verdict를 감사하도록 돕습니다.
Trust Receipts
신호, 허용된 맥락, 타임스탬프, 검증 가능한 참조를 요약한 서명된 receipts.
Registry
흐름이 허용하면 토큰, receipts, 공개 참조를 인증 없이 검증할 수 있습니다.
감사
조직은 receipts를 내부 정책, 승인, 컴플라이언스 통제와 결합할 수 있습니다.
공개 용어집
사용자, 지원팀, 통합자를 위한 공통 언어
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.
용어집 열기SecureStamp 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.
연합 네트워크
연합 네트워크와 승인된 노드
SecureStamp Foundation은 공유 레코드를 기록하고 검증하는 승인된 노드 네트워크를 조율합니다. 노드를 운영하려면 기술 심사, SLA, 거버넌스 원칙과의 정합이 필요합니다.
신청서 제출
조직, 지역, 운영 역량, 예상 SLA, 기술적 범위, 선언한 사용 사례를 포함하세요.
기술 심사
재단이 역량, 운영 보안, 커버리지, 잠재적 이해 상충을 평가합니다.
자격 증명 발급
승인되면 운영자는 네트워크 참여에 필요한 자격 증명과 연동 요건을 받습니다.
감사 대상 운영
노드는 가용성, 공개 health, 운영 추적성, 사고 대응 절차를 유지해야 합니다.
노드의 의무
검증 가능한 registry
우표, receipts, 공개 참조를 검증하세요
SecureStamp가 발급한 모든 우표, receipt, 공개 참조는 이 사이트를 상업용 랜딩 페이지로 바꾸지 않고도 검증할 수 있습니다. 재단은 표준과 조회 지점을 유지합니다.
securestamp.org/verify/[token]기술 FAQ
개발자와 통합 담당자를 위한 자주 묻는 질문
SecureStamp Foundation이란?
행동하기 전에 출처, 의도, 채널, 행동을 검증하기 위한 개방형 SecureStamp 표준을 발행하고 관리하는 주체입니다.
이 프로토콜은 어떤 문제를 해결하나요?
사람과 시스템, 에이전트가 답장·결제·데이터 공유·API 호출·워크플로 실행 전에 검증 가능한 신호를 조회하도록 돕습니다.
신뢰 스택과 표면은 어떤 관계인가요?
신뢰 스택은 출처, 의도, Execution Authorization, 실행 증거입니다. 표면은 이메일, 공식 채널, 에이전트, API, 워크플로입니다. 둘은 서로 독립적인 축이며, 같은 스택이 모든 표면에 적용되고 Execution Authorization은 계층이지 별도의 표면이 아닙니다.
Proof of Origin이란?
도메인, 채널, 발신자 또는 조직이 등록된 출처와 일치한다는 검증 가능한 증거입니다.
Execution Authorization이란?
승인된 결정을, 명시적 제약 아래 소프트웨어가 정의된 하나의 효과를 일으키도록 허용하는 한정적이고 거래별인 권한에 묶는 과정입니다. 접근 제어는 소프트웨어가 닿을 수 있는 범위를 제한하고, Execution Authorization은 일으킬 수 있는 정확한 효과를 한정합니다.
Action Verdict란?
실행 전에 구체적인 행동을 평가하는 것입니다. 신호와 정책에 따라 허용, 검토, 거부 또는 사람 승인을 권고할 수 있습니다.
SSF란?
SecureStamp Signal Framework. 출처, 인증, 채널, 콘텐츠, 맥락, 행동, verdict 신호를 위한 공통 언어입니다.
SecureStamp MCP Server란?
에이전트가 민감한 도구 호출 전에 Model Context Protocol로 trust check를 조회하도록 하는 developer preview 방향입니다.
문서와 명세
프로토콜 문서
명세는 Proof of Origin, Proof of Intent, SSF, Action Verdict, 통합 지점, receipts, 정직한 한계, 그리고 에이전트를 위한 MCP 방향을 다룹니다.
명세나 프로토콜 설계에 대해 궁금한 점이 있나요? protocol@securestamp.org
문의
연락 주세요
각 주소는 담당 팀으로 바로 연결됩니다. 티켓 시스템 없이, 사람이 응대합니다.