Chaque modèle est servi au moyen de votre propre clé de fournisseur. Ce n’est ni un palier ni une option — c’est appliqué par une contrainte de base de données, et il n’existe aucune capacité de plateforme sur laquelle se replier.
Ce qu’il advient de votre clé
- Chiffrée en AES-256-GCM sous une clé de données générée pour ce justificatif.
- Cette clé de données est elle-même encapsulée par une clé maîtresse détenue dans Google Cloud KMS, qui ne quitte jamais le service. Une copie de notre base de données ne déchiffre rien.
- Aucun point d’accès ne retourne un justificatif conservé. Ni à vous, ni au personnel, ni au soutien technique. La liste donne un indice de quatre caractères.
- Déchiffrée en mémoire seulement au moment de l’acheminement, et seulement pour une requête émise par votre organisation.
En ajouter une
POST/v1/byok
curl
curl -X POST https://autonomousrelay.com/v1/byok \
-H "Authorization: Bearer $AUTONOMOUSRELAY_MANAGEMENT_KEY" \
-H 'content-type: application/json' \
-d '{
"provider": "anthropic",
"api_key": "sk-ant-...",
"name": "prod",
"fallback_policy": "none_for_provider"
}'Clé de gestion uniquement. Une clé d’inférence est refusée ici, délibérément — voir Authentification.
Politique de repli
platform— en cas d’échec de votre clé, servir sur la capacité de la plateforme. Actuellement inatteignable : rien n’est revendu.none_for_models— un échec renvoie une erreur plutôt que de dépenser ailleurs en silence.none_for_provider— la plus stricte. Toute requête vers ce fournisseur doit utiliser votre clé.
Gérer les justificatifs
GET/v1/byok
PATCH/v1/byok/:id
DELETE/v1/byok/:id
PATCH n’accepte que disabled. Pour changer une clé, remplacez le justificatif — il n’existe aucun chemin de mise à jour qui pourrait retourner l’ancienne valeur.
Les politiques d’utilisation de votre fournisseur vous lient directement, puisque vous êtes son client. Ses restrictions sont souvent plus strictes que les nôtres et changent sans que nous en soyons informés.