Identity & tenancy
Who someone is, which organization they belong to, and what they can therefore see. This is the bottom layer of the platform: if it is wrong, nothing above it can be right — so it is enforced in the data layer rather than in the interface.
The shape of a tenant
| Entity | What it is |
|---|---|
| Organization | The tenant boundary. Every row of every table belongs to exactly one. |
| Team | A group inside an organization. The unit for team-ring sharing and for team-scoped policies. |
| User | A person, with one or more linked sign-in identities. |
| Workspace | Where content lives. Each user gets a personal workspace; teams and the organization have shared ones. |
Rings and visibility
Content — agents, skills, knowledge collections, library servers — lives in a ring that determines who can see it.
| Ring | Visible to |
|---|---|
| Personal | The owner alone. |
| Team | Members of that team. |
| Org | Everyone in the organization. |
| Public | Shared beyond the organization. |
Moving content from personal to a shared ring is a reviewed promotion, and a promotion can be limited to a pilot group — who see it while everyone else still does not, until rollout.
Roles
| Role | Can |
|---|---|
member | Use agents; build, test and automate in their personal ring — agents, skills, knowledge collections, automations over the agents they can see, and the Playground for what they built; approve writes on their own runs, connect their own accounts, manage their own memories. |
builder | Everything a member can, plus the org-level authoring surfaces (capabilities, analytics), testing any visible agent in the Playground, and proposing promotions of shared-ring work. |
team_admin | Team membership, and approvals routed to team administrators. |
org_admin | Policies, kill switches, privacy tier, legal holds, audit and SIEM, risk sign-off, shared-ring agent creation, connector and channel configuration. |
Signing in
| Method | How it lands |
|---|---|
| Enterprise SSO | Your identity provider federates in through the platform's broker, with a per-organization connection. Users arrive in the correct organization carrying their role and team membership. |
| Social sign-in | Google or GitHub, exchanged through the same verification path. Useful for self-serve and for smaller teams. |
| API keys | For programmatic access — personal, scoped, hashed at rest, revealed once. See Surfaces & integrations. |
However someone authenticates, the result is one internal token carrying their organization, role, and teams — so downstream code has a single notion of "who is asking".
Domain capture
An organization can claim an email domain by publishing a DNS record. Once verified, anyone signing in with an address at that domain joins the existing organization instead of creating a new one — which is what stops a company accumulating a dozen accidental tenants.
Self-serve gates
Free signup is protected by email verification, a disposable-domain blocklist, and per-address rate limiting. A social signup on an unclaimed domain creates a single-user free organization with a personal workspace.
Provisioning and deprovisioning
Trellaris implements SCIM 2.0 for users and groups, so your directory stays the source of truth. The part that matters most is the leaving path.
Deactivating a user runs an ordered cascade, not a status flip:
-
Suspend the account
Sessions stop working, and API keys are revoked. A previously issued token is rejected on its next use. -
Suspend the personal workspace
Their personal-ring content stops being reachable. -
Revoke access to external systems
Every connector credential is revoked, so an agent cannot keep acting as them. Agent identities they provisioned are revoked too. -
Stop the work in flight
Automations are disabled and skipped by the dispatcher; active and parked runs are cancelled. -
Record it
The whole cascade is written to the audit log.
The cascade is a registry, so a module that later owns something user-scoped registers its own handler rather than someone remembering to update a checklist.
Plans
| Plan | Automations per user | Trigger kinds |
|---|---|---|
| Free | 3 | Cron only |
| Team | 20 | All — cron, webhook, watch, email-in |
| Enterprise | By policy | All |
Plan limits are checked when an automation is created, and a refusal says which limit it hit.
Where data lives
| Data | Store | Notes |
|---|---|---|
| Agents, skills, runs, conversations, policies, audit | PostgreSQL with pgvector | Embeddings sit next to the rows they describe. |
| Live run events | Redis stream per run | Ephemeral — for streaming and short-window replay. |
| Documents, artifacts, skill bundles, recordings | Object storage (S3-compatible or Azure Blob) | Retention applies. |
| OAuth tokens, server credentials, secrets | Encrypted vault rows | Envelope-encrypted with a key version; never returned through the API. |
Everything is single-tenant per deployment at the infrastructure level and organization-scoped at the row level, which is what allows one deployment to host several organizations without their queries ever meeting.