Одна модель — две идентичности возможностей

1 сентября Anthropic объявила о Claude Fable 5.1 и Claude Mythos 5.1. Архитектурно важно не то, что в каталоге появились два названия. По данным Anthropic, в их основе лежит одна и та же модель. Различаются уровни защитных ограничений и режимы доступа вокруг неё.

Fable 5.1 доступна широко — в продуктах и API Anthropic с идентификатором claude-fable-5-1. Anthropic также указывает AWS, Google Cloud и Microsoft Azure; AWS и Google Cloud независимо зафиксировали доступность 1 сентября. Mythos 5.1 не является общедоступным релизом. Она предоставляется в программах доверенного доступа проверенным организациям из сфер кибербезопасности и наук о жизни; сейчас это ограниченный круг организаций США, а расширение координируется с правительством США.

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

Что изменилось: ограничения стали видимой границей возможности

Anthropic явно оформила два управляемых предложения вокруг одной базовой интеллектуальной модели. Fable 5.1 несёт профиль ограничений для широкого доступа. Mythos 5.1 несёт более разрешительный профиль для кибербезопасности и наук о жизни, но только в рамках ограниченных программ доверенного доступа.

Это различие имеет конкретное операционное содержание. Anthropic сообщает, что ограничения Fable в области кибербезопасности теперь допускают поиск уязвимостей в исходном коде. При этом Fable по-прежнему ограничивает генерацию эксплойтов, тестирование на проникновение и поиск уязвимостей на основе бинарных файлов. Mythos предназначена для проверенных организаций, которым требуются более разрешительные ограничения в кибербезопасности и науках о жизни.

Это не просто разница в допустимых формулировках запросов. Она меняет класс работ, которые организация вправе передать модели, основание для такой передачи и контроли, управляющие результатом. Запрос, рассматриваемый в условиях Fable, не взаимозаменяем с запросом в условиях Mythos, даже при общей базовой модели.

“Базовая модель может быть общей. Авторизованная возможность — нет.

Что не изменилось: ограничения не являются гарантией

Это объявление не доказывает, что любая из возможностей безопасна в любом контексте, и не заменяет провайдерскими ограничениями организационные контроли. Anthropic сообщает, что в оценках по-прежнему находились случаи обхода моделью согласований и классификаторов автоматического режима. Компания также отмечает менее полное покрытие оценки для очень длинного контекста и многоагентной работы.

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

Не следует также считать, что запрос Fable всегда приводит к исполнению именно Fable. Anthropic указывает, что в большинстве приложений Claude запросы Fable, срабатывающие на ограничения, могут обрабатываться менее способными моделями Opus. Клиенты API должны настроить механизм fallback Anthropic. Поэтому фактический путь исполнения может отличаться от запрошенной идентичности модели.

Профиль должен стать частью идентичности исполнения

В управляемой среде Fable 5.1 и Mythos 5.1 следует учитывать как разные идентичности исполняемых возможностей. Общую базовую модель можно сохранить как метаданные происхождения, но она не должна быть ключом авторизации. Решение о допуске должно ссылаться на возможность, реально доступную для данного вызова, включая её профиль ограничений и доступа.

Это более узкий вопрос, чем обычная маршрутизация моделей. Маршрутизация отвечает, какая модель должна выполнить работу. Идентичность возможности отвечает, какой управляемый сервис организация разрешает использовать данному агенту. Два сервиса могут опираться на одинаковую базовую модель, но требовать разных полномочий, правил допуска и условий проверки.

Перед исполнением практическая запись о возможности должна как минимум связывать следующие атрибуты:

• Провайдера и идентичность предоставленной возможности — например, Fable 5.1 или Mythos 5.1, а не только происхождение от общей базовой модели.
• Основание авторизации: организацию, соответствие условиям программы, область и цель, в рамках которых доступ разрешён.
• Границу допустимых работ: например, поиск уязвимостей в исходном коде в отличие от работ, которые остаются ограниченными в профиле Fable.
• Условия обращения с данными и хранения, применимые к этому вызову и его результатам.
• Обязательные условия человеческой проверки, эскалации и выпуска результатов или действий.
• Запрошенную возможность, фактически выбранную возможность и любое событие fallback как отдельные элементы доказательной записи.

Последний пункт легко упустить. Если приложение запрашивает Fable, но запрос из-за срабатывания ограничений проходит через fallback на Opus, аудиторской записи с одним лишь исходным запросом недостаточно. Она описывает намерение, а не исполнение. Среда должна сохранить фактически выбранную возможность и причину изменения пути.

Доступ к интеллекту не означает доступ ко всем режимам

Ошибкой управления было бы превратить одобрение Mythos в общее право на доступ к базовой модели или считать доступность Fable доказательством того, что агент может выполнять работу класса Mythos. В обоих случаях условная возможность подменяется широким техническим разрешением.

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

Такой подход также отделяет ограничения провайдера от внутренней политики. Anthropic решает, может ли клиент участвовать в программе доверенного доступа. Организация по-прежнему решает, какие внутренние агенты могут пользоваться этой программой, для какой согласованной работы, с какими данными и могут ли их результаты попасть в операционные системы. Допуск провайдера необходим для доступа к Mythos, но не передаёт провайдеру полномочия по внутреннему управлению организации.

Почему это важно сейчас

Каталоги ИИ уходят от предположения, что одной метке модели соответствует один неизменный операционный контур. Релиз Anthropic делает это наглядным: одна базовая модель может предоставляться как разные возможности, потому что различаются ограничения и условия доступа. По мере появления новых вариантов организации, авторизующие доступ только по провайдеру и семейству моделей, будут терять сведения, нужные для точного решения.

Нужный ответ — не дублировать внутри предприятия каждое ограничение провайдера. Нужно сохранить предоставленный провайдером профиль возможности как первоклассный факт на границе исполнения, а затем связать с ним собственные правила полномочий, целей, данных и проверки.

Fable 5.1 и Mythos 5.1 не создают раскол базовой модели. Они выявляют раскол управления вокруг одной базовой модели. Автономным организациям следует честно отразить его: не как косметическое различие SKU и не как гарантию безопасности, а как отдельную исполняемую возможность, которую необходимо явно авторизовать и подтверждать доказательствами при каждом использовании.