Ключи API AI на уровне клиента: изолируйте арендаторов, бюджеты и злоупотребления без разрастания ключей поставщика
Продукты SaaS, агентства и платформы реселлеров нуждаются в доступе к искусственному интеллекту на уровне клиента без раскрытия учетных данных вышестоящего поставщика. Используйте виртуальные ключи, выданные шлюзом, в качестве дескрипторов политик для атрибуции клиентов, доступа к моделям, бюджетов, ограничений ставок, отзыва, ротации и журналов использования.
Когда продукт позволяет множеству клиентов вызывать модели искусственного интеллекта, зачастую неправильный примитив является ключом вышестоящего поставщика. Ключ поставщика обычно представляет собой учетную запись учетной записи, проекта, рабочей области или службы. Вашему продукту нужно что-то более узкое: ключ, ориентированный на клиента, который идентифицирует одного арендатора, клиента, приложение, среду, модельную политику, бюджет и правило аудита.
В этом и заключается цель ключей API AI на уровне клиента. Шлюз выдает ключ, аутентифицирует запросы, применяет политику, измеряет использование, а затем вызывает вышестоящих поставщиков, используя скрытые учетные данные. Последующие клиенты никогда не получают ключ поставщика. Они получают стабильный контракт с вашей платформой.
Проблема читателя: изоляция клиентов без одного проекта поставщика на каждого клиента
Строителям SaaS, агентствам и платформам реселлеров обычно необходимо ответить на практические вопросы, прежде чем они смогут предоставить доступ к ИИ в дальнейшем:
<ул>Проекты и рабочие пространства на стороне поставщика могут помочь, но они не всегда подходят для каждого последующего клиента. Создание одной восходящей границы для каждого клиента может улучшить жесткую изоляцию и отчетность, но это также приводит к накладным расходам на предоставление ресурсов, фрагментации квот, разрастанию учетных данных и увеличению объема работы по сверке.
Ключ, выданный шлюзом, дает продукту точку управления на уровне клиента, даже если восходящие учетные данные объединены в пул. Он также поддерживает более строгие режимы, такие как учетные данные поставщика с привязкой к клиенту или использование собственного ключа, когда клиенту требуется разделение по договору, границы резидентности или прямое владение учетной записью поставщика.
Факты, рекомендации и прогнозы
Факты
<ул>Рекомендации
<ул>Прогнозы
<ул>Ключевой объект «Шлюз»
Ключ на уровне клиента должен разрешаться в объект структурированной политики. Как минимум, смоделируйте ключ как нечто большее, чем просто хэш и имя.
{
"key_id": "key_01J9...",
"tenant_id": "tenant_acme",
"customer_id": "cust_4812","application_id": "app_support_bot",
«окружающая среда»: «производство»,
"владелец": {
"type": "service_account",
"id": "svc_support_ai"
},
"model_profile_id": "profile_support_standard",
"allowed_modalities": ["текст", "image_input"],
"tool_policy_id": "tools_readonly_kb",
"monthly_budget": {
"валюта": "доллар США",
"сумма": "500,00"
},
"rate_limits": {
«запросы_в_минуту»: 120,
«input_tokens_per_mine»: 250000,
«output_tokens_per_mine»: 80000
},
"retention_policy": "только метаданные",
"статус": "активен",
"create_at": "2026-09-05T10:00:00Z",
«last_used_at»: ноль
Точные поля могут различаться, но принцип не должен быть таким: каждый входящий запрос преобразует ключ в политику клиента перед отправкой. Аутентификация отвечает «кто звонит?» Разрешение политики отвечает на вопрос: «Что может делать этот вызывающий абонент, сколько он может потратить, куда может направляться запрос и что должно регистрироваться?»
Здесь также важна семантическая стратегия продукта. Платформе, продающей AI API для агентств, могут потребоваться измерения клиентов и кампаний. Инструменту разработчика могут потребоваться размеры рабочей области и репозитория. Реселлеру могут потребоваться внешние идентификаторы клиентов, соответствующие его платежной системе.
Рабочий процесс создания ключей
Создание ключей должно быть достаточно детерминированным для автоматизации и достаточно строгим для проверки безопасности.
1. Сначала создайте запись о клиенте
Не создавайте потерянные ключи. Прежде чем ключ появится, он должен принадлежать арендатору и записи клиента. Для платформ реселлера запись о клиенте должна включать внешние идентификаторы из CRM или платежной системы реселлера, метаданные плана, группировку налогов или счетов, если это необходимо, а также поле статуса, которое может приостановить действие всех дочерних ключей.
2. Прикрепите профиль модели
Профиль модели сопоставляет названия моделей, ориентированных на клиента, с моделями и возможностями поставщиков. Например, support-standard может разрешить сбалансированную текстовую модель, ввод изображений и отсутствие выполнения кода. research-premium может поддерживать модели с длинным контекстом, веб-поиск и более высокие ограничения на количество запросов.
Не заставляйте нижестоящие приложения жестко запрограммировать идентификаторы модели поставщика. Используйте профиль шлюза для управления доступностью, резервным вариантом, ценами и прекращением поддержки.
3. Установите лимиты расходов и ставок
Используйте бюджеты и ограничения ставок вместе. Ежемесячный бюджет предотвращает повреждение счетов с течением времени. Ограничения скорости не позволяют внезапным злоупотреблениям, штормам повторных попыток или случайным циклам расходовать весь бюджет за считанные минуты.
Полезные элементы управления включают:
<ул>Соблюдение бюджета должно зарезервировать сметную стоимость перед отправкой, рассчитать фактическую стоимость после завершения и высвободить неиспользованный резерв. Это связывает ключевую политику с выставлением счетов AI API вместо того, чтобы рассматривать выставление счетов как задачу отложенной отчетности.
4. Правильно создавайте и храните секрет
Отобразите секретный текст открытого текста один раз. Сохраняйте только надежный хэш, а также короткий префикс или отпечаток пальца для поиска в службе поддержки. Префикс помогает службам поддержки идентифицировать «ключ, заканчивающийся на 8F2A», не видя секрета.
Типичный шаблон хранения:
<ул>key_id: стабильный идентификатор базы данных.secret_hash: хэш полного секрета с использованием соответствующего пароля или стратегии хеширования токена.secret_prefix: короткий неконфиденциальный префикс отображения.отпечаток пальца: детерминированный идентификатор для аудита.created_by: пользователь или партнер API-клиент, создавший ключ.статус: активен, опорожняется, отозван, помещен в карантин, срок действия истек.Никогда не храните ключи вышестоящего поставщика в объекте ключа клиента. Учетные данные поставщика хранятся в отдельном хранилище учетных данных с собственными правилами доступа.
Принудительное соблюдение времени запроса
Шлюз должен рассматривать каждый вызов модели как политическое решение, за которым следует отправка поставщика. Практический путь запроса выглядит следующим образом:
<ол>Эта последовательность возлагает на шлюз ответственность за договор с клиентом. Информационные панели поставщиков становятся входными данными для сверки, а не единственным источником достоверной информации.
Поля книги использования, которые действительно помогут в дальнейшем
Регистр шлюза должен сохранять достаточно подробностей, чтобы отвечать на вопросы о поддержке, выставлении счетов, злоупотреблениях и маршрутизации, не требуя по умолчанию хранения необработанных подсказок.
Полезные поля включают в себя:
<ул>request_id и trace_id.tenant_id, customer_id, application_id и key_id.Эта структура поддерживает возврат платежей, поддержку клиентов, реагирование на инциденты и рабочий процесс управления ключами API, который может ответить на вопрос: «Что сделал этот ключ?» без раскрытия несвязанных арендаторов.
Режимы учетных данных: пул, привязка к клиенту и BYOK
Объединенные учетные данные поставщика
В режиме по умолчанию многие ключи клиентов проходят через меньший набор учетных данных поставщика. Это просто с эксплуатационной точки зрения и уменьшает разрастание ресурсов на стороне провайдера. Это работает, когда шлюз имеет строгую атрибуцию клиентов, принудительное соблюдение бюджета, ограничение скорости, изоляцию злоупотреблений и контроль границ кэша.
Недостаток заключается в том, что в отчетах на стороне поставщика могут отображаться только учетные данные шлюза или проект поставщика. Вам необходимо объединить записи поставщиков с записями шлюзовой книги, чтобы выставлять счета и проводить аналитику на уровне клиентов.
Учетные данные поставщика, привязанного к клиенту
Для более крупных или более рискованных клиентов привяжите арендатора к выделенному проекту поставщика, рабочей области, учетной записи службы или ключу. Это обеспечивает более четкое разделение восходящих потоков и может упростить отчетность на стороне поставщика. Он также может обеспечить жесткое ограничение квоты, если провайдер поддерживает ограничения на этой границе.
Цена связана со сложностью эксплуатации. Предоставление ресурсов, ротация, ограничения поставщиков, реагирование на инциденты и сверка теперь выполняются в большем количестве вышестоящих объектов.
Принесите свой ключ
BYOK может быть полезен, когда клиенты должны владеть учетной записью поставщика, заключать собственный контракт с поставщиком или вести отдельную оплату счетов поставщика. Шлюз по-прежнему применяет профили модели, политику маршрутизации, аналитику и элементы управления на уровне приложения, где это возможно.
Компромисс — сложность поддержки. Учетная запись поставщика каждого клиента может иметь разные модели доступа, квоты, цены, настройки хранения и статус инцидента. Шлюз должен четко выявлять и объяснять эти различия.
Отзыв и карантин
Отзыв должен немедленно блокировать новые запросы на ключ клиента без замены учетных данных несвязанного вышестоящего поставщика. Это одно из главных преимуществ виртуальных ключей.
Используйте отдельные состояния для разных операционных действий:
<ул>активен: запросы разрешены.очистка: старый ключ принимается во время ротации, но выдаются предупреждения и события аудита.отозван: новые запросы отклоняются навсегда.на карантине: новые запросы блокируются из-за злоупотреблений, оплаты, политики или реакции на инцидент.истек: срок действия ключа истек, и его необходимо заменить.Карантин должен быть обратимым после разрешения инцидента. Отзыв обычно не должен быть обратимым, поскольку восстановление старых секретов увеличивает путаницу и риск.
Если ключ нарушает политику использования, зарегистрируйте причину, исполнителя, время и объем применения мер. Если решение было автоматизировано, сохраните версию правила и сигналы, которые его активировали. Это сохраняет актуальность разговоров с клиентами.
Ротация без остановки производства
При ротации клавиш следует использовать рабочий процесс с перекрытием двух клавиш:
<ол>освобождаемый.Это позволяет избежать распространенного режима сбоя, когда улучшение безопасности приводит к остановке производства. Ротация по-прежнему является средством контроля, но она становится оперативным рабочим процессом с доказательствами и сроками.
Поверхность партнерского 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-адреса или идентификатора клиента, а также причины, если таковая имеется.
Когда использовать проекты или рабочие области поставщика
Не рассматривайте ключи шлюза и границы провайдера как взаимоисключающие. Они решают разные проблемы.
Использовать ключи шлюза для обычного контроля на уровне клиента:
<ул>Добавьте проекты поставщиков, рабочие области или выделенные учетные данные поставщика, если клиенту требуется более строгое разделение:
<ул>Практическим значением по умолчанию является изоляция на уровне шлюза с выборочными жесткими границами восходящего потока. Это упрощает общий путь, сохраняя при этом путь эскалации для клиентов, которым требуется большее разделение.
Контрольный список реализации
<ул>Практическое заключение
Изоляция клиента для доступа к ИИ обычно должна начинаться с ключа шлюза, а не с ключа поставщика. Ключ шлюза — это контракт, ориентированный на клиента: в нем указаны арендатор, клиент, приложение, профиль модели, бюджет, ограничение скорости, правило хранения и политика аудита. Ключ поставщика — это деталь реализации этого контракта.
Эта архитектура обеспечивает сборщикам SaaS и платформам реселлеров быстрый отзыв, точную атрибуцию, бюджеты для каждого клиента, контролируемую ротацию и полезную аналитику использования без создания по умолчанию одного проекта вышестоящего поставщика для каждого клиента. Используйте вышестоящие проекты, рабочие области, учетные данные, привязанные к арендатору, или BYOK, когда этого требуют риск, объем, местонахождение или контракт. Для обычного пути необходимо обеспечить изоляцию клиентов в реестре шлюзов и механизме политик, а затем согласовать записи поставщиков.