## Problem Non-CI/CD secret access (#594090) is covered in-process by request specs tagged `:gitlab_secrets_manager` (which boot a real OpenBao server). That validates the mint-then-read path inside Rails, but not the real deployed network path an external client actually uses: a real token hitting the API, then the real external OpenBao URL. ## Proposal Add a QA spec for the non-CI API read path: 1. Provision Secrets Manager on a project (and/or group). 2. Create a secret. 3. Call the new access-token endpoint via the API to get a JWT plus OpenBao connection details. 4. Use the JWT to log into the real external OpenBao and read the secret. 5. Assert the value matches. This mirrors `qa/qa/specs/features/ee/browser_ui/.../project_secret_ci_access_success_spec.rb` (the pipeline read path) but for the API path. It reuses the existing SM QA scenario and helpers (`qa/qa/ee/support/helpers/secrets_management/secrets_manager_helper.rb`, `qa/qa/scenario/test/integration/secrets_manager.rb`). ## Scope - In scope: the QA spec for the endpoint to OpenBao read flow. No ESO, no Kubernetes cluster. - Out of scope: a full ESO-in-a-cluster automated test. The QA framework has no ESO harness today, and the ESO flow is validated manually with design partners during 19.2 beta. ## Related - #594090 (endpoint, this issue's parent)