--- title: Manage organizations and members canonical: "https://agentbarn.dev/guides/observe-and-govern/organizations-and-members" pubDate: "2026-08-29T00:00:00.000Z" updatedDate: "2026-09-13T13:41:42.000Z" author: Agent Barn description: "Manage Organization identity and Memberships: invitations, ownership transfer, tenant isolation, controlled deletion, and the model allowlist." tags: [Observe and govern, How-to, Organization owners and administrators, Organization, Membership, Organization Owner, Organization Admin, Organization Member, invitations, ownership transfer, tenant isolation, Platform View, Agent access, Agent Settings, model inheritance, allowed models] categories: [Guides, Observe and govern] --- - Organization - Membership - 14 minutes Create and configure Organizations, invite members, assign roles, transfer ownership, and remove access without crossing tenant boundaries. ## Organization and Membership boundaries An Organization is the primary ownership and security boundary in Agent Barn. Everything below belongs to exactly one Organization: **Organization** Acme Production ├── Memberships ├── Agents ├── Templates ├── Custom Skills ├── Shared Credentials ├── Activity └── Costs A user may hold Memberships in several Organizations. Each Membership belongs to exactly one Organization and carries exactly one Organization Role: **User** alice@example.com ├── Membership in Acme Production (OWNER) └── Membership in Acme Staging (MEMBER) The first diagram lists what a single Organization named Acme Production owns: Memberships, Agents, Templates, Custom Skills, Shared Credentials, Activity, and Costs. The second shows one user, alice@example.com, holding two separate Memberships: Owner in Acme Production and Member in Acme Staging. The two Organizations hold their own resources and authorization, and neither can reach into the other. Selecting a different Organization changes the active tenant context. It does not merge data, permissions, Agents, or credentials between Organizations. **Organization is the boundary** A role in one Organization provides no authority in another. Organization-scoped API requests carry the Organization ID and require a real Membership in that Organization. ## Understand the three Organization Roles Organization Roles govern Organization-wide capability. They are a separate model from Agent Access Roles (Agent Viewer, Agent Editor, Agent Owner, and custom roles), which govern one Agent at a time. ### Organization Owner An Organization normally has exactly one Owner. The Owner can: - Update Organization settings - Invite and remove members - Promote and demote Admins - Manage shared Templates, Skills, and Shared Credentials - Reach every Agent with implicit Agent Owner authority - Transfer ownership - Delete the Organization ### Organization Admin An Admin handles day-to-day administration. An Admin can: - Update Organization settings - List and invite members - Remove ordinary Members - Resend pending invitations - Manage shared Templates, Skills, and Shared Credentials - Reach every Agent with implicit Agent Owner authority - Remove their own Membership An Admin cannot transfer ownership, delete the Organization, change the Owner’s role, promote a Member to Admin, or demote or remove another Admin. ### Organization Member A Member works inside the Organization without administering it. A Member can: - Read basic Organization information - Create Agents - Use Organization Templates and Skills - Reach Agents they created - Reach Agents shared with them explicitly - Reach Agents covered by Agent General Access A Member cannot administer Memberships or shared Organization definitions. ### Organization Role matrix Rows marked Owner only are Organization governance operations that an Admin cannot perform. | Action | Organization Owner | Organization Admin | Organization Member | | --- | --- | --- | --- | | View Organization information | Yes | Yes | Yes | | Update Organization settings | Yes | Yes | No | | Manage Agent Settings and allowed models | Yes | Yes | No | | List Memberships | Yes | Yes | No | | Invite ordinary Members | Yes | Yes | No | | Resend pending invitations | Yes | Yes | No | | Remove ordinary Members | Yes | Yes | No | | Promote or demote Admins | Owner only | No | No | | Remove another Admin | Owner only | No | No | | Transfer ownership | Owner only | No | No | | Delete the Organization | Owner only | No | No | | Create Agents | Yes | Yes | Yes | | Access every Organization Agent | Implicit Agent Owner | Implicit Agent Owner | Only through Agent Access | | Manage shared Templates and Skills | Yes | Yes | Read and use only | | Manage Shared Credentials | Yes | Yes | List and attach when Agent permissions allow | **Assign Admin carefully** Select the Admin role only when the recipient should manage Organization-wide resources and hold implicit Agent Owner authority over every Agent. Treat assigning, promoting, demoting, or removing an Admin as an Owner-governed operation. ## Create an Organization Any authenticated user can create an Organization. ### 1\. Open the Organization selector Open the Organization selector from the Agent Barn dashboard and select **Create organization**. ### 2\. Enter a name Organization names must contain between 3 and 255 characters. Names are display labels and are not globally unique; two Organizations may both be named: ``` Acme ``` Use the description or the Organization ID to tell similarly named Organizations apart. ### 3\. Add an optional description Describe the Organization’s purpose or boundary. For example: ``` Production customer support Agents Internal engineering automation Staging environment ``` **Security** Do not place credentials, tokens, or other sensitive information in the name or description. Every member of the Organization can read them. ### 4\. Create the Organization Select **Create**. Creation accepts only a `name` and an optional `description`. Agent Barn then atomically: 1. Creates the Organization. 2. Records you as its immutable Organization Creator. 3. Creates your Owner Membership. 4. Initializes the allowlist with the platform default available at creation time, while Agent Settings continues following the platform default. ### Organization creation limit An installation may limit how many non-deleted Organizations an Organization Creator can make. When the configured limit is reached, creation returns a conflict identifying the applicable limit. Organization Creator is immutable provenance. Transferring ownership does not change who created the Organization, and does not move its creation-limit attribution. **Note** Platform Privilege does not bypass the Organization creation limit. ## Update Organization settings Organization Owners and Admins can update Organization settings. Depending on the deployed interface, those settings can include the name, the description, members, shared Templates, custom Skills, Shared Credentials, and the Organization-wide Agent Settings surface. Renaming an Organization does not change any of the following: - The Organization ID - Organization Creator - The current Owner - Memberships - Agent ownership - API routes Organization names remain non-unique display labels after a rename. ## Govern Organization Agent Settings Open `/dashboard/{org_id}/settings?tab=agents` after selecting the Organization. This is an Organization-wide settings surface, not the configuration page for one Agent. The **Agents** section shows the default model, its source, counts of inheriting and overridden Agents, allowed models, and an Organization model map. Reading or changing it requires `organization.update`. | Role | Manage Agent Settings | Manage allowed models | | --- | --- | --- | | Owner | Yes | Yes | | Admin | Yes | Yes | | Member | No | No | Agent Access controls a particular Agent; Organization Permissions control Organization-wide settings. Agent Owner or Agent Editor access alone does not allow someone to change the Organization default or its allowlist. ## Separate model governance concepts | Concept | Owner | Purpose | | --- | --- | --- | | Allowed models | Organization | Models or patterns that may be selected explicitly | | Organization default | Organization Agent Settings | Model inherited when the Organization owns a default | | Platform default | Installation configuration | Fallback when the Organization does not own a default | | Agent override | Individual Agent | Explicit model used instead of the Organization's effective default | | Running model | Active Agent Runtime | Model loaded when the current Runtime started | ``` effective_default_model(organization) = organization Agent Settings default or platform default effective_model(agent) = Agent model override or effective_default_model(organization) ``` An Agent Settings row is created lazily on its first write. A missing row and an all-null row both mean the Organization follows the platform default, which is resolved rather than copied into every Agent. | `default_model` | `default_model_source` | Meaning | | --- | --- | --- | | Concrete model | `organization` | The Organization owns its default | | `null` | `platform` | The Organization follows the current platform default | An explicit `null` update clears an Organization-owned choice and resumes following the platform default. Omitting `default_model` from an update leaves its current stored value unchanged. ## Manage the allowed-model policy The Organization's `allowed_models` determines what it may explicitly select for an Organization-owned default or Agent-specific override; it is not the effective default itself. ``` Allowed models ├── model-a ├── model-b └── model-c Organization default └── model-b Agent A └── inherits model-b Agent B └── explicitly overrides with model-c ``` Publishing or adding an allowed model does not change the default automatically. An Organization-owned default must remain allowed: selecting one outside the allowlist is rejected, and removing the active Organization-owned default is rejected until it is changed or cleared. Explicit Agent overrides must also remain allowed; an attempted removal identifies the affected Agents so an administrator can repin them or return them to inheritance first. When an Organization follows the platform default, that platform-controlled value may be outside the Organization's allowlist and can change during deployment. Inheriting Agents do not block removal of that model from the allowlist, but explicit overrides and an Organization-owned default remain subject to the policy. Allowed entries can be exact model identifiers or supported glob patterns. New entries are checked against the current OpenRouter catalogue when available; a temporary catalogue failure does not erase existing policy. Models no longer present in the catalogue can remain as orphaned entries until an administrator removes them. An Organization-owned default must resolve to one concrete selectable model. ## Review change impact and audit history The inheriting and override counts include all non-deleted Agents in the Organization. They show the scope of a policy change without revealing inaccessible Agent identities. - Changing the Organization default affects what inheriting Agents use at their next start; it does not write a model into every Agent, restart running Agents, or affect explicit overrides. - For a running Agent, `running_model` is the current Runtime value, `effective_model` is what would be selected now, and `pending_model` appears when they differ. - An inheriting Agent keeps its running model until its next start or an explicit restart. Do not restart an Agent with an explicit override solely because the Organization default changed. A changed default emits `organization.agent_settings.changed` through the Domain Event and security-audit path. A changed allowlist is a separate Organization update and emits `organization.model_allowlist.changed`. Saving the same value creates no event; these are distinct audit facts, not Communications journal entries. ### Governance workflow 1. Confirm that the user is an Organization Owner or Admin. 2. Open **Settings** and select **Agents**. 3. Review the effective default, its source, and the inheriting and override counts. 4. Add an allowed model if necessary, then select an Organization-owned default or continue following the platform. 5. Review the confirmation: inheriting Agents adopt the value after restart, while overridden Agents are unaffected. 6. Restart only the Agents that should adopt the changed effective model immediately, then review Organization audit history when needed. ## Invite a member Owners and Admins can invite users by email. Self-registration is disabled, so an invitation is the only way a new user joins. ### 1\. Open Members Select the Organization and open **Members**. The page lists each member’s name, email, Organization Role, and pending or accepted state. ### 2\. Select Add member Select **Add member**. ### 3\. Enter the recipient Enter the email address, an optional provisional full name, and the initial role. Use **Member** for normal invitations, and **Admin** only when the recipient needs Organization-wide administration and implicit access to every Agent. The Owner role cannot be assigned through an invitation. Invite the user first, then use ownership transfer. ### 4\. Add the member Select **Add member**. What happens next depends on whether the email already belongs to an active Agent Barn user. ### New or pending user Agent Barn creates or reuses the pending user, creates the Membership, generates a one-time set-password link, commits all three atomically, sends the invitation email, and displays a copyable invitation link. The Membership is listed as **Pending** until the recipient accepts. ### Existing active user Agent Barn adds the Membership immediately. No new set-password link is created, because the user already has an active account and can sign in. ### Invitation lifecycle 1. **Invitation created** An Owner or Admin adds the email. Agent Barn creates or reuses the pending user, creates the Membership, and generates a one-time set-password link. 2. **Pending Membership** The Membership is listed as Pending. The link expires after approximately 24 hours. 3. **Recipient sets their password** The recipient opens the link and sets their own authoritative full name and password. Any name entered by the inviter was provisional. 4. **Membership accepted** The Membership becomes active and the user can sign in and select the Organization. Two branches can interrupt that path before the Membership is accepted: ### Invitation resent A resend issues a fresh token and immediately invalidates the previous link. Only the newest link works. ### Pending member removed Removing a pending Membership revokes its outstanding invitation and set-password links. The lifecycle runs: invitation created, then a Pending Membership, then the recipient sets their password, then the Membership is accepted. From the Pending Membership state, resending the invitation invalidates the previous link, and removing the pending member revokes any outstanding link. **Protect invitation links** A valid invitation link lets whoever holds it set the pending user’s password. Send it only to the intended recipient, through a trusted channel. ## Manage pending invitations ### Resend an invitation 1. Open **Members**. 2. Find the member marked **Pending**. 3. Open **Member actions**. 4. Select **Resend invite**. 5. Copy the new link if manual delivery is required. Resending creates a fresh token and immediately invalidates the previous link. ### Cancel an invitation Remove the pending member from the Organization. Removing a pending Membership also revokes its outstanding invitation and set-password links. ### Already accepted invitations Agent Barn rejects a resend for a user who has already accepted their invitation. That user should sign in, or use password recovery instead. ## Change a member’s role Role changes take effect on subsequent requests. Permissions are resolved from current persisted Membership state, rather than being permanently embedded in the user’s access token. ### Promote a Member to Admin Treat this as an Owner-governed operation. An Admin cannot promote a Member to Admin through the role-change lifecycle. 1. Open **Members**. 2. Open the member’s actions. 3. Select **Make admin**. 4. Review the access increase. 5. Confirm the change. The new Admin receives implicit Agent Owner authority over every Agent in the Organization. ### Demote an Admin to Member Only the Organization Owner can demote an Admin. After the demotion: - The user loses Organization administration - The user loses implicit authority over every Agent - Explicit Agent Access and Agent General Access may still provide Agent permissions - Agents the user created remain Organization-owned - Their Membership remains active Review the user’s explicit Agent Access before demoting them, so you know what access will remain. ### Owner role changes The current Owner’s role cannot be changed directly. Transfer ownership instead. ## Transfer ownership Only the current Organization Owner can transfer ownership. **Transfer only to an accepted member** Transfer ownership only to an active, accepted member whose identity you have verified. Do not transfer ownership to a pending invitation, even where a deployment lets you select that member. ### 1\. Prepare the new Owner Confirm that the recipient has accepted their invitation, can sign in, understands the Organization’s security boundary, and is ready to manage Admins and recovery operations. ### 2\. Open the member actions Open **Members**, find the recipient, and select **Make owner**. ### 3\. Confirm the transfer The role transition is atomic: ### Before Current user Organization Owner Recipient Organization Member or Organization Admin ### After Current user Organization Admin Recipient Organization Owner Before the transfer, the current user is the Organization Owner and the recipient is an Organization Member or Organization Admin. After the transfer, the current user is an Organization Admin and the recipient is the Organization Owner. The previous Owner becomes an Admin. They are not removed from the Organization. Organization Creator does not change. Creator is historical provenance; Owner is current governance authority. ### 4\. Verify the new ownership Confirm that: - Exactly one member is marked Organization Owner - The new Owner can reach Organization administration - The previous Owner is now an Organization Admin - Recovery and operational documentation names the new Owner ## Remove a member **Removal revokes Organization access** Removing a Membership immediately ends that user’s access to the Organization’s Agents and data on subsequent requests. Confirm the Organization and the recipient before you continue. Removing a Membership does not delete the user’s Agent Barn account, and does not delete Organization-owned Agents. ### Remove an ordinary Member An Owner or Admin can remove an ordinary Member. 1. Open **Members**. 2. Open **Member actions**. 3. Select **Remove from org**. 4. Confirm the Organization name and the recipient. 5. Select **Remove**. The removed user loses: - Organization View for that Organization - Explicit Agent Access tied to the Membership - Agent General Access - Access to Organization Templates, Skills, and Shared Credentials - Organization activity and cost visibility Agents they created remain owned by the Organization. ### Remove an Admin Only the Owner can remove another Admin. An Admin may remove their own Membership to leave the Organization. ### Remove the Owner The Owner cannot be removed. Transfer ownership first. After the transfer, the previous Owner is an Admin, and can either remove their own Membership or be removed by the new Owner. ### Member self-service Organization Members do not currently have a general self-service leave operation. A Member who wants to leave should ask an Owner or Admin to remove the Membership. ## Understand Agent access Organization Roles and Agent Access Roles answer different questions: | Role family | Question answered | | --- | --- | | Organization Role | What can this Membership do across the Organization? | | Agent Access Role | What can this Membership do with this specific Agent? | Organization Owner and Organization Admin hold implicit Agent Owner authority over every Agent in the Organization. Organization Members receive Agent permissions through one or more of: - Creating the Agent, which grants explicit Agent Owner access - Explicit Agent Access - Agent General Access A Member with no applicable Agent Access cannot see that Agent at all. Changing an Organization Role therefore changes Agent visibility: - Member to Admin grants implicit authority over every Agent - Admin to Member removes that implicit authority - Explicit Agent Access and Agent General Access may remain after a demotion - Removing the Membership removes all Organization-derived Agent access See [Manage roles and permissions](/guides/observe-and-govern/roles-and-permissions) for the complete Agent Access model. ## Switch Organizations safely The Organization selector is built only from the user’s real Memberships. When you switch Organizations: - The active Organization ID changes - Organization-scoped routes use the new ID - Known Organization-scoped interface caches are cleared - Agent, Template, Skill, credential, activity, and cost views reload - Permissions are recalculated for the selected Membership Agent Barn has no default or primary Organization that silently grants access. Platform View is separate, and has no active Organization. ## Delete an Organization Only the Organization Owner can delete an Organization. **Deletion is permanent** Deleting an Organization removes its Memberships and Organization-owned resources. This cannot be undone. Export anything that must be retained before you continue. ### 1\. Delete every remaining Agent Organization deletion is blocked while any non-deleted Agent remains. Stop and delete each Agent first; stopping an Agent is not enough. If Agents remain, Agent Barn returns a conflict similar to: ``` Delete this organization's agents before deleting it (3 still active). ``` In this message, “active” means remaining non-deleted Agents, not only the Agents currently running. ### 2\. Review Organization-owned resources Review or export anything required from Templates and their versions, custom Skills, Shared Credentials, activity records, cost records, and Membership information. ### 3\. Transfer or revoke provider resources Revoke provider tokens, remove chat-platform apps, and clean up external service accounts that should not outlive the Organization. ### 4\. Open Delete organization Open the Organization management page and select **Delete organization**. ### 5\. Confirm the exact name Type the Organization name exactly as displayed, and confirm the deletion. **Important** Deleting an Organization does not necessarily delete external provider accounts, OAuth applications, chat applications, or third-party data. Manage those systems separately. ## Platform Administrator boundaries Platform Privilege and Organization Membership are independent. Platform Privilege is not an Organization Membership. ### Organization View A Platform Administrator who is also a member of an Organization operates through their persisted Organization Role, nothing more. They receive no extra Organization authority from Platform Privilege. Organization-scoped routes require a real Membership, including for Platform Administrators. ### Platform View Platform View uses dedicated, read-only oversight routes and is not an active Organization. It can expose allowlisted information such as Organization identity, Creator identity, current Owner identity, member metadata, Agent lifecycle summaries, and platform activity and cost projections. Platform View does not provide unrestricted access to: - Agent conversations - Prompts or Templates - Skill content - Credentials or Secrets - Runtime logs - Raw telemetry - Organization configuration payloads **Important** A Platform Administrator without a real Membership cannot update, invite members into, transfer, or delete an arbitrary Organization through Organization-scoped routes. ## API reference ### Create an Organization ``` POST /api/v1/organizations Content-Type: application/json ``` ``` { "name": "Acme Production", "description": "Production customer-support Agents" } ``` ``` { "id": "018f0000-0000-7000-8000-000000000001", "created_at": "2026-08-29T10:00:00Z", "updated_at": "2026-08-29T10:00:00Z", "name": "Acme Production", "description": "Production customer-support Agents", "owner_email": "owner@example.com", "owner_name": "Organization Owner", "allowed_models": [ "z-ai/glm-5.2" ] } ``` ### Read Organization details ``` GET /api/v1/organizations/{organization_id} ``` ### Update Organization settings ``` PATCH /api/v1/organizations/{organization_id} Content-Type: application/json ``` ``` { "name": "Acme AI Operations", "description": "Production Agent operations" } ``` ### Read or update Agent Settings ``` GET /api/v1/organizations/{organization_id}/agent-settings PUT /api/v1/organizations/{organization_id}/agent-settings ``` A read response describes the resolved default and its current blast radius: ``` { "default_model": null, "effective_default_model": "", "default_model_source": "platform", "inheriting_agent_count": 3, "override_agent_count": 1, "updated_at": null } ``` To select an Organization-owned default, send: ``` { "default_model": "" } ``` To resume following the platform default, send: ``` { "default_model": null } ``` ### Update allowed models Allowed models remain part of the Organization update contract, not the Agent Settings update body. ``` PATCH /api/v1/organizations/{organization_id} Content-Type: application/json ``` ``` { "allowed_models": [ "" ] } ``` ### List members ``` GET /api/v1/organizations/{organization_id}/members ``` Optional filters: ``` search=alice limit=50 ``` An example member: ``` { "user_id": "018f0000-0000-7000-8000-000000000002", "email": "alice@example.com", "full_name": "Alice Example", "role": "MEMBER", "is_pending": false } ``` ### Invite a member **Invitation tokens are credentials** The invitation response carries a one-time set-password link. Treat it like a credential: do not paste it into tickets, logs, chat channels, or source control. ``` POST /api/v1/organizations/{organization_id}/members Content-Type: application/json ``` ``` { "email": "new-member@example.com", "full_name": "New Member", "role": "MEMBER" } ``` A new user receives a response containing an invitation link: ``` { "member": { "user_id": "018f0000-0000-7000-8000-000000000003", "email": "new-member@example.com", "full_name": "New Member", "role": "MEMBER", "is_pending": true }, "invite_link": "https://app.example.com/set-password?token=REDACTED" } ``` For an existing active user, `invite_link` is `null`. ### Resend an invitation ``` POST /api/v1/organizations/{organization_id}/members/{user_id}/resend-invite ``` ``` { "invite_link": "https://app.example.com/set-password?token=REDACTED" } ``` The previous link becomes invalid. ### Change a member’s role ``` PATCH /api/v1/organizations/{organization_id}/members/{user_id} Content-Type: application/json ``` ``` { "role": "ADMIN" } ``` Do not assign `OWNER` through this endpoint. Use ownership transfer. ### Transfer ownership ``` POST /api/v1/organizations/{organization_id}/transfer-ownership Content-Type: application/json ``` ``` { "user_id": "018f0000-0000-7000-8000-000000000004" } ``` A successful transfer returns HTTP `204`. ### Remove a member ``` DELETE /api/v1/organizations/{organization_id}/members/{user_id} ``` A successful removal returns HTTP `204`. ### Delete an Organization ``` DELETE /api/v1/organizations/{organization_id} ``` The Owner must make sure no non-deleted Agents remain. ## Troubleshooting | Symptom | Likely cause | Resolution | | --- | --- | --- | | Organization creation returns HTTP 409 | The Organization Creator reached the configured creation limit | Delete an unused Organization, or ask the platform operator about the configured limit. | | Two Organizations have the same name | Organization names are display labels and are not globally unique | Use the description, the Owner, or the Organization ID to distinguish them. | | Adding a member returns HTTP 409 | The user already has a Membership in this Organization | Open the existing member instead of sending another invitation. | | The member stays marked Pending | They have not completed set-password enrollment | Ask them to open the most recent invitation link. | | An invitation link is invalid | It expired, was already used, was revoked, or was replaced by a resend | Resend the invitation and use only the newest link. | | Resending an invitation returns HTTP 409 | The user already accepted their invitation | Ask them to sign in, or to use password recovery. | | An Admin cannot promote a Member to Admin | Admin-role governance is reserved to the Organization Owner | Ask the Organization Owner to perform the promotion. | | An Admin cannot remove or demote another Admin | Admin removal and demotion are reserved to the Organization Owner | Ask the Organization Owner to remove or demote that Admin. | | The Owner cannot be removed | Every Organization must keep governance continuity | Transfer ownership first, then remove the resulting Admin. | | A Member cannot leave the Organization | Member self-service removal is not currently provided | Ask an Owner or Admin to remove the Membership. | | A demoted Admin lost visibility of Agents | Their implicit Agent Owner authority ended with the demotion | Grant explicit Agent Access, or configure Agent General Access where appropriate. | | A Platform Administrator receives HTTP 403 | Platform Privilege is not an Organization Membership | Use Platform View, or obtain a real Membership with the required Organization Role. | | A resource returns HTTP 404 or 403 after switching Organizations | The resource belongs to another Organization, or the Membership lacks the permission | Switch to the owning Organization and check the current Membership. | | Organization deletion returns HTTP 409 | One or more non-deleted Agents remain in the Organization | Delete every remaining Agent before deleting the Organization. | | The previous Owner is still listed after a transfer | Ownership transfer demotes the previous Owner to Admin rather than removing them | Remove that Admin separately if they should also leave the Organization. | | A removed pending user reports that their old link fails | Removing the pending Membership revoked its outstanding invitation links | Send a new invitation if the user should rejoin. | ## Security checklist **Membership changes are security changes** Inviting, promoting, transferring ownership, or removing a member changes access to Organization-owned Agents and data. Verify identity and intent before confirming the operation. Before inviting a user or changing a role: - Verify the recipient’s email address - Use Organization Member unless Organization-wide administration is genuinely required - Review whether Admin access would expose every Agent - Avoid transferring ownership to a pending user - Deliver invitation links through a trusted channel - Do not place invitation tokens in tickets, logs, or source control - Remove abandoned pending Memberships - Review explicit Agent Access after every role change - Keep at least one verified, active Organization Owner - Document every ownership transfer - Remove departing users promptly - Rotate Shared Credentials if a departing Admin knew provider credentials - Review external chat applications and provider accounts separately - Never use Platform Privilege as a substitute for Organization Membership - Confirm the active Organization before making destructive changes ## Next steps After configuring the Organization and its Memberships: 1. Review every Admin assignment. 2. Remove expired or abandoned pending invitations. 3. Configure Agent-specific access for Members. 4. Review Shared Credentials and provider identities. 5. Document the Owner and the recovery process. 6. Continue to [Manage roles and permissions](/guides/observe-and-govern/roles-and-permissions). [**Manage roles and permissions** The complete Agent Access model](/guides/observe-and-govern/roles-and-permissions) [**Share access to an Agent** Direct and General Agent Access](/guides/agents/sharing) [**Use shared credentials** Organization-owned provider identities](/guides/integrations/shared-credentials) [**Review activity** What the Organization’s Agents have done](/guides/observe-and-govern/activity)