본문으로 건너뛰기
securestamp.org
Execution Authorization · Action Proof

정확한 효과를 승인하기 위한
신뢰 프로토콜.

SecureStamp는 디지털 신뢰를 출처와 의도에서 실행까지 확장합니다. 승인된 결정은 고객이 통제하는 정책으로 제한된 한정적 실행 권한이 되고, 독립적으로 검증 가능한 증거가 뒤따릅니다.

Email

Gmail, Outlook, Apple Mail — 받은편지함에 출처 증거 표시

공식 채널

WhatsApp, Telegram, 그리고 브랜드가 선언한 경계

에이전트와 API

MCP 도구, API, 자율 워크플로

프로토콜 아키텍처

행동하기 전에 신뢰를. 실행한 뒤에 증거를.

하나의 신뢰 스택을 모든 표면에 적용합니다.

SecureStamp는 에이전트 기능을 덧붙인 이메일 검사기가 아닙니다. 출처, 의도, 실행 승인, 실행 증거는 하나의 사슬을 이루는 네 계층이며, 그 사슬은 지시가 받은편지함으로 오든, 메신저로 오든, MCP 도구 호출로 오든 똑같이 작동합니다.

SecureStamp는 신뢰를 지시에서 결과까지 확장합니다.

정확히 어떤 효과를 일으켜도 되는가? 승인된 결정은 명시적 제약 아래 하나의 정규 작업에 대한 한정적 일회성 권한이 됩니다.

실행 계층

Public Beta · 운영 접근 통제됨

판정은 증명이 아닙니다.

verdict는 어떤 행동을 진행해도 되는지 권고할 수 있습니다. 그러나 그 자체로는 무엇이 정확히 승인되었는지, 그 뒤의 권한이 무엇인지, 승인이 재사용되었는지, 실행에서 관찰된 결과가 무엇인지 증명하지 않습니다.

Action Proof가 그 증거 사슬을 만듭니다. 승인된 결정은 한정된 실행 권한이 됩니다. 정확한 효과 하나, 권한 하나, 만료 하나, 사용 한 번 — 누구나 오프라인에서 검증할 수 있습니다.

증명 체인

다섯 개의 고리, 각각 다른 주체가 서명

승인의 암호학적 증명. 실행 결과의 서명된 증거.

Source Envelope

플러그인은 사람이 실제로 본 것을, 기기 밖으로 나가지 않는 키로 기기에서 서명합니다. 메시지 본문은 절대 전송되지 않습니다.

Action Effect

모델이 아니라 Guardian이 공급자 상태를 읽고 정확한 효과를 정규화합니다. 공급자, 작업, 리소스, 파라미터, 그리고 직전 상태의 digest입니다.

Execution Grant

SecureStamp Cloud는 그 효과 digest, 승인한 권한, 유효한 정책 버전, 만료에 묶인 일회용 grant에 서명합니다. maxUses는 항상 1입니다.

Execution Claim

당신의 Guardian이 자체 ledger에 대해 grant를 청구합니다. 재생된 grant는 어떤 공급자와도 접촉하기 전에 거부됩니다.

Action Receipt

Guardian은 소비된 승인, 실행 맥락, 확인할 수 있었던 결과를, 그것을 한정한 로컬 정책의 digest와 함께 서명합니다.

에이전트와 하네스 · Beta

재현 가능한 랩이 코딩 에이전트에 선언된 제한을 MCP, 셸, 스크립트, 직접 API 호출을 통해 깨뜨리려 시도하고, 결과를 에이전트 밖에서 관측한 뒤 같은 프로파일로 실제 과업을 실행합니다. 밖으로 나가는 것은 검토된 바로 그 변경뿐이며, 그것도 Execution Guardian을 거칩니다.

방법과 그 한계 보기
더 깊이 보기 · 실행 계층

접근은 행동할 권한이 아닙니다

접근은 소프트웨어가 닿을 수 있는 범위를 통제합니다. 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를 덮어쓰지 않고 무효화합니다.

권한

어떤 요청도 자신의 허가를 함께 가져오지 않습니다.

어떤 작업이 요구하는 권한은 프로토콜이 정합니다. 호출자는 고를 수 없고, 모델은 그것을 주장할 수 없으며, 그 권한이 필요한 요청 안에서 낮출 수도 없습니다. 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 서비스에 의존하지 않습니다.

bash
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_mfa

Okta

group.add_userhuman_mfa

AWS

iam.attach_role_policyquorum

Google Cloud

iam.project_binding.addquorum

Azure

rbac.role_assignment.createquorum

Microsoft Entra

pim.directory_role_assignment.createquorum

기존 컨트롤 플레인에 들어맞습니다

이미 가진 통제와 함께 동작합니다.

SecureStamp는 아이덴티티, 정책 엔진, 승인 워크플로, 공급자 API를 대체하지 않습니다. 그들이 승인한 결정을 정확한 실행 가능 효과에 묶습니다.

증거의 경계

receipt가 입증하는 것과 입증하지 않는 것.

Action Receipt는 등록된 Guardian을 통과한 것과 그 Guardian이 확인할 수 있었던 결과를 증명합니다. SecureStamp 밖에서 아무 행동도 없었음을 증명하지 않으며, 공급자 계정의 법적 소유권을 확립하지도 않습니다.

증거의 경계는 등록된 실행 경로입니다.

그 경로 밖에서 이루어진 행동은 receipt의 범위 밖입니다.

릴리스 상태

이 패키지들이 아직 베타라고 표기된 이유.

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.

패키지

@securestamp/action-proof-verify

오프라인 검증기와 그 검증 계약. 검증 대상 전부보다 먼저 배포됩니다.

@securestamp/action-proof-verify
@securestamp/action-proof

