> ## Documentation Index
> Fetch the complete documentation index at: https://docs.honeyhive.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Security
> How HoneyHive protects your data, infrastructure, and AI applications.
HoneyHive is built for enterprises that need production-grade security for their AI observability and evaluation workflows. This page covers our security posture, compliance certifications, and the controls we apply across every layer of the platform.
SOC 2 Type II, GDPR, HIPAA
At rest (KMS) and in transit (TLS 1.2+)
VPC isolation, PrivateLink, network policies
Control/Data Plane separation
SSO, SAML, RBAC, API keys
US, EU, or any region
View our latest compliance reports, certifications, and security documentation.
## Compliance & Certifications
HoneyHive maintains the following compliance certifications, audited and verified through [Drata](https://app.drata.com/trust/9cc7ede3-0c38-11ee-865f-029d78a187d9):
| 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](/v2/setup/dedicated) or [Self-Hosted](/v2/setup/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](https://app.drata.com/trust/9cc7ede3-0c38-11ee-865f-029d78a187d9) or by contacting [security@honeyhive.ai](mailto:security@honeyhive.ai).
## Data Encryption
### Encryption at Rest
All data stored in HoneyHive is encrypted at rest using **AWS KMS**. [Dedicated Cloud](/v2/setup/dedicated) and [Self-Hosted](/v2/setup/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
Internal service-to-service communication within the Kubernetes cluster is isolated via VPC private subnets and security groups. Customers deploying [Self-Hosted](/v2/setup/self-hosted) can additionally enable service mesh TLS if required.
## Network Security
HoneyHive's network architecture is built on defense-in-depth principles. For full infrastructure details, see [Platform Architecture](/v2/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](/v2/setup/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](/v2/setup/dedicated) or [Self-Hosted](/v2/setup/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](/v2/setup/managed) | Shared | Shared | Application-layer tenant isolation. Shared infrastructure in AWS US-West-2. |
| [Dedicated Cloud](/v2/setup/dedicated) | Shared (managed by HoneyHive) | Dedicated (your AWS region) | Your trace and evaluation data runs on physically isolated infrastructure. Authentication remains centrally managed. |
| [Self-Hosted](/v2/setup/self-hosted) | Dedicated (your environment) | Dedicated (your environment) | Full physical isolation. Both planes deployed in your cloud account or on-premise environment. |
For more on how these planes work together, see [Platform Architecture](/v2/platform-architecture).
## 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](/v2/setup/dedicated) and [Self-Hosted](/v2/setup/self-hosted).
* Supports [SSO group-based provisioning from SAML group claims](/v2/workspace/roles#sso-group-based-provisioning) -- user roles and workspace memberships are automatically synced from your identity provider on every sign-in.
* **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](/v2/workspace/organization-hierarchy) (organization, workspace, and project levels). Custom role definitions available on Teams and Enterprise plans. See [Roles](/v2/workspace/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](/v2/workspace/roles#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](/v2/setup/dedicated) and [Self-Hosted](/v2/setup/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
For customers deploying on Azure, GCP, or on-premise, equivalent security controls are implemented using each provider's native services. See [Self-Hosted](/v2/setup/self-hosted) for supported platforms.
## Data Residency
HoneyHive provides flexible data residency options to meet regional compliance requirements. See the [Data Residency section in Platform Architecture](/v2/platform-architecture#data-residency) 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
Access our full Incident Response Policy through the [Trust Center](https://app.drata.com/trust/9cc7ede3-0c38-11ee-865f-029d78a187d9).
## 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](mailto: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](mailto:security@honeyhive.ai)
* **Enterprise sales**: [sales@honeyhive.ai](mailto:sales@honeyhive.ai)
* **Trust Center**: [View certifications and reports](https://app.drata.com/trust/9cc7ede3-0c38-11ee-865f-029d78a187d9)