Security & trust boundaries

Dyade preserves long-lived AI continuity. That continuity can become more sensitive than any individual chat, so the continuity store is treated as a primary high-value asset.

Current beta boundary: Dyade is a hosted service and is not zero-knowledge. Authorized service operators can technically access stored beta data when required for debugging, security, incident response or support. Sensitive enterprise use should wait for the customer-controlled deployment model described below.

Current V1 data flow

Dyade does not currently choose model providers or perform automatic provider fallback. The connected AI host requests continuity and writes observable results back.

Userintent + work AI hostChatGPT / Claude Dyade MCPHTTPS + OAuth Tenant boundarysubject scoped Kerneltrajectory logic Trajectory storeordered causal events Working contextportable derived state Sources / checkpointsexplicitly stored Failure reportsexplicit report only Selected model/providerchosen by host/user Stripesigned inbound webhook Dashed boxes/lines = external or conditional paths. Dyade has no general-purpose outbound model API path in V1.

What is stored

Stored for continuity

  • Hash-linked continuation trajectory
  • Portable working context
  • Explicit checkpoints
  • Linked sources when explicitly ingested
  • Tenant/account and entitlement state
  • Hashed access-code/token material

Not part of V1

  • No hidden chain-of-thought requirement
  • No Dyade-controlled model fallback
  • No general-purpose outbound model router
  • No embedding/vector-store layer in the current hosted continuation path
  • No claim of zero-knowledge storage

Trust boundaries

1. User ↔ AI host

Dyade can only persist material the host exposes through its tool surface. Hidden host state and undocumented compression events are outside Dyade's visibility.

2. AI host ↔ Dyade

Remote HTTPS/MCP with OAuth identity. User-facing continuation operations are scoped to the authenticated tenant.

3. Dyade ↔ hosted database

The database contains sensitive continuity material. Authorized operators can technically access it. This is the major current hosted-beta trust boundary.

4. AI host ↔ provider

The host controls which model/provider receives rehydrated context. Dyade V1 does not silently redirect it to another provider.

Threat model

ThreatCurrent controlResidual / gap
Cross-tenant accessOAuth subject scoping; fail-closed continuation resolutionNeeds continued adversarial isolation testing
Credential theftOpaque OAuth; persisted access codes/tokens are hashedMFA/device binding not yet implemented
Database compromiseHosted access controls + tenant-scoped app queriesCentral high-value target; not per-user customer-key encrypted
Operator misuseAccess is policy-limited to support/security needsFormal operator-access audit ledger and dual-control still needed
Unexpected provider routingNo Dyade provider fallback in V1Future orchestration must add explicit provider/egress authority
Failure-report overcollectionOnly explicit report; separate storeRetention/minimization and operator audit need formalization
Webhook forgeryStripe signature verificationCommercial identity binding remains a surface to harden
Incomplete deletionNo complete workflow yetOpen production blocker
Log/backup leakageContinuity payloads should not be telemetryFormal log/backup inventory and retention policy not yet published

Data use and diagnostics

Beta continuity data is used to provide Dyade and to diagnose failures explicitly reported by the user. It is not used for model training, advertising profiles, sale, or unrelated repurposing.

Explicit report onlySeparate diagnostic storeNo hidden CoTNo model fallbackTenant scoped

Deletion is not solved yet

Dyade V1 does not yet expose a complete user-facing export-and-delete workflow that proves removal across trajectory, working context, sources, checkpoints, failure reports, account linkage and backup/retention paths. Until that exists, Dyade will not claim complete deletion semantics.

Enterprise target: move the boundary to the customer

The target for sensitive enterprise use is self-hosted/customer-controlled operation, not a stronger marketing claim about the hosted beta.

CUSTOMER-CONTROLLED SECURITY BOUNDARY Users / hostsapproved clients Self-hosted DyadeMCP + continuity Customer-owned storecontinuity + keys Egress policy gatewaydeny-by-default allowlist Local/private modelcustomer approved External providerexplicit allowlist only Dyade vendorno data by default

Target requirements: self-hosting, customer-owned storage and keys, customer-owned provider credentials, explicit egress allowlists, no vendor telemetry/data return by default, auditable routing/admin access, export/delete under customer control, and optional fully local model execution.

Security invariants

NO_HIDDEN_PROVIDER_FALLBACK · TENANT_SCOPE_BEFORE_DATA · EXPLICIT_DIAGNOSTIC_CAPTURE · NO_HIDDEN_COT_DEPENDENCY · CONTINUITY_DATA_IS_PRIMARY_SENSITIVE_DATA · DELETE_MEANS_ALL_OWNED_STORES