EMILIA Protocol

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 모델에서 20개의 Tamarin 보조 정리 — 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 결과 허용 적합성 팩은 결과적 작업 전 마지막 제어 지점에서 구성된 CAID/AEC 경로를 테스트합니다: 네이티브 검증, 신뢰 당사자 수락, 정확한 작업 바인딩, 필수 CAID 일치, 필수 AEC 증거 충족, 로컬 권한 부여, 원자적 예약, INVOKING 관리, 별도의 공급자 결과 및 관찰 효과 진실, 무-맹목-재시도 동작, 인증된 조정.

결과 허용 경계 읽기 — 구성된 CAID/AEC 경로, 직접 네이티브 경로, AEB 관리, 공급자 결과 증거에 걸친 정확한 책임 분담을 위해.

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

형식 중립적이며 자체 실행됩니다. 통과 보고서는 자체 인증된 적합성 증거이며, 감사, 인증, 프로덕션 배포 주장 또는 작업 실행 권한이 아닙니다.

AEB-07에 따라, 2026-09-25에 개별 인터넷 초안으로 게시되고 어떤 작업 그룹에도 채택되지 않은, CAID는 독립적으로 인코딩된 작업을 결합해야 할 때만 사용되며, AEC는 로컬 정책이 여러 증거 다리를 요구할 때만 사용됩니다. 별도의 26-케이스 합성 코퍼스는 AuthZEN/COAZ-MCP, AP2, OAuth 트랜잭션 토큰, 로컬 서명 위임 어댑터 결과에 대한 직접 네이티브 수명 주기를 모델링합니다:

npm run conformance:composition:consequence-admission

코퍼스 러너는 자체 인메모리 저장소와 허용 논리를 가진 독립형 수명 주기 모델입니다. 배송된 @emilia-protocol/verify 또는 @emilia-protocol/gate 코드를 실행하지 않으므로 해당 패키지에 대한 증거가 아니며, 각각 자체 테스트 스위트가 있습니다. 또한 명명된 네이티브 프로토콜이 AEB-07에 적합하다는 증거도 아닙니다.

저장소의 Gate 경로에 대한 집중 실행 가능 증거를 위해 다음을 실행하세요:

npm run proof:gate:reference

이 명령은 생성된 키, 인메모리 상태, 모의 공급자 동작으로 로컬 예제와 집중 서비스 경계를 실행합니다. 유용한 로컬 증거이지만, 실제 인간, 외부 은행, 프로덕션 배포 또는 하나의 엔드투엔드 프로덕션 통합의 증거는 아닙니다.

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

신원은 누가 또는 무엇이 호출하는지 말합니다. 정책은 일반적으로 무엇이 허용되는지 말합니다. 둘 다 자율 작업자가 지금 수행할 수 있는 유한한 작업을 정의하지 않습니다: 임무, 중요 작업 한계, 예산, 필수 증거, 만료, 위임 규칙, 예외 경로.

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

계층	질문
신원	누가 또는 무엇이 존재합니까?
정책	일반적으로 무엇이 허용됩니까?
권한	이 위임 하에 이 에이전트가 수행할 수 있는 정확한 작업은 무엇입니까?

자격 증명은 접근을 부여합니다. 권한은 작업을 정의합니다. 모든 작업에 인간이 필요하지는 않습니다. 모든 결과적 작업에는 유효한 권한이 필요합니다.

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

---

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

고객은 임무, 한계, 증거 요구 사항, 만료, 예외 규칙을 정의합니다. 로컬 코드는 그 권한을 좁힐 수 있지만, 발명하거나 넓힐 수는 없습니다. 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를 생성하고 제한된 4-케이스 체크를 실행하세요:

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

# after reading emilia/authority-map.html and action-control.manifest.json
npx @emilia-protocol/scan@0.5.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을 사용할 수 있습니다. 페이지는 별도의 소프트웨어 시뮬레이션도 제공합니다. 어느 모드도 결제를 보내거나 프로덕션 권한을 설정하지 않습니다.

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

