Bind every resource lookup to its authenticated workspace

A resource ID is a locator, not authority

Applications often receive a resource identifier from a URL, queue message or tool result. That identifier tells the service what to look for; it does not prove that the current caller owns it. Resolve the authenticated workspace first, then constrain the resource lookup to that workspace and any narrower project or inbox scope.

Lupin distinguishes API workspace ownership from the human console identity. A full key belongs to one workspace and does not become a global administrator. Keep this relationship explicit in application sessions and background jobs instead of accepting a target organization field as evidence of authorization.

Carry ownership through asynchronous work

A queued job should retain the authenticated tenant context established at admission, the target resource reference and the intended effect. At execution, revalidate the resource boundary using the job’s authorized context. A consumer that trusts only a bare resource ID can mix records after a routing bug or a copied queue message.

Delayed recovery requires the same discipline. The Lupin phone finalizer checks that saved projections belong to the journal’s organization and that the referenced project still exists before applying them. An old accepted provider outcome does not authorize rebuilding its resource under a different tenant or a deleted project.

Handle absence without cross-tenant discovery

A failed lookup should not encourage searching other organizations until something matches. Return the appropriate bounded denial or absence and inspect the caller’s intended workspace privately. Some protected resources intentionally return not_found. This supports isolation even when an attacker already knows or guesses an identifier.

In operational diagnostics, record the caller scope and lookup category rather than dumping another tenant’s record into the incident. A support path can inspect ownership through its own authorized tools, while the application preserves the caller’s original boundary throughout retries.

Do not treat organization move as a workaround

Lupin’s durable production workspace move endpoint is unavailable and returns organization_move_unsupported. A destination ID alone never grants ownership. The legacy in-memory demonstration path is not a production migration mechanism, and it should not appear in an operational runbook as a way to repair a misplaced resource.

For an autonomous workspace, use the documented human claim flow when the aim is to attach an owner. Claiming a workspace differs from moving resources between tenants. A product that needs migration must design an explicit authorized export or recreation process around the capabilities actually supported, rather than infer a hidden transfer operation.

Test ownership at each seam

Create local fixtures with valid identifiers from another workspace, a project outside a scoped key and a job whose project was deleted after admission. Verify that reads, writes and recovery all refuse the incorrect boundary. Include a case where payload ownership disagrees with the authenticated context.

Keep the expected behavior consistent across REST handlers, tool routing and internal reconciliation. A secure public endpoint can still be undermined by a background worker that performs an unconstrained lookup. The invariant belongs to the shared resource operation, with each entry point supplying authenticated context rather than a trusted-looking payload field.

Sources & verification

Reviewed against the checked-in Lupin implementation and official reference documentation on 2026-11-05. Operational examples are illustrative; no live paid action, provider mutation or external message was executed.

• Lupin organizations and workspace moves ↗Checked 2026-11-05
• Lupin authentication and resource policy ↗Checked 2026-11-05
• Lupin error reference ↗Checked 2026-11-05

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