{"title":"Права доступа для AI-агентов: что нельзя отдавать модели","url":"https://verapointmedia.com/guides/prava-dostupa-dlya-ai-agentov/","markdownUrl":"https://verapointmedia.com/guides/prava-dostupa-dlya-ai-agentov.md","language":"ru","category":"guides","publishedAt":"2026-05-11T10:01:32.000Z","updatedAt":"2026-05-11T10:01:32.000Z","references":["https://owasp.org/www-project-top-10-for-large-language-model-applications/","https://www.nist.gov/itl/ai-risk-management-framework","https://developers.google.com/workspace/gmail/api/auth/scopes","https://developers.google.com/workspace/drive/api/terms","https://docs.github.com/en/rest/overview/permissions-required-for-fine-grained-personal-access-tokens"],"rights":"Public user-requested reading, summarization and citation allowed. Model training requires separate permission.","contentMarkdown":"# Права доступа для AI-агентов: что нельзя отдавать модели\n\n- Site: VeraPoint News\n- Section: Гайды\n- Date: 2026-05-11\n- Canonical: https://verapointmedia.com/guides/prava-dostupa-dlya-ai-agentov/\n- Markdown: https://verapointmedia.com/guides/prava-dostupa-dlya-ai-agentov.md\n- Summary: Главный риск AI-агента не в «силе модели», а в слишком широких правах. Разбираем, какие доступы можно давать, какие нельзя, и какой минимум логов и отката нужен до запуска.\n- SEO title: Безопасность AI-агентов: какие права доступа нельзя отдавать модели\n- SEO description: Разбираем права доступа AI-агентов: что можно разрешать, что опасно отдавать модели и как настроить контроль, логи и откат.\n- Target queries: безопасность ai агентов; права доступа ai агент; что нельзя доверять ai агенту; риски ai агентов; ai агент доступ к данным\n- Tags: #ai #security #agents #ai-agents #guide\n- Image: https://verapointmedia.com/static/content-assets/guides/prava-dostupa-dlya-ai-agentov/cover.webp\n\n## Sources\n\n- https://owasp.org/www-project-top-10-for-large-language-model-applications/\n- https://www.nist.gov/itl/ai-risk-management-framework\n- https://developers.google.com/workspace/gmail/api/auth/scopes\n- https://developers.google.com/workspace/drive/api/terms\n- https://docs.github.com/en/rest/overview/permissions-required-for-fine-grained-personal-access-tokens\n\n---\n\n## Короткий ответ\n\nГлавный риск AI-агента — не в том, что модель «слишком умная», а в том, что ей дали слишком широкие права. Безопасный принцип простой: читать можно больше, писать и удалять — только после ограничений, логов, подтверждения человека и понятного отката.\n\n![](https://verapointmedia.com/static/content-assets/guides/prava-dostupa-dlya-ai-agentov/slide-01.webp)\n\n\nГлавная ошибка в разговорах об AI-агентах обычно звучит слишком футуристично: люди спорят о том, «станет ли модель автономной», а реальный риск уже лежит на столе. Он скучнее и опаснее: **слишком широкий ключ, слишком длинный токен, слишком много прав и слишком мало журнала действий**.\n\nЯ посмотрела на эту тему не как на спор о будущем искусственного интеллекта, а как на обычную хозяйственную проблему: кому дали ключи, от какой двери, на какой срок и кто заметит, если человек — или модель — вошёл не туда. Если совсем по-бытовому, вопрос не в том, насколько модель умная. Вопрос в том, кто ей выдал связку от склада, бухгалтерии и редакционной кнопки «опубликовать».\n\nЧат-бот в худшем случае выдаёт плохой ответ. Агент может сходить в Gmail, прочитать Drive, открыть GitHub, запустить сценарий, отправить письмо, поменять запись в CRM или подготовить публикацию. То есть ошибка перестаёт быть текстовой. Она становится операционной.\n\nДля VeraPoint это часть не только разговора об [AI-агентах](/topics/ai-agents/), но и об [AI-безопасности](/topics/ai-security/). Если компания даёт модели права раньше, чем описывает рамки, она внедряет не «автономность», а новый источник тихих инцидентов.\n\n## Почему агент опаснее чат-бота\n\n![](https://verapointmedia.com/static/content-assets/guides/prava-dostupa-dlya-ai-agentov/slide-02.webp)\n\n\nЧат-бот в основном отвечает. Даже если ответ плохой, ущерб часто ограничен разговором.\n\nАгент отличается тем, что у него есть доступ к внешним системам:\n\n- почта;\n- файлы;\n- база знаний;\n- репозиторий;\n- CRM;\n- сайт;\n- внутренние API;\n- календарь или мессенджер.\n\nС этого момента вопрос звучит не «насколько умна модель», а «что именно она может сделать без человека». OWASP в списке рисков для LLM-приложений отдельно выделяет prompt injection и excessive agency. Это полезная пара: первая проблема заставляет модель следовать вредной инструкции, вторая делает вредную инструкцию дорогой, потому что у модели уже есть реальные полномочия.\n\nЕсли агент может только читать справочник, ущерб обычно ограничен ошибкой в понимании. Если он может удалить письмо, запустить платёж, опубликовать пост или открыть доступ к документу, цена ошибки резко растёт.\n\n## Минимальные права: только чтение по умолчанию\n\nГлавное правило простое: **начинать нужно не с «что агент умеет», а с «что ему точно не нужно»**.\n\nРабочий порядок такой:\n\n1. Сначала `только чтение`.\n2. Потом черновик или предложение действия.\n3. Потом отдельное подтверждение человеком.\n4. И только после этого ограниченное право записи там, где риск обратим и понятен.\n\nНа практике это означает:\n\n- отдельные токены под отдельные системы, а не один «суперключ»;\n- короткий срок жизни токена;\n- разные роли для чтения, черновика и изменения;\n- отдельные права на прод и на тестовую среду;\n- запрет на скрытые каскадные действия.\n\nGitHub прямо ведёт таблицы разрешений для fine-grained tokens: это хороший ориентир для любого агентного контура. Не «дай полный repo», а «дай ровно те permissions, которые нужны для конкретного endpoint». Та же логика должна работать и вне GitHub.\n\nGoogle в документации по Gmail scopes отдельно делит уровни доступа и предупреждает, что широкий доступ к данным пользователей требует более строгой проверки. Это хороший сигнал для любого владельца продукта: если платформа сама говорит, что определённые scopes считаются чувствительными или restricted, не надо выдавать их модели «для удобства».\n\n## Что нельзя отдавать модели без подтверждения\n\n![](https://verapointmedia.com/static/content-assets/guides/prava-dostupa-dlya-ai-agentov/slide-03.webp)\n\n\nЕсть пять зон, которые по умолчанию должны быть закрыты прямым human gate:\n\n### 1. Платежи и финансовые операции\n\nЕсли действие связано с деньгами, списанием, оплатой, выставлением счёта или изменением финансовых реквизитов, агент не должен исполнять его сам. Он может подготовить черновик, собрать данные, показать аномалии, но не нажимать финальную кнопку.\n\n### 2. Удаление\n\nУдаление писем, документов, веток, записей и файлов должно быть либо запрещено, либо уходить в карантин, корзину, архив, soft delete. «Удалить навсегда» без подтверждения человека для агентного контура почти всегда плохая идея.\n\n### 3. Публикация\n\nПубликация на сайт, отправка рассылки, пост в Telegram, LinkedIn или Facebook, изменение публичной страницы компании: всё это уже влияет на репутацию. Агент может собрать карточку публикации, проверить формат, добавить источники, но финальный publish должен оставаться за человеком.\n\n### 4. Исходящие сообщения от имени компании\n\nПисьмо клиенту, ответ партнёру, массовая рассылка, комментарий в issue, сообщение в Slack или Teams могут выглядеть «почти рутинно», но на практике это правовой и репутационный след. Допустимый режим для старта: агент готовит черновик, человек утверждает отправку.\n\n### 5. Персональные данные и чувствительный контент\n\nЕсли агент работает с почтой, документами, CRM, support-тредами или договорами, нужно отдельно описать, какие типы данных он вообще может читать. Restricted scopes и персональные данные нельзя считать «обычным контекстом». Это не память модели. Это чужие права и чужой риск.\n\n## Логи и откат: что должно остаться после каждого действия\n\nУ хорошего агентного процесса после каждого шага остаётся не только результат, но и след.\n\nМинимальный набор:\n\n- кто запустил сценарий;\n- какой был вход;\n- к каким системам агент обращался;\n- какие инструменты вызывал;\n- какие права использовал;\n- какой промежуточный результат получил;\n- что предложил изменить;\n- кто подтвердил опасный шаг;\n- как откатить действие назад.\n\nЕсли агент меняет внешнюю систему, у вас должен быть ответ на три вопроса:\n\n1. Что именно изменилось?\n2. Можно ли это отменить?\n3. Где это видно без чтения мыслей модели?\n\nДля Drive это может быть ограничение на изменение содержимого или разделение ролей только для чтения и редактирования. Для GitHub это отдельные permissions вместо общего write-доступа на всё. Для сайта это draft-only режим без права писать в `02_Published/` или запускать deploy.\n\nЛог без отката бесполезен как отчёт о пожаре после того, как сгорел склад. Нужны оба элемента.\n\n## Чеклист перед подключением агента к Gmail, Drive, GitHub, сайту или CRM\n\n![](https://verapointmedia.com/static/content-assets/guides/prava-dostupa-dlya-ai-agentov/slide-04.webp)\n\n\nНиже не «идеальная архитектура», а минимальный предзапусковой чеклист.\n\n### Gmail\n\n- Дайте только те scopes, которые реально нужны.\n- Не давайте send/delete доступ на первом этапе.\n- Запретите автоматическую отправку без human approval.\n- Логируйте, какие треды агент читал и какие черновики подготовил.\n\n### Google Drive\n\n- Начинайте с per-file или доступа только на чтение там, где это возможно.\n- Не давайте агенту право менять общие папки целиком «на всякий случай».\n- Разделяйте чтение, комментарии и редактирование.\n- Для чувствительных файлов заранее определите, что агент вообще не должен видеть.\n\n### GitHub\n\n- Используйте fine-grained permissions вместо широкого токена.\n- Отдельно отделяйте чтение issues, чтение кода, создание PR и изменение workflows.\n- Не давайте write к секретам, environments и deployments без крайней причины.\n- Любой merge, release или сценарий dispatch держите за подтверждением человека.\n\n### Сайт\n\n- Начинайте с чтения и подготовки draft, а не с публикации.\n- Отдельно разделяйте `01_Drafts/` и `02_Published/`.\n- Не запускайте deploy из агентного контура без review gate.\n- Логируйте, какой draft создан, какие ссылки проверены и кто утвердил перенос в publish.\n\n### CRM\n\n- Агент может классифицировать, тегировать и готовить черновик ответа.\n- Изменение стадии сделки, суммы, владельца или контакта должно быть ограничено.\n- Любая массовая операция должна иметь dry-run режим.\n- Храните журнал: какие записи тронуты и почему.\n\n## Простая развилка Веры\n\nЯ бы перед выдачей любого нового права задавала пять скучных, но спасительных вопросов:\n\n1. Если агент ошибётся, ущерб обратим?\n2. Есть ли журнал этого действия?\n3. Можно ли дать доступ только на чтение вместо write?\n4. Можно ли сначала дать draft вместо прямое действие?\n5. Есть ли конкретный человек, который отвечает за этот контур?\n\nЕсли хотя бы на один из первых четырёх вопросов ответ «нет», право выдавать рано.\n\n## Мой вывод для VeraPoint\n\nПосле этой проверки я думаю не про «страшный AI», а про скучные права доступа: главный риск AI-агента не в «сильной модели». Риск в том, что компании выдают модели полномочия быстрее, чем описывают процесс контроля.\n\nДля бизнеса это означает простую вещь: выигрыш даёт не тот, кто первым сказал «у нас агент», а тот, кто первым описал матрицу доступа, срок жизни токенов, точки подтверждения и логи. Для редакции это значит ещё жёстче: автоматизация без границ быстро превращает публикацию в репутационный долг.\n\nХороший агент делает меньше, чем обещают на демо, но делает это прозрачно. Плохой агент выглядит впечатляюще ровно до первого тихого инцидента.\n\n## Где я могу ошибаться\n\nСлишком жёсткие ограничения тоже вредны. Если не дать агенту никаких прав вообще, он останется дорогим чат-ботом с красивой вывеской. Польза появляется тогда, когда вы всё-таки открываете ему доступ к реальным данным и реальным инструментам.\n\nНо здесь и проходит граница зрелости:\n\n- сначала ограниченный сценарий;\n- потом доступ только на чтение;\n- потом draft;\n- потом подтверждение;\n- и только потом частичный write там, где есть откат.\n\nНельзя перескочить сразу к «пусть сам работает с Gmail, GitHub и сайтом». Это не смелость. Это плохой внутренний контроль.\n\n## Что сделать сегодня\n\nЕсли вы подключаете AI-агента в этом месяце, достаточно пяти шагов:\n\n1. Выпишите все системы, куда он просит доступ.\n2. Для каждой системы разделите `read`, `draft`, `write`, `publish`, `delete`.\n3. Запретите `publish` и `delete` по умолчанию.\n4. Введите короткие токены и отдельные роли вместо одного универсального ключа.\n5. Запустите один сценарий с полным логом и ручным подтверждением опасных действий.\n\nЭтого уже достаточно, чтобы перестать играть в «автономность» и начать строить управляемый агентный процесс.\n\n## Связанные материалы VeraPoint\n\n- [AI-безопасность](/topics/ai-security/)\n- [AI-агенты](/topics/ai-agents/)\n- [Иллюзия автономии: как Agentic AI стал массовым самообманом](https://verapointmedia.com/investigations/illyuziya-avtonomii-kak-agentic-ai-stal-massovym-samoobmanom/)\n## Частые вопросы\n\n### Какие права нельзя давать AI-агенту?\n\nОпасно сразу давать удаление данных, отправку писем от имени человека, платежи, массовое изменение файлов и доступ к чувствительным данным без ограничений.\n\n### Как безопасно дать AI-агенту доступ к файлам?\n\nНачинайте с read-only доступа, отдельной папки, минимальных прав, логов и тестового набора данных.\n\n### Нужен ли человеку контроль над AI-агентом?\n\nДа. Критичные действия должны проходить через подтверждение человека или отдельный approval-шаг.\n\n### Что важнее всего проверить перед запуском?\n\nПрава доступа, журнал действий, сценарий ошибки, откат изменений и то, кто отвечает за последствия.\n\n\n## Источники\n\n- OWASP Top 10 for Large Language Model Applications: https://owasp.org/www-project-top-10-for-large-language-model-applications/\n- NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework\n- Google Workspace, Choose Gmail API scopes: https://developers.google.com/workspace/gmail/api/auth/scopes\n- Google Drive API Terms: https://developers.google.com/workspace/drive/api/terms\n- GitHub Docs, permissions required for fine-grained personal access tokens: https://docs.github.com/en/rest/overview/permissions-required-for-fine-grained-personal-access-tokens\n"}