EMILIA Protocol

공식

명명된 인간의 오프라인 검증 가능한 승인을 요구하여 AI 에이전트가 되돌릴 수 없는 조치(결제 해제, 기록 변경, 배포)를 취하기 전에 승인을 받도록 합니다. 두 사람 규칙, Ed25519 신뢰 영수증, IETF 초안, Apache-2.0.

GitHub

550

EMILIA Protocol MCP(으)로 무엇을 할 수 있나요?

중요한 도구 보호 — sendWire와 같은 선언된 작업이 유효한 승인 없이는 호출을 거부하도록 EMILIA Gate를 설정해 달라고 어시스턴트에게 요청하세요.
승인을 정확한 세부 정보에 연결 — 승인이 금액, 통화, 공급업체, 목적지를 모두 포함하도록 요구하고, 결제 정보가 변경되면 거부하세요.
재생 및 위조된 증거 차단 — 어시스턴트가 일치하는 호출을 한 번만 승인하고 재생이나 위조된 영수증은 거부하도록 하세요.
오프라인으로 영수증 검증 — 백엔드에 연결하지 않고 고정된 키와 규칙을 사용해 서명된 영수증을 확인해 달라고 어시스턴트에게 요청하세요.
새 작업 동결 — 새 예약을 차단하고 결과가 불확실한 작업은 조정할 수 있도록 보존하는 긴급 권한 동결을 요청하세요.

문서

EMILIA Protocol

에이전트가 결제를 준비하게 하세요. 에이전트가 실행할 수 있는 범위를 제어하세요.

에이전트가 공급업체에 $82,000를 지급하도록 준비합니다. 누군가 이를 승인합니다. 그런 다음 금액이나 은행 계좌가 변경됩니다. 이전 승인이 변경된 결제를 실행해서는 안 됩니다.

EMILIA Gate는 보호된 도구가 실행되기 전에 권한을 확인합니다. 공개 프로토콜을 사용하면 결과 증거를 검증자 자체의 신뢰 키와 규칙에 따라 독립적으로 확인할 수 있습니다. 기존 ID 공급자, 에이전트 프레임워크, 비즈니스 시스템을 그대로 사용하세요.

결제 예제 실행

Node.js 20.19 이상과 npm이 설치되어 있어야 합니다.

git clone https://github.com/emiliaprotocol/emilia-protocol.git
cd emilia-protocol
npm ci
FAST=1 node examples/mcp/payment-server.mjs

이 예제는 승인 없는 호출을 거부하고, 승인 내용을 금액, 통화, 공급업체, 결제 대상에 연결합니다. 일치하는 호출은 한 번 허용하고, 변경된 결제 정보, 재생 공격, 위조된 증거는 거부합니다. 예제와 한계를 참조하세요.

로컬 데모입니다: 생성된 서명 키, 메모리 내 소비 상태, 모의 결제 도구를 사용합니다. 실제 사람의 승인 절차를 수행하거나 돈을 이체하지 않습니다. 프로덕션 환경에는 등록된 자격 증명, 영속적인 공유 상태, 보호된 공급자 자격 증명으로 이어지는 모든 경로에 적용되는 Gate가 필요합니다. 유효한 승인이 은행 정보의 정당성을 입증하지는 않습니다.

브라우저를 선호하시나요? 샘플 결제에서 패스키 사용해 보기. 별도의 이 데모는 플랫폼 인증기를 사용해 영수증 무결성을 보여 줍니다. 결제는 전송되지 않습니다.

이미 사용하는 도구 하나 보호하기

에이전트 프로세스 내부에만 적용하지 말고, 실제 공급자 자격 증명을 보유한 서비스에서 시작하세요. 소유자는 허용되는 작업과 새 승인이 필요한 시점을 정의합니다. 에이전트는 사람이 모든 호출을 승인하지 않아도 이러한 한도 내에서 작업할 수 있습니다.

MCP 또는 HTTP: Gate Starter에서 보호되는 작업 하나를 적용하는 방법을 안내합니다.
Hugging Face smolagents: 기존 도구 래핑하기.
GitHub: Merge Gate는 검사를 제안된 병합에 연결합니다. 해당 검사를 필수로 설정하고 다른 병합 경로를 차단해야 합니다.

프로토콜은 증명하고, Gate는 배포 환경이 완전히 중재하는 경로에서 차단합니다. 우회 경로는 Gate가 제약할 수 없습니다. 공급자의 결과를 알 수 없는 경우, 프로덕션 수명 주기는 무작정 재시도하는 대신 조정을 위해 그 불확실성을 보존합니다.

