Repository navigation
Gemini platform key is rejected because the AIza prefix check predates Google's new AQ. key format #3192
Description
Summary
PUT /api/settings/api-keys/gemini and POST /api/settings/api-keys/gemini/test reject every key that does not start with AIza before the live model-list check runs (services/platform_keys_service.py, gemini_key_error). Google AI Studio now issues keys that start with AQ. ("Auth keys"), so a key created today cannot be saved through Settings even though it is valid.
Steps to reproduce
- Create a new key at aistudio.google.com/apikey on any project. The key begins
AQ.Ab...(we tried two projects, free tier and prepay; both issueAQ.keys). - Settings > Gemini > paste the key.
- Response:
That doesn't look like a Gemini API key. Keys from Google AI Studio start with AIza — create one at aistudio.google.com/apikey.
Expected
The key is accepted, or at least handed to check_gemini_key, which already does the right thing: GET https://generativelanguage.googleapis.com/v1beta/models with x-goog-api-key.
Evidence that the key is valid
- Same key set as
GEMINI_API_KEYin.envon the backend: the model-list call withx-goog-api-keyreturns HTTP 200. - Google's developer forum documents the transition from
AIzaStandard keys toAQ.Auth keys, with Standard keys being phased out through September 2026: https://discuss.ai.google.dev/t/gemini-api-key-start-from-aq/171575 and https://discuss.ai.google.dev/t/new-api-keys-generated-with-aq-prefix-dont-work-with-rest-endpoint/176177
Proposed fix
Drop the prefix gate, or accept both AIza and AQ., and let check_gemini_key decide. The same AIza assumption also appears in services/mcp_validator.py:189, services/compatibility/static_checks.py:189 and canary/invariants/g04_no_creds_in_backlog_metadata.py:70; those are secret-detection patterns and should gain an AQ\.[A-Za-z0-9_-]+ alternative so new-format keys are still caught as secrets.
Environment
Trinity v0.9.5 (self-hosted, Docker Compose). main still carries the same check as of 2026-10-02.
Workaround
Set GEMINI_API_KEY in .env and recreate the backend; settings_service.get_gemini_api_key() falls back to the env value. The per-agent credential path has no prefix check.
Activity
Tiger-pack-ai-developer commentedon Oct 4, 2026
This is a critical issue that completely blocks anyone trying to connect a new Google AI Studio API key generated recently, as Google has moved to the new
AQ.prefix format for Authentication Keys.The proposed fix of dropping the prefix gate or adjusting the validation rules to accept both
AIzaandAQ.is the correct path forward.Here is how we can resolve this across the codebase based on the locations identified:
1. Fix the Validation Gate (
services/platform_keys_service.py)Instead of rejecting keys that do not start with
AIzainsidegemini_key_error, we should update the conditional logic to allow both prefixes:2. Update Secret Detection Patterns
For the regex-based validation and security invariants found in
services/mcp_validator.py,services/compatibility/static_checks.py, andcanary/invariants/g04_no_creds_in_backlog_metadata.py, the regex patterns should be updated to capture the new token format.Old Pattern Target:
New Recommended Pattern (to match both formats safely):
If the maintainers are open to this, I can quickly put together a PR updating
services/platform_keys_service.pyand the secret checking pipelines to ensure full compatibility with the currentAQ.authentication tokens.