Treat a Mobilebox API key as access to a project, not as a password for one phone. Keys in a project share access to that project’s phones and credit. A key named “ci” and a key named “laptop” help with attribution and rotation; the names do not create different authorization scopes.
The browser dashboard and the REST/MCP caller have different jobs. Use the configured browser sign-in path to manage the workspace. Give an automated caller a purpose-created API key, not your browser session cookie or a provider access token.
Give a key one operational owner
Use a separate named key for a trusted CI job, your local development machine and an agent integration. That makes it easier to revoke one integration without changing the others. If you need a separate phone inventory or credit pool, separate project ownership is the relevant boundary; another key in the same project is not enough.
Keep the key in your secret manager or the integration’s environment mechanism. The SDK and CLI keep its existing MOBILESANDBOX_API_KEY name for compatibility. Product branding does not require you to copy a secret into a new variable, file or prompt.
# The key is loaded by your environment, not committed in this command.
curl --fail-with-body "$MSB/v1/account" \
-H "Authorization: Bearer $MOBILESANDBOX_API_KEY"For MCP, the same bearer header belongs in the client’s protected configuration. A prompt such as “read the agent guide and use the configured Mobilebox connection” avoids teaching the model to echo credentials back into chat. The agent guide describes the tool contract without needing a real secret in its examples.
Rotate without guessing which caller failed
Create the replacement key, update one integration, perform a read-only account check, then revoke the old key through the authenticated dashboard. Check the old key returns unauthorized after revocation. Keep enough non-secret metadata to identify which integration changed, such as the key name and change owner; do not keep a copy of the full old value in a task or chat log.
A failed caller after rotation does not prove the service is down. Inspect the configured header, active key and project balance before recreating phones or retrying an entire workflow. Credentials and phone readiness are separate failure categories.
Keep browser access separate
Browser sessions use secure HttpOnly cookies. Project API keys are for REST and MCP. Do not copy cookies into CI, send OAuth provider tokens as Mobilebox keys, or assume a raw API key can perform every dashboard administrative action. Account availability and allowed sign-in paths depend on the deployed configuration.
Provider identity is also different from an email address in a screenshot. Do not assume signing in through another provider with the same displayed address grants access to an existing project. Use the workspace identity presented by the actual account flow.
Contain a suspected leak
Revoke the affected key, update the integration’s stored credential, then inspect the project’s phones and usage. Park or delete unwanted phones deliberately. Revoking access is not the same operation as shutting down a running phone; an idle or maximum-duration limit is a backstop, not a replacement for checking current state.
Review where the key could have been copied: environment dumps, request headers in debug output, CI logs, shared client configurations and saved agent conversations. Removing a local file does not revoke the credential that was in it.
For CI-specific handling, read APK smoke tests. For screen content and captured artifacts, read agent data boundaries. The API reference remains the source for request authentication and authorization requirements.