AI 시스템 및 저장소 검토자: AI_CONTEXT.md부터 확인하세요. 현재의 기계 판독 가능 증거, 출처, 가정, 제외 사항은 EMILIA-REPO-CONTEXT-v1에 게시되어 있습니다. 보관되었거나 준비 중인 문서는 현재 구현이나 IETF 상태를 입증하지 않습니다. 공개 실사 증거와 주장 범위: DUE_DILIGENCE.md.

아키텍처 주장이 아닌 엔지니어링 증거

EMILIA는 검토자가 직접 실행할 수 있는 보안 사례를 제공합니다. 현재 저장소는 해시된 증거 파일 264개에 걸쳐 보안 주장 35개를 해결하고, 두 개의 결합된 Dolev-Yao 모델에서 Tamarin 보조정리 20개를 검증합니다. 이 중 17개는 모든 추적에 대한 의무이고 3개는 존재 추적 도달 가능성 증명입니다. 또한 핵심 검사를 제거하면 구체적인 공격 추적을 생성하는 의도적으로 약화된 변형 8개를 보존합니다. 현재 동일 팀 적합성 테스트 코퍼스에는 스위트 21개와 현재 벡터 340개가 포함됩니다. 별도로 외부에서 작성한 Rust 검증기는 고정된 스위트 16개/벡터 164개 번들과 359개 사례의 적대성 테스트를 대상으로 합니다. 더 광범위한 테스트 스위트에는 650개 이상의 파일에 걸쳐 자동화 테스트 10,700개 이상이 포함됩니다.

프로덕션 JavaScript 및 JSDoc 표면은 TypeScript checkJs로 컴파일 검사를 받습니다. 보안 앱에는 자체 호환성 컴파일러 프로젝트가 있으며, 선언 파일과 공개 TypeScript SDK는 엄격 모드로 검사됩니다. 이는 구성된 프로덕션 타입 검사 범위가 완전하다는 뜻이지, 저장소 전체를 JavaScript에서 TypeScript로 변환했다거나 모든 JavaScript 프로젝트에서 TypeScript의 strict 옵션을 활성화했다는 뜻은 아닙니다.

각 보안 주장은 적용 경로, 긍정 및 부정 벡터, 언어 범위, 형식 검증 범위 또는 명시적 공백, 가정, 제외 사항, 증거 해시를 명시합니다. 먼저 사람이 읽을 수 있는 증거 지도를 확인한 다음, 해결된 보안 사례를 살펴보거나 npm run check:security-case을 실행하세요.

AEB-1: 증거에서 효과로 이어지는 경계 테스트

공개 AEB-1 Consequence Admission Conformance 팩은 중대한 작업 직전의 마지막 제어 지점에서 결합된 CAID/AEC 경로를 테스트합니다. 여기에는 네이티브 검증, 신뢰 당사자의 수락, 정확한 작업 바인딩, 필수 CAID 일치, 필수 AEC 증거 충족, 로컬 권한 부여, 원자적 예약, INVOKING 보관, 공급자 결과와 관찰된 효과의 진실성 분리, 무조건 재시도 금지 동작, 인증된 조정이 포함됩니다.

결합된 CAID/AEC 경로, 직접 네이티브 경로, AEB 보관, 공급자 결과 증거 간의 정확한 책임 분담은 결과 승인 경계 읽기를 참조하세요.

npx @emilia-protocol/verify aeb-conformance --reference

형식에 구애받지 않으며 직접 실행할 수 있습니다. 통과 보고서는 자체 인증된 적합성 증거이지, 감사, 인증, 프로덕션 배포 주장 또는 작업 실행 권한이 아닙니다.

2026-09-25에 개인 Internet-Draft로 게시되었으며 어떤 작업 그룹에서도 채택되지 않은 AEB-07에 따라, CAID는 독립적으로 인코딩된 작업을 결합해야 할 때만 사용하고, AEC는 로컬 정책에서 여러 증거 항목을 요구할 때만 사용합니다. 별도의 26개 사례로 구성된 합성 코퍼스는 AuthZEN/COAZ-MCP, AP2, OAuth Transaction Token, 로컬 서명 위임 어댑터 결과를 대상으로 직접 네이티브 수명 주기를 모델링합니다.

npm run conformance:composition:consequence-admission

코퍼스 실행기는 자체 메모리 내 저장소와 승인 로직을 갖춘 독립형 수명 주기 모델입니다. 제공된 @emilia-protocol/verify 또는 @emilia-protocol/gate 코드를 실행하지 않으므로 해당 패키지의 증거가 아니며, 각 패키지에는 자체 테스트 스위트가 있습니다. 또한 명시된 네이티브 프로토콜이 AEB-07을 준수한다는 증거도 아닙니다.

저장소의 Gate 경로를 집중적으로 실행해 증명하려면 다음을 실행하세요.

npm run proof:gate:reference

