Claus de l'API d'IA a l'abast del client: aïllar els inquilins, els pressupostos i l'abús sense l'expansió de la clau del proveïdor

Quan un producte permet a molts clients trucar a models d'IA, sovint la primitiva equivocada és la clau del proveïdor amunt. Una clau de proveïdor normalment representa un compte, un projecte, un espai de treball o un compte de servei. El vostre producte necessita quelcom més limitat: una clau orientada al client que identifiqui un inquilí, un client, una aplicació, un entorn, una política de model, un pressupost i una regla d'auditoria.

Aquest és el propòsit de les claus de l'API d'IA d'abast del client. La passarel·la emet la clau, autentica les sol·licituds, aplica la política, l'ús dels mesuradors i, a continuació, truca als proveïdors amunt amb credencials ocultes. Els clients aigües avall mai reben la clau del proveïdor. Reben un contracte estable amb la teva plataforma.

Problema del lector: aïllament del client sense un projecte de proveïdor per client

Els constructors, les agències i les plataformes de distribuïdors de SaaS solen respondre preguntes pràctiques abans de poder exposar l'accés d'IA a baix:

• Quin client ha generat aquest ús?
• Quina aplicació, entorn o integració ha fet la trucada?
• Quins models i modalitats es permeten?
• Quant pot gastar aquest client aquest mes?
• Què passa si es filtra una clau?
• Es pot suspendre aquest client sense afectar els altres?
• Es pot conciliar l'ús amb els informes del proveïdor més endavant?

Els projectes i els espais de treball del proveïdor poden ajudar, però no sempre són la unitat adequada per a tots els clients posteriors. La creació d'un límit aigües amunt per client pot millorar l'aïllament i la generació d'informes, però també crea sobrecàrregues d'aprovisionament, fragmentació de quotes, ampliació de credencials i més treball de conciliació.

Una clau emesa per passarel·la ofereix al producte un punt de control a nivell de client, fins i tot quan s'agrupen les credencials amunt. També admet modes més forts, com ara les credencials del proveïdor vinculades a l'inquilí o portar la teva pròpia clau, quan un client necessita una separació contractual, límits de residència o la propietat directa del compte del proveïdor.

Fets, recomanacions i prediccions

Fets

• Els projectes OpenAI admeten membres, comptes de servei, claus API, límits d'ús, pressupostos i recursos del projecte amb abast. Això fa que els projectes siguin útils com a límits aigües amunt, però no automàticament el primitiu adequat per a cada client final.
• Els informes d'ús d'OpenAI poden agrupar l'ús per dimensions com ara projecte, usuari, clau d'API, model, lot i nivell de servei. La devolució de SaaS encara necessita aquests registres del proveïdor units als identificadors de clients del producte.
• Els espais de treball antròpics separen els recursos de l'API per cas d'ús, equip, departament, projecte o producte. Les claus de l'API estan lligades a l'espai de treball on es creen i no es poden moure entre espais de treball.
• L'ús antròpic i els informes de costos admeten l'agrupació per clau de l'API, espai de treball, model, nivell de servei, finestra de context, residència de dades i opcions relacionades amb la velocitat, amb els costos retornats en dipòsits en USD.
• La guia de claus de l'API de Google Gemini recomana restringir les claus, i les claus de l'API Gemini estan restringides a l'API del llenguatge generatiu de manera predeterminada. Les restriccions de l'aplicació, com ara les adreces IP, poden estar disponibles en funció de la forma de desplegament.
• La guia d'OWASP tracta les claus de l'API com a controls necessaris per als punts finals protegits i diu que les claus s'han de revocar quan els clients infringeixen els acords d'ús.
• La guia de secrets de l'OWASP posa l'accent en els privilegis mínims, la revocació quan els secrets ja no són necessaris o estan compromesos i la rotació automatitzada per reduir l'error d'implementació.

Recomanacions

• Utilitzeu les claus de client emeses per la passarel·la com a controladors de polítiques, no només testimonis d'autenticació.
• Mantingueu les credencials del proveïdor amunt ocultes als clients avall.
• Escriu un registre d'ús de la passarel·la en el moment de la sol·licitud, abans de confiar en els taulers de control dels proveïdors.
• Utilitzeu els projectes o els espais de treball del proveïdor de manera selectiva per a clients d'alt risc, de gran volum, regulats, sensibles a la residència o contractualment separats.
• Creeu la rotació de claus com un flux de treball de superposició, no com un esdeveniment de trencament immediat.

Prediccions

• Més proveïdors exposaran agrupacions d'ús i controls pressupostaris més rics, però l'atribució de clients propietat del producte encara serà necessària per a la facturació SaaS i els informes de distribuïdors.
• Les plataformes de distribuïdors i agències tractaran cada cop més les claus de passarel·la com a objectes comercials: vinculades a plans, saldos crediticis, àmbits i fluxos de treball de suport.
• Els clients amb necessitats de compliment estricte o d'adquisició demanaran BYOK o la propietat del compte del proveïdor, mentre que la majoria dels clients normals preferiran un contracte de passarel·la gestionat.

L'objecte clau de la passarel·la

Una clau d'abast del client s'ha de resoldre en un objecte de política estructurada. Com a mínim, modeleu la clau com a més que un hash i un nom.

{
  "key_id": "key_01J9...",
  "tenant_id": "tenant_acme",
  "customer_id": "cust_4812","application_id": "app_support_bot",
  "environment": "producció",
  "propietari": {
    "type": "service_account",
    "id": "svc_support_ai"
  },
  "model_profile_id": "profile_support_standard",
  "allowed_modalities": ["text", "image_input"],
  "tool_policy_id": "tools_readonly_kb",
  "pressupost_mensual": {
    "currency": "USD",
    "import": "500,00"
  },
  "taxa_límits": {
    "requests_per_minute": 120,
    "input_tokens_per_minute": 250000,
    "output_tokens_per_minute": 80000
  },
  "retention_policy": "només metadades",
  "estat": "actiu",
  "created_at": "2026-09-05T10:00:00Z",
  "last_used_at": nul
}

Els camps exactes variaran, però el principi no ho hauria de fer: cada sol·licitud entrant resol la clau de la política d'inquilí abans de l'enviament. L'autenticació respon "qui truca?" La resolució de polítiques respon "què pot fer aquesta persona que truca, quant pot gastar, on pot la ruta de la sol·licitud i què s'ha de registrar?"

Aquí és també on importa l'estratègia semàntica del producte. Una plataforma que vengui una API d'IA per a agències pot necessitar dimensions de client i campanya. Una eina de desenvolupador pot necessitar dimensions d'espai de treball i dipòsit. És possible que un distribuïdor necessiti identificadors de client externs que coincideixin amb el seu sistema de facturació.

Flux de treball de creació de claus

La creació de claus ha de ser prou determinista per a l'automatització i prou estricta per a la revisió de seguretat.

1. Creeu primer el registre del client

No creeu claus òrfenes. La clau hauria de pertànyer a un inquilí i un registre de client abans que existeixi. Per a les plataformes de distribuïdor, el registre del client hauria d'incloure identificadors externs del CRM o del sistema de facturació del distribuïdor, metadades del pla, agrupació d'impostos o factures si cal, i un camp d'estat que pugui suspendre totes les claus secundàries.

2. Adjunteu un perfil de model

Un perfil de model mapeja els noms dels models orientats al client amb els models i les capacitats dels proveïdors. Per exemple, support-standard pot permetre un model de text equilibrat, entrada d'imatges i cap execució de codi. research-premium pot permetre models de context llarg, cerca web i límits superiors per sol·licitud.

No obligueu les aplicacions posteriors a codificar els ID de model de proveïdors. Utilitzeu el perfil de passarel·la per gestionar la disponibilitat, la alternativa, els preus i l'abandonament.

3. Estableix límits de despesa i tarifa

Utilitzeu els pressupostos i els límits de tarifes junts. Un pressupost mensual evita danys a les factures amb el temps. Els límits de tarifes eviten que els abusos sobtats, les tempestes de reintents o els bucles accidentals consumeixin tot el pressupost en qüestió de minuts.

Els controls útils inclouen:

