Choose OAuth scopes from the workflow’s actual needs
Map desired operations to provider scopes, inspect the auth blueprint and reauthorize deliberately when access changes.
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.
Scope the credential before inspecting permission names
Connections are shared workspace accounts, so the API requires an organization key. A project or inbox-scoped key cannot manage or execute against those accounts even if it carries a similarly named permission. Start an access investigation by identifying the key’s scope, then inspect its permitted operations. Do not repair a workspace_key_required response by distributing a broader credential to an untrusted worker. An owner can choose a safe application architecture for shared access without treating every agent associated with one inbox as an administrator of external accounts.
Separate lifecycle operations by privilege
Reading connections and discovering tools use api_key_read. Creating a hosted authorization link and reconnecting use api_key_create. Disconnecting uses api_key_delete because it revokes access and removes the durable account registry after provider cleanup. Those are distinct responsibilities. A read-only account inventory service should not need disconnect privileges, and a reconnect helper should not automatically be allowed to remove arbitrary shared accounts. The restricted autonomous registration key does not grant the authority to create paid resources or perform connected app writes simply because the initial workspace already exists.
Treat execution as a consequential boundary
App tool execution uses api_key_create and an organization key. The route additionally verifies active provider status, workspace ownership, toolkit identity, concrete tool version and account revision. These checks prevent a credential from turning one authorized account into an arbitrary provider proxy. Custom auth parameters and credential overrides are not accepted. A tool’s friendly name is not a reliable indication of effect: operations that look like reads can trigger provider behavior, metered usage or changes hidden behind the toolkit. Keep the execution boundary explicit in the application design.
Test denials as carefully as success
Use synthetic cases for an inbox key attempting discovery, an organization read key attempting execution, a stale account revision and a mismatched toolkit. Each should fail at its intended boundary without a provider effect. Include an authorized proposal whose arguments change after approval and assert that it cannot execute under the old grant. Record permission errors separately from provider availability errors so operators do not fix an outage by expanding privileges. The result is a capability matrix tied to actual routes and meaningful effects, allowing narrow delegation without relying on informal promises about agent behavior.
Keep a denial result useful
A read-only inventory worker should successfully list configured accounts but fail when attempting execute_connection_tool. Assert that the fake provider receives zero execution requests in that case. This demonstrates a meaningful boundary and gives operators confidence that granting inventory access did not quietly grant the ability to modify connected applications.
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
- Lupin authentication Checked 2026-11-05
- Composio execute tool API Checked 2026-11-05
Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.