Учётные данные и защита аккаунта

Три вида учётных данных решают разные задачи: вход в браузере открывает рабочую область компании, ключ Model API разрешает запросы к моделям, а управляемый владельцем токен Partner API — управление ресурсами. Они не взаимозаменяемы.

Авторизация запросов

Вызовы OpenAI-совместимого API используют заголовок Bearer:

Authorization: Bearer mg_live_...
Content-Type: application/json

Для Anthropic Messages также принимаются собственные заголовки протокола:

x-api-key: mg_live_...
anthropic-version: 2023-06-01
Content-Type: application/json

Запрос:

curl https://api.b2b-llm.com/v1/models \
  -H "Authorization: Bearer $B2B_API_KEY"

Ответ с пустым каталогом, показанным только как пример структуры:

{"object":"list","data":[]}

От чьего имени выполняется запрос

Долгоживущие учётные данные сохраняют закреплённого пользователя. Применяются статус этого пользователя, его API-ограничения по IP и персональные лимиты; за списания отвечает компания. При выборе общего ключа проекта в Playground вместо этого выдаётся краткосрочное разрешение браузера, привязанное к вошедшему сотруднику. Требуется право выполнения в группе; личные ограничения сотрудника сохраняются. Выбор ключа проекта владельца не передаёт финансовые права владельца.

Многоразовые секреты другого участника не раскрываются разработчикам проекта. Управление учётными данными владельцем или администратором организации отделено от права пользоваться Playground. Для серверных интеграций и долговременных пакетных/асинхронных задач используйте отдельные учётные данные приложения; временные браузерные сеансы предназначены только для непосредственных запросов из интерфейса.

Подтверждение аутентификатором

Для TOTP используются шестизначные коды аутентификатора с периодом 30 секунд. Важные действия в рабочей области принимают недавнее успешное подтверждение второго фактора в течение 60 минут по умолчанию. Этот интервал не является сроком жизни отдельного кода. У ожидающей подтверждения формы есть собственный короткий срок; повторное использование кодов не допускается.

Организация может потребовать аутентификатор для участников. Одноразовые коды восстановления показываются только при создании. Изменение учётных данных безопасности или политики аннулирует устаревшие браузерные сеансы. При запросах к Model API приложения не должны передавать коды аутентификатора.

Сеансы и сетевая политика

Стандартные ограничения браузерного входа — 12 часов бездействия и семь дней общего срока. Поведение cookie может завершить сеанс раньше. При истёкшем входе предлагается авторизоваться. Устаревший защитный токен страницы требует обновить её. Неуспешные изменения автоматически не повторяются после входа.

Если настроены личные и корпоративные списки разрешённых API IP, применяются оба. Укажите фактический исходящий IPv4/IPv6-адрес или CIDR, включая выход через NAT. Списки для входа в аккаунт настраиваются отдельно. Храните рабочие секреты в защищённом хранилище, меняйте раскрытые значения и не включайте заголовки Bearer во вложения поддержки.

Изменения состава команды и общие интеграции

Для управляемых аккаунтов сотрудников используйте Команду. Роль аккаунта и роль в проекте — отдельные решения: сотрудник по расчётам может просматривать кошелёк компании без автоматического участия в проекте, а разработчик проекта — выполнять разрешённые запросы без доступа к финансам компании. Администратор компании управляет обычными сотрудниками, но не владельцем, другим администратором или собой. Только владелец назначает администраторов компании, меняет роли аккаунтов и общую политику безопасности.

Перед каждым важным действием показываются его текущие последствия. Просмотрите аккаунт, изменение роли или проекта и затронутые ключи, затем подтвердите. Если до подтверждения состояние изменит другой руководитель или сотрудник, операция остановится без частичного применения. Обновите Команду и изучите Журнал действий, а не повторяйте отправку с неизвестным сетевым результатом. К этим действиям применяется тот же описанный выше срок свежести второго фактора.

Деактивировать аккаунт сохраняет запись сотрудника и email, обращения в поддержку, принадлежность запросов и учёт. Доступ блокируется, права проектов отзываются, сеансы и учётные данные сотрудника аннулируются. Архив деактивированных аккаунтов поддерживает поиск и страницы. Пригласить снова создаёт новое приглашение и пароль; нужную роль выбирайте явно. Отозванные права и ключи не восстанавливаются после принятия — их нужно выдать или заменить отдельно. Заморозить временно приостанавливает активного участника; Разморозить не восстанавливает отозванные секреты. Через Команду нельзя снять независимое ограничение платформы. Замороженная запись, созданная до учёта происхождения восстановления, сначала требует проверки платформой.

Ключ уходящего сотрудника может использоваться коллегами или серверной интеграцией. До деактивации Передать общие учётные данные позволяет передать неотозванный набор другому активному участнику компании с правом выполнения во всех затронутых проектах. При этом все затронутые секреты перевыпускаются. Установите новые через отдельно защищённый раздел API-ключи; не предполагайте, что старая конфигурация приложения продолжит работать. ID ключей, лимиты расходов и накопленные списания сохраняются, исторические запросы остаются за первоначальными исполнителями. Автоматического переноса на общий сервисный аккаунт нет.

Массовая заморозка или деактивация ограничена 50 выбранными аккаунтами и использует одно подтверждение для всего набора. Один устаревший или недоступный элемент блокирует всю операцию. Изменения безопасности компании и ключей записываются в журнал без раскрытия паролей или токенов. Кэшированные разрешения могут кратковременно действовать в пределах настроенного интервала; уже выполняющиеся запросы задним числом не отменяются.

Смена юридического/платёжного владельца — не изменение роли в Команде. Текущий владелец может открыть Компания → Подготовить запрос на смену владельца, просмотреть заполненное сообщение поддержки и отправить его. Само открытие формы ничего не меняет. Передача владельца, средств и исторических документов требует отдельной авторизованной проверки и процедуры; автоматического переноса кошелька нет.

Работа с квотами проекта

Рассматривайте пропускную способность и бюджет как разные уровни. RPM ограничивает число запросов за время, concurrency — одновременную работу. Квота использования ключа и квота проекта применяются обе вместе с доступными средствами компании. Ноль отключает только соответствующий уровень.

Usage Limit, USD измеряет текущий расчётный счётчик, а не совокупные списания за всё время. Уполномоченный управляющий может переопределить базу или коэффициент расчёта проекта; итоговая сумма учитывается в обоих счётчиках без повторного списания с кошелька компании.

На странице проекта Сбросить счётчик использования доступно владельцу компании и требует стандартного недавнего подтверждения безопасности. Сброс квоты ключа остаётся у уполномоченных управляющих ключами. Каждая операция сбрасывает только свой счётчик, сохраняя другой уровень, балансы и историю учёта. Интерфейс показывает остаток лимита и время сброса в UTC.

Лимиты обновляются по периодическому расчёту, а не предварительному резервированию. Уже допущенная работа может превысить предел; запрос, завершившийся после сброса, учитывается в новом интервале. Сам по себе просмотр или выполнение через общий ключ не даёт права управлять квотой.

Отдельное разрешение Images

Вкладка Business Images выдаёт отдельное короткое разрешение mg_image_, привязанное к фактическому сотруднику, сеансу, ключу проекта и профилю API. Его области — чтение, одно запечатанное создание или повтор скачивания одной операции. Принятые задания сохраняют личность исполнителя, а не многоразовые учётные данные, и требуют действующего разрешения перед отправкой поставщику. Секрет компании никогда не раскрывается. Это исключение не разрешает обычные async/Batch со старыми браузерными сеансами.