> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lasscyber.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Organizations

> Tenants in Agnes — what they are, how to create them, and how multi-tenant isolation works.

A **tenant** in Agnes is the unit of isolation. Every customer-owned
record — policies, YARA rules, SDP configurations, safety policies,
analysis logs, API keys, billing — is tenant-scoped. Two tenants cannot
see each other's data, period.

In product copy we often call a tenant an **organization**, especially
when it represents a real-world company. The terms are interchangeable.

## When you need a new tenant

Most customers operate **one tenant** — their company. You may want
multiple tenants when:

* You sell Agnes-as-a-feature to your end-customers and want strict
  isolation between them. (One tenant per end-customer.)
* You operate distinct products that should not share policies or
  threat intel. (One tenant per product.)
* You want a long-lived sandbox tenant for experiments without
  cluttering your production tenant's analysis logs.

There is no per-tenant fee on most plans, but each tenant has its own
billing relationship if you put it on a paid plan. See
[Billing](/administration/billing).

## Personal vs organizational tenants

Two flavours of tenant exist:

| Type             | Created when                                                             | Backed by                                                                |
| ---------------- | ------------------------------------------------------------------------ | ------------------------------------------------------------------------ |
| **Personal**     | A user signs in for the first time and does not have an existing tenant. | The user's Auth0 identity.                                               |
| **Organization** | An owner explicitly creates one.                                         | An Auth0 Organization (created automatically if you do not provide one). |

Personal tenants are useful for individual hacking; organizational
tenants are the right shape for any team larger than one person
because they support invitations, role-based access, and Auth0
organization branding.

## Creating an organization

1. Sign in to
   [`agnes.lasscyber.com`](https://agnes.lasscyber.com).
2. Use the tenant switcher in the top-left of the dashboard to choose
   **Create organization**.
3. Pick a display name. Agnes provisions an Auth0 Organization behind
   the scenes (or accepts an existing `auth0_organization_id` if you
   already have one).
4. Once created, you become the owner.

Programmatically, `POST /api/v1/tenants/` with a JWT (not an API key —
tenant creation is a JWT-only operation):

```bash theme={null}
curl -X POST https://api.lasscyber.com/api/v1/tenants/ \
  -H "Authorization: Bearer <auth0_jwt>" \
  -H "Content-Type: application/json" \
  -d '{
    "display_name": "Acme Corp",
    "tenant_type": "ORGANIZATION"
  }'
```

If you already have an Auth0 Organization you want to bind, pass
`auth0_organization_id`. Otherwise Agnes will create one for you.

## Switching tenants

Users with access to multiple tenants pick the active one in the
**tenant switcher** in the top-left of the dashboard. The selection is
stored in `localStorage` and travels with you across reloads.

For programmatic clients, an API key already implies a single tenant —
you cannot switch. To act on a different tenant, use a key from that
tenant.

## Inviting members

Organizations have first-class invitations. See
[Inviting team members](/administration/inviting-team-members) for the
flow.

## Deleting a tenant

Owners can delete their tenant from
[`agnes.lasscyber.com/agnes-info`](https://agnes.lasscyber.com/agnes-info).
Deletion is permanent and cascades to:

* All API keys (immediate revocation).
* All policies, YARA rules, SDP / safety policies.
* All threat-intel embeddings.
* All analysis logs and audit history.
* The Stripe customer (subscription is canceled and downgraded to
  unpaid; final invoice is generated for any unbilled usage).

The Auth0 Organization is **not** deleted — you may want to keep it
for SSO continuity. Delete it manually in Auth0 if needed.

## Tenant isolation in practice

* **API key** → exactly one tenant. The `X-Tenant-ID` header is
  inferred from the key; a mismatched value is rejected.
* **Auth0 JWT** → bound to whichever tenant the user has currently
  selected in the tenant switcher.
* **Database queries** → always include `tenant_id`. Cross-tenant
  reads are not possible from the public API surface.
* **Threat intel** → tenant-scoped by default; the public threat-intel
  set is opt-in via the
  [Semantic Threat Intelligence analyzer's](/analyzers/semantic-threat-intelligence)
  `include_public_threat_intel` parameter.

## Personal tenants in trial

A new personal tenant lands on the **trial** plan with 100,000
included tokens / month. Once the trial expires, the API responds with
[`billing_required`](/errors/billing_required) until the user picks a
paid plan or the tenant is converted to an organization on a paid
plan.

## Next

* [Roles & permissions](/administration/roles-and-permissions) — the
  role and scope system inside a tenant.
* [Inviting team members](/administration/inviting-team-members) —
  add users to your organization.
* [Billing](/administration/billing) — plans, quotas, and the Stripe
  Customer Portal.