이 명령은 생성된 키, 메모리 내 상태, 모의 공급자 동작을 사용해 로컬 예제와 집중적인 서비스 경계를 실행합니다. 유용한 로컬 증명이지만 실제 사람, 외부 은행, 프로덕션 배포 또는 프로덕션 종단 간 통합 하나를 입증하지는 않습니다.

신원은 직무 설명이 아닙니다

신원은 누가 또는 무엇이 호출하는지를 나타냅니다. 정책은 일반적으로 무엇이 허용되는지를 나타냅니다. 어느 쪽도 자율 작업자가 지금 수행할 수 있는 한정된 작업, 즉 임무, 중대한 작업의 한도, 예산, 필수 증거, 만료, 위임 규칙, 예외 경로를 정의하지 않습니다.

EMILIA는 이러한 질문을 분리합니다.

계층	질문
신원	누가 또는 무엇이 존재하는가?
정책	일반적으로 무엇이 허용되는가?
권한	이 에이전트가 이 위임에 따라 정확히 어떤 작업을 수행할 수 있는가?

자격 증명은 접근 범위를 부여합니다. 권한은 작업을 정의합니다. 모든 작업에 사람이 필요한 것은 아니지만, 모든 중대한 작업에는 유효한 권한이 필요합니다.

기반 계층에서 EP Core는 여전히 상호 운용 가능한 객체 세 가지를 제공합니다. Trust Receipt는 귀속 가능한 증거를 담고, Trust Profile은 구조화된 신뢰 상태를 나타내며, Trust Decision은 신뢰 당사자가 정책을 평가한 결과를 기록합니다. 권한 제어 평면 계층은 이러한 객체를 하나의 주장으로 합치지 않고 정확한 작업 바인딩, 유한한 위임, 승인, 소비, 결과 증거를 추가합니다.

위임은 한 번 설정하고 에이전트가 작업하게 하세요.

고객은 임무, 한도, 증거 요건, 만료, 예외 규칙을 정의합니다. 로컬 코드는 해당 권한을 좁힐 수 있지만 새로 만들어 내거나 확대할 수는 없습니다. Gate는 실행 가능한 각 요청을 위임에 연결하고, 공급자에 진입하기 전에 해당 권한을 예약하며, 공유된 영속 권한 도메인 내에서 해당 승인 인스턴스에 대해 승인된 공급자 시도를 한 번 허용합니다. 권한이 없거나, 오래되었거나, 소진되었거나, 범위가 너무 좁은 경우에만 상위 승인을 요청합니다.

번들에 포함된 MCP 예제는 경계에서 승인을 요구하는 정책 프로필을 실행합니다. 예제는 데모 서명 키를 생성하고 모의 도구를 호출합니다. 결제 예제는 선언된 중대한 필드 네 가지를 모두 바인딩하며, 다른 예제는 더 좁은 리소스 바인딩을 보여 줍니다. 실제 사람의 결정을 기록하거나 공급자에 접속하지는 않습니다.

node examples/mcp/payment-server.mjs    # release_payment  — refuses without a receipt
node examples/mcp/github-admin.mjs      # delete_repo      — refuses without a receipt
node examples/mcp/prod-deploy.mjs       # deploy_production — refuses without a receipt

더 심층적인 결합 데모는 Gate의 실제 제한된 기능 경로를 통해 CAID에 바인딩된 위임 결제를 실행한 다음, 서명된 실행 인증서를 오프라인으로 검증합니다.

npm run demo:receipt-program

이 데모에는 블록체인이나 시뮬레이션된 영지식 증명이 의도적으로 포함되지 않습니다. 프로덕션 상태 및 신뢰 요건은 영수증 프로그램 아키텍처를 참조하세요.

선언된 중대한 MCP 작업 하나부터 시작하세요. 정확한 로컬 런타임을 설치한 다음 Gate Starter를 만들고 제한된 네 가지 사례 검사를 실행하세요.

npm install --save-exact @emilia-protocol/mcp-guard@0.7.0
npx @emilia-protocol/scan@0.6.0 protect ./tools.json --action sendWire --apply --verify

# after reading emilia/authority-map.html and action-control.manifest.json
npx @emilia-protocol/scan@0.6.0 protect ./tools.json --action sendWire --reviewed \
  --crossing-profile ccs-wang-draft08-v13

생성된 로컬 검사는 명시적으로 임시 데모 상태를 사용하며, 명시된 합성 사례인 누락, 정확한 일치, 변경, 재생, 검사되지 않은 도구만 증명합니다. 검토된 명령은 개인정보를 제한한 인계 자료를 생성할 뿐 Gate를 활성화하지 않습니다. 프로덕션에는 영속적인 출처 원장, 공유 원자적 소비 저장소, 고정된 키, 실제 공급자 자격 증명으로 이어지는 모든 경로에 적용되는 래퍼가 필요합니다. examples/mcp/ 및 /mcp를 참조하세요.

