Vai al contenuto principale
Una singola chiave API può raggiungere ogni modello a cui il tuo workspace ha diritto. È comodo per una sessione di console e pericoloso per un agent a vita lunga: un agent vittima di prompt injection che possiede una chiave non ristretta può silenziosamente passare da gpt-4o-mini al modello più costoso a cui hai accesso, o a uno il cui trattamento dei dati non hai mai approvato. La soluzione è un’allow-list di modelli per singola chiave. Ogni chiave porta un campo model_limits (controllato da model_limits_enabled). Quando è attivo, una richiesta per qualsiasi modello non presente nell’elenco viene rifiutata al gateway — prima che venga selezionato un canale e prima che qualsiasi cosa parta verso un provider.
Questo è un vincolo sul key object. Si compone con l’allow-list di IP, il cap di spesa, la scadenza e il guardrail / la policy del firewall collegati alla chiave — ciascuno restringe la chiave in modo indipendente.

​
1. Perché restringere l’accesso ai modelli per singola chiave API

La scelta del modello è una leva di agenzia. Una chiave che può chiamare qualsiasi modello può essere indirizzata verso:
  • Esplosioni di costo — passare a un modello premium moltiplica il conto per token.
  • Capability creep — un task con scope per un modello piccolo finisce instradato a un modello di frontiera che può fare molto più di quanto intendevi.
  • Compliance drift — inviare traffico a una famiglia di modelli che non hai autorizzato per una data classe di dati.
Restringere una chiave a uno o due modelli di cui un agent ha effettivamente bisogno chiude tutti e tre i casi in una volta. È l’equivalente sull’asse dei modelli del firewall che mette i tool in allow-list — l’agent può raggiungere solo ciò che hai nominato, e niente altro.

​
2. I due campi

I limiti sui modelli vivono sulla chiave come una coppia:
CampoTipoSignificato
model_limits_enabledboolInterruttore principale. Quando è false, la chiave raggiunge ogni modello che il workspace consente.
model_limitslistL’allow-list dei nomi dei modelli. Significativa solo quando model_limits_enabled è true.
I due campi sono indipendenti, e la combinazione conta: model_limits_enabled = true con un elenco vuoto significa che la chiave non può raggiungere nessun modello — ogni richiesta viene rifiutata con “This token has no access to any models.” Attiva l’interruttore solo dopo aver nominato almeno un modello.

​
3. Impostalo su una chiave

Configura i limiti sui modelli nell’editor delle chiavi della console (/console/token), lo stesso posto in cui imposti gli altri vincoli della chiave. Creare o modificare una chiave richiede il ruolo Developer o superiore.
  1. Apri la chiave (o Crea chiave).
  2. Abilita Limiti sui modelli.
  3. Scegli i modelli che questa chiave può chiamare — digita per filtrare i modelli disponibili del workspace.
  4. Salva. La modifica ha effetto alla prossima richiesta della chiave — nessun redeploy, nessuna rotazione della chiave.
Un summarizer schedulato che dovrebbe sempre e solo toccare un unico modello economico finisce con un’allow-list di esattamente una voce: 
model_limits_enabled: true
model_limits:         ["openai/gpt-4o-mini"]
Da quel punto la chiave è fissata a gpt-4o-mini. Qualsiasi altro nome di modello in una richiesta da questa chiave viene rifiutato — non c’è fallback a un modello di default né downgrade silenzioso.
Abbina i limiti sui modelli a un cap credit_limit_usd sulla stessa chiave. L’elenco dei modelli vincola quale modello un loop incontrollato può raggiungere; il cap di spesa vincola quanto può bruciare prima che la chiave smetta di funzionare. Due tetti indipendenti, entrambi applicati al gateway. Vedi Quota, cap e scadenza.

​
4. Com’è fatta una richiesta rifiutata

Quando model_limits_enabled è attivo e una richiesta nomina un modello fuori dall’elenco, il gateway interrompe la richiesta con HTTP 403 e un corpo di errore in forma OpenAI: 
{
  "error": {
    "message": "This token has no access to model claude-opus-4-8 (request id: 2024...abc)",
    "type": "orcarouter_api_error",
    "code": ""
  }
}
Proprietà chiave del rifiuto:
Il controllo gira mentre il gateway sta ancora scegliendo un canale — la richiesta non raggiunge mai un provider upstream, quindi un modello vietato non costa alcun token del modello.
Con l’interruttore attivo e un’allow-list vuota, il messaggio è “This token has no access to any models” e ogni richiesta viene rifiutata. È la differenza tra “restringi a un elenco” e “blocca del tutto la chiave fuori dall’inferenza”.
Il nome del modello della richiesta viene normalizzato prima che l’elenco venga controllato, così le varianti correlate (es. le varianti thinking) si risolvono allo stesso nome canonico che hai messo in allow-list. Elenca il nome del modello base che la console ti mostra.

​
5. Limiti sui modelli vs. entitlement di gruppo

Due cose diverse decidono se una chiave può chiamare un modello. Non confonderle:
LayerScopeDomanda a cui risponde
Entitlement del workspaceWorkspaceQuesto modello è disponibile al workspace, in generale?
model_limitsSingola chiaveTra i modelli disponibili, quali può usare QUESTA chiave?
model_limits solo ed esclusivamente restringe. Una chiave non può usare i limiti sui modelli per raggiungere un modello a cui il workspace stesso non ha diritto — può solo ritagliare un’allow-list più piccola da ciò che è già permesso. Per concedere a una chiave nulla in più ma strettamente meno, è esattamente a questo che serve questo campo.

​
6. Dove si colloca nella postura di minima agenzia

I limiti sui modelli sono una riga della ricetta della chiave per singolo agent. La chiave utile più ristretta per un agent autonomo fissa tutti i suoi assi in una volta: Quando una tale chiave viene compromessa via prompt injection, il raggio d’esplosione è limitato su ogni asse — incluso su quali modelli l’attaccante può spendere il tuo budget.
I limiti sui modelli sono un vincolo di identità sulla chiave, non una policy sui contenuti o sulle azioni. Non ispezionano i prompt (è compito dei Guardrails) né le chiamate a tool (è compito del Firewall) — decidono, a monte, quale modello la chiave è anche solo autorizzata a indirizzare.

​
7. Prossimi passi

Il key object

Ogni campo che una chiave porta — limiti sui modelli, elenco di IP, cap, scadenza e collegamenti a policy — in un unico riferimento.

Checklist di minima agenzia

La ricetta completa della chiave per singolo agent: dai a ogni asse lo scope minimo di cui l’agent ha bisogno.

Scope, chiavi e policy

Come chiavi, guardrail e policy del firewall si collegano in un’unica identità dell’agent.

Collegare le policy a una chiave

Collega un guardrail e una policy del firewall alla stessa chiave.
Restringere l’accesso ai modelli per singola chiave API è il controllo di agenzia più economico che puoi applicare: un’unica allow-list, applicata al gateway, attorno a cui nessun agent compromesso può aggirarsi con le parole.