Security and Data Privacy

Below you’ll find the details of how we protect your information today—and the steps on our public roadmap as we move from alpha into a fully audited, production‑grade platform.

​

Our Commitment at a Glance

​

What Data We Collect & Why

​

How We Protect Your Credentials (Plaid Tokenisation)

Connections are created through Plaid’s OAuth/token flow. The short-lived public token is exchanged for a long-lived access token and written straight to our secrets vault, where it is encrypted at rest with AES-256 under a dedicated key in our cloud KMS.

No human operators have read access to these secrets. All data access after that occurs through Plaid’s encrypted API, so raw credentials remain with the bank.

​

Data Encryption & Storage

• In transit: All external traffic is forced over HTTPS. We allow only TLS 1.2+ with forward-secret cipher suites and add the Strict-Transport-Security header so browsers automatically return over HTTPS.

• At rest: Customer data lives on server-side–encrypted storage, protected with AES-256 keys managed by our cloud provider’s state of the art key-management service; backups and snapshots inherit the same encryption.

• Back‑ups: Encrypted, geo‑redundant, with automated integrity checks and a 30‑day retention.

​

Access Controls & Monitoring

• Least privilege & RBAC: IAM roles are scoped to the minimum set of resources and rotated quarterly.

• Multi‑factor authentication: Required for all console and GitHub access; SSO for all employees.

• Audit logging: Every action in our production environment is captured in a tamper-evident ledger. Logs are immutable, retained for 12 months, and continuously analyzed for anomalies.

​

Secure Development & Pen Testing

• CI/CD security gates: Every build must clear static analysis in SonarQube and automated dependency-vulnerability scanning; pipelines halt on any critical finding.

• Secrets management: Source code contains no secrets—runtime credentials are injected from our cloud secrets vault.

• External penetration tests: Conducted twice per year; summary reports available to customers under NDA starting July 2025.

​

Privacy by Design & De‑Identification

Before any prompt or transaction detail is used to fine‑tune models or build product analytics, we:

1. Strip direct identifiers (names, account numbers, email addresses).

2. Hash customer IDs with salt; map to pseudonyms.

3. Aggregate across at least ten (k ≥ 10) organisations.

4. Apply differential‑privacy noise (ε ≤ 1) to sensitive counts so no single user or company can be reverse‑engineered.

​

Compliance & Roadmap

​

Responsible AI & Model Training

Clove trains internal language models only on anonymised, aggregate telemetry or publicly available data. We do not feed raw customer statements or prompts into third‑party foundation models.

All training jobs run in isolated VPCs with encrypted object storage. Our ML governance framework follows NIST AI Risk Management Framework 1.0.

​

Incident Response & Reporting

We operate a 24×7 on‑call rotation and commit to notify affected customers within 24 hours of confirming a breach of customer data. Monthly tabletop exercises ensure readiness. Our full Incident Response Plan is available on request.

​

Your Controls & Choices

• Granular permissions: Disable analytics, revoke bank tokens or delete data in one click (Settings → Privacy).

• Right to be forgotten: We will delete all personal data within 30 days of request or account closure.

• Audit logs export: Enterprise plans can export six months of access logs via API.