이전 작업을 되돌리는 척하지 않고 새 작업 차단하기

Gate의 긴급 권한 동결은 새 예약을 차단하고, 보호 대상 제어 도메인의 에포크가 변경된 뒤에는 이전 예약이 진입하지 못하게 합니다. 공급자 진입이 먼저 발생했다면 해당 시도는 소비된 상태로 유지되며 조정이 필요합니다. 권한을 복원해도 이전 예약이 되살아나지는 않습니다.

이를 위해서는 완전한 중재와 권위 있는 공유 상태가 필요합니다. 계산을 중단하거나 효과를 되돌리거나 연결이 끊긴 도메인에 즉시 도달하지는 않습니다. 제어 도메인 구현 및 한계를 참조하세요.

30초 만에 사용해 보기

# Issue a receipt offline — no API key, no backend needed
npx @emilia-protocol/issue demo

# Add EMILIA to Claude / Cursor / Cline
npx -y @emilia-protocol/mcp-server

샘플 결제에서 플랫폼 패스키 사용해 보기 → 예시로 $82,000 결제에 서명하고 금액을 변경해 무결성 검사가 실패하는 것을 확인하세요. 인증기는 생체 인식이나 기기 PIN을 사용할 수 있습니다. 페이지에는 별도의 소프트웨어 시뮬레이션도 제공됩니다. 어느 모드도 결제를 전송하거나 프로덕션 권한을 설정하지 않습니다.

브라우저에서 영수증 검증하기 — 붙여넣기만 하면 됩니다. 아무것도 업로드되지 않습니다.

작동 방식 — 하나의 권한 수명 주기

EMILIA crash test — an autonomous agent tries to wire $82,000; the selected policy profile requires fresh human authority, the exact action is signed, the receipt verifies offline, and a forged copy fails.

직접 실행해 보세요: node examples/crash-test.mjs — 완전 오프라인이며 API 키가 필요하지 않습니다.

  [ MANDATE ]       [ EXACT WORK ]       [ VERIFY ]       [ RESERVE + ENTER ]  [ RECONCILE ]
  mission, limits   canonical action     pinned native    one admitted        preserve provider
  evidence, expiry  + occurrence         evidence         provider entry      and effect truth

위임. 권한 출처는 유한한 작업을 정의합니다. 고객이 서명한 운영 프로그램, 제한된 기능, 필수 사람 승인, 정족수 또는 신뢰 당사자가 네이티브 증거를 결합한 결과일 수 있습니다.

정확한 작업. Gate는 메서드, 출처, 호출 대상, 대상 리소스, 발생 시점, 모든 중대한 필드를 정규 실행 객체에 바인딩합니다. 의도, 프롬프트, 티켓 텍스트는 해당 객체가 아닙니다.

검증, 예약, 진입. 네이티브 아티팩트는 네이티브 형식 그대로 유지됩니다. 신뢰 당사자는 신뢰 및 매핑 프로필을 고정하고, 전체 증거 요건을 평가하며, 별도의 로컬 권한 부여 결정을 내리고, 자격 증명을 보유한 어댑터가 공급자에 진입하기 전에 보호 대상 권한을 예약합니다.

필요한 경우 새 사람 권한 확인. 정책은 정확한 작업과 결정적 표시 해시에 바인딩된 WebAuthn/패스키 결정을 요구할 수 있습니다. 이는 “본 내용에 서명했다”는 간극을 줄여 주지만, 이해도, 판단의 타당성, 적법성 또는 결과를 입증하지는 않습니다. 엔터프라이즈 배포에서는 Gate가 해당 인간 증거, 동일한 정확한 작업, AS가 실제로 관찰한 신원 스냅샷, 그리고 의도된 Resource Server 키에 결속된 독립적으로 검증된 Authorization Server 확인을 추가로 요구할 수 있습니다. 스냅샷 시각과 신뢰 당사자의 최대 유효 기간은 명시적입니다. 토큰이 최신이라고 해서 오래된 디렉터리 데이터가 최신 데이터가 되는 것은 아닙니다. AS 단계는 고객이 고정한 신뢰를 바탕으로 한 증거입니다. 그 자체로 권한을 부여하거나, 고용 상태가 현재 시점에도 유효함을 증명하거나, 에이전트 오케스트레이터를 권한 주체로 만들지는 않습니다.

진실한 결과. 승인은 실행이 아니며, 실행은 효과가 아닙니다. 서명된 기록은 오프라인에서 검증할 수 있습니다. 공급자 증거와 관찰자 증거는 서로 분리된 상태로 유지됩니다. 응답을 받지 못하면 INDETERMINATE 상태가 되며, 이는 재시도 권한이 아니라 조정해야 할 상태입니다. 구제 조치는 새로 승인된 작업이며, 이전 결과를 다시 쓰지 않습니다.

