EMILIA Protocol — Watchlist

MCP100 Assessment

Watchlist / Tracking

Why we’re tracking it

Follow authorization and protocol interoperability because identity policy is central

Reviewed Oct 5, 2026 · Documentation review; complete setup workflow not independently tested

Best fit

Authorization evidence, bounded authority and replay-resistant approval for high-risk agent actions

What we know

Standards/protocol portfolio for action-bound human authorization receipts, authority introduction, bounded capabilities and evidence-chain verification around consequential agent actions.

Maintenance / activity evidence

Observed Oct 4, 2026 (UTC)Merge pull request 877 from emiliaprotocol/automation/volatile-evide…

Tracking evidence observed Oct 5, 2026. These dated signals do not establish current maintenance. Reviewed enrichment confidence: high.

Activity source · commits ↗Activity source · releases ↗

Verification gaps / watch-outs

Installation and comprehensive security have not been independently audited.
Defines scoped authority/evidence semantics rather than owning an application's permissions. Writes: No direct execution surface in the standards repository.
Implementation-specific cryptographic identities/approver keys.
Sensitive access: Authorization evidence, Approver identity/proof material

The protocol is a security/governance layer for consequential actions, not a payment product; classify by authorization and compliance role.

Security source · repository notice ↗Security source · policy file ↗

Full authority, access and evidence limits are available in Review context and Access & risk.

Popularity

615 repository stars

Stars observed Sep 25, 2026.

Preserve any already-reviewed adoption metrics in MCP100. Batch 4 did not refresh package downloads because the package-stats provider had insufficient credits.

All limitations / Review context

Which authorization flows and MCP gateway integrations does the current protocol support?

The bounded assessment reviewed the official README, repository notices, security policy path, and security page for known material public-tracking blockers. No such blocker was identified. This is a public-tracking assessment, not an installation safety certification.

The protocol is a security/governance layer for consequential actions, not a payment product; classify by authorization and compliance role.
Defines scoped authority/evidence semantics rather than owning an application's permissions.
Implementation-specific cryptographic identities/approver keys.
Receipts/evidence chains are designed to be verifiable and replay-aware; application data handling is implementation-specific.
Reviewed write actions: No direct execution surface in the standards repository
Sensitive access: Authorization evidence, Approver identity/proof material
Installation, client compatibility and comprehensive security have not been independently audited. Authentication and access depend on the configured services.
No independent runtime, installation, or comprehensive security audit was performed.
No installation, runtime, client matrix, or complete tool-contract audit was performed in this review.
Evidence is not itself execution, legality or safety.
Multiple drafts/profiles have distinct responsibilities and should not be collapsed into one generic 'permission' claim.

Original activity observations

2026-10-04T21:56:10Z: Merge pull request 877 from emiliaprotocol/automation/volatile-evide…

Technical identity

github.com/emiliaprotocol/emilia-protocol

Exact implementation source: https://github.com/emiliaprotocol/emilia-protocol ↗
Reviewed resource type: Framework
Repository identity: emiliaprotocol/emilia-protocol

Evidence & Sources

Evidence basis: Recorded source evidence
Setup runtime verification: Not independently runtime-tested by MCP100 for this setup workflow.

Reviewed Oct 5, 2026 · Latest source observation Oct 6, 2026

GitHub repository ↗
emiliaprotocol/emilia-protocol
Recorded repository material and project history.
Includes references whose attribution is not established.

Setup · Watchlist

Framework setup

Publisher instructions.

Source evidence observed Oct 13, 2026.

Additional setup details required — see the specific gaps below.

Warning

Payment authority and signed approvals are sensitive.
Requires review of install side effects, credentials, remote scripts, or privileged application/database access before execution. Multiple publisher-documented README steps combined as an ordered excerpt; not a verbatim single publisher code block.
Do not destroy production authority maps, signed receipts or key material; the sample is distinct from deployed guard services.
Exact vendor-specific credential revoke procedure not established from checked official Setup documentation; may be external or not applicable. Do not invent.
Repository is SDK, examples, protocol or sunset service rather than a normal single MCP stdio install. Do not fabricate client registration.
Not a typical standalone MCP server installation; the product documentation does not establish a universal MCP host setup. Do not infer one.

