DRAFT — requires legal review. This privacy policy is an engineering-authored draft describing what data the CybrLink service actually collects, where it lives, and who processes it. It has not been reviewed by a privacy lawyer or data-protection specialist and may not satisfy GDPR, UK GDPR, CCPA/CPRA, or other applicable requirements as written. Do not publish or rely on it until counsel has reviewed it and completed the bracketed placeholders (e.g. [LEGAL ENTITY], [DPO / PRIVACY CONTACT]).

CybrLink — Privacy Policy (DRAFT)

Last updated: 2026-06-12 Status: DRAFT — not legally vetted.

1. Who is responsible for your data

[LEGAL ENTITY] ("CybrLink", "we", "us") operates the CybrLink service: a credential-vault and integration platform that lets you connect third-party accounts once and let AI agents act through them without exposing the underlying credentials. For data we hold about you, CybrLink is the controller; the third-party services we rely on (below) act as processors / sub-processors.

Privacy contact: [DPO / PRIVACY CONTACT EMAIL].

2. The most important thing to understand

CybrLink does not store your third-party provider credentials. When you connect an account (Slack, Gmail, an LLM provider, etc.), the OAuth tokens, API keys, or other secrets for that provider are held in our self-hosted Nango credential vault, never in CybrLink's own database. When an agent you authorize makes a call, CybrLink proxies it through Nango and returns the provider's API response — it never sees or persists the secret itself.

3. What data we store

The following is the complete set of customer data CybrLink persists in its own database (Supabase):

| Category | Examples | Why we hold it | |---|---|---| | Account identity | Name, email address, profile image, which sign-in provider(s) you used (GitHub, Google, email magic link), and a canonical internal user UUID | To authenticate you and tie your keys/connections to one identity | | Authentication records | OAuth account linkage records, session records, single-use email verification tokens | To run sign-in and account linking | | Hashed API keys | A non-secret display prefix (e.g. cbl_a1b2c3d4), a salted keyed hash (HMAC-SHA-256) of the full key, the key's name, allowed providers, created/last-used/revoked timestamps | To verify keys without storing them in recoverable form | | Hashed session tokens | Salted keyed hashes of short-lived agent-session tokens, their expiry, and the key they were minted from | To support the agent-session flow without storing raw tokens | | Connection metadata | Which providers you connected and their status (active / error / expired) | To show your connections and route calls | | Activity log (metadata only) | User, key id, provider, endpoint, HTTP method, status code, outcome, timestamp, and a per-row integrity HMAC | Audit trail, abuse detection, and (future) usage accounting | | Operational data | Rate-limit counters keyed to your account/keys | To enforce rate limits and protect the platform |

What we deliberately do not store

• Provider credentials (OAuth tokens, provider API keys, provider passwords) — these live only in the self-hosted Nango vault.
• Request or response bodies of proxied API calls — the activity log records metadata only, because bodies can contain secrets and personal data.
• Passwords for CybrLink itself — there is no CybrLink password; sign-in is OAuth or single-use magic link only.

4. How we use your data

We use the data above to:

• authenticate you and link your accounts to one identity;
• generate, verify, scope, rate-limit, and revoke API keys;
• proxy authorized API calls to your connected providers;
• maintain an audit trail and detect abuse or security incidents;
• operate, secure, debug, and improve the Service.

We do not sell your personal data, and we do not use it for advertising.

5. Legal bases for processing (where GDPR/UK GDPR applies)

Counsel should confirm and tailor these bases.

• Performance of a contract — to provide the Service you signed up for (identity, keys, proxying connections).
• Legitimate interests — security, abuse prevention, audit logging, and service improvement, balanced against your rights.
• Consent — where required, e.g. optional communications.
• Legal obligation — where we must retain or disclose data by law.

6. Sub-processors

