# A bigger hive. The same wall.

> SSO/SCIM, an admin boundary that can't cross into personal silos, SOC 2 Type II readiness and EU data residency, all built on the same rails as the app.

Canonical: https://beemy.co/enterprise/ · Last updated: 2026-09-01

Enterprise & Platform

SSO, admin controls, compliance readiness and region residency for teams of 50+, and a platform to build on. All of it rests on the isolation Beemy already enforces for one person. Nothing here is softened to get you in the door.

6 min read

For teams of 50+

## Need a bigger hive?

SSO, admin controls, custom integrations, compliance reviews and white-glove onboarding for teams of 50+. Custom pricing, human conversation: the details below are what that conversation covers.

Identity & administration

## Single sign-on, real deprovisioning, and an admin boundary that holds.

### SSO & SCIM, on your IdP

Single sign-on over SAML 2.0 or OIDC, plus SCIM provisioning, ride your existing identity provider. Add or remove someone there and their Beemy seat follows.

### Deprovisioning that actually revokes

Offboard someone in your IdP and their access is revoked on the next check. There's no long-lived grant sitting around to claw back later.

The admin boundary

### An admin manages the hive. Never a member's personal silo.

An admin manages membership, seats and policy. They can read audit *metadata* for the team silo: who did what, when, at a category level. An admin is never a path into a member's personal-silo content. The architecture never hands them that capability in the first place. Same [wall](https://beemy.co/trust), drawn around your whole team.

Compliance

## SOC 2 Type II readiness: the honest version.

Most of SOC 2 Type II, for us, is naming and evidencing controls the architecture already enforces. It isn't building new ones from scratch. Type II is a window rather than a snapshot. It's earned by an auditor observing those controls hold over time, and that observation window hasn't opened yet. Plainly: Beemy is readiness-stage, not yet certified.

### Silo isolation

Personal, work and public knowledge live in physically separate stores, the same architectural wall described on our Trust page.

### Envelope encryption + KMS key hierarchy

Data is encrypted with a unique key per tenant, wrapped by a managed key hierarchy. No single shared secret protects everyone at once.

### Immutable, hash-chained audit log

Every sensitive action is appended to a hash-chained log. Entries can't be edited or deleted after the fact, only appended.

### Crypto-shred deletion

Deleting an account destroys the encryption keys that protect it. That goes well beyond deleting a database row: the data becomes unrecoverable by construction.

### No-train model routing

Inference requests are routed so your content is never used to train shared models. That's the same commitment as our Trust page, enforced at the routing layer.

### TLS 1.3 everywhere

Every byte moving between you and Beemy, and between Beemy's own services, travels over TLS 1.3.

### An always-on security CI gate

Every change ships through automated security checks before it reaches production. That gate runs on every commit, not as a periodic review.

The controls above run today. What's ahead of us is the audit itself: engaging an auditor and completing the observation window Type II requires. See the full commitments on our [Trust & Security page](https://beemy.co/trust), or read [the honest version of "enterprise-ready"](https://beemy.co/blog/the-honest-version-of-enterprise-ready/).

Procurement usually asks about accessibility too. What we test and what's still short is on the[Accessibility page](https://beemy.co/accessibility).

Data residency

## EU and regional residency, for enterprise tenants.

Beemy is built to pin a tenant's data, encryption keys and model inference in-region. That's the same silo wall and row-level isolation that separates personal from work, just drawn around a region instead of around you. It's an enterprise-deployment capability we scope in the conversation below, not a default switched on for every account today.

For builders

## Build on Beemy: the same rails the app itself runs on.

### A scoped API

Beemy is built as a platform as much as a product. A credential is scoped to a single silo, able to mint a context for that silo alone. Every call runs through the same gateway and policy engine the app itself uses. A write still waits for your approval, until you raise the dial on that surface. And a credential can never grant itself more autonomy than you've handed it.

### Skills & custom workflows

A skill is a when-this-then-that binding of triggers Beemy already watches to actions it already takes. There's no new execution primitive, just your own automation on top of what exists. A skill lives inside exactly one silo and can't reach across the wall. It only acts at the autonomy level you've already granted that surface. Authoring one never grants it more power than you have.

Questions

## Fair questions, straight answers.

**Are you SOC 2 Type II certified?**

Not yet. We're readiness-stage. The controls SOC 2 Type II evidences (silo isolation, encryption, audit logging, deletion) are already built and enforced in the architecture. What's left is the audit itself. That means engaging an auditor and completing the observation window Type II requires, and that window hasn't opened yet.

**Can an admin read my personal inbox?**

No. An admin manages your team's seats and policy. They can see audit metadata for the team silo: who did what, when, at a category level. An admin has no path into a member's personal silo. That's true by construction, backed by the architecture, not a promise we're asking you to trust.

**Is my data stored in the EU today?**

For enterprise tenants, we can pin a tenant's data, encryption keys and model inference to a region. That's the same silo wall and isolation, just drawn around a region instead of around you. It's a deployment we scope in the enterprise conversation, rather than a default flipped on for every account.

**Can I build on Beemy's API today?**

There's no public API live yet. What's specified is the model it will ship on: a credential scoped to a single silo. Every call routes through the same gateway and policy engine the app itself uses. That credential can never grant itself more autonomy than you've handed it.

**What's a "skill" and can it act across my silos?**

A skill is a user-authored automation: when this happens, do that. It's a binding of triggers and actions Beemy already has, with no new execution primitive involved. A skill lives inside exactly one silo and can't reach across the wall. It can only act at the autonomy level you've already granted that surface.

**We need something specific: custom integrations, a compliance review, dedicated onboarding. Now what?**

Talk to us. Most enterprise requirements get worked out in that conversation directly, not through a self-serve form. That's true for custom integrations, compliance reviews and white-glove onboarding alike.

Last updated 1 September 2026