Skip to main content
Watch a DemoStart Free
Home›Docs›Security & Compliance›Security overview
Security & Compliance

Security overview

How Perceive8 protects customer data, encryption, access controls, and security review cadence.

Security overview

Version: 1.0
Last Reviewed: 2026-03-07
Review Cadence: Quarterly
Classification: Public — Customer-Facing
Owner: Perceive8 Engineering & Security

Table of Contents

  1. Security Philosophy
  2. Infrastructure Security
  3. Application Security
  4. Data Security
  5. API Security
  6. Operational Security
  7. Compliance & Certifications
  8. Vulnerability Management
  9. Employee Security
  10. Third-Party Security
  11. Security Disclosure Policy
  12. Contact Information

Security Philosophy

Perceive8 processes sensitive audio data — meeting recordings, conversations, and real-time streams — that our customers trust us to protect. Our security approach is built on four principles:

  1. Defense in Depth: Multiple overlapping security controls at every layer — network, application, data, and operational.
  2. Least Privilege: Every user, service, and API key receives only the minimum permissions required.
  3. Transparency: We are honest about our current security posture, including areas where we are actively improving.
  4. Continuous Improvement: Security is not a destination. We maintain a living roadmap of security enhancements and review it quarterly.

We recognize that as a growing platform, our security program is maturing. This document reflects our current controls honestly and identifies areas where we are investing in improvements.

Infrastructure Security

Hosting & Deployment

Component Provider Details
Application API Railway Containerized deployment, isolated environments
Database Supabase Cloud Managed PostgreSQL with Row-Level Security, pgvector embeddings
Object Storage Supabase Storage S3-compatible audio file and artifact storage
API Gateway Managed gateway Reverse proxy, rate limiting, request routing
Edge Functions Supabase Functions Isolated serverless execution

Network Isolation

  • All services communicate over private networks where possible.
  • Database connections are restricted to application services — no direct public access.
  • A managed API gateway serves as the single public entry point, enforcing routing rules and rate limits before requests reach application services.

DDoS Protection

  • Rate limiting enforced at two layers: gateway-level and application-level middleware.
  • Per-endpoint and per-key rate limiting enforced.
  • Pagination caps prevent resource exhaustion via large queries.
  • Per-user concurrent WebSocket stream limits prevent streaming resource abuse.

Container Security

  • Application containers are built from minimal base images.
  • Containers run with non-root users where supported.
  • Docker images are rebuilt on each deployment to incorporate latest base image patches.

Application Security

Authentication

Perceive8 supports multiple authentication methods to serve different integration patterns:

Method Use Case Details
JWT Bearer Tokens Dashboard & user sessions Supabase-issued, HS256 signed, audience-validated (authenticated), expiry-enforced
API Keys Server-to-server integrations pk_live_ prefixed, bcrypt-hashed (cost=12), prefix-based lookup, expiry enforcement
OAuth Client Credentials Third-party integrations Standards-based client credentials flow (Alpha)
Query Parameter Tokens SSE/EventSource streams For clients that cannot set Authorization headers

All authentication tokens are validated on every request. JWT tokens are checked for valid signature, audience claim, and expiry. API keys are verified against bcrypt hashes — plaintext keys are never stored.

Authorization

  • Resource Ownership: Every resource endpoint verifies that the authenticated user owns the requested resource before returning data.
  • Role-Based Access: Admin capabilities are restricted to an explicit allowlist managed through environment configuration.
  • Scope Enforcement: API keys carry scopes that restrict which operations they can perform. Scope enforcement is applied on every scoped endpoint.
  • Row-Level Security (RLS): Supabase PostgreSQL enforces row-level access policies at the database layer, providing defense-in-depth beyond application-level checks.

Input Validation

  • Request payloads are validated using Pydantic schemas with strict type enforcement.
  • File uploads undergo MIME type validation to prevent malicious file types.
  • Path traversal attacks are mitigated through UUID validation and path resolution checks.
  • Pagination parameters are capped to prevent resource exhaustion.

Data Security

For detailed encryption documentation, see Encryption.

