Security & Data Handling

Data Minimization

No conversation storage
No prompt/content logging on the public verification surface
Claim receipts can carry content hashes instead of raw content
Public ledger and status surfaces expose minimal verification context
Receipts are customer-owned by default unless custody is explicitly enabled
Rate limiting is used to reduce abuse on exposed surfaces

Privacy

Public verification is designed around signed artifacts, not hidden model state
Public ledger surfaces expose aggregate or minimal status information
Customer-owned receipts reduce default Embassy-side data custody

Authority and Trust

Embassy trust root is operated, not ambient
Embassy-issued artifacts are only authoritative when they chain back to the Embassy-operated trust root. Forks and local builds can demonstrate protocol behavior, but they do not represent the same operated service boundary.

The operated trust root provides:

Accountability: A visible operator and a defined service boundary for authoritative issuance
Verification: Cryptographic signatures from a known trust root
Consistency: One operated issuance surface for artifacts that need to be recognized later
Audit: Signed receipts and ledger evidence for later verification and review
Revocation: Ability to revoke or refuse authoritative artifacts at the service layer

Why Forks Cannot Represent The Same Authority

No shared operated trust root for signature verification
No shared operator contact or service boundary
No shared revocation surface for artifacts already issued
No shared receipt and ledger context for later review
No guarantee they map to the same service posture buyers are evaluating

Service Posture

The Embassy service provides:

Clear operator contact and service boundaries
Signed receipts for later verification, disputes, and internal review
Public documentation and verification endpoints for independent checking
Authoritative services operated separately from the public reference surface

Local builds and forks are provided as-is with no warranties or service agreements.

Security Practices

Protected endpoints require the appropriate auth or request context
Rate limiting is used to reduce abuse on exposed surfaces
Time-limited artifacts can expire automatically where the protocol uses expiry
Issued artifacts can be checked for status and revocation where supported
Public verification remains separate from policy judgment

Back