OpenHands 1.20 lets agent profiles select secrets, with server-enforced scope limits

OpenHands released version 1.20.0 on September 17, letting users select which secrets an agent profile can make available to a conversation and allowing automated tasks to use saved profiles. For engineers connecting coding agents to scheduled tasks or team workflows, this provides a way to narrow credential access by task—for example, giving a code exploration agent read credentials without including deployment keys. [Release notes](https://github.com/OpenHands/OpenHands/releases/tag/v1.20.0)

The change closes a gap between secret delivery and authorization. The existing Secret Registry detects secret references in terminal commands, injects environment variables on demand, and masks sensitive values in output; these mechanisms govern how secrets are used. Profiles can now restrict which secrets enter a conversation in the first place, reducing the chance that an agent receives unrelated credentials. [Official documentation](https://docs.openhands.dev/sdk/guides/secrets)

The core field, `secret_refs`, has three possible meanings: `null` preserves unrestricted behavior for compatibility, an empty array delivers no user secrets, and a list of names allows only the specified entries. Filtering takes place after the server resolves the profile and before it creates the conversation’s secret registry and context, so sending additional credentials from the client cannot expand the allowlist. The scope established at startup is saved for conversation resumption; subsequent profile changes do not directly broaden access in existing conversations. [Server implementation](https://github.com/OpenHands/software-agent-sdk/pull/4931)

The frontend also fixes the compatibility fallback path: a restricted profile must retain its identity and be resolved by the server, rather than silently falling back to launching without a profile. The selector appears only when the backend advertises `profile_secret_scope_v1`. This implementation excludes the Cloud backend, so the feature in the local interface should not be taken as evidence of equivalent protection in the cloud. [Frontend changes](https://github.com/OpenHands/OpenHands/pull/17237)

Upgrading alone does not automatically tighten existing profiles, because the default remains `null`. For agents launched through ACP, provider credentials stored in the user registry are also subject to the allowlist, and omitting them may cause authentication failures. Regular LLM profiles and MCP authentication use separate delivery paths. This change also does not address ACP subprocesses inheriting environment variables from the parent process. [Scope details](https://github.com/OpenHands/software-agent-sdk/pull/4931)

During rollout, test empty allowlists, explicitly selected credentials, and conversation resumption separately, and confirm which profile the automation actually references. The next engineering question is whether deployment backends can consistently enforce the same secret policy, beyond simply allowing the interface to save the selections.