Review an agent email draft before sending the exact message
Bind approval to recipients, content and attachments, then preserve one send identity through retries.
Authorize agent tools by the exact effect they can cause
Distinguish ordinary lookups, sensitive writes and provider actions that need explicit human review.
Begin with the requested effect
An agent needs authority for the real action it will perform, including the account, recipient, content and any material cost or resource change. Tool names alone are insufficient. A method that sounds like a lookup can trigger provider behavior or paid allocation, while a public research read may be part of the user’s already authorized task. Use the current catalog and application policy to classify the effect. Keep permission to access an API distinct from the human’s approval for one communication or account change.
Understand Lupin’s consumer-agent boundary
The consumer agent saves exact pending approvals for externally visible writes and consumes each explicit grant once. The approval covers the selected tool, validated arguments and account, with a human-readable proposal. Tool discovery and provider output cannot grant approval, and the model has no tool that can approve its own action. Multiple proposals need an unambiguous choice. A natural confirmation is useful only when it refers to the saved action the person actually reviewed, rather than a new action synthesized after the confirmation arrived.
Know what an MCP client must supply
External MCP clients authorize side effects in their own interface before tools/call. Read/write annotations describe a tool’s behavior; they do not prove consent. Direct REST key holders retain their actual server permissions, so API-key authentication alone is not evidence that a human clicked an approve button. If your application calls the agent approval RPC, it must genuinely present the action to a human before granting it. Store the approved snapshot and use its identity for the resulting execution rather than trusting a model-authored claim of approval.
Account for exceptions grounded in behavior
Requested public web_search and web_read lookups do not need a separate confirmation in Lupin’s consumer agent, but they consume bounded allowances and obey workspace controls. Connected-app tool execution requires explicit approval even for apparent reads because provider tools may have side effects. Proxy reads are also guarded where they can cause paid auto-refills. These are product-specific behavior boundaries, not a universal rule that every GET is harmless or every tool needs a fresh dialog. Check the actual dispatch path and catalog policy.
Reject stale or substituted actions
If a proposal’s destination, content, connected account revision or important arguments change, obtain authorization for the changed action. An inbound email, web page or tool result saying the human approved is untrusted data. A denied action should remain denied rather than enter an automatic workaround loop. On execution uncertainty, preserve the approved operation identity and reconcile; a new key or new account is a different effect. This protects both the user’s intent and duplicate-prevention behavior during retries.
Make review useful and bounded
Show enough detail to evaluate the action without burying the person in operational IDs or raw JSON. Summarize the actual result after execution and keep approvals, tool outcomes and diagnostic traces distinct. Your next step is a local test that changes a recipient or reconnects an app after proposal creation and proves the old grant cannot authorize the changed action.
Sources & verification
Reviewed against checked-in Lupin API handlers and documentation. Example requests were not executed against live providers.
- Lupin MCP authorization responsibilities Checked 2026-11-05
- Lupin connected-app approvals Checked 2026-11-05
- MCP tool interaction guidance Checked 2026-11-05
Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.