Dijin is built with privacy-first controls. This policy explains what data is processed, why it is processed, and how users remain in control across memory, translation, note, insight, and context workflows.
1. Data categories
We process only the data required to run the product and support user-requested workflows.
- Account data: email, profile fields, and authentication metadata.
- Workspace data: memory, notes, insights, action items, and user-managed sharing state.
- Service diagnostics: health and security events used to keep the platform reliable.
2. Why we process data
Processing is limited to service delivery, security, and support operations.
- Provide memory and context features you explicitly use.
- Protect accounts, prevent abuse, and maintain service integrity.
- Respond to support requests, troubleshooting, and compliance obligations.
3. Security controls
Dijin applies layered controls for confidentiality, integrity, and access governance.
- Encryption in transit and at rest for managed cloud data paths.
- Role-scoped access controls and auditable service boundaries.
- Periodic security reviews and incident response procedures across all system components.
4. Data sharing boundaries
We do not sell user data. Sharing is limited to explicit product flows and required infrastructure partners.
- User-initiated sharing links and collaboration features.
- Service providers operating under contractual and security obligations.
- Lawful requests where disclosure is legally required.
5. Data retention
Retention windows are aligned with product operations and legal obligations.
- Workspace data remains available until user deletion or account closure.
- Operational and security logs are retained for limited monitoring periods.
- Backup and recovery copies expire under controlled lifecycle policies.
6. User rights and controls
Users can manage their data directly and may request additional rights handling through support.
- Access, correction, export, and deletion controls are available in product flows.
- Account and content removal requests are handled with verification safeguards.
- Region-specific rights (including GDPR/CCPA) are supported through formal request handling.
7. Connector data flow (third-party AI clients)
When you grant a third-party AI client (Claude, ChatGPT, Cursor, Zed, etc.) access to your Dijin memory via the OAuth Connector at dijin.co/oauth/authorize, the following data flow applies. Full technical reference: dijin.co/docs/connector.
- Scope-bound: each connector grant is limited to the specific scopes you select on the consent screen (summaries, evidence snippets, entities, action items, decisions, daily summaries, access log, contradictions, raw source text). Anything outside the selected scopes is refused server-side.
- Raw-source scope is the highest-trust scope (memory.transcript.read.raw). When granted, requests resolve under server-side device confirmation.
- Tamper-evident access ledger: every connector OAuth issuance, scope-denied event, rate-limit hit, and tool call appends a hash-chained row to your audit_logs. You can read it via the connector itself (getAuditLog tool) or via Settings → Privacy → Activity Log.
- Instant revocation: revoking a connector grant from Settings → Privacy → Connected Apps takes effect within one second, the AI client's next request returns token_not_found and is blocked.
- Token hashing: connector access tokens are SHA-256-hashed at rest. The raw token is shown once at issuance time and never stored unhashed. The AI client holds the raw token in its own configuration; if you reset/uninstall the AI client, the token's local copy is gone.
Questions about these terms?
Our support team can help with policy interpretation, compliance requests, and production usage questions.
Contact SupportContinue reading our trust documentation:
Next: GDPR Rights