### Summary On GitLab Self-Managed, `PUT /api/v4/application/settings` refuses to set `secret_detection_token_revocation_enabled=true` unless `secret_detection_token_revocation_url` and `secret_detection_revocation_token_types_url` are supplied in the same request. Those two URLs configure an external Token Revocation API, which is only used for third-party secret types. Automatic revocation of GitLab personal access tokens is handled internally and never reads them. The result is that an administrator who wants only GitLab PAT revocation, which the documentation lists as available by default on Self-Managed, cannot enable it through the API at all. The validation is also asymmetric: setting the flag to `false` succeeds with HTTP 200, and only setting it to `true` returns HTTP 400. The Rails console sets the same flag to `true` successfully with both URLs left `nil`. So the setting itself accepts the value, and the API parameter validation is stricter than the feature it guards. ### Steps to reproduce 1. Install a Self-Managed instance at 19.2.0 with an Ultimate license. 2. Create an administrator personal access token with the `api` scope. 3. Confirm the flag is currently off, and that neither URL is configured: ```shell curl --silent --header "PRIVATE-TOKEN: $TOKEN" \ --url "https://gitlab.example.com/api/v4/application/settings" | jq . | grep 'secret_detection_token' ``` 4. Turn the flag *off* through the API. This succeeds with HTTP 200, even though the two URLs are absent: ```shell curl -i --request PUT \ --header "PRIVATE-TOKEN: $TOKEN" \ --data "secret_detection_token_revocation_enabled=false" \ --url "https://gitlab.example.com/api/v4/application/settings" ``` 5. Now run the command documented under [Turn on automatic token revocation](https://docs.gitlab.com/user/application_security/secret_detection/automatic_response/#turn-on-automatic-token-revocation), changing only the value to `true`: ```shell curl -i --request PUT \ --header "PRIVATE-TOKEN: $TOKEN" \ --data "secret_detection_token_revocation_enabled=true" \ --url "https://gitlab.example.com/api/v4/application/settings" ``` 6. Observe HTTP 400 and the error below, for the same request that succeeded with `false`. 7. Set the same flag from a Rails console instead: ```ruby ::Gitlab::CurrentSettings.update!(secret_detection_token_revocation_enabled: true) ``` 8. Observe that it returns `true`, and that reading the settings back through the API shows the flag enabled with the URL settings still `null`. ### Example Project Not applicable — this is an instance-level application setting, reproducible on any Self-Managed instance without project data. ### What is the current *bug* behavior? Setting the flag to `true` is rejected with HTTP 400: ```json {"error":"secret_detection_token_revocation_url is missing, secret_detection_revocation_token_types_url is missing"} ``` The two URL parameters are mandatory whenever the flag is set to `true`, regardless of which secret types the administrator intends to cover. Setting the same flag to `false` in the same way returns HTTP 200, so the requirement applies only to enabling. Because the flag is also settable to `true` from the Rails console, and because the setting has no UI, the API is the only blocked path. ### What is the expected *correct* behavior? `secret_detection_token_revocation_enabled=true` should be settable through the API without the Token Revocation API URLs, since GitLab PAT revocation does not use them. Requiring the URLs only when a Token Revocation API integration is actually being configured would match both the feature's behavior and the documentation. If the requirement is intentional, then the API tab under [Turn on automatic token revocation](https://docs.gitlab.com/user/application_security/secret_detection/automatic_response/#turn-on-automatic-token-revocation) needs to say so, because it currently presents the API and the Rails console as equivalent ways to enable the feature and the API path cannot work for PAT-only revocation. ### Relevant logs and/or screenshots All output below is from a single 19.2.0 instance, in order. **Before enabling.** The flag is off and no revocation URLs are set: ```plaintext $ curl --silent --header "PRIVATE-TOKEN: $TOKEN" \ --url "http://localhost:7081/api/v4/application/settings" | jq . | grep 'secret_detection_token' "secret_detection_token_revocation_enabled": false, "secret_detection_token_revocation_url": null, "secret_detection_token_revocation_token": null, ``` **Setting the flag to `false` through the API — HTTP 200**, with the two URLs absent from the request: ```plaintext $ curl -i --show-error --write-out '\nHTTP %{http_code}\n' \ --request PUT \ --header "PRIVATE-TOKEN: $TOKEN" \ --data "secret_detection_token_revocation_enabled=false" \ --url "http://localhost:7081/api/v4/application/settings" HTTP/1.1 200 OK Server: nginx Date: Mon, 24 Aug 2026 22:14:22 GMT Content-Type: application/json Content-Length: 26694 Connection: keep-alive Vary: Accept-Encoding Cache-Control: max-age=0, private, must-revalidate Etag: W/"159105366c3c63e227f95473be6f0fff" Nel: {"max_age": 0} Vary: Origin X-Content-Type-Options: nosniff X-Frame-Options: SAMEORIGIN X-Gitlab-Meta: {"correlation_id":"01M0TXDGQVM3J7KCZFNHFW796R","version":"1"} X-Request-Id: 01M0TXDGQVM3J7KCZFNHFW796R X-Runtime: 0.073482 Strict-Transport-Security: max-age=63072000 Referrer-Policy: strict-origin-when-cross-origin ``` **The same request with `true` — HTTP 400:** ```plaintext $ curl -i --show-error --write-out '\nHTTP %{http_code}\n' \ --request PUT \ --header "PRIVATE-TOKEN: $TOKEN" \ --data "secret_detection_token_revocation_enabled=true" \ --url "http://localhost:7081/api/v4/application/settings" HTTP/1.1 400 Bad Request Server: nginx Date: Mon, 24 Aug 2026 22:17:13 GMT Content-Type: application/json Content-Length: 116 Connection: keep-alive Cache-Control: no-cache Nel: {"max_age": 0} Vary: Origin X-Content-Type-Options: nosniff X-Frame-Options: SAMEORIGIN X-Gitlab-Meta: {"correlation_id":"01M0TXJR8GS3RCP64DPFT5EZ75","version":"1"} X-Request-Id: 01M0TXJR8GS3RCP64DPFT5EZ75 X-Runtime: 0.022045 Strict-Transport-Security: max-age=63072000 {"error":"secret_detection_token_revocation_url is missing, secret_detection_revocation_token_types_url is missing"} HTTP 400 ``` **Enabling it from the Rails console instead, on the same instance:** ```plaintext gitlab(prod)> ::Gitlab::CurrentSettings.update!(secret_detection_token_revocation_enabled: true) => true ``` **After enabling.** Reading the settings back through the API shows the state the API itself refuses to create — the flag on, with no revocation URLs configured: ```plaintext $ curl --silent --header "PRIVATE-TOKEN: $TOKEN" \ --url "http://localhost:7081/api/v4/application/settings" | jq . | grep 'secret_detection_token' "secret_detection_token_revocation_enabled": true, "secret_detection_token_revocation_url": null, "secret_detection_token_revocation_token": null, ``` ### Output of checks Reproduced on a self-managed 19.2.0 instance (Linux package, Docker image `gitlab/gitlab-ee:19.2.0-ee.0`), Ultimate license. Not applicable to GitLab.com, where automatic token revocation is enabled by default and the setting is not administrator-configurable. #### Results of GitLab environment info Expand for output related to GitLab environment info ```plaintext GitLab 19.2.0-ee, Linux package (official Docker image), Ultimate. Single-node instance. Full `gitlab-rake gitlab:env:info` output omitted: the reproduction depends only on version, edition and tier, none of which the environment dump would change. ``` #### Results of GitLab application Check Expand for output related to the GitLab application check ```plaintext Not run. The instance is a clean 19.2.0 install that booted healthy and serves the API normally, and the failure is a parameter validation on a single endpoint rather than an instance health problem. ``` ### Possible fixes The requirement comes from the parameter block in [`ee/lib/ee/api/helpers/settings_helpers.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/19-2-stable-ee/ee/lib/ee/api/helpers/settings_helpers.rb): ```ruby optional :secret_detection_token_revocation_enabled, type: ::Grape::API::Boolean, desc: 'Enable Secret Detection Token Revocation' given secret_detection_token_revocation_enabled: ->(val) { val } do requires :secret_detection_token_revocation_url, type: String, desc: '...' requires :secret_detection_revocation_token_types_url, type: String, desc: '...' end ``` This also explains the `false`-versus-`true` asymmetry above: the `given` lambda returns the parameter's own value, so the `requires` block is only applied when the flag is truthy. Turning the feature off needs no URLs; turning it on always does. Those URLs are only consumed on the external path. In [`ee/app/services/security/token_revocation_service.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/19-2-stable-ee/ee/app/services/security/token_revocation_service.rb), `execute` partitions GitLab PATs out of the revocable keys and revokes them in-process through `PersonalAccessTokens::RevokeService` **before** consulting `external_token_revocation_enabled?` or raising `'Missing revocation token data'`: ```ruby glpats, @revocable_keys = @revocable_keys.partition { |key| key[:type] == GLPAT_KEY_TYPE } revoke_glpats(glpats) return success if @revocable_keys.empty? || !external_token_revocation_enabled? raise RevocationFailedError, 'Missing revocation token data' if missing_token_data? ``` Changing `requires` to `optional` for the two URL parameters would let the flag be enabled on its own, leaving the existing runtime guard (`missing_token_data?`) to handle the case where third-party keys are found but no Token Revocation API is configured. That guard already exists and already only fires for non-PAT keys. There is a related documentation change either way: the API tab under [Turn on automatic token revocation](https://docs.gitlab.com/user/application_security/secret_detection/automatic_response/#turn-on-automatic-token-revocation) gives the exact command that fails. The ✅ marking GitLab PATs as available by default on Self-Managed in [Supported secret types and actions](https://docs.gitlab.com/user/application_security/secret_detection/automatic_response/#supported-secret-types-and-actions) appears accurate and should not change.