Security Policy

1. Overview

Security is foundational to the Hippocortex platform. Agent memory contains sensitive operational data, including conversation history, tool interactions, and compiled knowledge. Our infrastructure is designed with defence-in-depth principles to protect the confidentiality, integrity, and availability of all data processed through the Services.

This Security Policy describes the technical and organisational measures implemented by OPENGATE TECHNOLOGY LTD. to protect the Hippocortex platform and Customer Data.

2. Infrastructure Security

2.1 Tenant Isolation

Complete logical isolation is enforced between tenants at every layer of the stack:

• •API layer: Every request is authenticated via Bearer token and resolved to a specific tenant ID. All subsequent operations are scoped to that tenant.
• •Database layer: All PostgreSQL queries include a tenant_id filter. There are no administrative endpoints or queries that bypass tenant scoping. Cross-tenant data access is architecturally impossible.
• •Queue layer: BullMQ job payloads include the tenant ID. Workers validate tenant context before processing any job.
• •Search layer: Semantic vector search is pre-filtered by tenant ID, ensuring results from other tenants are never included in similarity matches.

2.2 Encryption

In Transit

All data transmitted between clients and Hippocortex services is encrypted using TLS 1.3. We enforce HTTP Strict Transport Security (HSTS) headers. Deprecated TLS versions (1.0, 1.1) are not supported. Internal service-to-service communication (API to Redis, API to PostgreSQL) also uses TLS encryption.

At Rest

All stored data, including Customer Data, metadata, and backups, is encrypted using AES-256. Database encryption is managed by our infrastructure provider (Neon) with automatic key rotation. Redis data is encrypted at rest by our provider (Upstash).

3. API Key Security

API keys are the primary authentication mechanism for programmatic access to the Services.

• •Hashing: API keys are hashed with SHA-256 before storage. The plaintext key is displayed only once at creation and cannot be retrieved afterwards.
• •Scoped permissions: Keys support fine-grained permissions (read, write, admin). We recommend creating keys with the minimum required permissions for each use case.
• •Key rotation: You can rotate API keys without downtime by creating a new key before revoking the old one. We recommend rotating keys regularly.
• •Environment separation: Production keys (hx_live_*) and test keys (hx_test_*) operate in separate environments to prevent accidental cross-contamination.

4. Authentication and Access Control

Dashboard access uses JWT-based authentication with the following security measures:

• •Passwords hashed with Argon2id (memory cost: 64 MB, time cost: 3 iterations, parallelism: 4)
• •Access tokens with 1-hour expiry, refresh tokens with 7-day expiry
• •Rate limiting on authentication endpoints: 5 attempts per email per 15-minute window
• •Email verification required for full account activation
• •Password reset tokens with limited validity and single-use enforcement

5. Network Security

Production infrastructure is deployed behind load balancers with the following protections:

• •DDoS protection at the edge through our CDN provider (Vercel)
• •Database connections restricted to application-level network access only
• •Redis access secured with authentication tokens and TLS
• •No direct public access to database or queue infrastructure
• •Secrets managed through environment variables and secret management systems, never stored in code

5.1 Browser Security Headers

All public-facing pages enforce a comprehensive set of HTTP security headers:

• •Content Security Policy: Restricts script execution, resource loading, and frame embedding to explicitly approved origins. Inline styles are permitted for rendering performance; script evaluation is restricted to the domains required by our authentication provider.
• •Clickjacking protection: X-Frame-Options DENY and CSP frame-ancestors 'none' prevent the site from being embedded in iframes on other domains.
• •MIME sniffing protection: X-Content-Type-Options nosniff prevents browsers from interpreting files as a different MIME type.
• •Referrer Policy: strict-origin-when-cross-origin limits referrer information sent to external origins.
• •Permissions Policy: Browser features including camera, microphone, geolocation, and payment APIs are explicitly disabled.
• •HSTS: Strict-Transport-Security with a two-year max-age, includeSubDomains, and preload directives.

6. Rate Limiting and Abuse Prevention

Per-key and per-tenant rate limits protect the platform from abuse and ensure fair resource allocation across all customers. Rate limits are enforced via Redis counters. When limits are exceeded, the API returns HTTP 429 with a Retry-After header indicating the wait time in seconds.

Persistent abuse patterns (repeated rate limit violations, anomalous request patterns, attempts to circumvent quotas) result in automatic key suspension. Severe violations may lead to account termination.

7. Input Validation and Request Hardening

All API inputs are validated against strict schemas before processing:

• •Required fields (type, sessionId, payload) are validated on every capture request
• •Batch requests are limited to 1,000 events maximum
• •SQL injection mitigated through parameterised queries (no string concatenation in database operations)
• •XSS protection through output encoding and Content Security Policy headers enforced across all public-facing pages, restricting script sources, frame embedding, and resource loading
• •Request body size limits enforced at the edge

8. Monitoring and Alerting

The platform includes comprehensive monitoring across all subsystems:

• •Health checks: Continuous monitoring of PostgreSQL, Redis, and worker queue health via the /v1/health endpoint
• •Prometheus metrics: Internal metrics collection for capture throughput, synthesis latency, queue depths, and error rates
• •Alert engine: Configurable alerting for queue backlog growth, failed job accumulation, database connection pool exhaustion, and Redis memory pressure
• •Anomaly detection: Monitoring for unusual access patterns, unexpected traffic spikes, and authentication failures

9. Incident Response

We maintain a documented incident response procedure that includes:

1. 1.Detection: Automated alerting and monitoring systems identify potential security events.
2. 2.Triage: Security team assesses severity and scope within 1 hour of detection.
3. 3.Containment: Immediate measures to limit impact, including key revocation, access restriction, or service isolation.
4. 4.Notification: Affected customers notified within 72 hours of confirmed data breach, as required by GDPR.
5. 5.Remediation: Root cause analysis and implementation of corrective measures.
6. 6.Post-mortem: Documented review of the incident with lessons learned and preventive actions.

10. Data Deletion and Retention

We support GDPR-compliant hard deletion with the following guarantees:

• •Deletion requests processed within 30 days of receipt
• •Deletion propagated to all storage layers, including database replicas and backups, within 90 days
• •Audit trails maintained for deletion operations
• •Deletion confirmation available upon request

11. Vulnerability Disclosure

We maintain a responsible vulnerability disclosure programme. Security researchers and users who discover potential security issues should report them to:

security@hippocortex.dev

Our disclosure commitments:

• •Acknowledge reports within 48 hours
• •Provide status updates every 5 business days during investigation
• •We will not take legal action against researchers acting in good faith
• •We request that you do not publicly disclose the vulnerability until we have had an opportunity to address it
• •We request that you avoid accessing or modifying other users' data during testing

12. Compliance

Our security practices are aligned with the following standards and regulations:

• •UK GDPR and EU GDPR: Full compliance with data protection regulations, including data minimisation, purpose limitation, and data subject rights.
• •SOC 2 readiness: Controls aligned with SOC 2 Type II trust service criteria for security, availability, and confidentiality. Formal audit planned.
• •Penetration testing: Regular third-party penetration testing of the API and infrastructure. Results and remediation plans available to Enterprise customers under NDA.

13. Contact

For security-related inquiries or to report a vulnerability: