# Дать агенту рабочую почту и сервер компании: как решать

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

URL: https://posts.danashkin.ru/guides/dostup-agenta-k-pochte-i-serveru
Обновлено: 2026-09-01

---

## Коротко

**Главное**

- Вопрос «можно ли дать агенту рабочую почту и файловый сервер» решается не настройками, а моделью прав: агент получает ровно то, что получил бы новый сотрудник в твоей роли.
- Технически ты ничего секретного в переписку не отдаёшь: ключи доступа вносятся в отдельный файл на твоём компьютере, а не диктуются в чат.
- Юридически всё, что агент прочитает, уходит на серверы поставщика сервиса. Для документов под соглашением о неразглашении это не мелочь, а предмет отдельного решения.
- Решение принимаешь не ты один. В компании за это отвечает служба безопасности, юрист или тот, кто подписывал соглашения с клиентами.
- Пока разрешения нет, работает обходной путь: выгрузка, обезличивание, отдельная папка. Он медленнее, но не ставит под удар твой рабочий инструмент.

## Что на самом деле спрашивают, когда спрашивают про безопасность

**Главное**

Не инструкцию по подключению, а гарантию. За вопросом «можно ли дать доступ к серверу» почти всегда стоит страх сломать или обнародовать то, на чём держится работа. Отвечать надо именно на страх, а не на техническую часть.

Формулировка, которую я слышу на обучениях чаще всего, звучит примерно так: я хочу понять, есть ли у вас опыт клиентов, которые подключали свои серверы, насколько это безопасно, я немножко волнуюсь.

Разберём, что здесь спрошено на самом деле. Человек шесть лет держит все рабочие документы на корпоративном сервере и ничего не хранит у себя на компьютере. Сервер для него не хранилище, а рабочий инструмент: без него он завтра не работает.

Поэтому опасений на самом деле три, и они разные:

- **Сломает.** Агент что-нибудь удалит, перепишет, перенесёт не туда.
- **Утечёт.** Содержимое документов уйдёт наружу и всплывёт там, где не должно.
- **Прилетит.** Компания узнает, что доступ дали без спроса, и виноват будет тот, кто дал.

Первое снимается правами. Второе - пониманием, что и куда уходит. Третье - разговором с человеком, который в компании за это отвечает. Смешивать их в один ответ бессмысленно.

## Модель прав нового сотрудника

**Главное**

Самая рабочая рамка: [ИИ-агент](/concepts/ai-agent) получает те же права, что новый сотрудник на твоём месте. Если у тебя нет прав на удаление в общей папке, у агента их тоже не будет. Он работает от твоей учётной записи и не может больше тебя.

Эта рамка снимает половину тревоги за минуту, потому что переводит незнакомую ситуацию в знакомую.

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

С агентом ровно так же. Он ходит в те же места, куда пускает твоя учётная запись, и упирается в те же запреты. Разница только в скорости: он делает больше действий за единицу времени, а значит ошибка масштабируется быстрее.

Отсюда практические выводы:

| Что делаем | Зачем |
|---|---|
| Даём доступ к одной папке, а не ко всему серверу | Ограничивает область даже теоретической ошибки |
| Начинаем с режима «только чтение» | Читать безопасно, писать - уже решение |
| Требуем подтверждения на действия с файлами | Убирает класс ошибок «сделал раньше, чем ты понял» |
| Заводим отдельную рабочую папку под проект | Изолирует эксперименты от боевых документов |

Про то, почему нельзя наводить порядок в этой папке руками параллельно с агентом, у меня есть отдельный разбор: [гигиена рабочей папки](/guides/gigiena-rabochey-papki-agenta).

## Куда уходят данные и что с этим делать?

**Главное**

Всё, что агент прочитал для ответа, обрабатывается на серверах поставщика сервиса. Настройки использования данных для обучения моделей у разных сервисов разные и описаны в их документации. Для документов под соглашением о неразглашении вывод один: это отдельное решение, а не техническая мелочь.

Тут заканчивается техника и начинается ответственность.

Когда агент открывает документ на сервере, содержимое уходит в обработку наружу. Это не побочный эффект и не дыра: без этого он не сможет с документом работать. Вопрос в том, что именно ты ему открыл.

На одном обучении реакция группы была показательной: у нас глобально всё под соглашением о неразглашении, мы им дышим. Для агентств, юристов и подрядчиков это норма, а не исключение.

**Что проверить до подключения**

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

Для персональных данных в России действует отдельный закон, и он не про нейросети, а про любую обработку. Разбирал этот угол подробнее в материале про [прототип, деплой и персональные данные](/guides/prototip-gotov-chto-dalshe-deploy-152fz).

## Файлы с ключами: почему запрет ставится первым

**Главное**

Ключи доступа и пароли хранятся в отдельном файле настроек, который агенту запрещают читать с первого дня. Запрет ставится до всякой работы и защищает от простой вещи: чтобы ключ не оказался в переписке, логах и истории.

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

