Безопасность AI-агента: как ИТ должен контролировать нечеловеческий доступ к бизнес-приложениям?

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

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

Почему доступ агента ИИ создает новые проблемы безопасности?

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

Автоматизация, но не так, как мы ее знаем:

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

От чтения бизнес-данных до действий на их основе:

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

Аутентификация не равна авторизации:

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

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

В его 2026 работа над программным обеспечением и идентичностью агента ИИ NIST подчеркивает необходимость решения вопросов идентичности, полномочий, аудита и ответственности для ИИ-агентов.

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

Какую идентичность должен использовать агент ИИ?

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

Посвященные идентификаторы и учетные данные нагрузки

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

Кроме того, это помогает различать автоматизированную активность и человеческую активность, применять специальные политики безопасности и отключать агента, не затрагивая доступ сотрудника, например, в Microsoft Entra Agent ID. Стремитесь к тому, чтобы агенты ИИ имели узкую область применения, были хорошо документированы и могли быть независимо проверены.

Делегированный доступ против автономного доступа

AI-агенты могут работать под различными моделями авторизации.

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

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

Примечание по MFA

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

Хотя многофакторная аутентификация (MFA) полезна для человеческого доступа, автономные механизмы идентификации рабочих нагрузок требуют поддержки. Некоторые примеры, в зависимости от приложения и инфраструктуры идентификации:

• управляемые идентификаторы,
• федеративные учетные данные,
• сертификаты
• или краткосрочные токены.

Как IT должен ограничить доступ AI-агентов?

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

Минимальные привилегии для приложений, инструментов и данных

• Разрешения инструментов: Какие API, скрипты, интеграции и инструменты выполнения может вызывать агент?
• Разрешения приложения : Какие бизнес-приложения и функции он может использовать?
• Разрешения на данные: Какие записи, папки, файлы или базы данных он может читать? Может ли он изменять?
• Системные разрешения: Может ли он выполнять команды, получать доступ к операционной системе или выполнять административные операции?

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

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

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

Доступ с ограниченным временем и чувствительные операции

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

Как безопасность AI-агента отличается в различных бизнес-приложениях?

Не каждое приложение предоставляет одинаковые механизмы для контроля доступа к ИИ. Команды ИТ должны адаптировать контроль доступа к своей среде и требованиям.

SaaS приложения и API

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

Хотя они могут сделать авторизацию агента более точной, разрешения API все еще могут быть чрезмерно широкими, поэтому администраторам следует проверять объем, ограничивать доступ и регулярно очищать разрешения.

Веб-приложения для бизнеса

Веб-приложения представляют собой различные проблемы с взаимодействием графического интерфейса.

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

Унаследованные приложения Windows и удаленные рабочие столы

Унаследованные приложения Windows представляют собой особую проблему, поскольку их средства управления доступом, как правило, были разработаны для человеческих пользователей, а не для автономных процессов.

Доступ

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

Безопасность

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

Механизм доступа	Основные меры безопасности	Основная забота
SaaS API	OAuth области, токены, роли API	Слишком широкие разрешения, неправильное использование токена
Веб-приложение	Сессии, роли приложений	Несанкционированные действия в действующей сессии
Опубликованное приложение для Windows	Идентификация Windows, назначение приложений, разрешения	Доступ за пределами запланированной задачи
Полный удаленный рабочий стол	права ОС, ограничения сеанса, ужесточение	Широкая экспозиция системы и латеральное движение

Какие риски кибербезопасности требуют дополнительных мер контроля?

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

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

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

Как ИТ может контролировать, отзывать и проверять доступ агентов ИИ?

Управление доступом неполно, если администраторы не могут определить, что сделал агент, или остановить его, когда его поведение становится неожиданным.

Отслеживание идентичностей, решений и действий

Полезная запись аудита: идентичность агента + ответственный владелец + запрашиваемая операция + одобрение + вызов инструмента + результатирующее действие + итог.

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

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

Отзыв доступа и реагирование на инциденты

Предопределите процедуру завершения работы для каждого развертывания AI-агента перед производством.

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

Вы можете включить следующее в практическую процедуру реагирования на "неправильное поведение":

• содержать доступ,
• сохранять журналы,
• исследовать изменения,
• заменить учетные данные
• и подтвердить, что несанкционированный инцидент завершен.

Что такое практический контрольный список безопасности для ИТ-команд с использованием ИИ-агентов?

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

1. Определите право собственности. Документирует его назначение, оператора/владельца, среду выполнения, инструменты и потоки данных.
2. Назначьте уникальную идентичность. Избегайте совместного использования учетных данных. Установите отдельную ответственность.
3. Карта и ограничение разрешенных ресурсов. Укажите необходимые приложения, записи, данные, системы, разрешения API, временные интервалы.
4. Ограничить чувствительные действия. Определите требования к одобрению и запретите изменения с высоким воздействием и ненужные привилегии.
5. Защитите учетные данные. Используйте поддерживаемую аутентификацию рабочей нагрузки и управляемые секреты.
6. Проверьте среду выполнения. Обзор изоляции сеансов, сетевого доступа и соответствующих настроек безопасности Windows.
7. Включить доказательства и восстановление: храните записи об аутентификации, выполнении инструментов, активности приложений и значительных изменениях.
8. Сценарии сбоя тестирования: подтвердить, что доступ может быть отозван, сессии завершены, а неожиданная активность расследована.

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

Как TSplus может помочь обеспечить безопасность доступа к приложениям Windows?

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

TSplus Remote Access: Доставка приложений и назначение

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

TSplus Advanced Security: Защита серверов Windows и сеансов

TSplus Advanced Security добавляет защиту Windows Server и сессий через защиту от грубой силы, географические ограничения, контроль рабочего времени, управление разрешениями, защиту от программ-вымогателей, уведомления и журналы событий безопасности.

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

Совместно соответствующие возможности TSplus поддерживают практический принцип: поддерживать контролируемый доступ к бизнес-приложениям и защищать Windows-среду за ними, оставляя администраторам возможность внедрять специфические для ИИ меры безопасности и оркестрацию там, где новые рабочие нагрузки требуют этого.

Заключение

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

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

Часто задаваемые вопросы

Что такое не-человеческая идентичность в безопасности агентов ИИ?

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

Как отличается идентичность агента ИИ от учетной записи службы?

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

Могут ли агенты ИИ безопасно получать доступ к устаревшим приложениям Windows?

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

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

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

Как могут администраторы ИТ отозвать доступ агента ИИ?

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