modal-devin reduces where long-lived credentials appear and fails conservatively
when it cannot establish a safe session state. An arbitrary session workload can still
use its assigned Outposts capability.
Devin credential handling
The generated Modal functions receive the configured Secret and use it for all queue API calls — claiming, status checks, and release. Those calls happen in the Modal function process, outside the Sandbox that runs the session. The Sandbox itself never receives the service user token. The claimed session is handed to the Devin CLI with a short-lived, session-scoped connect token, which is the only Devin credential the session workload can reach. Compromising a session therefore exposes that one session’s connection, not the queue-wide credential.- Use a dedicated Enterprise service user with only the Outposts scopes
(
account.outposts.machine, plusaccount.outposts.orchestratorwhere outposts are created or deleted), and set an expiration. - Separate outposts and credentials for different trust environments.
- Limit the session workload to credentials required for its work.
Token handling during setup
The interactive setup:- Prompts without echo.
- Avoids placing the token in subprocess arguments.
- Stores it in a named Modal Secret when approved.
- Excludes it from the generated application.
Network model
The Devin worker initiates outbound connections to Devin Cloud. No inbound port or public IP is required. Apply Modal’s Sandbox network controls to any internal services the session is allowed to reach.Recovery behavior
When final session state is unavailable or unrecognized,modal-devin treats the work
as incomplete. It attempts to preserve the filesystem and reports a
failure so the condition remains visible to monitoring while the durable recovery
snapshot remains available to a later claim attempt.