Прежде чем давать AI-агенту доступ к инструменту, стоит ответить на вопрос, который просят иногда пропустить для скорости: какие данные вообще находятся в контуре, и что агент сможет при этом увидеть. Если пропустить классификацию и пойти сразу выдавать права на Jira, GitLab и внутреннюю документацию, легко получить агента, который «всё видит», - вместе с полями, которым там делать нечего.
Права доступа отвечают на вопрос «кому и с какими ролями можно вызывать действие». Классификация данных отвечает на более ранний вопрос: «какие данные существуют в системе и где граница чувствительности». Без неё раздача инструментов превращается в согласование вручную или в правило «дай всё».
Две разные проблемы: «кому дать инструмент» и «какие данные в контуре»
Когда агент подключают к корпоративной системе, чаще всего обсуждают одно: может ли агент вызвать этот инструмент и с какими правами. Это вопрос ролей. Но инструмент возвращает данные, и вот данные из корпоративной системы попадают в контекст агента - а дальше потенциально куда угодно, включая внешние инструменты.
Поэтому модель доступа имеет два измерения:
- Роли и права: какое действие агент может выполнить (читать, писать, публиковать).
- Данные: какие поля, записи и системы вообще доступны этим действием.
Автоматически закрыть второе первым нельзя. Право «читать задачу в Jira» говорит, что агент может зайти, но не говорит, какие поля он обязан видеть, а какие не должен. Классификация данных отвечает на второе и делает возможным точечное маскирование.
Три категории: что отдавать всегда, выборочно и никогда
Проще всего разложить данные на три категории по ценности и риску. Для каждой настраивается отдельное поведение.
Можно всегда (низкий риск). Публичные описания, технические имена полей, структуры, документация без внутренних деталей. Агент может видеть их свободно в рамках своих ролей. Для таких данных политика доступа простая: разрешить по роли, без ручного согласования по каждой записи.
Выборочно (средний и высокий риск). Внутренние документы, исходники, данные клиентов, персональные данные внутри команд. Тут нужны правила: кто из агентов может, какие поля маскировать, какие операции писать ограничить. Именно на этот класс уходит большая часть работы.
Никогда (критичные, без исключений в общем случае). Секреты, ключи, строки подключения, токены всех видов. PII и чувствительные персональные данные тоже попадают сюда, если нет явного бизнес-сценария и средств маскирования. Такие данные не должны попадать в контекст агента вообще - ни через инструменты, ни через конфиги, ни через код.
Секреты и PII - отдельная категория «ни при каких условиях»
Категории «выборочно» и «никогда» иногда путают, а для секретов это критично. Секреты - это ровно тот случай, где «дай агенту почитать файл с конфигом, чтобы он понял окружение» звучит безобидно, а на практике открывает доступ к подключению к базе, сторонним API и проду.
Секреты должны жить отдельно от агентского контекста даже тогда, когда агент умеет с ними работать. Принцип простой: агенту отдаётся права и описания инструментов, а секрет downstream-системы держится на стороне управляемого шлюза, перехватывающего вызов. Так агент вызывает «Jira» без знания токена, а токен применяет точка доступа при реальном обращении.
Отдельно у PII свои правила: даже «разрешённые» персональные данные в запросах LLM-провайдеру - это передача чувствительных сведений наружу. Поэтому поля PII либо маскируются до вызова, либо агент вообще не получает к ним доступ. Правило: если данных нет в контексте - они не могут утечь.
Как классифицировать на практике
Классификация не обязана быть дорогим одномоментным проектом. Начните с инвентаризации и обновите по мере роста:
- Инвентаризация. Перечислите системы и поля, к которым агенты получат доступ. Отметьте, какие поля содержат секреты, PII, внутреннюю коммерческую информацию.
- Скоринг риска. Для каждого поля или класса данных определите: что будет, если оно утечёт. Секреты и PII - всегда высокий риск, внутренние технические детали - средний.
- Метки (labels). Проставьте каждой сущности категорию из трёх:
public,internal,restricted. Метка - это то, на что потом ссылаются политики. - Владелец данных. Назначьте человека, который отвечает за категорию и за то, кому её можно открывать. Без владельца классификация за год превращается в пустое оформление.
- Пересмотр. Раз в квартал сверяйте метки с реальными данными - поля появляются и меняются быстрее, чем кажется.
Ключевое: метки не для людей на бумаге, а для того, чтобы на них ссылались машины при принятии решения о доступе. Именно поэтому важна не столько точность «раз навсегда», сколько то, что у каждой метки есть автоматическое следствие.
Из классификации в исполнимые политики
Цель классификации - превратиться в автоматические правила, а не в очередь согласования. Вот как категория превращается в политику:
- Метка
public→ разрешить по роли, без ручного шага. - Метка
internal→ разрешить read-операции, писать только с подтверждением, поля PII маскировать. - Метка
restricted→ запретить по умолчанию, открывать точечно и временно.
Это принцип наименьших привилегий (least privilege) в применении к данным: агент получает минимальный набор данных, достаточный для его задачи. Вместе с маскированием чувствительных полей он сводит к минимуму и то, что попадает в контекст - а значит, и поверхность потенциальной утечки. OWASP MCP Top 10 прямо называет избыточные привилегии и широкий доступ к данным одним из ключевых рисков MCP-решений.
Где Codenik: классификация как политики на единой точке
Классификация даёт метки, но политики нужно где-то исполнять. Codenik - та единая точка, где классификация превращается в правила доступа:
- права выдаются на конкретные данные и инструменты, с учётом меток категории;
- секреты и токены downstream-систем не попадают в runtime агента - их применяет шлюз;
- чувствительные поля маскируются до того, как данные попадут в контекст;
- каждый доступ и запрос данных пишется в аудит.
То есть команда один раз классифицирует данные, а дальше правила исполняются автоматически, без ручного согласования каждого вызова. Про сам слой доступа без секретов - в статье «MCP без локальных секретов».
Короткий вывод
Классификация данных - это мост между «кому дать инструмент» и «что агент реально увидит». Разбейте данные на три категории - всегда, выборочно, никогда - и превратите их в автоматические политики с наименьшими привилегиями и маскированием чувствительных полей. Секреты и PII держите вне контекста агента по умолчанию.
Чем раньше категории станут машиночитаемыми метками, тем дешевле будет подключать каждого следующего агента - и тем меньше данных окажется там, где им быть не должно.