Does AI-Proxy now support Reference Format replacement for retrieving secrets from GCP Secret Manager?

[mohamedDev]

Hello,
Does AI-Proxy now support Reference Format replacement for retrieving secrets from GCP Secret Manager?

Would the following example work?

name: ai-proxy
enable: true
config:
provider: gemini
auth:
header:
Authorization: "Bearer $secret://gcp/xxxxx/apisix-sa-ai-providers-api-key/gemini_key"
logging:
summaries: true
payloads: false
timeout: 300000

In other words, can APISIX retrieve the secret from GCP Secret Manager and replace the $secret://... reference with the actual secret value in the Authorization header?
@dosu

[dosubot[bot]]

Yes, $secret:// references work with the ai-proxy plugin, so your example configuration would work — with one prerequisite.

What changed: PR #13312 introduced centralized secret resolution for all plugins. Previously, only specific plugins (like key-auth, limit-count, etc.) explicitly called fetch_secrets(). Now, plugin.filter() resolves $secret:// and $env:// references in every plugin's configuration before execution — including ai-proxy [1].

What you need to set up first: Register GCP Secret Manager as a secret provider resource in APISIX via the Admin API [2]:

curl "http://127.0.0.1:9180/apisix/admin/secrets/gcp/xxxxx" -X PUT -d '{
  "auth_config": {
    "client_email": "...",
    "private_key": "...",
    "project_id": "my-project"
  }
}'

Once registered, your ai-proxy config with $secret://gcp/xxxxx/apisix-sa-ai-providers-api-key/gemini_key will resolve correctly. The reference format is $secret://gcp/{confid}/{secret_name}/{sub_key}, where {confid} matches the ID used when registering the GCP secret resource, {secret_name} is the secret name in GCP Secret Manager, and {sub_key} is the JSON key within the secret value [3].

One thing to watch for: If the secret reference fails to resolve (e.g., wrong credentials or missing secret resource), APISIX will use the literal $secret://... string as the header value and log an error — it won't silently succeed [4]. So check the error logs if your provider rejects the request.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[mohamedDev]

@dosu
The configuration as it is currently set up does not work as intended

[dosubot[bot]]

@mohamedDev That makes sense — there are two issues with the configuration you shared:

1. gemini is not a supported provider in open-source APISIX

The ai-proxy plugin schema in the open-source repo only accepts these providers: openai, deepseek, aimlapi, and openai-compatible [1]. There is no gemini driver in the codebase [2]. The Gemini example from the docs is explicitly noted as applying "only to API7 Enterprise from version 3.9.2 and is not applicable in APISIX" [3] — apologies for the confusion in my earlier answer.

2. The logging field is not in the open-source schema either

The open-source ai-proxy schema does not include logging.summaries / logging.payloads fields [4]. That feature also appears to be API7 Enterprise-only.

Your options:

• Use openai-compatible as the provider and point it at the Gemini OpenAI-compatible endpoint (https://generativelanguage.googleapis.com/v1beta/openai/chat/completions) via the override.endpoint field [3]. The $secret://gcp/... reference for the auth header will still work, since secret resolution is handled centrally for all plugins [5].

Here's what that would look like:

name: ai-proxy
enable: true
config:
  provider: openai-compatible
  auth:
    header:
      Authorization: "$secret://gcp/xxxxx/apisix-sa-ai-providers-api-key/gemini_key"
  override:
    endpoint: "https://generativelanguage.googleapis.com/v1beta/openai/chat/completions"
  options:
    model: gemini-2.5-flash

• Use API7 Enterprise if you need native gemini provider support and the logging configuration.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[mohamedDev]

@dosu,
My problem is this config line Authorization: "$secret://gcp/xxxxx/apisix-sa-ai-providers-api-key/gemini_key"
So, references are not supported with the ai-proxy.

[dosubot[bot]]

@mohamedDev you're right — $secret:// references are not currently supported in the ai-proxy plugin's auth.header fields. The plugin's base.lua passes ai_instance.auth.header directly to the AI driver without resolving secret references [1], and the ai-proxy.lua plugin itself never calls fetch_secrets [2]. The schema also defines auth.header values as plain strings with no secret-aware handling [3].

The good news is that PR #13312 adds centralized secret resolution for all plugins — including ai-proxy — so $secret:// and $env:// references will work in any plugin string field without plugins needing to handle it themselves. That PR has been merged, but it hasn't shipped in a stable release yet.

For now, your options are:

1. Pass the API key directly in the config (less secure but works today).
2. Watch for the next APISIX release that includes PR feat: extend secret references to all plugins with central resolution #13312, which will make $secret://gcp/... work seamlessly in ai-proxy auth headers.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.