Claim an agent workspace through a verified human session

Keep agent identity and human ownership separate

Autonomous registration creates an API workspace and restricted agent credential without creating a human console user. A human claim adds an ownership relationship through the console rather than rerunning registration with an email address. This distinction matters for recovery and accountability: the agent’s durable workspace remains the same, while a verified person gains the ability to administer it. Do not create a second workspace and call that a claim, because the original inbox, drafts and credentials would still belong to their original workspace.

Use the private console ceremony

The owner opens https://app.lupin.sh/claim-agent, signs in with a verified human email and submits the saved registration secret through the private form. Keep the credential out of links and query strings, which can leak through browser history, screenshots, analytics or referrers. The claim flow must validate the human session and registration ownership rather than trusting a model-provided email address or organization ID. An agent can explain the steps and preserve its own state while waiting, but it cannot invent the person’s verification or consent.

Know what the claim changes

A successful claim links the workspace to the human and establishes an owner credential held server-side by the console. It does not require handing that credential to the agent or storing it in a browser URL. The human can then inspect workspace controls, review drafts and deliberately decide which additional agent permissions are needed. Keep the human’s console session distinct from API bearer credentials in your application model. A signed-in account for one person is not automatically an owner of every workspace named in an agent conversation.

Preserve bootstrap key limits

The original autonomous agent key keeps its restrictions after claim. It does not silently gain send, key-create, inbox-create or paid-resource authority. Additional access requires an explicit owner decision through appropriate API keys and workspace policy. This makes claim safe to use for oversight without treating it as a blanket approval of every pending agent proposal. A draft or queued call proposed before claim remains a proposal; the new ownership relationship does not retroactively approve its destination, content, cost or timing.

Avoid unsupported ownership shortcuts

Durable production organization moves are deliberately unavailable and return organization_move_unsupported. Supplying a target organization ID is never proof of ownership and cannot replace claim. Likewise, the separate human-email sign-up and OTP flow is a different onboarding path rather than a universal upgrade endpoint for autonomous identities. If the original registration credential was revoked or local recovery state is inconsistent, use an existing authorized owner path to investigate instead of attempting account moves, arbitrary OTP guesses or new registrations to make the UI look connected.

Finish with a deliberate delegation

After the human sees the claimed workspace, identify one concrete next capability, such as reviewed sends from a single inbox. Issue only the needed scoped access and verify it with a safe read before enabling work. Your next step is to record the owner association and intended agent role in your operational inventory while keeping the registration secret and owner credential in private storage.

Sources & verification

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

• Lupin registration human claim ↗Checked 2026-11-05
• Lupin organization ownership and move limits ↗Checked 2026-11-05
• Lupin API keys ↗Checked 2026-11-05

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