• Pressupost mensual del client.
• Tapa suau diària per a la detecció d'anomalies.
• Taxa de sol·licitud per clau.
• Taxa de testimoni d'entrada i sortida.
• Cost màxim estimat per sol·licitud.
• Límits específics de l'eina per a la cerca allotjada, el processament de fitxers o l'execució de codi.

L'execució del pressupost hauria de reservar el cost estimat abans de l'enviament, liquidar el cost real després de la finalització i alliberar la reserva no utilitzada. Això connecta la política de claus amb la facturació de l'API AI en lloc de tractar la facturació com una tasca d'informes retardada.

4. Genera i emmagatzema el secret correctament

Mostra el secret de text sense format una vegada. Emmagatzema només un hash fort, a més d'un prefix breu o una empremta digital per a la cerca d'assistència. El prefix ajuda els equips d'assistència a identificar "la clau que acaba en 8F2A" sense veure'n el secret.

Un patró d'emmagatzematge típic és:

• key_id: identificador de base de dades estable.
• secret_hash: hash del secret complet utilitzant una estratègia de hash de contrasenya o testimoni apropiada.
• prefix_secret: prefix de visualització breu i no sensible.
• empremta digital: identificador determinista per a la cerca d'auditoria.
• created_by: usuari o client de l'API de partner que ha creat la clau.
• estat: actiu, esgotat, revocat, en quarantena, caducat.

No emmagatzemeu mai les claus del proveïdor aigües amunt a l'objecte de clau del client. Les credencials del proveïdor pertanyen a una caixa de credencials independent amb les seves pròpies regles d'accés.

Execució a l'hora de la sol·licitud

La passarel·la hauria de tractar cada model de trucada com una decisió política seguida d'un enviament del proveïdor. Un camí de sol·licitud pràctica és el següent:

1. Analitzeu la clau de passarel·la presentada.
2. Cerca l'estat i el hash de la clau.
3. Resol el perfil d'inquilí, client, aplicació, entorn, propietari i model.
4. Comproveu si l'arrendatari i el client estan actius.
5. Valida l'àlies de model sol·licitat, la modalitat, les eines, el mode de retenció, la regió i el nivell de servei.
6. Estimeu el cost de la sol·licitud i el pressupost de reserva.
7. Comproveu els límits de tarifes i els llindars d'ús abusiu.
8. Seleccioneu el mode de credencial amunt: agrupat, vinculat a l'inquilí o BYOK.
9. Enviament al proveïdor.
10. Captureu l'ús, el cost, les referències de proveïdors, els errors i els senyals de seguretat.
11. Liquida la reserva del pressupost i escriu l'esdeveniment del llibre major final.

Aquesta seqüència fa que la passarel·la sigui responsable del contracte del client. Els taulers de control dels proveïdors es converteixen en inputs de conciliació, no en l'única font de veritat.

Feu servir camps del llibre major que realment ajuden més tard

Un registre de passarel·la hauria de conservar prou detalls per respondre a les preguntes d'assistència, facturació, ús abusiu i encaminament sense requerir emmagatzematge d'avís en brut de manera predeterminada.

Els camps útils inclouen:

• request_id i trace_id.
• tenant_id, customer_id, application_id i key_id.
• Identificador de l'usuari final, preferiblement pseudònim si escau.
• Àlies de model sol·licitat pel client.
• S'han resolt el proveïdor i el model aigües amunt.
• Ús d'entrada, sortida, raonament, memòria cau, àudio, imatge, vídeo i eines si escau.
• Cost cotitzat, import reservat, cost liquidat, moneda i versió del catàleg de preus.
• Identificador de sol·licitud del proveïdor, referència de l'informe d'ús, projecte, espai de treball o dimensió d'agrupació de claus de l'API, si està disponible.
• S'ha aplicat la política de retenció.
• Codis de seguretat, abús o de decisió de polítiques.
• S'ha produït una categoria d'error i torna a provar les metadades.

Aquesta estructura admet devolucions de càrrec, assistència al client, resposta a incidents i un flux de treball de gestió de claus API que pot respondre "què va fer aquesta clau?" sense exposar llogaters no vinculats.

Modes de credencials: agrupat, vinculat al llogater i BYOK

Credencials del proveïdor agrupades