Объясняю коротко. Когда ты подключаешь агента к почте, диску или сервису, нужен ключ доступа - длинная строка, которая заменяет логин и пароль. Хранят её не в переписке, а в отдельном файле рядом с проектом. Агент этот файл использует, но читать его ему запрещают.

Зачем запрет, если файл всё равно на твоём компьютере:

1. **Чтобы ключ не попал в переписку**

   Всё, что агент прочитал, он может процитировать в ответе. Ключ в переписке - это ключ, уехавший наружу.

2. **Чтобы он не попал в историю проекта**

   Файлы проекта фиксируются в истории изменений. Оттуда ключ достать проще, чем кажется.

3. **Чтобы его нельзя было выдать по ошибке**

   Ошибочный запрос вида «покажи все настройки» не должен приводить к показу секретов.

4. **Чтобы отзыв ключа был дешёвым**

   Если ключ всё-таки утёк, его отзывают и выпускают новый. Но узнать об утечке надо раньше клиента.

Важная деталь, которая успокаивает людей: агент не просит диктовать ему ключи в чат. Ты вносишь их руками в файл, он обращается к ним сам.

## Кто в компании принимает это решение?

**Главное**

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

Это самая неудобная часть ответа, и она же самая важная.

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

Порядок, который я советую:

1. **Сформулируй задачу в одну строку.** Не «хочу подключить нейросеть», а «хочу, чтобы агент читал папку такого-то проекта и готовил по ней сводку».
2. **Назови объём.** Какие папки, чьи документы, только чтение или запись.
3. **Принеси документацию сервиса.** Ответственному нужны факты про обработку данных, а не твой пересказ.
4. **Предложи ограниченный пилот.** Одна папка, один проект, месяц, отчёт по итогам.
5. **Зафиксируй ответ письменно.** Устное «ну попробуй» защищает ровно до первого инцидента.

Смежная тема - как вообще учить команду нейросетям, когда документы нельзя выгружать наружу. Разбирал её отдельно в материале про [работу с чувствительными данными](/guides/chuvstvitelnye-dannye-i-neyroseti-v-kompanii).

## Что делать, если разрешения не будет

**Главное**

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

Отказ - нормальный сценарий, и он не означает конец истории.

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

Что теряется: автоматизм. Каждый раз выгружать файлы руками неудобно, и часть задач так просто не решается.

Что остаётся: сама работа. Анализ, сводки, черновики документов, разбор больших массивов текста - всё это делается на обезличенной копии не хуже.

**Рабочее правило**

Начинай с обезличенной копии, даже если разрешение получил. Первые две недели ты всё равно учишься ставить задачи, и цена ошибки на копии равна нулю.

Кстати, самый продвинутый шаг, который я видел у участника обучения, был не про доступы вообще: человек собрал себе отдельный набор правил, который проверяет всё, что скачивается извне. Не по инструкции, а потому что понял логику.

## Частые вопросы

**Главное**

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

### Частые вопросы

**Агент увидит папки соседней команды?**

Только если их видишь ты. Он работает от твоей учётной записи и упирается в те же ограничения прав.

**Можно дать доступ только на чтение?**

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

**С почтой сложнее, чем с файлами?**

Да. В почте больше персональных данных и переписки третьих лиц, которые своего согласия не давали. Начинать лучше с папки документов, а не с ящика.

**Доступ работает, когда компьютер выключен?**

Прямой доступ через твою учётную запись - нет. Постоянная работа без тебя устроена иначе и требует отдельного размещения сервиса.

## Главный вывод

**Главное**

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

Ошибка, которая дорого стоит, выглядит не как утечка, а как обычная инициатива: человек подключил агента к рабочим документам, потому что так удобнее, и никому не сказал.

Правильный порядок обратный: сначала маленький объём и понятный сценарий, потом разговор с ответственным, потом расширение. Так ты не теряешь ни скорость, ни рабочий инструмент.

А если подключение сервисов для тебя пока тёмный лес, начни с материала про [MCP простыми словами](/guides/mcp-prostymi-slovami): там разобрано, как агент вообще получает доступ к внешним данным.

Открой список папок, к которым у тебя есть доступ на работе. Какую из них ты готов показать первой, если завтра тебя спросят?

### Источники

- [Федеральный закон «О персональных данных» от 27.07.2006 N 152-ФЗ, действующая редакция](https://www.consultant.ru/document/cons_doc_LAW_61801/)
- [Персональные данные - обзорная статья о понятии, Википедия](https://ru.wikipedia.org/wiki/Персональные_данные)
- [Anthropic Privacy Center - используются ли данные пользователя для обучения моделей](https://privacy.claude.com/en/articles/10023580-is-my-data-used-for-model-training)
- [Claude Code - раздел документации о безопасности и разрешениях агента](https://code.claude.com/docs/en/security)
- [Claude Code - документация об аутентификации и учётных записях](https://code.claude.com/docs/en/iam)
- [Model Context Protocol - обзорная статья о протоколе подключения инструментов и данных, Википедия](https://en.wikipedia.org/wiki/Model_Context_Protocol)
- [Claude Code - документация о подключении агента к внешним инструментам через MCP](https://code.claude.com/docs/en/mcp)