Grounds

Legal

Security Addendum

Last updated August 5, 2026. Plain text, Word

This Security Addendum ("Security Addendum") describes the technical and organizational measures Owndevice, Inc. ("Grounds") applies to the Grounds service. It supplements the Terms of Service and our Data Processing Addendum (available on request from legal@grounds.ai; the controls described here expand on Annex II of the DPA). Capitalized terms not defined here have the meaning given in the Terms.

1. Identity and access

  • End-user identity, sessions, and organizations are managed by Clerk. Multi-factor authentication is enforced for all administrator accounts and is available to every user.
  • Internal access to production systems follows least-privilege principles: production access is limited to a single vetted engineer (the founder), with no shared accounts and short-lived credentials where supported. Access is reviewed whenever personnel or vendor access changes.

2. Encryption

  • In transit: TLS 1.2 or higher for all client and inter-service connections. HSTS is enabled on public hostnames.
  • At rest: AES-256 encryption for Supabase Postgres storage and managed backups.
  • Sensitive fields — document text, AI outputs, and titles — are additionally encrypted at the application layer with per-firm AES-256-GCM keys before they reach the database; the key-encryption key is held outside the database. Where the AI Agent is configured, its authentication subkeys are wrapped with AWS KMS.

3. Tenant isolation

  • Every record in the primary data store carries a tenant identifier tied to the Clerk organization. The API layer enforces tenant scoping on every read and write.
  • Row-level security (RLS) is enabled on all public tables, and the database API's grants to the anonymous and authenticated roles were revoked as part of an August 2026 database hardening. RLS operates as defense-in-depth alongside the application-level tenant checks above.
  • AI inference contexts (prompts, retrieved documents, embeddings) are constructed within a single tenant scope. Embeddings are partitioned by tenant in the vector store.

4. Logging and monitoring

  • Application logs carry structured fields for tenant, user, and request id. An append-only application audit log (authentication events, document uploads and downloads, portal and AI activity, admin changes) is stored in the primary database and retained for the life of the account.
  • Edge request metadata (not request bodies) is captured by Cloudflare and retained per its standard log retention.

5. Vulnerability management

  • Dependency versions are exact-pinned through committed lockfiles, and advisories are reviewed with ad-hoc npm audit scans.
  • A workspace-wide minimum-release-age of 7 days is enforced on every package installation to defend against typosquatting and account-takeover supply-chain attacks. Lifecycle scripts are disabled by default and re-enabled only for packages whose postinstall behavior has been reviewed.
  • Critical-severity advisories on direct dependencies are triaged and patched on a best-effort priority basis, typically as soon as a fixed release clears the minimum-release-age window.

6. Application security

  • Input validation at the API boundary using strongly-typed schemas generated from the wire spec.
  • LLM prompt-injection mitigation: untrusted content that arrives through the wire protocol (the "received_message" payload) is never folded into a system or assistant prompt role. It is presented to the model as user-role, attributed content with a structural barrier — see packages/llm/src/prompt.ts for the implementation.
  • Output encoding and content security policies on the marketing and app surfaces to mitigate XSS risk.
  • Rate limiting at the edge (Cloudflare) and at the API layer to mitigate abuse and brute force.

7. Backup and disaster recovery

  • Daily encrypted Postgres backups taken by our database provider (Supabase), retained on a rolling basis up to 35 days.
  • Recovery objectives will be published after our first timed restore rehearsal.

8. Incident response

  • Incident response is handled directly by the founder-engineer. Support is provided during business hours, with best-effort response outside business hours for production-impacting issues.
  • Customer notification within 72 hours of a confirmed personal-data breach, consistent with Section 8 of our Data Processing Addendum (available on request).
  • A written post-mortem is produced within 14 business days of any incident, with action items and owners.
  • Customers may report suspected security issues to security@grounds.ai.

9. Personnel

  • Grounds is operated by its founder, a licensed attorney bound by professional duties of confidentiality. No other personnel currently hold access to production systems or customer content.
  • Before any future personnel or contractor is granted production access, they will be subject to a written confidentiality agreement and security onboarding covering AI-specific risks (prompt injection, data leakage, agent misuse).

10. Vendor management

  • Every Subprocessor — see the Subprocessors page — is reviewed before adoption, including its security posture and data-processing terms, and re-reviewed when its role or terms materially change.
  • Inference partner contracts (currently AWS Bedrock) include zero-retention and no-training commitments.

11. Security testing

Internal security review is continuous: authentication, tenant isolation, and data-handling code paths are reviewed as part of development, and findings are tracked to remediation in an internal security log. A summary of our current security posture is available to customers on request under NDA.

12. Sensitive-data posture

Grounds is built for contract content. That content frequently includes sensitive commercial information — deal economics, litigation exposure, M&A diligence — and, for law-firm customers, privileged attorney-client communications and work product. The controls described above apply to that content, and the Law-Firm Confidentiality Addendum adds additional protections for matter content.

The Service is not designed for and customers must not upload:

  • Protected Health Information (PHI) subject to HIPAA, unless the parties have a signed Business Associate Agreement (we do not currently offer one).
  • Cardholder data subject to PCI DSS (raw card numbers, magnetic stripe data, CVV).
  • Child sexual abuse material (CSAM) — see the AUP.
  • Government-issued credentials (driver's license numbers, passport scans, full SSNs) beyond what is incidentally present in a contract or signing block.

13. Compliance roadmap

Grounds is on the SOC 2 Type II readiness path. We are not yet certified. Customers on enterprise plans may request our current unaudited security questionnaire and SOC 2 readiness summary under NDA at security@grounds.ai. We expect to publish a first SOC 2 Type I report by the end of 2026 and to begin a Type II observation window thereafter; this is a forward-looking commitment, not a guarantee of timing.

14. Changes

We will post any material change to this Security Addendum here and notify active customer administrators at least 30 days before the change takes effect. Reductions to a customer's protections require explicit customer consent.

15. Contact

Questions about security? security@grounds.ai.