En el mode predeterminat, moltes claus de client encaminen a través d'un conjunt més petit de credencials de proveïdor. Això és senzill operativament i redueix l'expansió del proveïdor. Funciona quan la passarel·la té una forta atribució d'inquilí, aplicació del pressupost, limitació de tarifes, aïllament abusiu i controls de límits de memòria cau.

La compensació és que els informes del proveïdor només poden mostrar la credencial de la passarel·la o el projecte del proveïdor. Heu de tornar a unir els registres del proveïdor als registres del llibre major de la passarel·la per produir anàlisis i facturació a nivell de client.

Credencials del proveïdor vinculats al llogater

Per als inquilins més grans o més arriscats, vincula un inquilí a un projecte de proveïdor dedicat, àrea de treball, compte de servei o clau. Això proporciona una separació aigües amunt més forta i pot simplificar els informes del proveïdor. També pot proporcionar un suport de quota dur si el proveïdor admet límits en aquest límit.

El cost és la complexitat operativa. L'aprovisionament, la rotació, els límits del proveïdor, la resposta a incidents i la conciliació ara es produeixen en més objectes aigües amunt.

Porta la teva pròpia clau

BYOK pot ser útil quan els clients han de ser propietaris del compte del proveïdor, negociar el seu propi contracte amb el proveïdor o mantenir la facturació del proveïdor separada. La passarel·la encara aplica perfils de model, política d'encaminament, anàlisis i controls a nivell d'aplicació sempre que sigui possible.

La compensació és la complexitat del suport. El compte de proveïdor de cada client pot tenir diferents models d'accés, quotes, preus, configuració de retenció i estat de l'incident. La passarel·la ha de detectar i explicar aquestes diferències amb claredat.

Revocació i quarantena

La revocació hauria de bloquejar les noves sol·licituds immediatament per a una clau de client sense rotar les credencials del proveïdor no relacionades. Aquest és un dels principals avantatges de les claus virtuals.

Utilitzeu estats separats per a diferents accions operatives:

• actiu: es permeten sol·licituds.
• drenatge: s'accepta la clau antiga durant una finestra de rotació, però s'emeten advertències i esdeveniments d'auditoria.
• revocat: les sol·licituds noves es rebutgen permanentment.
• en quarantena: les sol·licituds noves es bloquegen a causa d'un abús, un pagament, una política o una resposta a incidents.
• caducat: la clau ha superat la seva vida útil i s'ha de substituir.

La quarantena hauria de ser reversible quan es resolgui l'incident. Normalment, la revocació no hauria de ser reversible, perquè la restauració de vells secrets augmenta la confusió i el risc.

Quan una clau infringeix la política d'ús, registreu el motiu, l'actor, el temps i l'abast de l'aplicació. Si la decisió s'ha automatitzat, conserveu la versió de la regla i els senyals que l'han activat. D'aquesta manera, les converses dels clients es mantenen reals.

Rotació sense trencar la producció

La rotació de tecles hauria d'utilitzar un flux de treball de superposició de dues tecles:

1. Creeu una clau de substitució amb el mateix client, aplicació, perfil de model i límits tret que l'operador els canviï intencionadament.
2. Mostra el nou secret una vegada.
3. Marqueu la clau antiga com a esgotant.
4. Accepteu les dues claus durant un període limitat, com ara 7, 14 o 30 dies, segons el pla i el risc del client.
5. Emet advertències d'ús a la clau d'esgotament.
6. Notifiqui al propietari o al client de l'API del partner quan la clau antiga encara s'utilitzi a prop de la data límit.
7. Revoca la clau antiga al final de la finestra.
8. Conserveu l'atribució dels dos identificadors de clau en el mateix client i aplicació.

Això evita el mode d'error comú en què una millora de seguretat es converteix en una interrupció de la producció. La rotació encara és un control, però es converteix en un flux de treball operatiu amb proves i terminis.

Partner API Surface

Si les plataformes posteriors gestionen els clients mitjançant programació, exposa les operacions clau mitjançant una API de partner. L'API hauria d'admetre claus d'idempotència i esdeveniments d'auditoria perquè el subministrament sovint es produeix dins dels fluxos de treball de facturació, incorporació o CRM.

Punts finals mínims:

