Manage multiple agent workspaces without confusing ownership

Workspace identity is an authorization boundary

An organization or workspace owns its projects, keys and resources. A human console account is a separate identity that may have authorized membership in more than one workspace. An agent service serving several customers must preserve that distinction in every job. Do not infer the active workspace from the last chat message, an email subject or a globally cached API client. Store the intended application tenant and workspace in trusted server state so concurrent requests cannot borrow another customer’s credential through accidental mutable configuration.

Select credentials from trusted routing

Resolve the tenant to its workspace and delegated role before reading a resource or exposing tools to a model. Construct an immutable per-job client or request context instead of updating one shared global bearer token. Include project and inbox references for scoped email work, and verify the returned identities against the job mapping. A user-supplied organization_id is a candidate reference, not authority. The same routing checks should apply to retries and background jobs, where an interactive workspace selector is no longer visible to remind the operator which account was intended.

Understand autonomous registration’s scope

Each autonomous registration creates a new bounded Free workspace, default project, inbox and restricted key. It does not attach the agent to another existing customer workspace and cannot grant global administrator authority. Preserve the returned organization_id rather than assuming a chosen username identifies a reusable organization. Exact registration replay recovers the same workspace; changing secrets creates a different admission request. Do not use repeated registration to evade daily quotas or replace the deliberate process of an existing owner granting access to the correct workspace.

Associate humans through claim and membership

A verified human claims an autonomous workspace through the private console form with the saved registration secret. The console establishes the owner relationship and holds its credential server-side. The original agent key remains restricted; separate explicit delegation supplies any additional agent authority. Human team management belongs in the authenticated dashboard rather than a general API-key agent tool. A login or owner role in workspace A does not establish ownership in workspace B, and a forged role header cannot replace a membership check.

Do not promise durable workspace moves

POST /v0/organizations/move is deliberately unsupported for durable production workspaces and returns 409 organization_move_unsupported. A target ID alone cannot transfer resources or ownership. If your product needs a customer migration, design an application-level process using supported reads, explicit ownership decisions and careful retirement, while acknowledging which identities cannot be preserved automatically. Avoid treating a legacy in-memory demonstration path as a production migration facility. A claim is a supported ownership association, while moving durable resources across organizations is a different capability.

Prove isolation under concurrency

Test two synthetic workspaces with overlapping local customer names and simultaneous background jobs. Assert each request uses its own credential and cannot read the other’s resource even if IDs are swapped. Your next step is an operations view that shows tenant, workspace, project, delegated key identity and verified owner together, without exposing any secret material.

Sources & verification

Reviewed against checked-in Lupin API handlers and documentation. Example requests were not executed against live providers.

• Lupin organization ownership ↗Checked 2026-11-05
• Lupin authentication scopes ↗Checked 2026-11-05
• Lupin registration claim ↗Checked 2026-11-05

Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.