계약, 서명, proof bundle.

@securestamp/action-proof
@securestamp/execution-guardian

고객이 호스팅하는 daemon과 그 공급자 커넥터.

@securestamp/execution-guardian
@securestamp/execution-guardian-mcp

MCP bridge. 구조상 자격 증명도, 클라우드 SDK도 없습니다.

@securestamp/execution-guardian-mcp

위임된 권한

권한이 소프트웨어에 위임되는 모든 곳에서.

에이전트, 자동화, 워크플로, 남을 대신해 움직이는 위임된 서비스 — 모두 같은 질문을 남깁니다. 접근 권한은 그것들이 무엇에 닿을 수 있는지를 말할 뿐, 이번 거래에서 승인된 정확한 효과를 정의하지 않습니다.

지시에 따라 움직이기 전에 출처와 선언된 의도를 검증한다.
답장하기 전에 상대방의 공식 채널을 확인한다.
영향이 큰 작업을 넓은 접근이 아니라 하나의 정확한 효과에 묶는다.
승인은 한 번만 소비하고, 그 뒤로는 다시 쓰지 않는다.
실행을 조직이 통제하는 지점에 둔다.
모호한 결과는 무작정 재시도하지 말고 대사한다.
우리 없이도 검증할 수 있는 서명된 증거를 남긴다.
이 모든 것을 내부 정책과 사람의 승인과 결합한다.

에이전트를 위한 MCP

SecureStamp MCP Server

Public Beta

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 → ActionReceiptV3

적용 범위

Email

Gmail · Outlook · Apple Mail

공식 채널

WhatsApp · Telegram · 선언된 경계

에이전트

MCP 클라이언트와 어시스턴트

APIs

직접 연동

Workflows

자동화와 위임된 서비스

Execution Authorization은 AI 에이전트뿐 아니라 권한이 소프트웨어에 위임되는 모든 곳에 적용됩니다. 남을 대신해 움직이는 자동화, 워크플로, 위임된 서비스도 같은 질문을 남깁니다. 정확히 어떤 효과가 승인되었는가?

어디서 시작할까

해야 할 일에 따라 네 가지 경로.

DNS, 이메일 헤더, REST API 또는 MCP 서버에서 신뢰를 선언하고 조회합니다. 방식마다 예시와 문서가 함께 있습니다.

DNS TXT record

_securestamp.[domain] 아래에 TXT 레코드를 게시하세요. 검증자는 서브도메인을 확인하고, 비공개 콘텐츠를 들여다보지 않은 채 선언된 출처를 검증합니다.

Email header

보내는 메시지에 X-SecureStamp를 삽입하면 클라이언트, 플러그인, 게이트웨이가 서명된 신호로 출처와 상태를 조회할 수 있습니다.

REST API

민감한 지시를 평문으로 저장하지 않고 도메인, 채널, 행동을 조회합니다. 응답에는 신호, reasons, Trust Receipts를 포함할 수 있습니다.

MCP Server

에이전트가 도구 호출, API, 워크플로, 민감한 작업 전에 trust check를 조회할 수 있는 활성 Agent Trust 레이어입니다.

더 깊이 보기 · 통합 지점

통합 지점

신뢰를 선언하고 조회하는 네 가지 방법

DNS TXT record

_securestamp.[domain] 아래에 TXT 레코드를 게시하세요. 검증자는 서브도메인을 확인하고, 비공개 콘텐츠를 들여다보지 않은 채 선언된 출처를 검증합니다.

  • —v=1 — 프로토콜 버전
  • —id=<stamp_id> — 검증 가능한 식별자
  • —url=<verify_url> — 표준 검증 URL
DNS zone
_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
  • —검증용 공개 키 또는 검증 가능한 참조
SMTP header
X-SecureStamp: v=1;
  token=eyJhbGciOiJFUzI1NiJ9.eyJzdGFtcElkIjoiZjQ3YWMxM...;
  verify=https://securestamp.org/verify/eyJhbG...

REST API

민감한 지시를 평문으로 저장하지 않고 도메인, 채널, 행동을 조회합니다. 응답에는 신호, reasons, Trust Receipts를 포함할 수 있습니다.

  • —도메인과 채널에 대한 trust check
  • —민감한 행동에 대한 Action Verdict
  • —감사를 위한 검증 가능한 receipts
  • —해당하는 경우 공개 검증기와 registry
request
GET https://securestamp.org/v1/trust/example.com
response
{
  "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
  • —정책이 요구할 때의 사람 승인
MCP tool call
securestamp.get_action_verdict({
  origin: "billing@example.com",
  action: "payment_request",
  amount: "1200.00",
  destination: "acct_..." 
})

문서와 명세

프로토콜 문서

자율 소프트웨어에 작업을 위임하는 개발자와 기관을 위한 문서. Break the Mandate로 MCP 서버, 에이전트, 하네스를 보호하는 방법(네이티브 파일에 대한 Doctor, 재현 가능한 랩, Exact Export, 실행 제어), 정확한 효과를 승인하고 오프라인으로 검증되는 영수증을 제공하는 Action Proof, Task Contract를 통한 한정된 위임, 메시지를 위한 Proof of Origin, Proof of Intent, SSF, Action Verdict(이미 게시된 Gmail 및 Outlook 플러그인 포함), 각 프로파일의 증거 수준, 그리고 이 모든 것의 정직한 한계를 다룹니다.

명세나 프로토콜 설계에 대해 궁금한 점이 있나요? protocol@securestamp.org

기술 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 방향입니다.

문의

연락 주세요

각 주소는 담당 팀으로 바로 연결됩니다. 티켓 시스템 없이, 사람이 응대합니다.

SecureStamp Foundation — AI 에이전트와 MCP 도구를 위한 Execution Authorization