• POST /clients: creeu o engegueu un client.
• POST /customers/{customer_id}/keys: crea una clau.
• GET /customers/{customer_id}/keys: llista claus i estats.
• PATCH /keys/{key_id}: actualitza els àmbits, el propietari, els límits, el perfil del model o l'estat.
• POST /keys/{key_id}/rotate: crea un reemplaçament i marca la clau antiga com a drenant.
• POST /keys/{key_id}/revoke: revoca immediatament.
• GET /customers/{customer_id}/usage: retorna l'ús i el cost per interval de temps, clau, aplicació, model o dimensió d'usuari final.

Cada sol·licitud de mutació hauria d'acceptar una clau d'idempotència. Cada canvi hauria d'escriure un esdeveniment d'auditoria amb l'actor, l'objectiu, els camps abans i després, la IP d'origen o la identitat del client i el motiu quan estigui disponible.

Quan utilitzar projectes o espais de treball del proveïdor

No tracteu les claus de passarel·la i els límits del proveïdor com a exclusius mútuament. Solucionen diferents problemes.

Utilitzeu les claus de passarel·la per al control normal a nivell de client:

• Atribució per client.
• Claus per aplicació.
• Límits de pressupost i tarifes.
• Suspensió ràpida.
• Fluxos de treball de rotació.
• Analítica d'ús i informes de distribuïdors.

Afegiu projectes de proveïdor, espais de treball o credencials de proveïdor dedicades quan el client necessiti una separació més forta:

• Volum mensual elevat que mereix quotes dedicades.
• Càrregues de treball regulades amb requisits explícits de residència o retenció.
• Separació de factures contractuals.
• Pressupost dur o suport de quota del proveïdor.
• Supervisió d'abús dedicat o límits de revisió de seguretat.
• Comptes de proveïdor propietat del client mitjançant BYOK.

El valor predeterminat pràctic és l'aïllament forçat per passarel·la amb límits durs selectius aigües amunt. Això fa que el camí comú sigui senzill alhora que es manté un camí d'escalada per als clients que necessiten més separació.

Llista de verificació d'implementació

• Definiu un esquema de claus de client amb inquilí, client, aplicació, entorn, propietari, perfil del model, límits, política de retenció i estat.
• Comprimir els secrets en repòs i mostrar text sense format només una vegada.
• Separeu les claus de passarel·la de l'emmagatzematge de credencials del proveïdor amunt.
• Resol totes les sol·licituds a la política abans de l'enviament.
• Reserveu el pressupost abans que el proveïdor truqui i liquideu-lo un cop se'n conegui l'ús final.
• Registreu l'ús amb client, clau, àlies de model, model amunt, categories de testimoni, ús d'eines, cost cotitzat, cost liquidat i referències de proveïdor.
• Implementeu els estats actiu, drenant, revocat, en quarantena i caducat.
• Admet la superposició de rotació de dues tecles.
• Exposa les operacions de l'API del partner amb claus d'idempotència.
• Utilitzeu projectes o espais de treball del proveïdor només quan el seu cost operatiu estigui justificat.

Conclusió accionable

L'aïllament del client per a l'accés d'IA normalment hauria de començar a la clau de la passarel·la, no a la clau del proveïdor. La clau de la passarel·la és el contracte orientat al client: anomena l'inquilí, el client, l'aplicació, el perfil del model, el pressupost, el límit de tarifa, la regla de retenció i la política d'auditoria. La clau del proveïdor és un detall d'implementació darrere d'aquest contracte.

Aquesta arquitectura ofereix als creadors de SaaS i a les plataformes de distribuïdors una revocació ràpida, una atribució precisa, pressupostos per client, rotació controlada i anàlisis d'ús útils sense crear un projecte de proveïdor amunt per a cada client de manera predeterminada. Utilitzeu projectes amunt, espais de treball, credencials vinculades a l'inquilí o BYOK quan el risc, el volum, la residència o el contracte ho requereixin. Per a la ruta normal, apliqueu l'aïllament del client al llibre major de la passarel·la i al motor de polítiques i després reconcilieu els registres del proveïdor.

Lectura relacionada

• aprovisionament de claus, API de partners, idempotent per a clients i partners crèdits