The short answer

Multi-tenancy in an AI control plane means every resource — agents, workflows, connections, audit logs, billing data — belongs to exactly one organization, and no request can touch another organization's data regardless of who calls it. Praesidia enforces this boundary at the data layer on every read and write, not just at the UI layer. Membership inside that organization is managed through role-scoped invites and a set of owner-gated operations that cover the full lifecycle from first invite to final offboarding.

Why org-level isolation matters for AI tooling

Most SaaS products need multi-tenancy to keep customer data separated. AI control planes need it for a harder reason: the blast radius of a boundary violation is far larger. A misconfigured agent with access to the wrong organization's workflows could read confidential context, trigger actions against systems it should never touch, or run up costs on another team's budget. This is the core concern explored in tenant isolation and row-level security.

Flat, global data models make this too easy to get wrong. A query without a tenant filter, a service method that trusts a client-supplied identifier without validating it against the authenticated user's memberships, a missing guard on a single endpoint — any of these creates a cross-tenant data path. At scale, these mistakes are both inevitable and high-impact.

The only durable fix is to make the organization boundary a structural property of the data model, not a convention developers remember to apply. Every record carries a tenant identifier as a hard constraint, and every service method derives that identifier from the authenticated user's session — never from the request body alone.

How organizations work in Praesidia

When a user creates an organization in Praesidia, they become its owner. That organization is then the lens through which everything else is accessed: agents belong to it, teams are defined within it, connections are scoped to it, and billing rolls up to it. Multiple organizations can exist independently, and a single user account can be a member of several, but each membership carries its own role and permissions within that specific organization's context.

The organization model supports four built-in roles: owner, billing admin, compliance officer, and member. These roles gate which operations a member can perform — managing settings, inviting teammates, adjusting billing, accessing compliance reports — and the role assignment is enforced structurally on every protected operation, not left to per-callsite conditionals. For teams that need finer-grained control, RBAC and custom roles for AI operations covers how role hierarchies layer on top of the organization model.

The invite and acceptance flow

Adding a teammate starts with the organization owner sending an invite to an email address. Praesidia generates a secure token for that invite and delivers it to the invitee via email, while storing only a non-reversible representation server-side. This means the invite credential is never stored in a form that would be useful to an attacker who gains read access to the data store.

The invitee follows the link, which surfaces just enough context to let them make an informed decision before accepting. When they accept, the token is validated against the stored hash, a membership record is created, and the role is assigned. The token is not reusable after acceptance.

This flow handles the joiner case cleanly. For movers — members whose role changes — Praesidia ensures role changes take effect consistently across concurrent requests, preventing a race condition where a role is elevated and then rapidly restored in a way that lets a mid-flight request slip through at the elevated level.

Managing membership through its full lifecycle

Beyond the initial invite, Praesidia exposes the full set of membership operations an organization owner needs:

  • Role changes — an owner can promote or demote any member, with the change taking effect immediately across all subsequent requests.
  • Removal — an owner can remove a member, revoking their access to all organization resources at once.
  • Voluntary leave — any non-owner member can leave an organization without requiring owner action.
  • Ownership transfer — ownership can be transferred to another existing member, which is the correct path before an owner account is decommissioned.

Each of these operations is gated by both role checks (only owners can modify other members) and explicit permission requirements on the API routes. The combination ensures that a member who was granted a high-level role in one organization cannot exercise those permissions in a different organization, even if they are a member of both.

Data export and organization lifecycle

Organization owners can export a structured archive of their organization's data: settings, members, teams, agents, workflows, and connections. This supports compliance requirements around data portability and gives teams a clean snapshot for audit or migration purposes. The export operation is rate-limited to prevent abuse. For related compliance considerations around data subject rights, see GDPR for AI Systems: Data Subject Rights and Erasure.

At the end of an organization's lifecycle, an owner can delete it. This is a destructive and irreversible operation, which is why it is owner-only and not delegable. Praesidia's design keeps the ownership transfer path deliberately straightforward so that deleting an org is never the only way to handle a departing owner.

How Praesidia enforces the boundary

The isolation guarantee in Praesidia rests on three layers working together.

First, every entity in the data model is tied to exactly one tenant through a structural constraint enforced at the database level, not a soft convention.

Second, every data operation derives the tenant scope from the authenticated user's verified membership, not from anything the client supplies in the request. A request from a user who is not a member of the target organization is rejected before any data operation is attempted.

Third, every protected endpoint enforces a consistent set of checks covering authentication, role, and permission. Routes that are intentionally public are explicitly designated as such, which means the default is protected, not open.

This layered approach means a single missing check is unlikely to open a cross-tenant path, because the boundary is enforced structurally at multiple independent points. For a detailed look at how access control roles are structured on top of this model, see Organizing Access with Teams.

Common questions

Can a user be a member of multiple organizations?

Yes. A user account can hold memberships in multiple organizations simultaneously, each with a different role. When a request comes in, the role and permissions in effect are always those of the specific organization targeted by the request, not some global aggregate of all the user's memberships.

What happens to pending invites when an organization is deleted?

Invites are scoped to the organization that issued them. When an organization is deleted, its associated data — including pending invites — is removed. An invitee who tries to accept a cancelled or expired invite will receive an error rather than being admitted to a non-existent or different organization.

Can organization owners see other organizations' data?

No. Being an owner within one organization grants no visibility into any other organization. The owner role is a role within a tenant boundary, not a platform-wide privilege. Admin-level access to the platform itself is a separate concept managed outside the organization membership model.

For organizations that provision users via identity providers, automating user lifecycle with SCIM 2.0 describes how automated provisioning and deprovisioning integrates with the membership model described here.

What happens if an invited user already has an account in a different organization?

An existing account can accept an invite and gain membership in the new organization without any conflict. The invite creates a new membership record tied to the existing account, and the user can switch between organizations in their session. Each organization's data remains fully isolated — the user's presence in multiple organizations does not create any shared visibility between them.

Multi-tenancy done correctly is invisible — your team members see only their organization's data, and the boundary holds without anyone having to think about it. That is the goal the design is built around.