Encryption in Transit

  • TLS 1.2+ is enforced on all external connections. Older TLS versions and plaintext HTTP are rejected.
  • HSTS headers are set to instruct browsers to always use HTTPS.
  • WebSocket connections (wss://) are encrypted with the same TLS standards.

Encryption at Rest

  • Database: Supabase PostgreSQL provides infrastructure-level encryption at rest (AES-256) for all stored data.
  • Object Storage: MinIO supports server-side encryption for stored audio files and artifacts.
  • API Keys: Stored as bcrypt hashes (cost factor 12) — never in plaintext.
  • Application-Level Encryption: We are developing field-level encryption for PII fields. See our Encryption Roadmap for details.

Data Handling

  • Secrets (API keys, JWT secrets, provider credentials) are stored in environment variables, never in source code.
  • JWT signing secrets are validated at startup to ensure minimum length (≥32 characters).
  • Outbound webhooks are signed with HMAC-SHA256 so recipients can verify authenticity.
  • Webhook receiving endpoints verify Stripe HMAC signatures using constructEvent().

Data Retention & Deletion

API Security

Rate Limiting

Rate limiting is enforced at two layers:

  1. Kong API Gateway: Global rate limits applied before requests reach the application.
  2. Application Layer: Per-endpoint rate limiting middleware with configurable limits per API key (rate_limit_rpm).

Authentication Methods

All API endpoints require authentication. See Access Control Model for the complete access control matrix.

Webhook Security

Outbound webhooks include multiple security controls:

  • HMAC-SHA256 Signatures: Every webhook payload is signed. Recipients should verify the signature before processing.
  • Domain Verification: Webhook destination domains are verified via DNS TXT records before delivery begins.
  • TLS Enforcement: Webhooks are delivered only over HTTPS.

Security Headers

All API responses include security headers:

Header Value Purpose
Strict-Transport-Security max-age=31536000; includeSubDomains Force HTTPS
X-Frame-Options DENY Prevent clickjacking
X-Content-Type-Options nosniff Prevent MIME sniffing
Referrer-Policy strict-origin-when-cross-origin Limit referrer leakage

CORS Policy

  • CORS is configured with an explicit allowlist of permitted origins.
  • Wildcard (*) origins are not permitted.

Operational Security

Monitoring & Logging

  • Audit Logging: All /v1 API routes are covered by audit logging middleware that records user ID, action, IP address, and timestamp.
  • API Key Tracking: last_used_at is updated on every API key usage for activity monitoring.
  • Webhook Event Logging: Stripe webhook events are logged for billing audit trails.

Planned Improvements:

  • Structured JSON log format (replacing plain text)
  • Centralized log aggregation
  • Log tamper protection
  • Audit logging for admin routes

Incident Response

We maintain a documented incident response process covering detection, containment, eradication, recovery, and post-incident review. See Incident Response Plan for full details.

Customer notification timelines comply with applicable regulations:

  • GDPR: Within 72 hours of becoming aware of a personal data breach
  • HIPAA: Within 60 days of discovery
  • State Laws: Per applicable state breach notification requirements

Compliance & Certifications

Current Status

Framework Status Details
GDPR Readiness assessed GDPR Readiness
CCPA/CPRA Readiness assessed CCPA/CPRA Readiness
HIPAA Reviewed, BAA workflow defined HIPAA Review and BAA Workflow
COPPA/FERPA Reviewed COPPA/FERPA Review
SOC 2 Type II Planned On roadmap — not yet initiated
ISO 27001 Planned On roadmap — not yet initiated
HIPAA Certification Not applicable HIPAA does not have a certification; we support BAAs

Data Processing Agreements

We provide a standard Data Processing Agreement (DPA) for customers who require one. Contact support for the DPA template.

Subprocessors

A current list of subprocessors is maintained at Subprocessors.

Vulnerability Management

Dependency Scanning

  • Python dependencies are managed via Poetry with pinned versions in poetry.lock.
  • Dependency updates are reviewed for security advisories before adoption.

Security Testing

  • Input validation is enforced via Pydantic schemas across all endpoints.
  • Authentication and authorization logic is covered by automated tests.

Planned Improvements:

  • Automated dependency vulnerability scanning in CI/CD (e.g., pip-audit, Dependabot)
  • Periodic third-party penetration testing
  • Static Application Security Testing (SAST) integration

Responsible Disclosure

We welcome security researchers to report vulnerabilities responsibly. See Security Disclosure Policy below.

Employee Security

Access Controls

  • Production infrastructure access is restricted to essential engineering personnel.
  • Admin capabilities within the Perceive8 application are restricted to an explicit allowlist.
  • Database access requires authenticated connections through managed service interfaces.

Security Practices

  • All code changes require peer review before merging.
  • Secrets are managed through environment variables and are never committed to source control.
  • .env.example files document required configuration without exposing actual values.

Security Awareness

  • Team members are expected to follow secure coding practices.
  • Security considerations are part of the code review process.

Third-Party Security

Subprocessor Vetting

All third-party services that process customer data are evaluated for:

  • Security certifications (SOC 2, ISO 27001)
  • Data processing agreements and privacy commitments
  • Data residency and transfer mechanisms
  • Encryption practices (in transit and at rest)

A complete list of subprocessors is maintained at Subprocessors.

Data Processing Agreements

We require DPAs from subprocessors that handle personal data. Customers requiring a DPA with Perceive8 can contact support.

AI Provider Security

Audio data sent to AI providers (transcription, analysis) is:

  • Transmitted over TLS-encrypted connections
  • Processed according to provider DPAs that prohibit training on customer data
  • Not retained by providers beyond the processing window (per provider agreements)

See Data Inventory for details on data flows to third parties.

Security Disclosure Policy

Responsible Disclosure

If you discover a security vulnerability in Perceive8, we ask that you:

  1. Report it privately to [email protected].
  2. Do not publicly disclose the vulnerability until we have had a reasonable opportunity to address it.
  3. Provide sufficient detail for us to reproduce and understand the issue.
  4. Avoid accessing or modifying other users' data during your research.

Our Commitment

  • We will acknowledge receipt of your report within 2 business days.
  • We will provide an initial assessment within 5 business days.
  • We will work to remediate confirmed vulnerabilities promptly and keep you informed of progress.
  • We will not pursue legal action against researchers who follow this policy in good faith.

Scope

The following are in scope for security research:

  • Perceive8 API (api.perceive8.com)
  • Perceive8 MCP Server (mcp.perceive8.com)
  • Perceive8 Dashboard (app.perceive8.com)
  • Perceive8 SDKs (Python, JavaScript)

The following are out of scope:

  • Third-party services (Supabase, Stripe, AI providers)
  • Social engineering or phishing attacks
  • Denial of service attacks
  • Physical security

Contact Information

Purpose Contact
Security vulnerabilities [email protected]
Privacy inquiries [email protected]
DPA requests [email protected]
General security questions [email protected]

Document History

Version Date Author Changes
1.0 2026-03-07 Perceive8 Engineering Initial release
1.1 2026-04-28 Perceive8 Engineering Added MCP server to bug bounty scope

This document is reviewed quarterly. Next scheduled review: 2026-06-07.

← Back to docs