# Security and menu data handling at Honeycomb

> Honeycomb processes restaurant menu data in isolated containers that are destroyed after every job, uses only zero data retention models, keeps a full audit log, and can run in Honeycomb Cloud, your own VPC, or on premises.

Source: https://honeycomb.ai/security/  
Last updated: 2026-11-03

## The short version

Your files go into a container built for one job and destroyed when it finishes. Models only see your data through zero data retention agreements. Only the structured result is kept, unless you choose to keep the originals. Everything is logged. If you need it, Honeycomb can run inside your own cloud or on your own servers instead.

## How processing works

1. **Secure upload.** Files are uploaded over TLS to a signed, single-use link that expires in minutes and only works for your organization.
2. **Isolated container.** A new container is started for that one job: no shared disk, no access to other customers, network access only to approved inference endpoints.
3. **Inference.** The Honeycomb model runs inside the container. Other models are called only through zero data retention providers.
4. **Destroy.** When the job finishes or times out, the container, its storage, and your original files are wiped. A deletion record is written to your audit log.
5. **Structured output.** Only the processed menu (items, allergens, diets, nutrition) remains, in your workspace, for review before anything goes live.

## Zero data retention models

- **Honeycomb model** (first party): runs inside the job's container; no external call.
- **Cloudflare Workers AI**: inputs and outputs not stored, not used for training. https://developers.cloudflare.com/workers-ai/platform/privacy/

## Retention is your choice

- **Process and forget (default):** source files are destroyed with the container; only structured menu data is kept.
- **Keep for reprocessing (opt in):** source files stored encrypted in storage set aside for your organization, readable only by processing jobs, no human access, every read logged, deletable at any time.

## Three ways to deploy

| | Honeycomb Cloud | Your VPC | On premises |
| --- | --- | --- | --- |
| Where data is processed | Isolated, disposable containers | Your cloud account | Your own servers |
| Third party model calls | Zero data retention providers only | Your cloud's private model endpoints | None required |
| Time to go live | Days | Weeks | Weeks to months |
| Relative cost | Standard | Higher | Highest |

VPC and on-premises deployments cost more because they require significant dedicated engineering time for packaging, installation, security review, and upgrades in an environment Honeycomb does not operate day to day.

## Audit logs

Append-only, searchable, exportable by your admins: uploads, processing jobs, container start and destruction, every model call with provider and region, human and service access, drafts, approvals and publishes, retention changes, deletion receipts, sign-ins, role changes, and API key events.

## Testing and compliance

- **Red team:** container escape and cross-tenant attempts, prompt injection inside uploaded files, API key and role abuse, malicious uploads.
- **Blue team:** alerting on unusual access, incident response plan with named owners, every finding fixed and retested.
- **SOC 2:** in progress with an independent auditor.

## Also

Encryption in transit (TLS 1.2+) and at rest (AES-256), tenant isolation, role-based access, no standing staff access, hashed and revocable organization API keys, signed internal calls, draft and approval on every change, guardrails on AI features, no training on customer data, encrypted backups with point-in-time recovery, incident response, and reviewed code.

## Subprocessors (Honeycomb Cloud)

- Cloudflare: edge network, Workers AI inference, file storage
- DigitalOcean: application hosting and managed database
- PropelAuth: sign in, organizations, roles (no menu data)

Talk to our team: https://calendly.com/honeycombai/honeycomb-demo-15