CybrLink relies on the following sub-processors. Each processes only the data necessary for its function. [Counsel/ops to confirm each entity's role, location, and that a Data Processing Agreement is in place.]

| Sub-processor | Role | Data it handles | |---|---|---| | Supabase | Primary database (Postgres) and the canonical-UUID identity store | Account identity, hashed keys, hashed session tokens, connection metadata, activity-log metadata, rate-limit counters. Accessed server-side only via a service-role key under deny-by-default row-level security. | | Nango (self-hosted) | Third-party credential vault and API proxy | Your third-party provider credentials and the API traffic proxied to those providers. Self-hosted by us; it is the only place provider secrets exist. | | Resend | Transactional email delivery | Your email address and magic-link sign-in emails. | | Vercel | Application hosting and edge/serverless compute | Request metadata and any data in transit while the app runs; standard hosting logs. | | Sentry (optional) | Error monitoring and observability | Error and diagnostic data. Configured to avoid capturing secrets and to redact sensitive fields; enabled only if [Sentry is provisioned]. |

We may also rely on the OAuth identity providers you choose to sign in with (GitHub, Google) and on each third-party provider you connect — your use of those is governed by their own privacy policies.

We will update this list before adding or replacing a sub-processor that materially affects your data.

7. Data retention

We keep data only as long as needed for the purposes above. Concrete retention periods are defined in the Retention Policy. In summary:

• Account identity, hashed keys, connection metadata — retained while your account is active; deleted (cascading) when you delete your account.
• Agent sessions — short-lived; expire automatically and are purged after expiry.
• Activity log — retained for a limited window (target: 90 days) then purged.
• Email verification tokens / magic links — single-use, expire in 15 minutes.

8. Your rights

Depending on where you live (e.g. EEA/UK under GDPR, California under CCPA/CPRA), you may have rights to:

• access the data we hold about you;
• correct inaccurate data;
• delete your data ("right to erasure");
• export / portability of your data;
• object to or restrict certain processing;
• withdraw consent where processing is based on consent;
• not be discriminated against for exercising these rights.

Many of these you can exercise directly in the dashboard: view and revoke keys, disconnect providers, and delete your account (which cascades to your keys, sessions, and connection metadata). For anything else, contact [DPO / PRIVACY CONTACT EMAIL]. We aim to respond within the timeframes required by applicable law.

Note on connected-provider data: to delete the credentials and any cached authorization for a connected provider, disconnect it (which removes it from the Nango vault) and, where needed, revoke CybrLink's access from within that provider's own settings.

9. International data transfers

Our sub-processors may process data in [REGIONS — confirm Supabase/Nango/Resend/ Vercel/Sentry hosting regions]. Where data is transferred across borders, we rely on appropriate safeguards (e.g. Standard Contractual Clauses) as required by law. [Counsel to confirm transfer mechanisms.]

10. Security

We apply, among others, the following technical controls (see the security hardening plan for the full set):

• Sign-in is OAuth-first with a canonical internal UUID identity; no CybrLink passwords are ever stored.
• API keys and session tokens are stored only as salted keyed hashes (HMAC-SHA-256 with a server-only pepper); raw secrets are shown once and never persisted. Verification uses constant-time comparison.
• The database is reached only server-side via a service-role key, with deny-by-default row-level security and all access funneled through a user-scoped data-access layer.
• The activity log is append-only with per-row integrity HMACs; request and response bodies are never logged.
• The provider proxy is guarded against SSRF, header injection, and endpoint manipulation, with provider scoping and rate limiting that fails closed.
• Security headers (HSTS, nosniff, frame-deny, CSP frame-ancestors) and HttpOnly/Secure/SameSite session cookies are enforced; errors are sanitized so internals are never exposed.

No system is perfectly secure. In particular, prompt-injection through data an agent reads from a connected provider is an inherent risk of the category that we mitigate but cannot eliminate, and the self-hosted Nango vault is a single point of custody for provider credentials.

11. Children's privacy

The Service is not directed to children. You must meet the eligibility requirements in the Terms of Service (at least 18). We do not knowingly collect data from children.

12. Changes to this policy

We may update this Privacy Policy. Material changes will be reflected by a new "Last updated" date and, where appropriate, additional notice.

13. Contact

Privacy questions or rights requests: [DPO / PRIVACY CONTACT EMAIL].

---

This is a DRAFT prepared by the engineering team to accurately reflect the Service's data handling. It is not legal advice and must be reviewed and completed by qualified privacy counsel before publication.