개발자가 사용하는 이유

먼저 로컬에서 작업을 매핑한 다음, MCP 서버 또는 얇은 SDK 래퍼로 선언된 작업 표면 하나를 보호합니다. 스캐너는 검토 가능한 맵을 제안하고, 소유자는 권한 범위를 정의하며, Gate는 공급자 자격 증명을 보유하고 보호 경로에서 정확한 작업을 강제합니다. 어떤 스캔도 완전한 중개를 증명하지 않으며, 탐색만으로는 권한이 부여되지 않습니다.

# langchain-emilia — wrap any LangChain tool with an EP gate
from langchain_emilia import EmiliaGateClient

gate = EmiliaGateClient(base_url="https://www.emiliaprotocol.ai", api_key="...")
safe_tool = gate.wrap(your_destructive_tool)

pip install langchain-emilia   # PyPI
npm install @emilia-protocol/verify  # npm

에이전트는 범위가 제한된 작업을 수행할 능력을 받으며, 임의로 재해석할 수 있는 상시 자격 증명을 받지 않습니다.

엔터프라이즈에 필요한 이유

에이전트 프로세스는 재시작되고 모델은 바뀝니다. 고객의 권한 범위, 소비 상태, 취소, 불확실성, 작업 이력은 에이전트 외부에 보존되어야 합니다. EMILIA는 고객 경계에 이 지속적인 권한 상태를 유지하면서 고정된 어댑터를 통해 외부 증명을 수용합니다.

관리형 Gate와 Assurance Plane은 개방형 프로토콜을 중심으로 권한 범위 운영, 통합, 증거 운영, 재수행, 지원, 서비스 수준을 제공합니다. 권한, 신뢰 루트, 자격 증명, 정책, 이동 가능한 증거에 대한 통제권은 고객에게 있습니다.

표준

EMILIA Protocol은 개방형이며 Apache-2.0 라이선스를 따릅니다. 표준화 작업은 개별 Internet-Draft 포트폴리오로 공개됩니다. 공개된 Internet-Draft는 RFC도, 채택된 워킹 그룹 문서도, IETF의 지지도 아닙니다. 개정판과 상태에 대한 권위 있는 정보는 Datatracker에서 확인할 수 있습니다.

IANA 등록

등록된 두 이름은 EMILIA 형식에 대한 공통 참조를 구현자에게 제공합니다.

application/vnd.emilia.authorization-evidence-challenge+json 는 2026년 10월 6일에 등록되었습니다. 이는 공개된 직렬화 명세에 정의된 독립형 AE-CHALLENGE-v1 JSON 객체를 식별합니다. HTTP 거부 응답은 계속 application/problem+json를 사용합니다.
canactid: 는 2026년 10월 5일에 잠정 등록되었습니다. CAID-05에 따른 정확한 형식의 작업을 나타냅니다. 수정된 CRI 스킴 번호는 1033입니다.

이 등록은 이름과 해당 명세를 공개합니다. IETF 채택, 지지, 인증 또는 고객 배포를 의미하지 않습니다.

하나의 결과 경계 표면

현재 공개된 AEB-07은 2026-09-25에 개별 Internet-Draft로 게시되었으며 채택되지 않았습니다. 이 문서는 네이티브 결정 이후 AEB를 구성 지점으로 삼습니다. OAuth, AuthZEN, COAZ, AP2 및 로컬 시스템은 각자의 자격 증명, 작업 매핑, 권한 부여 결정을 계속 소유합니다. AIMS (draft-ietf-wimse-aims)는 기존 표준인 WIMSE와 OAuth 등을 프로파일링하는 Informational WIMSE 워킹 그룹 문서입니다. AIMS 자체는 자격 증명이나 결정을 발급하지 않습니다. AEB는 보호된 공급자 경계에서 네이티브 결정을 적용합니다. 필요한 경우 최종 작업을 결속하고, 권한 부여마다 하나의 네이티브 재생 식별자를 도출하며, 공급자 진입 전에 예약하고, 이전 시도가 진행 중이거나 불확실한 동안 동일 작업에 대한 두 번째 시도를 거부하며, 인증된 조정이 이루어질 때까지 불확실한 결과를 잠금 상태로 유지합니다.

