Understand an autonomous agent’s bootstrap permissions

Read capabilities as an initial boundary

Autonomous registration returns explicit capabilities: receive_email, read_email and create_drafts are true, while send_email and paid_resources are false. The workspace exists so the agent can receive work and prepare a proposal before a human grants broader access. Those flags are not an invitation to probe blocked actions until one succeeds. Use the assigned inbox, inspect authorized resources and create reviewable drafts. A new workspace API key is still a key for that workspace only; it never grants global administration or access to existing customer data.

Permissions and resource policy both matter

The checked-in bootstrap permission map permits relevant reads and draft operations while denying sending, inbox creation and API-key creation. The unverified workspace also begins with no outgoing recipients enabled. These are independent checks. A worker that can read its inbox still cannot infer it has send permission, and a plan allowance does not grant the ability to create a resource. GET /v0/auth/me identifies the key scope and permissions; use that actual response alongside the registration capabilities when building the agent’s initial tool menu.

Do not mistake quotas for authority

The registration response includes a three-inbox allowance and zero custom domains, but the bootstrap key cannot create the remaining inboxes. An allowance describes workspace policy, while permission controls who can consume it. The same distinction applies to browsing, compute, calls and connected apps: a documented feature or configured provider does not authorize this agent to use it. Keep unavailable actions out of the normal bootstrap flow and explain the needed human delegation when the user’s task requires more than reading or drafting.

Claim preserves the original restriction

A verified human can claim the workspace in the private console using the registration secret. The console associates ownership and holds its owner credential server-side. The original bootstrap key remains restricted after claim. The owner must explicitly grant additional access through appropriate credentials and controls; claim itself does not authorize outgoing email, payment, calls or paid resources. Do not retry old blocked requests after claim on the assumption that the existing agent key silently became an owner key.

Spending defaults are intentionally bounded

New autonomous workspaces begin on Free with overages disabled and the spending setting at zero. Registration contacts no provider and does not buy a number, start a container or launch a browser. Provider readiness, plan allowances, explicit spending controls and key permissions remain separate layers for any later action. A successful capability lookup is descriptive evidence, not a billing change. Keep budget changes and paid-resource requests in explicit owner-authorized flows rather than adding them as hidden setup steps for a reading task.

Make the first useful workflow concrete

Build an initial path that reads the returned inbox, processes one received message and saves a draft with a stable client_id. Report that the proposal is awaiting review and that no reply was sent. Your next step is a local permission matrix demonstrating allowed read/draft operations and denied send, inbox-create, key-create and paid-resource operations using the original bootstrap credential.

Sources & verification

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

• Lupin registration capabilities ↗Checked 2026-11-05
• Lupin authentication policy ↗Checked 2026-11-05
• Lupin organizations ↗Checked 2026-11-05

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