---

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

직접 실행: 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/패스키 결정을 요구할 수 있습니다. 이것은 "본 것이 서명한 것" 격차를 좁힙니다. 이해, 지혜, 적법성 또는 결과를 증명하지는 않습니다. For enterprise deployments, Gate can additionally require an independently verified Authorization Server confirmation bound to that exact human evidence, the same exact action, the identity snapshot the AS actually observed, and the intended Resource Server key. The snapshot time and relying-party maximum age are explicit: a fresh token cannot make stale directory data current. The AS leg is evidence under customer-pinned trust; it never authorizes by itself, proves instantaneous employment standing, or turns the agent orchestrator into an authority.

Truthful result. Admission is not execution, and execution is not effect. A signed record can be verified offline; provider and observer evidence remain separate. A lost response becomes INDETERMINATE, which is a state to reconcile—not permission to retry. A remedy is a new authorized action and never rewrites the old result.

---

Why developers use it

Start by mapping the work locally, then protect one declared action surface with the MCP server or thin SDK wrapper. The scanner proposes a reviewable map; the owner defines the mandate; Gate owns the provider credential and enforces the exact action on the covered path. No scan proves complete mediation, and discovery alone grants no authority.

# 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

The agent receives the ability to perform bounded work, not a standing credential it can reinterpret.

---

Why enterprises need it

Agent processes restart and models change. The customer's mandate, consumption state, revocation, uncertainty, and work history must survive outside them. EMILIA keeps that durable authority state at the customer's boundary while accepting foreign proof through pinned adapters.

The managed Gate and Assurance Plane add mandate operations, integrations, evidence operations, re-performance, support, and service levels around the open protocol. The customer retains control of authority, trust roots, credentials, policy, and portable evidence.

---

The standard

EMILIA Protocol is open and Apache-2.0. Its standards work is published as a portfolio of individual Internet-Drafts. A published Internet-Draft is not an RFC, an adopted working-group item, or IETF endorsement; Datatracker is authoritative for revision and status.

One consequence-boundary surface

The current published AEB-07, posted on 2026-09-25 as an individual Internet-Draft and not adopted, makes AEB the composition point after a native decision. OAuth, AuthZEN, COAZ, AP2, and local systems keep ownership of their credentials, operation mappings, and authorization decisions. AIMS (draft-ietf-wimse-aims) is an Informational WIMSE working-group document that profiles existing standards such as WIMSE and OAuth; it does not itself issue credentials or decisions. AEB applies the native decision at the protected provider boundary: it binds the final action when needed, derives one native replay identity per grant, reserves before provider entry, refuses a second attempt at the same action while an earlier one is in flight or uncertain, and keeps an uncertain result locked until authenticated reconciliation.

CAID-04 is used when independently encoded representations must be compared. It is not a mandatory second mapping when the consequence-owning PEP already derives and enforces a current decision over the final operation. AEC-06 is used when the relying party requires several evidence legs. Authorization Receipts, Human Authorization Binding, and Authority Introduction remain available profiles for deployments that need them; they are not prerequisites for every AEB integration. Architecture-03 remains the navigation document.

The consequence-admission guide states the implementation boundary and the cases where AEB is unnecessary. The direct native handoff profile is a repository implementation profile that shows how an existing permit reaches Gate without a second CAID or AEC layer. AEB-07 specifies what such a gateway handoff attests and how the boundary verifies it, but leaves the encoding to deployment pins; it cites a pinned snapshot of this profile as one informative reference encoding. The exact submitted -07 bytes and their publication record are retained in standards/staged/NEXT-AEB-07.

The complete active portfolio is 26 Datatracker records: 21 sole-authored records and five coauthored records, each with its own scope, revision history, and recorded maintenance status. See the standards guide, portfolio, and machine-readable status inventory.