독립적으로 인코딩된 표현을 비교해야 할 때는 CAID-05를 사용합니다. 새 식별자는 IANA에 잠정 등록된 canactid: URI 스킴을 사용합니다. 이 등록은 IETF 채택, 지지, 인증 또는 영구적인 상태를 의미하지 않습니다. 결과를 소유하는 PEP가 최종 작업에 대해 최신 결정을 이미 도출하고 강제한다면 CAID는 필수적인 두 번째 매핑이 아닙니다. 정확한 작업 플레이그라운드 사용해 보기 또는 CAID-04에서 CAID-05로의 마이그레이션 가이드 읽기. 신뢰 당사자가 여러 증거 단계를 요구할 때는 AEC-06을 사용합니다. Authorization Receipts, Human Authorization Binding, Authority Introduction은 필요한 배포를 위한 프로파일로 계속 제공되지만, 모든 AEB 통합의 전제 조건은 아닙니다. Architecture-03은 계속 탐색 문서 역할을 합니다.

결과 승인 가이드는 구현 경계와 AEB가 불필요한 경우를 설명합니다. 직접 네이티브 핸드오프 프로파일은 기존 허가가 두 번째 CAID 또는 AEC 계층 없이 Gate에 도달하는 방식을 보여 주는 저장소 구현 프로파일입니다. AEB-07은 이러한 게이트웨이 핸드오프가 무엇을 증명하고 경계에서 이를 어떻게 검증하는지 명시하지만, 인코딩은 배포 핀에 맡깁니다. 이 문서는 이 프로파일의 고정된 스냅샷을 참고용 인코딩 사례로 인용합니다. 제출된 정확한 -07 바이트와 게시 기록은 standards/staged/NEXT-AEB-07에 보존되어 있습니다.

활성 포트폴리오 전체는 Datatracker 기록 26개로 구성됩니다. 단독 저자 기록 21개와 공동 저자 기록 5개이며, 각 기록에는 자체 범위, 개정 이력, 기록된 유지 관리 상태가 있습니다. 표준 가이드, 포트폴리오, 기계 판독 가능한 상태 인벤토리를 참조하세요.


IETF Internet-Draft	현재 로컬 스냅샷 경로: 상태 인벤토리 · 단독 저자 게시 인벤토리 · 권위 있는 실시간 상태: IETF Datatracker
다중 언어 검증기	JavaScript · Python · Go — 세 구현 모두 매 푸시마다 적대적 적합성 벡터와 일치함이 입증되었습니다 (`npm run conformance`). 한 팀의 포트 간 일관성 검사이며, 독립적인 클린룸 구현은 아닙니다. 별도로, 외부 작성자가 명세를 바탕으로 구현한 Rust 버전(소스 공개)은 평가자가 제어하는 불변 소스 트리 재빌드에서 고정된 16개 스위트/164개 벡터 번들과 고정된 359개 사례 적대성 캠페인을 통과합니다. 체크인된 구성 증거는 여전히 구현자 서명 증거이며 제3자 증명은 아닙니다 (서명된 진술). 수정된 제3자 증명 매니페스트와 독립적으로 고정된 증명자 키가 제공될 때까지 엄격한 클린룸 승인은 보류됩니다.
형식 모델 증거	구성된 상태 공간에서 경계가 설정된 TLA+ 안전성 속성 26개가 성립했습니다. 이는 구현 정련이나 무제한 증명이 아닙니다 · 네 개 모델에 걸친 Alloy 사실 35개, 단언 32개 · 챌린지, CAID, 두 건의 승인, 발급자 및 권한 핀, 레지스트리 뷰, 취소, 소비, 실행, 그리고 여섯 개의 전용 클레임 경계를 다루는 두 개의 합성 기호 Dolev-Yao 모델. Tamarin 보조정리 20개가 검증되었습니다. 모든 추적 의무 17개와 존재 추적 증인 3개이며, 부하를 지탱하는 검사를 제거하면 의도적으로 약화한 변형 8개에서 구체적인 공격 추적이 생성됩니다 (formal/tamarin/).
MCP 배포	npm 패키지 `@emilia-protocol/mcp-server` · 공식 Registry 게시 현황은 MCP-REGISTRY.md에서 별도로 추적합니다. 집계 사이트의 목록은 어느 상태에서도 추론하지 않습니다.
라이선스	Apache-2.0

같은 팀이 만든 참조 포트 3개(JS / Python / Go)는 21개 스위트와 340개 벡터 전체에서 일치합니다. 별도로, 외부 작성자가 만든 Rust 구현은 고정된 공개 소스 트리에서 재빌드한 뒤 고정된 16개 스위트/164개 벡터 클린룸 번들과 359개 사례 적대성 캠페인을 통과하며, 자체 CI 레인에서 변경 사항이 있을 때마다 다시 실행됩니다. 최신 AEC 승인 및 4가지 결과 해결 스위트는 Rust의 성과로 간주하지 않습니다. 이는 외부 상호 운용성 증거이지 엄격한 클린룸 구현 승인은 아닙니다. 독립적인 증명이 완료될 때까지 집계 CI 사례는 엄격한 승인 건수를 0으로 기록합니다. CONFORMANCE.md를 참조하거나 emiliaprotocol.ai/verify에서 직접 영수증을 검증하세요.

