Ключове за AI API с обхват на клиента: Изолирайте наематели, бюджети и злоупотреби без разрастване на ключовете на доставчика

Когато даден продукт позволява на много клиенти да извикват AI модели, грешният примитив често е ключът на доставчика нагоре по веригата. Ключът на доставчик обикновено представлява акаунт, проект, работно пространство или акаунт за услуга. Вашият продукт се нуждае от нещо по-тясно: ключ, обърнат към клиента, който идентифицира един наемател, клиент, приложение, среда, политика на модела, бюджет и правило за одит.

Това е целта на ключовете за AI API с обхват на клиента. Шлюзът издава ключа, удостоверява заявките, прилага политиката, измерва използването и след това се обажда на доставчиците нагоре по веригата, използвайки скрити идентификационни данни. Клиентите надолу по веригата никога не получават ключа на доставчика. Те получават стабилен договор с вашата платформа.

Проблем с четеца: Изолация на клиента без един проект на доставчик на клиент

Създателите на SaaS, агенциите и платформите за дистрибутори обикновено трябва да отговорят на практически въпроси, преди да могат да изложат AI достъп надолу по веригата:

• Кой клиент е генерирал това използване?
• Кое приложение, среда или интеграция е извършило обаждането?
• Кои модели и модалности са разрешени?
• Колко може да похарчи този клиент този месец?
• Какво се случва, ако ключ изтече?
• Може ли този клиент да бъде спрян, без това да засегне всички останали?
• Може ли употребата да бъде съпоставена с отчетите на доставчика по-късно?

Проектите и работните пространства от страна на доставчика могат да помогнат, но те не винаги са правилната единица за всеки клиент надолу по веригата. Създаването на една граница нагоре по веригата за всеки клиент може да подобри твърдата изолация и отчитане, но също така създава допълнителни разходи за осигуряване, фрагментиране на квотите, разрастване на идентификационните данни и повече работа по съгласуване.

Издаден от шлюз ключ дава на продукта контролна точка на ниво клиент дори когато идентификационните данни нагоре са обединени. Той също така поддържа по-силни режими, като идентификационни данни на обвързан с наемател доставчик или донесете свой собствен ключ, когато клиентът се нуждае от договорна раздяла, граници на пребиваване или директна собственост на акаунт на доставчик.

Факти, препоръки и прогнози

Факти

• Членове за поддръжка на проекти на OpenAI, акаунти за услуги, API ключове, ограничения за използване, бюджети и обхватни проекти за ресурси. Това прави проектите полезни като граници нагоре по веригата, но не и автоматично правилния примитив за всеки краен клиент.
• Отчитането на използването на OpenAI може да групира използването по измерения като проект, потребител, API ключ, модел, партида и ниво на услугата. Обратното плащане по SaaS все още се нуждае от тези записи на доставчика, свързани с идентификаторите на клиенти, притежавани от продукти.
• Антропичните работни пространства разделят API ресурсите по случай на употреба, екип, отдел, проект или продукт. API ключовете са свързани с работното пространство, където са създадени, и не могат да се преместват между работните пространства.
• Антропичното отчитане на употребата и разходите поддържа групиране по API ключ, работно пространство, модел, ниво на услугата, контекстен прозорец, пребиваване на данни и свързани със скоростта опции, като разходите се връщат в дневни кофи в щатски долари.
• Указанията за ключовете на Google Gemini API препоръчват ограничаване на ключовете, а ключовете на Gemini API са ограничени до Generative Language API по подразбиране. Ограниченията на приложенията като IP адреси може да са налични в зависимост от формата на внедряване.
• Указанията на OWASP третират API ключовете като необходими контроли за защитени крайни точки и казват, че ключовете трябва да бъдат отменени, когато клиентите нарушат споразуменията за използване.
• Указанията за тайните на OWASP наблягат на най-малките привилегии, отмяната, когато тайните вече не са необходими или са компрометирани, и автоматизираната ротация за намаляване на грешките при внедряване.

Препоръки

