Understand recipient restrictions before sending agent email

Identify the registration mode first

Lupin has two distinct onboarding paths. Autonomous POST /v0/agent/register needs no human email and starts with no outgoing recipients enabled. The returned bootstrap key also lacks send permission, independently of the workspace recipient gate. Human-email POST /v0/agent/sign-up starts an unverified workspace that can send only to the supplied human address until its verification flow completes. Treating these modes as interchangeable leads to confusing failures and unsafe advice. Reading an inbox successfully proves read access; it says nothing about authority to contact another person.

Use the intended human verification flow

In the human-email flow, POST /v0/agent/verify consumes the OTP delivered to the owner’s supplied address. The agent must not invent the code, scrape unrelated mailboxes or substitute another person’s address to pass this check. Verification lifts that flow’s signup-recipient gate, while plan limits, key permissions, provider availability and budgets remain in force. For an autonomous workspace, use the private console claim process with a verified human session. Claim establishes human ownership but leaves the original bootstrap credential restricted until the owner deliberately grants additional access.

Check every recipient field

The sending policy evaluates to, cc and bcc recipients rather than only the primary to list. A draft that appears allowed in a summary can still fail because a copied or hidden recipient falls outside the permitted audience. Review the expanded destination set before submission and before any reply-all action. Do not automatically drop a blocked recipient to make the request succeed, since that changes the authorized action and can mislead the user about who received the message. Return the policy problem for a deliberate correction instead.

Separate policy failures from delivery failures

A 403 missing_permission indicates the caller lacks a required permission. send_not_allowed reflects the unverified-workspace recipient boundary, while rejected can reflect allow/block-list enforcement. A mail_not_configured result is a provider setup issue, and provider rejection or uncertainty belongs to a later stage. Keep the structured code and stage in your application record. Repeating a denied request with different casing, a new idempotency key or another agent identity is not a legitimate recovery plan; none of those actions supplies the missing authority.

Request the smallest useful delegation

If the workflow needs approved replies to customers, an owner can choose an appropriate scoped credential and recipient policy after considering the actual use case. Broader workspace ownership is unnecessary for a worker that only handles one inbox. Preserve a draft for human review while access remains restricted, and explain that no outbound message has been sent. Your next step is to inspect GET /v0/auth/me and the workspace onboarding state, then compare the draft’s full recipient set with the applicable signup gate and hierarchical lists before attempting an authorized send.

Keep denied proposals reviewable

When sending is unavailable, retain the proposed draft with its intended recipients and explain the exact boundary to the owner. Do not repeatedly send verification messages to unrelated addresses as a workaround. Once the owner grants the needed access, reread and review the draft because the original content or recipient list may have become stale during the wait.

Sources & verification

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

• Lupin organizations and verification ↗Checked 2026-11-05
• Lupin authentication ↗Checked 2026-11-05
• Lupin allow and block lists ↗Checked 2026-11-05

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