권한 스택

계층	역할
권한 범위	임무, 한도, 증거, 만료, 위임, 예외 규칙을 정의합니다.
CAID / 정확한 작업	권한 부여와 실행에서 독립적으로 인코딩된 표현을 사용할 때 중요한 의미를 비교합니다. 권한을 부여하지는 않습니다.
AEC	필요한 경우, 독립적으로 검증되고 일치된 증거가 신뢰 당사자의 다중 단계 요구 사항을 충족하는지 평가합니다. 권한을 부여하지는 않습니다.
AEB / Gate	결과 경계에서 네이티브 또는 로컬 권한 부여 결정을 적용하고, 해당 권한을 예약하며, 공급자 진입을 제어합니다.
결과 증거	호출, 공급자 응답, 관찰된 효과, 불확실성을 서로 구분해 유지합니다.

입증 자료

지표	값
자동화 테스트 사례	650개 이상의 파일에 걸쳐 10,700개 이상. 플랫폼에 적용되는 모든 사례를 통과해야 합니다.
TLA+ 안전성 속성	구성된 상태 공간에서 경계가 설정된 불변식 26개가 성립했습니다. 구현 정련이나 무제한 증명은 아닙니다. PROOF_STATUS.md 참조
Alloy 관계형 단언	네 개 모델에 걸쳐 사실 35개 + 단언 32개 — CI에서 검증됨
목록화된 레드팀 사례	86개 — RED_TEAM_CASES.md
릴리스 보안 상태	저장소 보안 검사를 통과했습니다. 감사 대상 변경 사항에서 발견된 모든 Strix 항목은 회귀 테스트를 포함해 해결되었으며 검토 스레드도 종결되었습니다.
적합성 (7/7)	`node conformance/ep-conformance-test.js https://www.emiliaprotocol.ai`
다중 언어 적합성	340개 벡터 · 21개 스위트: 영수증 · 기기 승인 · 4가지 결과 해결 · 다자 정족수 · 취소 · Outcome Binding(의미 + 실제 암호화) · Authority Document/Proof 발급자 결합 · 시간 증명 · 신뢰 영수증(프로파일 2개) · 출처 · 증거 기록 · 정규화 · 경계 · AEC 승인 · 통화 · 개시자 증명 · 소비 증명 · 증인 · 타임스탬프 증명(RFC 3161). JS / Python / Go 검증기가 일치합니다 (`node conformance/run.mjs`). 외부 Rust 기준선은 164개 벡터 / 16개 스위트를 유지합니다. CONFORMANCE.md 참조.
핸드셰이크 생성 p95	50 VU에서 575ms — PERFORMANCE_PROOF.md

암호학적 장기 유효성 (명시적인 배포 경계 포함)

수년 뒤에도 검증해야 하는 증거는 서명에 사용된 알고리즘보다 오래 유효해야 합니다. EP는 이를 위해 경계가 명확한 네 가지 기능을 제공하며, 각 기능에는 주장의 일부인 정확한 경계가 있습니다.

하이브리드 서명(EP-RECEIPT-HYBRID-v1). 동일한 정규 바이트에 대해 Ed25519와 ML-DSA-65를 사용하며, 필수 알고리즘 집합을 서명된 바이트에 포함하므로 한쪽 서명을 제거하면 남은 서명도 무효화됩니다. 이 기능은 배포 시 선택적으로 활성화할 수 있습니다. 승인된 이중 서명자가 등록되고 정책에서 PQ 서명을 허용하면, 고정되지 않은 Gate 상태는 기본적으로 이중 발급으로 결정됩니다. 그렇지 않으면 명시된 사유와 함께 기존 방식만 사용합니다. v1 검증기는 하이브리드 영수증을 한쪽 서명만 받아들이는 대신 정상적으로 거부합니다. 외부 서명자 계약과 AWS KMS 어댑터는 구현되어 있지만, 실제 AWS 서명 호출, 프로덕션 키, 신뢰 당사자 검증 또는 ML-DSA FIPS 검증을 수행했다고 주장하지 않습니다. conformance/hybrid-receipts/ 및 lib/pq-custody-aws-kms.ts를 참조하세요.
SCITT 서명된 명세서 프로필(EP-SCITT-STATEMENT-v1). CWT Claims 보호 헤더를 포함하여 EP 영수증을 위한 완전한 RFC 9943 서명된 명세서 형식입니다. 경계: Transparency Service가 EP 명세서를 수락한 적은 없습니다. 외부 등록은 별도의 승인 절차가 필요한 단계이며, 아직 수행되지 않았습니다. EP-RECEIPT-SCITT-PROFILE.md를 참조하세요.
재증명(EP-EVIDENCE-REATTESTATION-v1). 오래된 알고리즘으로 서명된 증거는 해당 알고리즘이 약화되기 전에 현재 알고리즘으로 다시 고정할 수 있습니다. 경계: 재증명은 침해가 발생하기 전에 이루어져야 하며, 사후에 증거를 복구할 수는 없습니다.
FIPS 배포 모드(EP-FIPS-MODE-v1). 운영자가 제공하는 FIPS 140-3 검증 공급자를 통해 기존 방식의 작업을 수행하며, ML-DSA 경로는 검증되지 않은 구현임을 명시적으로 확인한 경우에만 사용할 수 있습니다. 경계: 이 모드는 "검증된 공급자 배포 모드를 사용하는 FIPS 기반 알고리즘"이라는 설명을 뒷받침하며, 운영자의 공급자와 선언된 인증서 경계에 따라 달라집니다. 포괄적인 규정 준수 주장은 아니며, 여기의 어떤 항목도 FIPS 검증을 받은 것은 아닙니다. FIPS-MODE.md를 참조하세요.

