Embassy Trust Protocol (ETP)
·
v0.3.4
·
Reference implementation (non-authoritative)
Security & Data Handling
Data Minimization
- No conversation storage
- No prompt/content logging
- No raw identity token storage
- Ledger stores minimal event metadata (hashed identity + decisions)
- Rate limiting is enforced per verified identity hash
Privacy
- Agent identities are hashed with salt before storage
- Public ledger shows only aggregate statistics, no individual data
- No cross-agent correlation possible from ledger data
Authority and Trust
Central Authority Required
Only Embassy-issued visas provide verifiable issuance. Decentralized forks cannot provide the same verifiable issuance.
Central authority provides:
- Accountability: Single point of responsibility for visa issuance and enforcement
- Verification: Cryptographic signatures from known, audited key infrastructure
- Consistency: Uniform policy enforcement across all issuances
- Audit: Centralized ledger provides evidence for compliance and legal verification
- Enforcement: Ability to revoke and blacklist at scale
Why Forks Cannot Provide Authority
- No recognized trust root for signature verification
- No legal accountability or terms of service
- No centralized audit trail for compliance
- No consistent policy enforcement
- No commercial support or SLA
Service Posture
The Embassy service provides:
- Clear terms of service and service boundaries
- Audit receipts for legal and regulatory compliance
- Professional support and incident response
- Commercial service agreements (commercial service)
Local builds and forks are provided as-is with no warranties or service agreements.
Security Practices
- All API endpoints require identity verification
- Rate limiting prevents abuse
- Time-limited visas with automatic expiration
- Revocation capability for all issued visas
- Security headers enforced on all responses
Back