Legal / Compliance

SOC 2 controls posture.

An honest mapping of Hydrate's security controls against the AICPA's Trust Services Criteria (TSC). This is a self-assessment, not a certified SOC 2 Type II report. Enterprise customers requiring a formal attestation should contact us.

Version 1.0 · Effective: 2026-04-25 · Next review: 2027-04-25 · Owner: Seamus Waldron, Sedasoft Ltd

Certification status: not yet certified. Hydrate is in a pre-certification stage. Formal SOC 2 Type II certification requires an independent AICPA-registered auditor to evaluate controls over a minimum observation period (typically 6 months). We are tracking the criteria below to be audit-ready. Enterprise customers with a hard SOC 2 requirement should contact [email protected] to discuss timelines.

Why our architecture reduces the SOC 2 surface

SOC 2 scope is determined by what data the service provider holds and processes. Hydrate's local-first design shrinks this surface materially:

Free and Pro tiers: All session data and extracted facts are stored exclusively in ~/.hydrate/ on the user's own machine. Sedasoft holds no session content, no extracted facts, and no conversation history. The SOC 2 scope for these tiers is limited to the software distribution pipeline and the Stripe billing integration.
Team tier: Team canon is stored in the team's own git repository. Sedasoft does not process or hold team facts. The scope remains the distribution pipeline.
Hydrate Enterprise: Deployed on-premise on the customer's own infrastructure. Sedasoft holds no customer session data. The broader set of controls documented below apply to this tier.

A traditional SaaS SOC 2 audit covers the provider's cloud infrastructure where customer data is processed. Because Hydrate does not process customer session data on Sedasoft infrastructure in any tier, the relevant SOC 2 controls are narrower than for a cloud-hosted service. The controls documented here cover the software itself, the distribution infrastructure, and the practices around development and operations.

CC1: Control Environment

CC1.1: Values and ethics

Implemented

Acceptable use and prohibited deployment constraints are documented in the Enterprise Terms of Service and the EU AI Act assessment. Responsible disclosure policy is published at /.well-known/security.txt.

CC1.2: Board oversight

Partial

Sedasoft is a two-person company at this stage. Security decisions are made by the founding team and documented in the incident log and policy versions. Formal board governance does not apply at current scale.

CC1.3: Competent personnel

Implemented

Security policy, incident response plan, and compliance documentation are authored and maintained by the founding team. No contractor or third-party contributor has access to production infrastructure or customer data.

CC1.4: Accountability

Implemented

Named individuals own each compliance document. Access review records identify who holds which production credentials. Offboarding revokes access within 24 hours.

CC1.5: Enforcement

Partial

Policy exceptions require documented approval and a time-bound compensating control. No formal disciplinary framework at current team size.

CC2: Communication and Information

CC2.1: External information

Implemented

Privacy policy, EU AI Act assessment, data handling document, and this controls posture are published at gethydrate.dev/compliance.

CC2.2: Internal communication

Implemented

Security policy and incident response plan are version-controlled in the website repository. Changes are reviewed before publication. On the Team tier, the GET /api/v1/team/{team_id}/conflicts endpoint surfaces contradictory conventions between team members — identifying which contributor wrote each conflicting fact and in which category — so anomalies in the shared knowledge base are actively communicated to managers rather than silently injected into AI sessions.

CC2.3: Incident notification

Implemented

Incident response plan specifies user notification within 72 hours for GDPR-reportable incidents, with template communications. See Incident Response.

CC3: Risk Assessment

CC3.1: Risk identification

Implemented

Seven risks assessed with inherent and residual likelihood × impact scores in Risk Assessment. Covers secrets capture, prompt injection, SSRF, supply chain, unauthorised API access, data retention, and EU AI Act reclassification.

CC3.2: Risk analysis

Implemented

Each risk has documented mitigations, residual score, and a treatment action. Annual review cadence.

CC3.3: Change risk

Partial

New features are reviewed informally against risk categories. No formal pre-release risk gate beyond govulncheck and CI tests.

CC3.4: Fraud risk

Partial

Payment processing is fully delegated to Stripe. No internal payment handling; fraud risk at the application layer is minimal. No formal fraud risk assessment.

CC4: Monitoring Activities

CC4.1: Performance monitoring

Implemented

The Enterprise server exposes Prometheus metrics at /metrics covering HTTP latency, RAG query duration, OpenAI API calls, and user memory maintenance operations. Health at /health and /ready. On the Team tier, inline conflict detection (DetectInlineFacts) runs on every context-preview request and flags same-subject, same-category facts with divergent content before they are injected into an AI session. The GET /api/v1/team/{team_id}/conflicts endpoint provides a 30-day rolling view of cross-contributor convention conflicts, attributed by source email, for manager review.

CC4.2: Deficiency evaluation

Partial

Monitoring is implemented; formal SLO thresholds and automated alerting are not yet configured. Deficiencies are identified reactively via on-call review. Known gap: conflict detection events are not persisted — the 30-day conflicts query has no permanent audit record of when a conflict was first detected or how it was resolved.

CC5: Control Activities

CC5.1: Control selection

Implemented

Controls are documented in the security policy, incident response plan, data handling document, and vendor risk document. Each is linked to the relevant TSC and reviewed annually.

CC5.2: Technology controls

Implemented

Rate limiting (100 req/min), input size limits (10 MiB body), UUID parsing, parameter validation, secrets scrubbing, and injection defence framing are all implemented in the application layer.

CC5.3: Policies and procedures

Implemented

Security policy, data handling policy, incident response plan, and vendor risk policy are published and version-controlled.

CC6: Logical and Physical Access Controls

CC6.1: Access provisioning

Implemented