전체 스택의 하이브리드 프로그램(모든 내부 서명 표면)은 pq-hybrid-program.md에 정리되어 있으며 아직 완료되지 않았습니다. 완료될 때까지 전체 스택에 대한 포괄적인 주장은 하지 않습니다.

핵심 프로토콜 객체

객체	설명
권한 프로그램 / 제한된 권한	명시적인 범위, 예산 또는 단위, 만료, 위임 및 소비 규칙을 갖는 유한한 권한입니다.
CAID	명명된 매핑 프로필에 따라 하나의 실질적 작업을 식별하는 정규 식별자입니다. 일치 여부는 권한 부여를 의미하지 않습니다.
증거 요건 및 AEC 결과	신뢰 당사자가 고정한 규칙과 해당 규칙의 `SATISFIED`, `UNSATISFIED` 또는 `INDETERMINATE` 평가입니다.
AEB 승인 및 보관 기록	권한 부여, 예약, 공급자 진입 및 조정 상태를 기록하는 실행기 측 기록입니다.
권한 부여 및 결과 증거	발급자, 범위 및 클레임 경계를 정확히 유지하는 이식 가능한 네이티브 또는 EP 아티팩트입니다.

빠른 시작

정확한 로컬 가드 런타임을 설치한 다음 npx @emilia-protocol/scan@0.6.0 protect ./tools.json --action sendWire --apply --verify를 실행합니다. sendWire을 정확히 선언된 중대한 도구 하나로 바꿉니다.
생성된 Authority Map, 작업 매니페스트, 실질적 필드, 선택된 경계 및 명시된 사각지대를 검토합니다.
별도의 --reviewed --crossing-profile <launch-profile> 명령을 실행하여 변경되지 않은 해당 바이트로 소유자 전용 핸드오프와 봉인되지 않은 Lab 작업 공간을 만듭니다.
공급자 자격 증명과 영속적인 소비 상태를 관리하는 경로에 Gate를 설치합니다.
운영 권한과 새로 확인된 사람의 승인 또는 정족수 예외 규칙을 정의합니다.
시행을 활성화하기 전에 거부, 정확한 작업, 재생, 시간 초과 및 조정 사례를 실행합니다.

90초 데모 · 빠른 시작 · 에이전트 안내 · IETF 초안 · Discord

EP란 무엇이며, 무엇이 아닌가

EMILIA는 자율 작업을 위한 권한 인프라이지, 신원 시스템, 지갑, 평판 점수, 결제 레일 또는 범용 정책 엔진이 아닙니다.

해당하는 것: 유한한 운영 권한, 정확한 작업 검증, 영속적인 승인 상태, 불확실성의 정직한 표현, 그리고 적용 대상 실행기 경로에서 사용할 수 있는 이식 가능한 증거를 위한 제어 평면입니다.
해당하지 않는 것: OAuth/OIDC, 워크로드 신원 또는 정책 엔진의 대체재가 아닙니다. 이러한 요소는 신뢰 당사자가 고정한 네이티브 입력으로 계속 사용됩니다.
해당하지 않는 것: 모든 작업에 사람이 승인해야 한다는 요구가 아닙니다. 권한은 유한한 범위 내에서 자동 작업을 허용하고, 경계에 도달했을 때만 새로운 권한을 요구할 수 있습니다.
해당하지 않는 것: 승인된 작업이 성공적으로 실행되었거나 의도한 효과를 일으켰다는 증명이 아닙니다.
해당하지 않는 것: 독점적인 프로토콜 통제가 아닙니다. 핵심은 Apache-2.0 라이선스이며, Internet-Draft는 개별 제출물이지 RFC나 IETF의 지지가 아닙니다.

CONFORMANCE.md · SECURITY.md · THREAT_MODEL.md · GOVERNANCE.md · 중립성 서약