• Използвайте клиентски ключове, издадени от шлюза, като манипулатори на правилата, а не само токени за удостоверяване.
• Пазете идентификационните данни на доставчика нагоре по веригата скрити от клиентите надолу по веригата.
• Напишете регистър на използването на шлюза при поискване, преди да разчитате на таблата за управление на доставчика.
• Използвайте проекти или работни пространства на доставчици избирателно за клиенти с висок риск, голям обем, регулирани, чувствителни към пребиваване или договорно разделени клиенти.
• Изграждане на ротация на ключове като работен процес на припокриване, а не като незабавно събитие на счупване.

Прогнози

• Повече доставчици ще разкрият по-богато групиране на употребата и контрол на бюджета, но приписването на клиентите, собственост на продукта, все още ще е необходимо за SaaS таксуване и отчитане на дистрибутори.
• Платформите за дистрибутори и агенции все повече ще третират ключовете на шлюза като търговски обекти: свързани с планове, кредитни салда, обхвати и работни потоци за поддръжка.
• Клиенти със стриктно съответствие или нужди от доставка ще поискат BYOK или собственост на акаунт на доставчик, докато повечето обикновени клиенти ще предпочетат договор за управляван шлюз.

Ключовият обект на шлюза

Ключът с обхват на клиента трябва да се преобразува в структуриран обект на политика. Като минимум моделирайте ключа като нещо повече от хеш и име.

<пре><код>{ "key_id": "ключ_01J9...", "tenant_id": "tenant_acme", "customer_id": "cust_4812","application_id": "app_support_bot", "среда": "производство", "собственик": { "тип": "сервизен_акаунт", "id": "svc_support_ai" }, "model_profile_id": "профил_поддържан_стандарт", "allowed_modalities": ["text", "image_input"], "tool_policy_id": "tools_readonly_kb", "месечен_бюджет": { "валута": "щатски долари", "сума": "500,00" }, "ограничения_на_скорост": { "заявки_на_минута": 120, "input_tokens_per_minute": 250000, "output_tokens_per_minute": 80000 }, "retention_policy": "само метаданни", "статус": "активен", "created_at": "2026-09-05T10:00:00Z", "последно_използвано_в": нула }

Точните полета ще варират, но принципът не трябва: всяка входяща заявка разрешава ключа в политиката на клиента преди изпращане. Удостоверяването отговаря на „кой се обажда?“ Резолюцията на правилата отговаря на „какво може да направи този обаждащ се, колко може да похарчи, къде може да се насочи заявката и какво трябва да се регистрира?“

Тук също има значение семантичната продуктова стратегия. Платформа, продаваща AI API за агенции, може да се нуждае от измерения на клиента и кампанията. Инструмент за разработчици може да се нуждае от размери на работно пространство и хранилище. Дистрибуторът може да се нуждае от външни идентификатори на клиенти, които съответстват на неговата система за таксуване.

Работен процес за създаване на ключ

Създаването на ключ трябва да бъде достатъчно детерминистично за автоматизация и достатъчно строго за преглед на сигурността.

1. Първо създайте клиентски запис

Не създавайте осиротели ключове. Ключът трябва да принадлежи на наемател и клиентски запис, преди да съществува. За платформи за дистрибутори клиентският запис трябва да включва външни идентификатори от CRM или системата за таксуване на дистрибутора, метаданни за плана, групиране на данъци или фактури, ако е необходимо, и поле за състояние, което може да спре всички дъщерни ключове.

2. Прикачете профил на модел

Профилът на модел съпоставя имената на моделите, ориентирани към клиента, към моделите и възможностите на доставчика. Например support-standard може да позволи балансиран текстов модел, въвеждане на изображение и без изпълнение на код. research-premium може да позволи модели с дълъг контекст, търсене в мрежата и по-високи тавани на заявка.

Не принуждавайте приложенията надолу по веригата да твърдо кодират идентификаторите на модела на доставчика. Използвайте профила на шлюза, за да управлявате наличността, резервния вариант, ценообразуването и отмяната.

3. Задаване на лимити за разходи и процент

Използвайте бюджети и лимити за тарифи заедно. Месечният бюджет предотвратява повреда на фактурите във времето. Ограниченията на скоростта предотвратяват внезапна злоупотреба, повторни бури или случайни цикли от изразходване на целия бюджет за минути.

Полезните контроли включват:

• Месечен клиентски бюджет.
• Ежедневно меко ограничение за откриване на аномалия.
• Процент на заявка за ключ.
• Процент на входни и изходни символи.
• Максимална прогнозна цена на заявка.
• Специфични ограничения за инструмента за хоствано търсене, обработка на файлове или изпълнение на код.

Прилагането на бюджета трябва да резервира прогнозните разходи преди изпращането, да уреди действителните разходи след приключване и да освободи неизползван резерв. Това свързва ключовата политика с таксуването на AI API вместо да третира таксуването като задача за отложено отчитане.

4. Генерирайте и съхранявайте тайната правилно

Покажете веднъж тайната на обикновен текст. Съхранявайте само силен хеш плюс кратък префикс или пръстов отпечатък за търсене на поддръжка. Префиксът помага на екипите за поддръжка да идентифицират „ключа, завършващ на 8F2A“, без да виждат тайната.

Типичен модел на съхранение е:

• key_id: стабилен идентификатор на база данни.
• secret_hash: хеш на пълната тайна, използвайки подходяща стратегия за хеширане на парола или токен.
• secret_prefix: кратък нечувствителен префикс на дисплея.
• пръстов отпечатък: детерминистичен идентификатор за одитно търсене.
• created_by: потребителски или партньорски API клиент, създал ключа.
• статус: активен, изтощаващ, отменен, поставен под карантина, изтекъл.

Никога не съхранявайте ключовете на доставчика нагоре по веригата в обекта на клиентския ключ. Идентификационните данни на доставчика принадлежат към отделен хранилище за идентификационни данни със собствени правила за достъп.

Принудително изпълнение по време на заявка

Шлюзът трябва да третира всяко моделно повикване като решение на политиката, последвано от изпращане на доставчика. Практичен път на заявка изглежда така:

1. Анализирайте представения ключ на шлюза.
2. Потърсете хеша на ключа и състоянието.
3. Разрешаване на клиент, клиент, приложение, среда, собственик и профил на модел.
4. Проверете дали наемателят и клиентът са активни.
5. Потвърдете искания псевдоним на модела, модалността, инструментите, режима на задържане, региона и нивото на услугата.
6. Оценете цената на заявката и резервирайте бюджет.
7. Проверете лимитите на скоростта и праговете за злоупотреба.
8. Изберете режим на идентификационни данни нагоре: обединен, обвързан с клиент или BYOK.
9. Изпращане до доставчика.
10. Уловете използване, цена, препратки на доставчици, грешки и сигнали за безопасност.
11. Уредете бюджетната резервация и запишете окончателното събитие в счетоводната книга.

Тази последователност държи шлюза отговорен за клиентския договор. Таблата за управление на доставчиците се превръщат във входни данни за съгласуване, а не в единствен източник на истина.

Използване на полета в Ledger, които действително помагат по-късно

Главната книга на шлюза трябва да съхранява достатъчно подробности, за да отговаря на въпроси за поддръжка, таксуване, злоупотреба и маршрутизиране, без да изисква необработено бързо съхранение по подразбиране.

Полезните полета включват:

• request_id и trace_id.
• tenant_id, customer_id, application_id и key_id.
• Идентификатор на краен потребител, за предпочитане псевдоним, където е подходящо.
• Псевдоним на модела, поискан от клиента.
• Разрешен доставчик и модел нагоре по веригата.
• Вход, изход, разсъждение, кеширане, аудио, изображение, видео и използване на инструменти, където е приложимо.
• Оферирана цена, резервирана сума, уредена цена, валута и каталожна версия на цените.
• Идентификационен номер на заявка на доставчик, препратка към отчета за използването, проект, работно пространство или измерение за групиране на ключове на API, ако е налично.
• Прилага се политика за задържане.
• Кодове за безопасност, злоупотреба или правила за вземане на решения.
• Категория на грешката и метаданни за повторен опит.

Тази структура поддържа сторниране на плащане, поддръжка на клиенти, реакция при инциденти и работен поток за управление на API ключове, който може да отговори на „какво направи този ключ?“ без да излагате несвързани наематели.

Режими на идентификационни данни: Обединени, обвързани с наемател и BYOK

Обединени идентификационни данни на доставчик

