Compliance
SOC 2 Type II, GDPR, HIPAA
Encryption
At rest (KMS) and in transit (TLS 1.2+)
Network Security
VPC isolation, PrivateLink, network policies
Tenant Isolation
Control/Data Plane separation
Auth & Access
SSO, SAML, RBAC, API keys
Data Residency
US, EU, or any region
HoneyHive Trust Center
View our latest compliance reports, certifications, and security documentation.
Compliance & Certifications
HoneyHive maintains the following compliance certifications, audited and verified through Drata:| Certification | Scope | Details |
|---|---|---|
| SOC 2 Type II | All hosting options | Audited annually. Covers security, availability, and confidentiality trust service criteria. |
| GDPR | All hosting options | Full data residency controls. EU hosting available via Dedicated Cloud or Self-Hosted. |
| HIPAA | Enterprise plans | Business Associate Agreements (BAAs) available for healthcare customers. |
Request copies of our SOC 2 report and other compliance documentation through the Trust Center or by contacting security@honeyhive.ai.
Data Encryption
Encryption at Rest
All data stored in HoneyHive is encrypted at rest using AWS KMS. Dedicated Cloud and Self-Hosted customers can use their own customer-managed KMS keys. Multi-Tenant SaaS uses HoneyHive-managed encryption keys.- PostgreSQL (Amazon RDS) - Metadata, user accounts, project configurations, prompt templates, and dataset definitions
- ClickHouse - Trace and event data, evaluation scores, aggregated metrics
- Amazon S3 - Long-term log archival with server-side encryption (SSE-KMS) and versioning for audit trails
Encryption in Transit
External network communication is encrypted using TLS 1.2+:- Client-to-platform API calls (SDK and REST API)
- Database connections
Network Security
HoneyHive’s network architecture is built on defense-in-depth principles. For full infrastructure details, see Platform Architecture.| Control | Description |
|---|---|
| VPC isolation | All data processing runs in private subnets within an isolated Virtual Private Cloud. |
| Security groups | Strict ingress/egress rules limit traffic to required ports only. |
| Kubernetes network policies | Self-Hosted customers can configure Kubernetes NetworkPolicy resources to restrict pod-to-pod communication to explicitly allowed paths. |
| NAT Gateway | Outbound internet access for private resources is routed through a managed NAT Gateway. |
| AWS Firewall Manager | Centralized firewall rule management with DDoS protection. |
| No direct internet exposure | The EKS cluster runs entirely in private subnets. |
Private Networking
For customers on Dedicated Cloud or Self-Hosted, HoneyHive supports private connectivity so trace data never traverses the public internet:- AWS PrivateLink - Private endpoint connections between your VPC and HoneyHive services
- VPC Peering - Direct network peering for low-latency, private communication
Tenant Isolation
HoneyHive’s architecture separates the Control Plane (authentication, RBAC, organization configuration) from the Data Plane (trace ingestion, evaluation, storage). These planes operate on independent databases. Your application data (traces, evaluations, datasets) is never accessible from the control plane infrastructure. This separation enables different levels of physical isolation depending on your hosting option:| Hosting Option | Control Plane | Data Plane | Isolation Model |
|---|---|---|---|
| Multi-Tenant SaaS | Shared | Shared | Application-layer tenant isolation. Shared infrastructure in AWS US-West-2. |
| Dedicated Cloud | Shared (managed by HoneyHive) | Dedicated (your AWS region) | Your trace and evaluation data runs on physically isolated infrastructure. Authentication remains centrally managed. |
| Self-Hosted | Dedicated (your environment) | Dedicated (your environment) | Full physical isolation. Both planes deployed in your cloud account or on-premise environment. |
Authentication & Access Control
User Authentication
Users authenticate through the Control Plane. The Data Plane verifies access using short-lived tokens issued by the Control Plane — the two planes share no database or credentials.- SSO providers - Google, GitHub, and Microsoft SSO supported out of the box
- SAML 2.0 - Enterprise SSO integration with Okta, Azure EntraID, Google Workspace, OneLogin, PingSSO, and custom SAML providers (available on Dedicated Cloud and Self-Hosted)
- Email and password - Standard credential-based authentication
- Multi-factor authentication (MFA) - Available for all user accounts
Platform Access Control
- Role-based access control (RBAC) - Roles are assigned per-scope across your organization hierarchy (organization, workspace, and project levels). Custom role definitions available on Teams and Enterprise plans. See Roles for details.
- Dual-control access - Access to any scope requires both an explicit membership (invite) and a role that grants the required permissions. Neither condition alone is sufficient. See How Access Is Evaluated.
- No permission inheritance - Permissions do not cascade between scope levels. An organization admin does not automatically have access to workspaces or projects within it.
- Anti-privilege escalation - Users cannot grant themselves roles or expand their own access. Role assignment requires explicit admin permissions at the relevant scope.
- Session re-authorization - When a user’s roles or memberships change, their active sessions are marked stale. The platform detects this and triggers re-authorization to recalculate permissions without requiring the user to log out.
- API key authentication - Scoped API keys for SDK and REST API access, issued per-project
- Least privilege - Each internal service operates with the minimum required permissions
Infrastructure Access Control
- Kubernetes RBAC - Role-based access control enforced at the cluster level
- External Secrets Store - Secrets are stored in AWS Secrets Manager with automatic rotation, separated from application code
Infrastructure Security
HoneyHive runs on managed AWS infrastructure with the following controls:Compute and Networking
- Amazon EKS - Managed Kubernetes with automatic security patches, running in private subnets across multiple availability zones with no direct internet exposure
- Multi-AZ deployment - Services and databases distributed across availability zones for high availability with automatic failover
- Application Load Balancer - Traffic distribution across availability zones
- Amazon Route 53 - Global DNS with health checks and failover
- Auto-scaling - Horizontal pod auto-scaling based on CPU and memory utilization
Secrets and Key Management
- AWS IAM Roles for Service Accounts (IRSA) - Kubernetes pods authenticate using temporary credentials, with no shared or long-lived secrets
- AWS KMS - Encryption keys for data at rest (customer-managed keys available on Dedicated Cloud and Self-Hosted)
- AWS Secrets Manager - Centralized secrets with automatic rotation, separated from application code
Monitoring and Audit
- Amazon CloudWatch - Real-time monitoring, logging, and alerting across all services
- AWS CloudTrail - Comprehensive audit logging for all AWS API calls
- ArgoCD for GitOps - Infrastructure-as-code with automated, auditable deployments and rollbacks
- Automated backups - Point-in-time recovery for PostgreSQL with Multi-AZ automatic failover
Data Residency
HoneyHive provides flexible data residency options to meet regional compliance requirements. See the Data Residency section in Platform Architecture for the full breakdown of residency options by hosting model.Incident Response
HoneyHive maintains a documented incident response policy covering detection, containment, notification, and remediation procedures. Key details:- Real-time monitoring - Automated alerting on anomalous activity across infrastructure and application layers
- Defined escalation paths - Structured response procedures with clear ownership and SLAs
- Customer notification - Timely communication for any incident that affects customer data or availability
- Post-incident review - Root cause analysis and corrective action for every incident
Vulnerability Management
- Continuous scanning - Automated vulnerability scanning across infrastructure and application dependencies
- Patch management - Security patches applied promptly, with critical vulnerabilities prioritized
- Dependency monitoring - Automated alerts for known vulnerabilities in third-party libraries
Responsible Disclosure
If you discover a security vulnerability in HoneyHive, please report it to security@honeyhive.ai. We take all reports seriously and will respond promptly.Questions
For security questionnaires, compliance documentation, or any security-related questions, contact us:- Security team: security@honeyhive.ai
- Enterprise sales: sales@honeyhive.ai
- Trust Center: View certifications and reports