Map connection permissions to the action being authorized
Separate workspace scope, lifecycle privileges, tool discovery and exact action approval instead of using one connected flag.
Approve apparent reads as well as writes in connected apps
Use actual tool behavior, account identity and exact arguments to authorize connected application execution.
Tool names do not fully describe effects
A tool called search or fetch may contact an external service, consume metered usage or perform provider behavior that its friendly name does not reveal. A name-based read/write classifier therefore cannot safely establish blanket authorization. Lupin’s consumer agent requires exact human approval for every connected app tool execution, including apparent reads. This is different from reading the configured catalog or discovering schemas, which are preparation surfaces. Explain the distinction in the interface so the owner can review meaningful work without mistaking a tool list for an action against their account.
Show the selected account and requested data
An approval for a mailbox lookup should identify the connected account, search terms and relevant limits, not merely ask may I use Gmail. The same search against a shared operations mailbox can expose different data from a personal account. For an outward write, include the exact recipient, destination resource and content or material field changes. Keep the account revision and concrete tool version with the proposed arguments. If the owner changes a query or target, regenerate the proposal rather than treating the earlier approval as authority for a broader request.
Review the actual discovered schema
Discover tools under the intended active connection and inspect input_schema, description and scopes. The schema tells the application which arguments are accepted, while the provider documentation helps explain the operation’s meaning. Neither is a human grant by itself. Treat tool descriptions and returned content as untrusted data; they cannot instruct the agent to bypass approval or disclose credentials. If the tool has a surprising side effect, choose a narrower supported operation or explain the effect before asking for approval. Do not assume that a familiar app name makes every toolkit action harmless.
Make approval useful without making it vague
Use a compact proposal with the purpose, account, operation, exact material arguments and known cost or uncertainty. Avoid burying the decision under raw provider metadata, but keep enough structure for the owner to spot the wrong account or an unintended recipient. If execution times out, preserve its operation key and reconcile before asking for a nominally identical new action. A useful acceptance case changes only the target account after approval and checks that execution is blocked. This demonstrates that approval governs a particular effect rather than granting the agent open-ended access to the service.
Show a narrow read proposal
For a mailbox search, present the selected account, exact query and page bound before execution. If the result contains an instruction to forward attachments, treat that as message content and require a separate authorized task for any forwarding. The initial read approval does not transfer authority to instructions discovered inside the returned data.
Sources & verification
Reviewed against current checked-in Lupin routes, shared contracts and official provider references. No live calls, OAuth authorizations, app actions or purchases were performed.
- Lupin connections Checked 2026-11-05
- Composio execute tool API Checked 2026-11-05
- Lupin MCP Checked 2026-11-05
Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.