В режима по подразбиране много клиентски ключове преминават през по-малък набор от идентификационни данни на доставчик. Това е оперативно просто и намалява разрастването от страна на доставчика. Работи, когато шлюзът има силно приписване на клиенти, прилагане на бюджета, ограничаване на скоростта, изолиране на злоупотреби и контроли на границите на кеша.

Компромисът е, че отчитането от страна на доставчика може да показва само идентификационните данни на шлюза или проекта на доставчика. Трябва да присъедините записите на доставчика обратно към записите на главната книга на шлюза, за да генерирате фактуриране и анализи на ниво клиент.

Идентификационни данни на обвързан с наемателя доставчик

За по-големи или по-рискови наематели, обвържете наемател със специален проект на доставчик, работно пространство, акаунт за услуга или ключ. Това осигурява по-силно разделяне нагоре и може да опрости отчитането от страна на доставчика. Може също така да осигури твърда квотна защита, ако доставчикът поддържа ограничения на тази граница.

Цената е оперативна сложност. Осигуряването, ротацията, ограниченията на доставчиците, реакцията при инциденти и съгласуването вече се случват в повече обекти нагоре по веригата.

Донесете свой собствен ключ

BYOK може да бъде полезен, когато клиентите трябва да притежават акаунта на доставчика, да договорят свой собствен договор с доставчик или да поддържат отделно таксуване на доставчика. Шлюзът все още прилага профили на модели, правила за маршрутизиране, анализи и контроли на ниво приложение, където е възможно.

Компромисът е сложността на поддръжката. Акаунтът на доставчик на всеки клиент може да има различен модел на достъп, квоти, цени, настройки за задържане и статус на инцидент. Порталът трябва да открие и обясни ясно тези разлики.

Отмяна и карантина

Отмяната трябва да блокира незабавно новите заявки за клиентски ключ, без да се сменят идентификационните данни на несвързан доставчик нагоре по веригата. Това е едно от основните предимства на виртуалните ключове.

Използвайте отделни състояния за различни оперативни действия:

• активно: заявките са разрешени.
• източване: старият ключ се приема по време на прозорец за ротация, но се излъчват предупреждения и събития за проверка.
• revoked: новите заявки се отхвърлят за постоянно.
• карантинирани: новите заявки се блокират поради злоупотреба, плащане, правила или реакция при инцидент.
• изтекъл: ключът е изтекъл живота си и трябва да бъде заменен.

Карантината трябва да бъде обратима, когато инцидентът бъде разрешен. Отмяната обикновено не трябва да бъде обратима, тъй като възстановяването на стари тайни увеличава объркването и риска.

Когато ключ наруши правилата за използване, регистрирайте причината, актьора, времето и обхвата на прилагането. Ако решението е автоматизирано, запазете версията на правилото и сигналите, които са го задействали. Това поддържа разговорите с клиентите реалистични.

Ротация без прекъсване на производството

Ротацията на ключове трябва да използва работен процес с припокриване на два клавиша:

1. Създайте резервен ключ със същия клиент, приложение, профил на модела и ограничения, освен ако операторът не ги промени умишлено.
2. Покажете новата тайна веднъж.
3. Маркирайте стария ключ като източващ.
4. Приемете и двата ключа за ограничен период, например 7, 14 или 30 дни в зависимост от плана и риска на клиента.
5. Излъчване на предупреждения за използване на ключа за източване.
6. Уведомете собственика или партньорския API клиент, когато старият ключ все още се използва близо до крайния срок.
7. Анулирайте стария ключ в края на прозореца.
8. Съхранявайте приписването и на двата идентификатора на ключ при един и същи клиент и приложение.

Това избягва обичайния режим на повреда, при който подобрение на сигурността се превръща в прекъсване на производството. Ротацията все още е контрол, но се превръща в оперативен работен процес с доказателства и крайни срокове.

Партньорска API повърхност

Ако платформите надолу по веригата управляват клиенти програмно, изложете ключови операции чрез API на партньор. Приложният програмен интерфейс (API) трябва да поддържа ключове за идемпотентност и събития за одит, тъй като осигуряването често се случва в работните потоци за таксуване, адаптиране или CRM.