IETF Internet-Drafts	Current local snapshot paths: status inventory · sole-authored posted inventory · authoritative live status: IETF Datatracker
Cross-language verifiers	JavaScript · Python · Go — all three proven to agree on adversarial conformance vectors, every push (npm run conformance). A consistency check across one team's ports, not clean-room independent implementations. Separately, an externally authored from-spec Rust implementation (source public) passes the pinned 16-suite/164-vector bundle and the pinned 359-case hostility campaign under an evaluator-controlled rebuild from an immutable source tree. Its checked-in construction evidence remains implementer-signed, not third-party-attested (signed statement); strict clean-room acceptance waits for the corrected third-party-attested manifest and independently pinned attestor key.
Formal-model evidence	26 bounded TLA+ safety properties held in their configured state spaces; this is not implementation refinement or an unbounded proof · 35 Alloy facts, 32 assertions across four models · two composed symbolic Dolev-Yao models covering challenge, CAID, two approvals, issuer and authority pins, registry view, revocation, consumption, execution, and six dedicated claim boundaries. Twenty Tamarin lemmas verify — 17 all-traces obligations and 3 exists-trace witnesses; eight deliberately weakened variants produce concrete attack traces when load-bearing checks are removed (formal/tamarin/).
MCP distribution	npm package @emilia-protocol/mcp-server · official Registry publication is tracked separately in MCP-REGISTRY.md; aggregator listings are not inferred from either state
License	Apache-2.0

Three same-team reference ports (JS / Python / Go) agree across all 21 suites and 340 vectors. Separately, an externally authored Rust implementation rebuilt from a pinned public source tree passes the pinned 16-suite/164-vector clean-room bundle and a 359-case hostility campaign, re-run in its own CI lane on every change. The newer AEC acceptance and four-outcome resolution suites are not attributed to Rust. That is external interoperability evidence, not strict clean-room construction acceptance; the aggregate CI case records the strict acceptance count as zero pending independent attestation. See CONFORMANCE.md, or verify a receipt yourself at emiliaprotocol.ai/verify.

---

The authority stack

Layer	What it does
Mandate	Defines mission, limits, evidence, expiry, delegation, and exception rules.
CAID / exact action	Compares material meaning when authorization and execution use independently encoded representations; it does not authorize.
AEC	When required, evaluates whether independently verified and matched evidence satisfies the relying party's multi-leg requirement; it does not authorize.
AEB / Gate	Applies the native or local authorization decision at the consequence boundary, reserves the covered authority, and controls provider entry.
Outcome evidence	Keeps invocation, provider response, observed effect, and uncertainty distinct.

---

Proof points

Metric	Value
Automated test cases	10,700+ across 650+ files; all platform-applicable cases must pass
TLA+ safety properties	26 bounded invariants held in the configured state space; not an implementation-refinement or unbounded proof — see PROOF_STATUS.md
Alloy relational assertions	35 facts + 32 assertions across four models — verified in CI
Red-team cases cataloged	86 — RED_TEAM_CASES.md
Release security status	Repository security checks pass; every Strix finding on the audited changes is remediated with regression coverage and its review thread resolved
Conformance (7/7)	node conformance/ep-conformance-test.js https://www.emiliaprotocol.ai
Cross-language conformance	340 vectors · 21 suites: receipts · device signoffs · four-outcome resolution · multi-party quorum · revocation · Outcome Binding (semantic + real-crypto) · Authority Document/Proof issuer join · time-attestation · trust-receipt (x2 profiles) · provenance · evidence-record · canonicalization · boundary · AEC acceptance · currency · initiator-attestation · consumption-proof · witness · timestamp-proof (RFC 3161). JS / Python / Go verifiers agree (node conformance/run.mjs). The external Rust baseline remains 164 vectors / 16 suites. See CONFORMANCE.md.
Handshake create p95	575ms at 50 VUs — PERFORMANCE_PROOF.md

Cryptographic longevity (with explicit deployment boundaries)

Evidence meant to be verified years later must outlive the algorithms it was signed under. EP ships four bounded capabilities for that, each with an exact boundary that is part of the claim:

• Hybrid signatures (EP-RECEIPT-HYBRID-v1). Ed25519 and ML-DSA-65 over the same canonical bytes, with the required algorithm set committed into the signed bytes so stripping a leg breaks the surviving signature. The capability is opt-in at deployment; once an approved dual signer is registered and policy permits its PQ leg, an unpinned Gate posture resolves to dual issuance by default. Otherwise it stays classical-only with a named reason. v1 verifiers refuse hybrid receipts cleanly rather than accepting one leg. The external signer contract and AWS KMS adapter are implemented, but no live AWS signing call, production key, relying-party verification, or ML-DSA FIPS validation is claimed. See conformance/hybrid-receipts/ and lib/pq-custody-aws-kms.ts.
• SCITT Signed Statement profile (EP-SCITT-STATEMENT-v1). A complete RFC 9943 Signed Statement shape for EP receipts, including the CWT Claims protected header. Boundary: no Transparency Service has accepted an EP statement; external registration is a separate, gated step and none has been performed. See EP-RECEIPT-SCITT-PROFILE.md.
• Re-attestation (EP-EVIDENCE-REATTESTATION-v1). Evidence signed under an aging algorithm can be re-anchored under a current one before the old one weakens. Boundary: re-attestation must precede compromise; it cannot repair evidence after the fact.
• FIPS deployment mode (EP-FIPS-MODE-v1). Runs classical operations through an operator-supplied FIPS 140-3 validated provider, with the ML-DSA path gated behind an explicit unvalidated-implementation acknowledgment. Boundary: this earns "FIPS-based algorithms, with a validated-provider deployment mode" and depends on the operator's provider and declared certificate boundary; it is not a blanket compliance claim, and nothing here is FIPS validated. See FIPS-MODE.md.

The stack-wide hybrid program (every internal signature surface) is mapped in pq-hybrid-program.md and is not complete; until it is, no blanket claim about the whole stack is made.

---

Core protocol objects

객체	설명
권한 프로그램 / 경계된 능력	명시적 범위, 예산 또는 단위, 만료, 위임, 소비 규칙을 갖춘 유한한 권한.
CAID	명명된 매핑 프로필 하에서 하나의 구체적 행위에 대한 표준 식별자. 일치가 곧 인가를 의미하지는 않음.
증거 요구사항 및 AEC 결과	신뢰 당사자가 고정한 규칙과 그에 대한 SATISFIED, UNSATISFIED, 또는 INDETERMINATE 평가.
AEB 승인 및 보관 기록	인가, 예약, 제공자 등록, 조정 상태에 대한 실행자 측 기록.
인가 및 결과 증거	발행자, 범위, 주장 경계를 정확히 유지하는 이식 가능한 네이티브 또는 EP 아티팩트.

---

빠른 시작

1. 정확한 로컬 가드 런타임을 설치한 후, npx @emilia-protocol/scan@0.5.0 protect ./tools.json --action sendWire --apply --verify을 실행하고 sendWire를 정확히 선언된 결과적 도구 하나로 교체합니다.
2. 생성된 권한 맵, 행위 매니페스트, 중요 필드, 선택된 경계, 명명된 사각지대를 검토합니다.
3. 별도의 --reviewed --crossing-profile <launch-profile> 명령을 실행하여 변경되지 않은 해당 바이트로 소유자 전용 핸드오프와 봉인 해제된 Lab 워크스페이스를 생성합니다.
4. 제공자 자격 증명과 지속적 소비 상태를 보유한 경로에 Gate를 설치합니다.
5. 운영 권한과 신규 인간 또는 정족수 예외 규칙을 정의합니다.
6. 거부, 정확한 행위, 재생, 시간 초과, 조정 사례를 강제 적용 전에 실행합니다.

90초 데모 · 빠른 시작 · 에이전트 워크스루 · IETF 초안 · Discord

---

EP가 무엇인지 — 그리고 무엇이 아닌지

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

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

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