Named access only. Least-privilege provisioning. Quarterly access review. Offboarding revokes access within 24 hours and rotates shared credentials.

CC6.2: Restricting access

Implemented

The Enterprise server enforces API key + JWT authentication on all /api/v1/* routes. Role-based access control (read / write / admin) and connector-scoped access. Hydrate-server enforces a per-server API key on all write-path endpoints.

CC6.3: Third-party access

Implemented

Third-party access is limited to the LLM and embedding provider APIs, which receive only the data the user's own API key authorises. No third party has access to Sedasoft's production infrastructure. Vendor risk is documented in Vendor Risk.

CC6.4: Encryption in transit

Implemented

The Enterprise server enforces HSTS (Strict-Transport-Security: max-age=63072000; includeSubDomains). All external API calls (OpenAI, Anthropic, Voyage) use HTTPS. Hydrate-server uses HTTP on localhost only by default; remote Enterprise deployments are expected to operate behind TLS termination (load balancer or reverse proxy).

CC6.5: Encryption at rest

Partial

Hydrate Free/Pro fact and session data is encrypted at rest using AES-256-GCM field-level encryption. Hydrate Enterprise can be configured with HYDRATE_STORAGE_MODE=plain for auditable-at-rest deployments. Enterprise server PostgreSQL data is not encrypted at the column level; encryption at rest depends on the customer's storage layer (OS-level disk encryption, cloud provider encryption). macOS FileVault is enabled on all developer devices.

CC6.6: Threat and vulnerability management

Implemented

govulncheck runs on every CI build and blocks release on known vulnerabilities. CVSS ≥ 9.0 patched within 7 days; High within 30 days. SHA-256 checksums on published binaries.

CC6.7: Physical access

Implemented

Development devices use full-disk encryption (macOS FileVault). Devices are locked when unattended. The production deployment server is physically secured; remote access requires device authentication; SSH is not exposed to the public internet.

CC6.8: Preventing unauthorised use

Implemented

Application-layer rate limiting (100 req/min per IP/API key), input size limits, CORS restrictions, Content-Security-Policy: default-src 'none', X-Frame-Options: DENY. No WAF deployed.

CC7: System Operations

CC7.1: Vulnerability detection

Implemented

govulncheck on CI. Responsible disclosure channel at [email protected] with 48-hour acknowledgement SLA.

CC7.2: Monitoring for anomalies

Partial

Prometheus metrics and structured audit logs are in place. Automated alerting on anomalous patterns is not yet configured.

CC7.3: Incident response

Implemented

P1-P4 severity classification, five-step response procedure, GDPR 72-hour notification obligation, and incident log format are documented in Incident Response.

CC7.4: Recovery

Partial

Hydrate Enterprise server deployment procedure is documented (binary copy + Docker restart). Recovery time objective is not formally tested. Business continuity plan is not yet written.

CC7.5: Disclosure

Implemented

Incident response plan specifies user and regulator disclosure procedures. Contact address published.

CC8: Change Management

CC8.1: Change authorisation

Implemented

All changes are committed to Git. CI runs govulncheck, build tests, and unit tests before release artifacts are produced. Binary signing and SHA-256 checksums are attached to all releases.

CC8.2: Infrastructure change

Implemented

Docker images are rebuilt from updated base images before deployment. Deployment procedure documented in CLAUDE.md. Rollback procedure is binary replacement.

CC9: Risk Mitigation

CC9.1: Risk mitigation activities

Implemented

Seven risks with mitigations and residual scores are documented in Risk Assessment. Key controls include secrets scrubbing, injection defence framing, SSRF endpoint validation, govulncheck, rate limiting, and eligibility gating on fact extraction.

CC9.2: Vendor risk management

Implemented

DPA status, sub-processor lists, breach notification SLAs, and risk ratings for OpenAI, Anthropic, Cloudflare, and GitHub are documented in Vendor Risk. Annual review cadence.

Acknowledged gaps (as of 2026-04-25)

The following items are not yet in place. They are documented here as part of our commitment to an honest assessment rather than a curated checklist.

Independent audit

No AICPA-registered auditor has assessed these controls. This self-assessment does not constitute a SOC 2 Type I or Type II report.

Target: 2027 (Enterprise pipeline dependent)

Penetration test

No third-party penetration test has been conducted. Responsible disclosure channel is open; no confirmed external findings to date.

Target: within 12 months of Enterprise GA

Automated alerting

Prometheus metrics and audit logs are in place but no automated alerting rules or SLO dashboards are configured. Monitoring is currently reactive.

Target: Q3 2026

Business continuity plan

Recovery procedures exist for Enterprise server deployment but no formal BCP or RPO/RTO targets are documented.

Target: Q3 2026

Enterprise server database encryption at rest

PostgreSQL tables in the Enterprise server are not column-encrypted. Encryption at rest depends on the customer's infrastructure (OS disk encryption or cloud storage encryption). Enterprise customers deploying in a regulated context should enable OS-level or cloud-provider encryption.

Recommendation: use OS-level encryption; column encryption is on the roadmap

Multi-factor authentication for internal systems

GitHub and Cloudflare accounts use hardware security keys (FIDO2). Production SSH access uses Tailscale device authentication. No additional MFA layer on the API itself.

Already partially addressed; no planned change

Enterprise customers

Enterprise customers who require a formal SOC 2 Type II report as a procurement condition should contact us before signing. We can discuss the current controls posture, the certification roadmap, and compensating controls that may satisfy specific requirements in the interim.

[email protected]: Enterprise sales and pre-sales
[email protected]: Compliance and legal

Version 1.0 · This is a self-assessment, not a certified audit report. Controls are reviewed annually. Next review: 2027-04-25.