Минимални крайни точки:

• POST /customers: създайте или добавете клиент.
• POST /customers/{customer_id}/keys: създайте ключ.
• GET /customers/{customer_id}/keys: списък с ключове и състояния.
• PATCH /keys/{key_id}: актуализиране на обхвати, собственик, ограничения, профил на модел или състояние.
• POST /keys/{key_id}/rotate: създайте заместител и маркирайте стария ключ като изтощаващ.
• POST /keys/{key_id}/revoke: незабавно отмяна.
• GET /customers/{customer_id}/usage: връща потреблението и разходите по период от време, ключ, приложение, модел или измерение на краен потребител.

Всяка заявка за промяна трябва да приема ключ за идемпотентност. Всяка промяна трябва да записва одитно събитие с актьор, цел, полета преди и след, IP адрес на източника или идентичност на клиента и причина, където е налична.

Кога да използвате проекти или работни пространства на доставчик

Не третирайте ключовете на шлюза и границите на доставчика като взаимно изключващи се. Те решават различни проблеми.

Използвайте ключове за шлюз за нормален контрол на ниво клиент:

• Приписване на клиент.
• Ключове за всяко приложение.
• Бюджетни и тарифни ограничения.
• Бързо окачване.
• Ротационни работни процеси.
• Анализ на използването и отчитане на дистрибутори.

Добавете проекти на доставчик, работни пространства или специални идентификационни данни на доставчик, когато клиентът се нуждае от по-силно разделяне:

• Голям месечен обем, който заслужава специални квоти.
• Регулирани работни натоварвания с изрични изисквания за пребиваване или задържане.
• Договорно разделяне на фактурите.
• Твърди предпазни мерки за бюджет или квота от страна на доставчика.
• Специално наблюдение на злоупотреби или граници за проверка на безопасността.
• Акаунти на доставчици, притежавани от клиента чрез BYOK.

Практическият стандарт по подразбиране е наложена от шлюза изолация със селективни твърди граници нагоре по веригата. Това поддържа общия път прост, като същевременно запазва пътя за ескалация за клиенти, които се нуждаят от повече разделяне.

Контролен списък за внедряване

• Дефинирайте схема на клиентски ключ с наемател, клиент, приложение, среда, собственик, профил на модела, ограничения, политика за задържане и състояние.
• Хеширане на тайните в покой и показване на обикновен текст само веднъж.
• Отделни ключове за шлюз от хранилището на идентификационните данни на доставчика нагоре по веригата.
• Разрешете всяка заявка в политиката преди изпращане.
• Запазете бюджет преди обаждането на доставчика и уредете, след като стане известно окончателното използване.
• Записване на използването с клиент, ключ, псевдоним на модела, модел нагоре по веригата, категории токени, използване на инструмента, котирана цена, уредена цена и референции на доставчик.
• Внедрете активни, изтощаващи, отменени, поставени под карантина и изтекли състояния.
• Поддържа припокриване на ротация с два клавиша.
• Показва операциите на API на партньора с ключове за идемпотентност.
• Използвайте проекти или работни пространства на доставчици само когато оперативните им разходи са оправдани.

Изпълнимо заключение

Изолирането на клиентите за AI достъп обикновено трябва да започва от ключа на шлюза, а не от ключа на доставчика. Ключът на шлюза е договорът, обърнат към клиента: той посочва наемателя, клиента, приложението, моделния профил, бюджета, лимита на скоростта, правилото за задържане и политиката за одит. Ключът на доставчика е детайл за изпълнение зад този договор.

Тази архитектура дава на създателите на SaaS и платформите за дистрибутори бързо оттегляне, точно приписване, бюджети за всеки клиент, контролирана ротация и полезен анализ на използването, без да създава един проект на доставчик нагоре по веригата за всеки клиент по подразбиране. Използвайте проекти нагоре по веригата, работни пространства, обвързани с наематели идентификационни данни или BYOK, когато рискът, обемът, пребиваването или договорът го изискват. За обикновения път наложете изолация на клиента в главната книга на шлюза и механизма за правила, след което съгласувайте записите на доставчика след това.

Свързано четене

• idempotent Partner API осигуряване за клиенти, ключове и кредити