Enclaves

An enclave is a team’s private workspace for building and running automated workflows. It’s where your Slack channel, your team’s workflows, shared services like databases and storage, and your team membership all come together as one governed unit. When a team works in Tentacular, they work inside an enclave.

What Is an Enclave?

An enclave is a complete workspace that a team owns, operates, and collaborates in — with an identity rooted in Slack rather than in infrastructure. Your team’s Slack channel is your enclave. The Kraken mediates all interaction, so the underlying infrastructure is an implementation detail that most users never see.

Enclave = Slack channel
        + Isolated compute environment
        + Shared services (database, object storage, optionally messaging/identity)
        + Team membership (owner + members)
        + Permission policy

A Tentacular deployment hosts many enclaves. Each enclave is isolated from the others — workflows in one enclave cannot see or access resources in another.

Binding

Each enclave is bound to exactly one Slack channel. You work where you already are — no separate portal, no infrastructure console. The Kraken handles everything behind the scenes.

What	Where It Comes From
Identity	Slack channel name
Ownership	Slack channel owner
Membership	Channel members who have signed in
Compute	Dedicated isolated environment per enclave
Storage	Database + object storage scoped to the enclave
Services	Private shared services isolated within the enclave

The enclave’s internal name is set at creation from the Slack channel name and never changes, even if the channel is later renamed.

Roles

Every enclave has three principal classes, following a POSIX-like model:

Role	Who	Privileges
Owner	Slack channel owner	Full control over the enclave and all tentacles within it. Can add/remove members, change permissions, transfer ownership, freeze or deprovision the enclave. Superuser within their enclave — can modify any tentacle regardless of who deployed it.
Member	Registered channel members who have completed OIDC sign-in	Can deploy, run, and manage their own tentacles within the enclave. Exact permissions depend on the enclave’s mode preset.
Other	Authenticated users who are not the owner or a registered member	Visitors. Access depends on the enclave’s mode preset — typically read-only or none at all.

Membership is managed through Slack. When a user joins the channel and completes OIDC sign-in, The Kraken registers them as a member. When they leave the channel, they are removed automatically.

See Team Collaboration for the full permission model.

Lifecycle

Enclaves move through four states:

provision → active → frozen → deprovision

State	What Can Happen
Provisioning	Namespace, exoskeleton services, RBAC, network policies, and resource quota are being created. Transient — completes in seconds.
Active	Normal operation. Members can deploy tentacles, run them, and iterate. Cron triggers fire.
Frozen	Triggered when the Slack channel is archived. Running tentacles continue, but no new deployments are allowed and cron triggers are paused. Unarchiving the channel unfreezes the enclave.
Deprovisioned	All tentacles stopped, all exoskeleton services cleaned up, namespace deleted. Irreversible. Requires explicit confirmation from the enclave owner.

Shared Services (Exoskeleton)

Every enclave is automatically provisioned with shared infrastructure services so teams don’t have to set up databases, storage, or messaging themselves:

Service	What It Provides	Notes
Database (Postgres)	One database per enclave, one schema per tentacle	Workflows in the same enclave can share data across schemas
Object Storage (S3-compatible)	One bucket per enclave, one prefix per tentacle	Files are shared across workflows within the enclave
Messaging (NATS)	Optional. Event-driven communication between workflows	Auto-provisioned when a workflow declares a messaging dependency
Workload Identity (SPIRE)	Optional. Cryptographic identity for service-to-service auth	Auto-provisioned when a workflow declares an identity dependency

Diagrams

State Across Three Layers

An enclave exists simultaneously in three synchronized layers. Understanding this is important for disaster recovery and agent continuity:

• Git — the enclaves/<enclave-name>/ directory in your state repo holds enclave metadata (enclave.yaml) and tentacle source. Git is the authoritative source for rebuilding from scratch.
• Disk — the agent’s working copy at ~/tentacles/<enclave-name>/ where tentacles are built and modified before deployment.
• Kubernetes — the live namespace and all its resources (Deployments, ConfigMaps, Secrets, annotations). The cluster is the runtime, not the source of truth.

See The Three Layers for the full model, including the layer mapping table and disaster recovery procedure.

Channel-Scoped Operations

All operations on an enclave are channel-scoped: The Kraken only acts within the context of the channel it’s operating in. A message in #marketing-automations cannot affect the #infra-ops enclave. This isolation is enforced at the MCP server level — each request carries the enclave identity derived from the channel context, and the authorization check verifies the caller has rights within that specific enclave.

Relationship to Namespaces

In earlier Tentacular releases, namespaces were the primary tenant boundary. Enclaves replace namespaces as the user-facing abstraction. Internally, each enclave still maps 1:1 to a Kubernetes namespace. All namespace lifecycle is handled through the enclave tools (enclave_provision, enclave_deprovision, etc.).

Platform operators who need emergency access can still work at the namespace/deployment level using tntc with a bearer token. Regular users and The Kraken always operate through the enclave abstraction.