Secrets Manager (public preview) looks great: named key-value secrets, regions, versions with revert, audit logs, and doctl support from day one. One thing keeps us from adopting it.

Reading a secret's values isn't separated from reading its metadata. The secret scopes are plain create/read/update/delete, so any token with read access to secrets returns the plaintext values. That includes every Read Only (api:read) token. In doctl, values are masked only on the client, and doctl secrets get --show or --key … --raw prints them.

Other DigitalOcean products already keep credentials out of plain read access:

Managed Databases: database:read vs database:view_credentials

Kubernetes: kubernetes:read vs kubernetes:access_cluster

Spaces keys: spaces_key:read vs spaces_key:create_credentials (the secret key is returned only on creation)

Proposal

Add a dedicated scope for retrieving values, for example secret:view_values or secret:access. secret:read would cover only metadata: names, regions, versions, timestamps, key names.

Leave value access out of Read Only (api:read) tokens, as with database credentials and kubeconfigs.

Nice to have: limit value access to specific secrets by name or tag.

Why it matters: many teams give Read Only tokens to monitoring, inventory and automation tools, including AI agents, precisely because those tokens can't reach credentials. Today, storing anything in Secrets Manager makes it readable by every such token in the team, existing or future.