Install / connect
Publisher instructions
Publisher-specific setup path. Follow prerequisites, then register or connect to your MCP host.
publisher documented install or connect · Publisher instructions · Review before use
```
git clone https://github.com/emiliaprotocol/emilia-protocol.git
cd emilia-protocol
node examples/mcp/payment-server.mjs
```
Configure / authenticate
Publisher instructions
EMILIA Protocol includes several protected MCP EXAMPLES, not one package-wide server. Select examples/mcp/payment-server.mjs, github-admin.mjs, or prod-deploy.mjs and wire that specific demo into a client.
Check connection
Suggested check
Use the documented policy dry run/`node emilia/verify-setup.mjs` after `npx @emilia-protocol/scan protect ./tools.json --apply` in a prepared integration; the generated check uses synthetic state.
Remove / uninstall / revoke
MCP100 setup guide
Stop the selected example process and remove its MCP host entry. Removing the whole repository is optional and not a credential revocation.

Official Documentation & Sources

What it does

Standards/protocol portfolio for action-bound human authorization receipts, authority introduction, bounded capabilities and evidence-chain verification around consequential agent actions.

Capability: Security & Testing
Resource type: Framework
Industry: Legal & Compliance, Cybersecurity
Best fit: Authorization evidence, bounded authority and replay-resistant approval for high-risk agent actions

Representative uses

Bind a named human approval to an exact action
Create verifiable authorization receipts
Compose authorization evidence chains
Gate high-risk actions before execution

Limitations

Evidence is not itself execution, legality or safety.
Multiple drafts/profiles have distinct responsibilities and should not be collapsed into one generic 'permission' claim.

Reviewed access

Access & risk

Review the exact access boundary before connecting this MCP to accounts, credentials, or sensitive data.

Authentication: Implementation-specific cryptographic identities/approver keys.
Permissions: Defines scoped authority/evidence semantics rather than owning an application's permissions.
Data handling: Receipts/evidence chains are designed to be verifiable and replay-aware; application data handling is implementation-specific.
Cost: free
Risk and cautions: The protocol is a security/governance layer for consequential actions, not a payment product; classify by authorization and compliance role.

Access scope and cautions

Write actions: No direct execution surface in the standards repository
Sensitive access: Authorization evidence Approver identity/proof material
Risk level: moderate

FAQ

Based on reviewed evidence as of 2026-10-06. Watchlist tracking is not a recommendation or a security certification.

Which tasks are documented for this implementation?

The reviewed tasks include: Bind a named human approval to an exact action; Create verifiable authorization receipts; Compose authorization evidence chains; Gate high-risk actions before execution.

What setup and authentication are documented?

A complete connection procedure is not verified. Client notes: This is a protocol/standards resource, not a standalone MCP server. These facts do not supply missing installation commands, credentials or a verified authentication procedure. Authentication: Implementation/relying-party specific.

Can it modify data or perform write operations?

Documented write actions include: No direct execution surface in the standards repository. Recorded permission boundary: Defines scoped authority/evidence semantics rather than owning an application's permissions.

What data-handling boundary should I consider?

Receipts/evidence chains are designed to be verifiable and replay-aware; application data handling is implementation-specific. Recorded sensitive-access context: Authorization evidence; Approver identity/proof material.

What limitations and risks should I check before use?

The protocol is a security/governance layer for consequential actions, not a payment product; classify by authorization and compliance role. Evidence is not itself execution, legality or safety. Multiple drafts/profiles have distinct responsibilities and should not be collapsed into one generic 'permission' claim. No independent runtime, installation, or comprehensive security audit was performed.

Is this an official MCP?

EMILIA Protocol is listed as First-party MCP in MCP100’s current evidence.